OSNews: http://www.osnews.com/story/21963/AMD_Does_Reverse_GPGPU_Announces_OpenCL_SDK_for_x86 Exploring the Future of Computing en-us Copyright 2001-2013, David Adams adam+nospam@osnews.com Wed, 19 Jun 2013 12:48:32 GMT http://www.osnews.com/images/osnews.gif OSNews.com http://www.osnews.com Who's on first? http://www.osnews.com/thread?377626 http://www.osnews.com/thread?377626 This competitive stuff is fun! Fri, 07 Aug 2009 03:40:00 GMT donotreply@osnews.com (Tuishimi) Comments Really AMD? http://www.osnews.com/thread?377673 http://www.osnews.com/thread?377673 OpenCL for the CPU earlier than for the GPU?

At least NVIDIA already has a working OpenCL developer release for their GPUs, you know the intended target audience of the system. Bah... Fri, 07 Aug 2009 17:06:00 GMT donotreply@osnews.com (tylerdurden) Comments RE: Really AMD? http://www.osnews.com/thread?377711 http://www.osnews.com/thread?377711
OpenCL for the CPU earlier than for the GPU?

At least NVIDIA already has a working OpenCL developer release for their GPUs, you know the intended target audience of the system. Bah...


So does AMD. Just go sign up and download it.Edited 2009-08-08 00:08 UTC Sat, 08 Aug 2009 00:08:00 GMT donotreply@osnews.com (tyrione) Comments RE[2]: Really AMD? http://www.osnews.com/thread?377746 http://www.osnews.com/thread?377746 .... to be fair NVIDIA has had the opencl sdk available for developers for a while, whereas ATI just released theirs (which brings down our linux devel system for stream really hard, so it seems they are not ready for production yet... so this x86 opencl release seems to be a stopgap to not keep developers waiting) Sat, 08 Aug 2009 15:23:00 GMT donotreply@osnews.com (javiercero1) Comments But I thought... http://www.osnews.com/thread?377751 http://www.osnews.com/thread?377751 ...the purpose of the GPU was to offload some work from the CPU? I understand that this would be good for mini/micro systems - where GPU is limited. Would this help them work together in some way - act like a multi-processor GPU? That would be nice - maybe preprocess the commands before popping the results off to the GPU for final calculation and rendering. Sat, 08 Aug 2009 16:15:00 GMT donotreply@osnews.com (Tuishimi) Comments RE: http://www.osnews.com/thread?377756 http://www.osnews.com/thread?377756 OpenCL is a lot more than just a GPU accelerator for code; it's designed to be a system where the code you write can run on CPUs, GPUs and other accelerator cards without you having to do any other work. It also maximizes performance and threading usage for compute tasks running on the CPU. Sat, 08 Aug 2009 19:35:00 GMT donotreply@osnews.com (grabberslasher) Comments Comment by malkia http://www.osnews.com/thread?377807 http://www.osnews.com/thread?377807 I've "ported" the nvidia nbody sample from their OpenCL package, to the AMD cpu based one.

