I gave up on the 9.12 drivers, I managed through some vnc trickery to a single display up in crossfireX mode, and 2 GPUs were "visible", but judging from the performance, it looked like it really was just a single GPU.
Jumping through the hoops, I reverted to 9.10 - which gives me good dual GPU performance, but alas no OpenCL or evergreen IL instrutions.
What is most frustrating (apart from the time wasted on this exercise) is the near total lack of proper feedback channels. I work as a SW developer, and understands that bugs and regressions happens, but if bugs are not reported back to the developers, it is also impossible for them to be fixed.
We have developers monitoring these forums and we also have email@example.com for emails. The OpenCL runtime does not load balance between multiple GPU's so you have to access them seperately. Try exporting the environment variable GPU_DEVICE_ORDINAL to select which card you want to execute on. Another method is to use the DISPLAY environment variable. For example if you want to execute on display0 but device 1 instead of device 0, export DISPLAY=:0.1 will do so.
Originally posted by: MicahVillmow frankas,Try exporting the environment variable GPU_DEVICE_ORDINAL to select which card you want to execute on. Another method is to use the DISPLAY environment variable. For example if you want to execute on display0 but device 1 instead of device 0, export DISPLAY=:0.1 will do so.
I haven't gotten around to writing any OpenCL code yet (part from some old Windows code that had performace issues on the beta) So I just tested my 2 brook programs. In CrossfireX mode only a single desktop is available, so setting the DISPLAY isn't much help. I set the BRT_ADAPTER on one of the programs, but the performance was pretty much 50% of what I get running on two cards, similarly my other progrem calls brook:::useDevice from seperate threads, and although it supposedly schedulde jobs to two devices, the resultant performance indicated that only a single device was in use.
I suppose that this problem resides at the CAL / driver level, and don't expect it to be any different using OpenCL.