<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt; font-weight:400; font-style:normal;">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</body></html>