<!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 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 </body></html>