Khronos Releases OpenCL Spec
kpesler writes "Today, the Khronos Group released the OpenCL API specification (which we discussed earlier this year). It provides an open API for executing general-purpose code kernels on GPUs — so-called GPGPU functionality. Initially bolstered by Apple, the API garnered the support of major players including NVIDIA, AMD/ATI, and Intel. Motivated by inclusion in OS X Snow Leopard, the spec was completed in record time — about half a year from the formation of the group to the ratified spec."
Only when I can get it.
"Slow Down Cowboy!" indeed!
...but does it run Linux?
is this simply a spec that people expect ati and nvidia to conform to? or is this another api outside of CUDA and CAL, that wraps the two up so that a single api can execute code on all GPGPU's?
portfolio
There's no way I'm writing a single line of CUDA code when it only works with nVidia hardware, and I think there are a lot of other people like me. This could open up GPGPU programming to a much wider group of programmers.
While I see quite a few members that I wasn't expecting (Creative Labs), my concern is that there are some companies that should definitely be participating in this but aren't.
By that I mean gfx chip makers such as Via or S3, as for now it seems we're tied to the major players (nVidia, AMD, Intel) for desktop/laptop implementations and that's never good for the consumer.
Either way the spec itself is a great initiative and I can't wait to get my hands on beta bulids of Snow Leopard to try it out...
Now, if only they could do the same for OpenGL... Which is needed by a lot more people, and is in my opinion a lot more important for anyone who wishes to be free of Windows.
I don't think redundant means what you think it means ;)
Looking at http://www.khronos.org/registry/cl/api/1.0/cl_gl.h ,they are using the CL prefix.
This will cause a huge headache for existing code that uses the ClanLib SDK.
http://clanlib.org/docs/clanlib-0.9.0/reference/modules.html
Do the other major players for SIMD (or SIMT as NVidia has it) systems also sign on?
I would like to know if code written in OpenCl will be able to use cell processors or other multi thread systems just as easily.
Actually I'm glad to hear this. With IGP and Crossfire/SLI with dual-GPU in a quad arrangement. One could have an inexpensive (relatively speaking) supercomputer under their desks. Throw in the upcoming quad-core in 45nm fabrication and now is a good time to be into computers.
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
I wouldn't know whether to mod you insightful, funny or off topic. You are all three!
I wish Khronos would put some effort into their OpenVG stuff because that is something that is really needed badly. Cairo is not a worthwhile substitute because its performance is not very good, the API is too big (and it sucks), and Glitz is too complicated/buggy.
Currently there is no decent and complete free OpenVG implementation. The reference implementation is slow, ShivaVG is incomplete and appears dead, that Qt version requires Qt, ginkoVG doesn't support OpenGL, etc.
they just have been integrated into the main chip
by 486 era if I remember correctly.
By that time they had enough transistor to just put everything inside the same silicon chip, faster, cheaper.
Today, every CPU have an IEEE floating point unit.
To say we don't have maths co-proc is misleading.
Now, work on getting double-precision.
Anyone know how long we have to wait for an OpenCL enabled driver from nVidia or ATI?
OpenCL code is a subset of c, with an API that the GPU must implement. So it will work on Cell (or any CPU) with gcc and a library implementing the API.
Do you even lift?
These aren't the 'roids you're looking for.
VLC is fine if you don't care about preserving the quality of the format, or if you're too braindead to install proper codecs. Or if you want your integrated subtitles to look like shit, unless you run a nightly build with a few tweaks.
Honestly, I've found that Zoom Player's codec downloader and auto-configured silent install work the best for everyone, from the common person to the hardcore encoder to the obscure format enthusiast. Its a nice little stand-alone exe that, when run, will actually update your codecs too if you don't have the newest version.
http://www.mediafire.com/?emxigti2dwh
The hard-working people of the REAL open source codec scene (ie none of the ones you mentioned) are who I want to look at this.
Why are all HPC languages targeting the GPU pretending that compiler technology stopped with C? I can understand wanting the low-level control, but not always. How about some higher level constructs to encapsulate the often repeated GROUPSIZE, group_id, local_id logic?
There's only one way of accessing memory that performs - so make the compiler enforce it, unless I explicitly want to use low-level API to do something fancy.
Plugins for ffmpeg or any other codec for that matter could provide a huge boosts for linux. What about blender or yafray support.
There would be a huge uptake of Linux for video editor and 3d graphics artists.
CUDA on ATI can't be done easily.
As a writer of CUDA code, I can tell you that a lot of CUDA isn't as high level as nVidia's marketing would like you to believe. And thus is very much linked to specific properties of the current hardware from nVidia.
The lower-level of CUDA enables the programmer to do some really clever optimisations. But as the hardware peculiarities aren't abstracted away, writing a compatible implementation for chips from a different manufacturer which aren't exactly the same underneath isn't trivial, even if the specifications of CUDA *are* published.
On the other hand, the Brook language is a really a high level language which completely abstracts the details of hardware implementation. The BrookGPU implementation supports several back-end, including en OpenGL + GLSL back-end which as well on GPUs from both ATI and nVidia.
Though I didn't follow the latest development since ATI hired the main guy to write Brook+ for them.
Because it is supposed to be vendor neutral, OpenCL looks promising too, but I haven't read the specifications yet.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
You think we could get this little bugger working on Linux (and BSDs, etc) then?
http://www.leadtek.com.tw/eng/tv_tuner/specification.asp?pronameid=447&lineid=6&act=2
It looks very nice, being a 4-core Cell CPU on a card with 128MB of XDR. PCIEx1 (it's too bad I can't find PCIE splitters/risers...) and half-height but it uses a fan (I'm sure we can fix that. heh.) so it's almost the right card for a mythTV backend (or combo, or frontend since it can decode video).
It would also be nifty for those of us who like to do... "creative" programming.
But leadtek hobbled it, with drivers only for XP and Vista and requiring their bloatware to go with.
The Cell architecture is mentioned in the intro section of the spec as an example of what OpenCL might be good for. The language is generic enough that most any vector processor should work as a target.
I cannot express how disappointed I am by OpenCL. Take CUDA, add some levels of overengineering and make it unusable like OpenGL.
CUDA is far from perfect, but to a certain degree free of hassles: Get your memory with cudaMalloc(), write a __global__ function, and launch it. Done.
Things that can be done with 5 lines of CUDA now need 3 pages of OpenCL setup code. Its not rocket science, but very annoying to do and I really hope CUDA will stay for a while.
Sorry for the self reply.
Because it is supposed to be vendor neutral, OpenCL looks promising too, but I haven't read the specifications yet.
I did read the OpenCL specifications afterwards, yesterday night. Call me crazy, but that's the field I'm currently working in.
OpenCL *is* very promising, indeed.
It's not quite that different than CUDA.
And now the best parts : It is definitely vendor-neutral.
In short, I personally think that OpenCL is like CUDA, done better, although at a slightly lower level.
That leaves us in GPGPU world with OpenCL as a very powerful low-level API.
And several systems like Brook and RapidMind which can take advantage of it to expose a much more abstracted high-level environment.
Now all we need is Python & Perl bindings and syntactic sugar.
And an OpenCL frontend to the Gallium3D linux driver stack.
Both of which will probably happen really soon.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Oddly the XBMC folks have found that a 3ghz DUAL CORE CPU - Intel - is what it takes to do high bitrate HD video. So I'm sorry to burst your bubble but some GPU help would certainly be helpful! I'll agree that encoding takes far longer but playback shouldn't require such beefy hardware either and encoding need only be done once as opposed to DEcoding which happens on every user's machine who wishes to see the content. Have you looked at the sorts of speed-ups the NVIDA code has been giving? When you see a more than 50% drop in CPU usage I'd say that's pretty significant - sadly it seems to be both manufacturer and worse profile dependent...
Build it, Drive it, Improve it! Hybridz.org