Ocelot

[Frizz]

This technology sounds interesting. Has somebody already tried it?

"Ocelot is a modular dynamic compilation framework for heterogeneous system, providing various backend targets for CUDA programs and analysis modules for the PTX virtual instruction set. Ocelot currently allows CUDA programs to be executed on NVIDIA GPUs, AMD GPUs, and x86-CPUs at full speed without recompilation."

[EDIT] I more and more get the impression that NVIDIA wants to kill off support for OpenCL - and push CUDA. Will be interesting to see what happens when Apple swings (back) from AMD to NVIDIA.

[Jason G]

Ocelot looks interesting.  Where difficulties come into play with heterogenous type applications, is the design tends to be quite high level by nature, so can be tricky to factor in microarchitectural optimisations where they are needed.  It'll be interesting to see how such toolsuites evolve to deal with that effectively, in order to make programs not just work, but work efficiently on the diverse range of hardware they are meant to support.

[EDIT] I more and more get the impression that NVIDIA wants to kill off support for OpenCL - and push CUDA. Will be interesting to see what happens when Apple swings (back) from AMD to NVIDIA.

I'm not so sure about that, as they've but a lot of work into the underlying driver & library frameworks to get this far, and are a major contributor to the Khronos Group.  Cuda's definitely more mature, and some aspects of OpenCL are still to mature, and so are subject to rapid change.  But at the same time elements of the underlying infrastructure are seemingly converging to the point that Cuda & OpenCL share more than the visual semantic difference would suggest. 

Jason

[Frizz]

afaik NVIDIA OpenCL 1.1 drivers are still pre-release.

AMD is about to release 1.2

That's (one of) the reasons why I assume NVIDIA focues on CUDA rather than on OpenCL.

[Jason G]

That's (one of) the reasons why I assume NVIDIA focues on CUDA rather than on OpenCL.

Sure, they're 'Cuda cores' after all, but I reckon that priority focus is different to wanting to 'kill off support for' what is supposed to be a cross-vendor language.  As it stands, as far as I've been told, Raistmer's code only uses OpenCL 1.0 features at the moment, with existing feature deprecation & apparently driver bugs being bigger issues than added language extensions being unavailable.   I guess if he finds something useful in 1.1 or 1.2 then it might become more pressing an issue. 

 I myself have been scratching for a way to implement GPU callbacks in Cuda like OpenCL 1.1 has, and only recently came across the separate Cupti api in later SDKs. So it goes both ways with feature migration, making the technologies complementary rather than diametrically opposed.

Jason

[Raistmer]

I read OpenCL 1.1 spec completely recently and found that these callbacks more resemble interrupt handlers than anything else.
They should be so small that even "heavy OS services"calls are no-no. No blocking OCL calls from callback also. (So to assign flag readback in callback not possible until there is another callback and, ultimately, event-waiting or blocking read in main thread). Looks like the single useful move could be to change blocking read to non-blocking read and then blocking on event, just as workaround. Will see if these callbacks will be useful in some other area.

P.S. I found much more useful feature in OCL 1.1 than callbacks IMHO: subbuffers and rectangular subbufer read. This can be directly applied to my way of gaussian handling, should be optimization step (when current driver issues will be resolved).

[Jason G]

Yep, looks like some handy stuff.  Hopefully the technology changes will settle down for a little while & becomes stable.