[Openicc] GSoC & oyranos

[Cyrille Berger]

On Friday 03 April 2009, you wrote:
> It seems that a future OpenCL implementation would be based on the C++
> llvm framework.
Yup.

> So my main reservation seems pointless with llvm appearing
> virtualy everywhere (Mesa/Xorg). 
C++ is slowly being used almost everywhere now ;) (even gcc, only the kernels 
are resisting).

> This was probably the intention not to
> write OpenGTL in project idea page. So I have a few question around
> OpenGTL.
>
> CTL apepars to be a established language for our main field of
> application - colour transformations.
At least, it's seems to be very used by the motion picture industry, which 
makes it impossible to see how (much) it is used. As far as I am concern, I 
see a lot of potential for CTL in the possibility to exchange color 
transformation between people, since CTL is a secure language (modulo the bug 
in the interpreter), but in itself it doesn't give any access to the system. 
Which means you can send a file, and a set of color transformation to someone 
else without caring about what software (and/or version) he uses, and he will 
see the correct results. It's a bit similar to color profile, but much more 
general, there is no limitation in what kind of transformation you can apply.

> How about Shiva? Is it fully compatible with PixelBender alias Hydra?
No. There are divergence, for one thing, I started shiva by getting inspired 
by Hydra when it was still an alpha, and there are things in Hydra I didn't 
like and made differently, and there are things that adobe changed in Hydra 
when they called it PixelBender, but it is still close enough that moving from 
Hydra to Shiva is quiet easy, and I intend at some point to make it possible 
to use PixelBender kernel with Shiva, right now it's not a top priority since 
there are still relatively few kernel written for PixelBlender.

> I
> found no specification for the format used by PixelBender. It seems to
> change from time to time and Adobe is free to do so.
There is a specification in the SDK.

> 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 :)

> In OpenCL pointers are much more restrictively used than in traditional C.
Not sure what you mean by that, but it's the same in Shiva/CTL, you don't see 
pointers. and in OpenCL you only have access to textures.

> 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.

> 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 ? In which 
case it should be done by the user, I have made effor to make OpenGTL thread 
safe (in fact it fails if you build llvm in debug mode :(, but otherwise it 
works fine).

> 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.
-- 
Cyrille Berger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/openicc/attachments/20090403/6754a38b/attachment.htm