[Openicc] GSoC & oyranos

[Kai-Uwe Behrmann]

Am 03.04.09, 13:39 +0200 schrieb Cyrille Berger:
>> Can Shiva and CTL programms be automatically converted to OpenCL to get
>> advantage of its expected hardware support in LLVM [2]? This would relax
>> the need to care about OpenCL from user side - Krita, Oyranos ...
> When I started OpenGTL, my goal was to have the possibility to run Shiva and
> CTL on CPU and GPU, depending on what the hardware support. At that time my
> idea was to have a GLSL backend, since I haven't started, all options are
> still opeened :)

Ah, that is a point I did not really understand. So a library can add a 
(GPU) backend to LLVM at runtime? E.g. thus enabling GPU support in 
gallium3d while OpenGTL has no benefit?
So a (longterm) plan could be:
   CTL/Shiva -> IL -> GLSL -> IL -> GPU/CPU assembler code ?

>> Would this be an issue for a LLVM based convertor? Can or must CTL and
>> Shiva programms be optimised for OpenCL? I read LLVM has to convert to IL
>> anyway. But optimisation is not always an easy task.
> I am not sure about the question. Yes LLVM (or gcc for that matter) convert to
> a IL where the optimisation are done, and then a backend convert to assembly.
> As far as I can see, it's how gallium3D/mesa is going to do things, the
> OpenCL/GLSL front-end convert to LLVM's IL and then it's converted to
> something the GPU can handle (or the CPU). Which also means, that an other
> solution would be to hook OpenCTL/OpenShiva at the llvm part of the driver,
> this is less portable, and not sure if the llvm part will be visible.

... OpenCTL/Shiva as a LLVM frontend ?

>> How does you solve multi channel processing in OpenGTL if at all? Does you
>> simply split processing for non channel crossing operators? Or ist this to
>> be done by the user?
> Not sure what is you mean by channel ? You mean multi-threading ?

e.g. spectral data or Rgb/Cmyk + alpha + z buffer + UV + ???

>> What are your plans for OpenGTL? Do you plan a transition to OpenCL when
>> it will be available? Your suggestion to Yiannis above make me thinking
>> this is likely.
> I don't really have a definite plan. My suggestion about OpenCL vs GLSL was
> that in my opinion, GLSL is often used for what it wasn't designed for, it was
> designed to manipulate textures and vertexes, then people start considering
> that if you can manipulate textures, then you can do general computation, but
> since GLSL isn't designed for this, it's not convenient, and since there is a
> huge market, hardware manufacturer were interested in finding a better
> solution, that's where OpenCL comes. So my opinion on the subject is, GLSL is
> going to be deprecated for that kind of general computation, OpenCL is going
> to take its place, *but* we don't know when it will be available on linux
> (either proprietary drivers or open source drivers).
> On a side note, we don't know when OpenGTL will be able to run on GPU, it's
> definitively on my todo list, but it's not on the top, and I (or anyone else)
> haven't started anything on the subject.

So we should have suggested a additional OpenGTL/LLVM/(OpenCL/GLSL) GSoC 
project ;-)

Well there is the ILM CTL implementation, which deploys some GPU support. 
This would allow single users to hook that as backend into Oyranos, at 
least for CTL.


best regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org