Hello WCG.
Attention: Wilgard
Reference: Wilgard [Jan 17, 2011 2:00:35 PM] post

Greetings

I guess that the specific website using a GPU should be consulted if their WU-crunching executable designed for a discreet GPU would continue to work under Sandy Bridge (SB). Given what I have read thus far from a number of hardware-review sites about the graphics-processing capabilities of SB, I seriously doubt if they would find an incentive to support SB. Of course, IF any given executable targeting a GPU through DirectCompute, OpenGL and OpenCL would work unchanged using SB, fine (but that is a very big IF), just don't expect the kind of performance possible with a discreet GPU.

Another thing is that the graphics-processing part of SB targets mainly video processes. To the extent that the underlying silicon logic can also be used by GPU-using WU (WorkUnit), then SB has the potential to do more performance than a CPU-using-WU targeting CPU only (But, the WU code needs to be re-written); and, I'd say, decidedly less performance than a GPU-using-WU targeting discreet GPU only (So, why bother to rewrite the code to address SB?).

Good day
;

Thanks, andzgrid and skgiven.

I didn't want to say discouraging things about Sandy Bridge because it might make me seem like an anti-GPU curmudgeon. But I am glad that other people have pointed out that Sandy Bridge is intended for fast execution of video codecs and perhaps a few photoshop-style applications that are programmed for this type of GPU. It looks like a bad fit for most GPU distributed projects.

Lawrence

Boinc does not support Open CL because Boinc is just a conduit for the apps; it'€™s the apps that can or cannot support the various OpenCL capable processors. Some apps such as those of MilkyWay already support OpenCL, demonstrating that Boinc is not a hurdle here, however success is not guaranteed (Aqua tried but gave up due to poor performance).

Until OpenCL programming and support matures take-up will probably be limited, and I cannot see projects being attracted to utilizing the 6 or 12 shaders on a very specific CPU/CPU. Especially if it means writing 32bit only apps using an Intel OpenCL SDK, and more so considering the chipset restrictions (you can either overclock the top Sandy Bridge (SB) processors or use the shaders, but not both).

Some questions worth asking are:
Does Intel'€™s SB support OpenCL well enough for it to be immediately (or easily in the near future) usable with existing OpenCL apps?
If so, would using it expedite any projects (is it faster), or slow them down?
If not, what would need to be done to the apps to use these 12shaders?
Would this be a worthwhile project, facilitating one CPU type?
Would OpenCL take away from the CPU to the extent that it would make the efforts not worth while?
I ask this because OpenCL tends to be CPU burdensome and also slower than conventional GPU apps such as CUDA. To try to utilize 6 or 12 limited shaders at the expense of 8 high end CPU threads might not make any sense to any project. Alternatively, it might be possible for one or two projects to add OpenCL support at some stage to allow some users to expedite parts of some tasks. My guess is this will not happen any time soon, even if possible.

In the future, when more powerful CPU/GPU combo processors are around, it is likely that OpenCL will become much more widespread, but I don'€™t think that even a 48 shader CPU/ GPU chip will ever replace the top PCIE GPU'€™s or come close to matching them for ability. It might only be a move to this size (from a 6/12 shader entry level GPU to mid range GPU) that would bring in the droves of crunchers to make the efforts worthwhile. I guess this is some way off and I cannot see the competition (ATI and NVidia) not having an answer to any mid range GPU challenge, so even then the uptake might not occur.