Well it works on AMD CPUs also, it doesn't work on Intel GPUs, as Intel iGPUs don't even have OpenCL support. So the only GPU acceleration it works with is nVidia. Why? Just because Cycles uses giant monolithical chunks of code to push through to the GPU, using the same calls for OpenCL that were used for CUDA, in other words, Cycles is not very optimized for OpenCL, because nVidia isn't performing well in OpenCL, so Cycles implements the least interesting OpenCL GPU acceleration, but not the much stronger OpenCL technologies? OK... Second thing... show me where AMD doesn't implement the OpenCL API perfectly according to the specs... well, you can't, because AMD has implemented everything just right, and they have toolkits available for free that enables application devs to easily implement the full spectrum of OpenCL acceleration. The Cycles devs only use a small and very particular part of OpenCL calls that happen to work on nVidia cards because they are just a translation of the CUDA calls.
The only long term solution for this that would really benefit GPU acceleration in Cycles, is if Cycles recodes their system to split up the instruction codes into smaller chunks that are optimized for OpenCL. They're going to have to do it anyway to keep up with evolving technology, because nVidia is going to implement OpenCL to the full extent like AMD anyway. Proof of this is that they've contributed code to the OpenMP/OpenACC projects, thereby following AMD and Samsung in that direction, in order to upgrade their OpenCL capabilities, which are, quite frankly, hugely sub-par for the moment, which is holding them back from adopting GP-GPU scaling.
Cycles is a small open source project, it may well be that they don't have the energy to rewrite all of their stuff, and then another renderer will become more popular, just like it always goes in open source: the best solution wins. And to be very honest, I think that's exactly what's going to happen, Mac Pros have AMD solutions because of the much better OpenCL performance now, and they are used a lot in the creative sector, Apple is probably just going to issue a recommendation to use another renderer, possibly help development of a more suitable solution. It's going to be sorted out fast, but not by AMD, because AMD has done nothing wrong, I don't want to criticize the Cycles devs, they have made a choice based on a driver situation from the past, and always wanted to support the commercial closed source platforms, which is part of why they have become so popular, but they have to recognize that some of the choices they've made don't stand the test of time, nor the test of open source programming standards, and they either adapt, or become less relevant.
So the real problem with your earlier wall of text was that the premiss was wrong: the AMD drivers are in fact better for OpenCL than nVidia drivers, as they provide better OpenCL support, the real problem is the implementation of Cycles, which is not optimized for full OpenCL acceleration. Instead of claiming that the AMD OpenCL drivers aren't any good, which is just wrong because they are by far the best OpenCL implementation of any GP-GPU solution out there for the moment, you could have posted that Cycles doesn't do well with OpenCL, which would be a more correct statement, and ask the forum if they knew of a renderer that would implement OpenCL acceleration technology better...
