[Openicc] GSoC & oyranos

Cyrille Berger cberger at cberger.net
Wed Apr 1 13:51:06 PDT 2009


On Wednesday 01 April 2009, you wrote:
> Yes, I understand that.  For some reason I have doubts that the
> performance when using OpenCL to execute on the native CPU (as a
> fall-back) will be up to snuff as compared with code which is
> carefully optimized to execute on the native CPU.  If OpenCL is
> optimized for certain CPUs, then other CPU types will suffer as a
> result.
I am very doubtfull of that, I would need to see benchmarks of that. In my 
benchmarks of JITed code (using the CTL language) vs native code, both of them 
were performing about the same. As in C/C++ you can write 
optimized/unoptimized code with CL.

> Regardless, there are server (or diminished privilege) execution modes
> which should certainly benefit from use of a GPU if the execution
> model could safely support it.  Quite often the originator of the
> request is not fully trusted or is not trusted at all.  I think that
> it is safe to say that these execution modes are almost as common as
> the dedicated-user modes, even on "single user" type systems.

I don't feel qualified to speak about security implications of using GPU. I 
have seen some people claiming that you could write a GLSL virus, but I found 
the explanation a bit moot since you still needed some code outside the GLSL 
for loading it into the GPU. I know that they don't have the possibility to 
access other system ressources, what I am not sure is wether they can access 
ressources from other kernel running on the GPU. That said, I don't think an 
administrator of a web server should let the users run arbitrary CL kernel on 
the GPU of the server.

> Examples would be printing system drivers, web-based photo albums like
> "Gallery", or large image posting sites like Flickr.  All of these
> applications may benefit from color management.
>
> OpenCL is currently being pushed by vendors interested in promoting
> their proprietary hardware and proprietary systems. 
Huh ? OpenCL is now an open standard from the khronos group (the same guys 
behind OpenGL), which is indeed supported by most hardware vendors, but then 
we are speaking GPUs there, so at some point you have to use the hardware from 
those proprietary vendor. Nvidia's CUDA and the ATI/AMD's MetalWhatever thing  
where proprietary technologies that are now deprecated in favor of OpenCL.

> I am unable to find an open-source OpenCL implementation or any actual
> project to produce an open-sourced free OpenCL implementation. 
Mesa has an initial implementation of OpenCL.

> It took ten years for OpenMP to finally be supported by GCC. 
I think the main reason is that OpenMP doesn't bring much to anyone, the 
performance boost is minimal to what you can get with proper multi-threading.

> In the time it takes for
> OpenCL to be independently implemented so that it can be used in Linux
> and *BSD the CPU vendors may very well have integrated GPU
> capabilities, with full compiler support.
Well that's what OpenCL is for... GPU has a very specific design, you can't 
expect to run the same type of program on a CPU on a GPU, you have to write 
your code in a specific way, and bend to the graphics pipeline, that's what 
OpenCL provides for you.

-- 
Cyrille Berger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/openicc/attachments/20090401/c0c633a2/attachment.htm 


More information about the openicc mailing list