OpenCL (Open Compute Library)

I didn't assume you was an idiot. You said you see "aboslute no value" in OpenCL supporting CPU, that leads to all these discussions. I don't agree with what you said all along.

 

To be exact, I said this:
"Seeing as the main point of writing massively parallel code is performance, I don't see myself ever using OpenCL on anything that is not a massively parallel architecture. So at this point I see no use for OpenCL outside GPUs."

So I was speaking about 'now', and about my own preferences/experiences, not anyone else's. Nothing different than what was said in the past few posts.
Clearly I left room in my statement for future CPU architectures that will deal with massive parallelism in a better way.

 

Because I see value in writing opencl code now as it will be far far more maintainable and (easier to hack) while (performance) porting across myriad architectures.

Agreed, you have use longer than I have. But I see value in it that you don't see right now. Let's see where we both stand after 5 years.

I say, you'd come around.

 

Doesn't mean I see the same value. I was merely speaking for myself.

There is no 'coming around'. I already see value in OpenCL, and I've already decided to move from Cuda to OpenCL... which is now complicated because I got DirectCompute to work with, and the first impression was better than OpenCL so far.
But I have nothing against OpenCL, I've already used it, and will continue to use it... it's just that I think people are overhyping it (then again, it IS an Apple initiative, so what do you expect? ).

 

Agreed, although I think every language in this space has been over-hyped (except perhaps, ironically, ComputeShader), with OpenCL being one of the lesser evils that pales in comparison to the marketing around CUDA.

 

First real ocl/gpgpu noise from AMD,

http://gpgpu.org/developer/ppam2009

I expect a lot more of this after 22nd.

 

I'd like to read your opinions on the flaws in the memory model. I have my doubts, but I think your opinion is worth more...

I know that you generally want a higher-level of abstraction, but I'm curious about your thoughts on the flaws, before considering what kind of abstraction is useful.

Jawed

 

Oh my goodness, do Marco and I agree on flaws in the OCL memory model too? This thread is blowing my mind.

(probably not, I bet he hates CUDA too )

 

I won't speak for Marco, but I think both of them have a long way to go...

While it has its own problems, I still maintain that Sequoia was a step in the right direction here. We're trying to specify data locality here, not micro-manage the memory controller in one GPU architecture.

Still, I think we'll eventually get there. I'm just hoping we don't accumulate too much crufty code written against one architecture that doesn't scale to future hardware in the mean time.

 

Ah Sequoia. Lots good things there, and some bad. I think the memory model was good, but it did limit the applications you could run (only regularizable) and the communication semantics (i.e. no in-place synchronization, but for good reason). But, I know there is work at Stanford to make the model more flexible while trying to maintain much of the goodness.

 

We have been making noise since GDC 2009 in March
For instance http://techreport.com/discussions.x/16640
We have also made speeches about OpenCL at other conferences.

PPAM09 was fun. Lots of people came to the tutorial and the crowd at my later keynote was really big (compared to the overall size of the conference).

I would dare to say that scientific community is very interested in OpenCL.

 

Does Intel plan to adopt OpenCL, or will they introduce another proprietary API (like CUDA) for LRB?

 

They support OpenCL, but on the other hand they have their Ct for Larrabee and Sandy Bridge.

 

As long as they keep their underlying technology to implement the underpinnings of their OpenCL tech (nVIDIA's OpenCL support likely takes a lot of advantage from their CUDA support), it should not hurt OpenCL.

 

Im not reading all the SDK documentations. But maybe someone can answer for me. I downloaded opencl-z from sourceforge and dropped the exe in the ati-stream-sdk folder with opencl.dll. It wouldnt work.
Checking the project files on sf.net with ViewVC showed references to some cuda directories with the dll (i suppose).
Sooo, what if i have an old g92, larrabee and an AMD processor? or intel CPU & amd GPU? Must I install the drivers for each one? Will they cooperate? Or must i choose a single driver?
What about OSX? Linux? There isnt a system wide dispatcher that registers different drivers and makes them work together, isnt it?
AMD's driver will be good for their GPU & SSEx CPU. Nvidia's driver for their GPUs (and SSEx? iirc cuda can output x86). Intel driver is a mistery, larrabee most likely. Will intel CPUID block amd cpus? or just optimize for their uarch and amd be damned?
I see (developer & user) pain ahead.

 

What you describes is the platform issue. This is a non-issue on MacOS X because Apple is taking care of all these issues (all OpenCL devices appear in the same platform provided by Apple). However, on other OS there'd have to be a similar common platform, otherwise different OpenCL devices wouldn't be usable in one program.

AFAIK the major backers of OpenCL has been talking on this issue but there're no public information released for Windows or other OS yet.

 

NVIDIA OpenCL drivers are publicly available now:

http://developer.nvidia.com/object/get-opencl.html

 

No double precision in OpenCL "soon"

http://forums.amd.com/devforum/messageview.cfm?catid=390&threadid=119492

It still amazes me that developers are expected to roll their own double-precision functions for common math that is anything but MUL, ADD or DIV, almost 2 years after RV670 arrived.

And now we find that OpenCL is a no-go zone for DP on AMD GPUs for the foreseeable future.

Jawed

 

Bad, Bad AMD

 

It will get there, it just takes some time. Note that I don't believe anyone's CPU OpenCL implementation supports double at the moment either, or any OpenCL implementation for that matter. Passing the math tests to the precisions required by the spec is challenging.