[Openicc] GSoC & oyranos

[Cyrille Berger]

On Saturday 04 April 2009, you wrote:
> 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 ?
In fact either, CTL/Shiva -> GLSL -> IL -> GPU or CTL/Shiva -> IL -> CPU / 
GPU. There is little point in doing IL -> GLSL (while probably possilbe, there 
is a IL -> C backend, it can only produce brain damaged 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 ?
It's allready the case.

> >> 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 + ???
Well basically, neither CTL nor Shiva knows anything about colors, it's low-
level stuff. I indeed consider that the meaning of channels is something that 
need to be known at the next layer (in oyranos, or koffice's pigment, or in any 
other CM aware library).

> So we should have suggested a additional OpenGTL/LLVM/(OpenCL/GLSL) GSoC
> project ;-)
Maybe, but my feeling is that this year was/is too early for this.

> 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.
There is no support for GPU in AMPAS's  CTL implementation at the moment.

-- 
Cyrille Berger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/openicc/attachments/20090405/e59bf72d/attachment.htm