I can't comment on NVIDIA OpenCL benchmarks as I'm under NDA, but compared to the same CUDA sample it was 1.3GFLOPS for AMD/OpenCL (CPU) vs. 28GFLOPS CUDA (can't comment on NVIDIA OpenCL). Though I need to test again

MacBook Pro (MacBookPro3,1)
Intel Core 2 Duo 2.6 Ghz, 1 Processor, 2 cores, 4MB L2 Cache, 4GB Memory, Bus Speed 800Mhz
GeForce 8600M GT (PCI-Express x16 width) 256MB

Bootcampe'd Windows XP 32 bit Service Pack 3 using 190.38 nvidia drivers (bit modified to install on the 8600M - thanks to laptop2go)

That to be said, CPU based OpenCL is exactly what we need. There are lots of servers, where graphics cards are not present, also if you have Remote-Desktop'd into such machine, the graphics driver is replaced and you can't use CUDA (won't comment on OpenCL). VNC is too slow for solution (maybe only HP RGS). And OpenCL would be there for the PS3 SPE's...

The beauty of it, is that it offers a more restricted "C"-based language, where you can still program normally (not an assembler), but it would still run efficiently. From that perspective, you can forget all your worries about using C++ as dominantly performance language (through boost, and other template libraries), and use your favourite high-level language (javascript, C#, java, lisp, rub, python, perl, etc.) as long as it has some form of freezing foreign array data (e.g. the garbage collector should not move it) and accessing it later.

Put the management decisions of what work need to be done in the high-level language (it would be easier to organize such tasks there), and then write directly the low-level workers in OpenCL - most likely all OpenCL implementations would always have the compiler loaded so you can even change on the fly, instead of recompiling - much like GLSL in OpenGL.

It would take quite time to catch on, but I think it might hit the sweet spot. Sun, 09 Aug 2009 20:56:00 GMT donotreply@osnews.com (malkia) Comments RE: Comment by malkia http://www.osnews.com/thread?377871 http://www.osnews.com/thread?377871
I've "ported" the nvidia nbody sample from their OpenCL package, to the AMD cpu based one.

I can't comment on NVIDIA OpenCL benchmarks as I'm under NDA, but compared to the same CUDA sample it was 1.3GFLOPS for AMD/OpenCL (CPU) vs. 28GFLOPS CUDA (can't comment on NVIDIA OpenCL). Though I need to test again

MacBook Pro (MacBookPro3,1)
Intel Core 2 Duo 2.6 Ghz, 1 Processor, 2 cores, 4MB L2 Cache, 4GB Memory, Bus Speed 800Mhz
GeForce 8600M GT (PCI-Express x16 width) 256MB

Bootcampe'd Windows XP 32 bit Service Pack 3 using 190.38 nvidia drivers (bit modified to install on the 8600M - thanks to laptop2go)

That to be said, CPU based OpenCL is exactly what we need. There are lots of servers, where graphics cards are not present, also if you have Remote-Desktop'd into such machine, the graphics driver is replaced and you can't use CUDA (won't comment on OpenCL). VNC is too slow for solution (maybe only HP RGS). And OpenCL would be there for the PS3 SPE's...

The beauty of it, is that it offers a more restricted "C"-based language, where you can still program normally (not an assembler), but it would still run efficiently. From that perspective, you can forget all your worries about using C++ as dominantly performance language (through boost, and other template libraries), and use your favourite high-level language (javascript, C#, java, lisp, rub, python, perl, etc.) as long as it has some form of freezing foreign array data (e.g. the garbage collector should not move it) and accessing it later.

Put the management decisions of what work need to be done in the high-level language (it would be easier to organize such tasks there), and then write directly the low-level workers in OpenCL - most likely all OpenCL implementations would always have the compiler loaded so you can even change on the fly, instead of recompiling - much like GLSL in OpenGL.

It would take quite time to catch on, but I think it might hit the sweet spot.


You might want to retest that code because I'd imagine the GFLOPS between your Macbook Pro and the 8600GT will differ wildly as well.

More to the point, you didn't actually mention the ATi card you tested against. Mon, 10 Aug 2009 07:02:00 GMT donotreply@osnews.com (tyrione) Comments RE[2]: Comment by malkia http://www.osnews.com/thread?377873 http://www.osnews.com/thread?377873
More to the point, you didn't actually mention the ATi card you tested against.

He didn't test against an ATI card. "to the AMD cpu based one." and "for AMD/OpenCL (CPU)" should be hints. Mon, 10 Aug 2009 07:40:00 GMT donotreply@osnews.com (MamiyaOtaru) Comments RE[2]: Comment by malkia http://www.osnews.com/thread?378035 http://www.osnews.com/thread?378035 I said 8600M GT, not 8600GT Tue, 11 Aug 2009 10:22:00 GMT donotreply@osnews.com (malkia) Comments