[Openicc] Xorg low level buffers - colour conversion

[Kai-Uwe Behrmann]

Am 07.03.08, 20:48 +0100 schrieb Tomas Carnecky:
> Kai-Uwe Behrmann wrote:
> > Control:
> > What kind of buffers can a Xorg composite manager cover? ... static
> > screen content, Xvideo, OpenGL?
> > In other words, is the composite manager a key component to influence all
> > colour paths to the screen at once?
> 
> The only special case is XVideo: If the 'video texture' adaptor is used then
> everything goes through the compositing manager. If the 'video blitter' use
> used (the 'blue overlay'), then that can't be influenced by the compositing
> manager. The XV adaptor itself can have several attributes influencing colors
> and such, but these are very much video card/driver specific. The video
> texture adaptor is default in many of the newer video drivers, although I've
> heard that using it can cause video tearing.

Ok. That would be great.
 
> > Modularity:
> > Is it possibly to generalise GPU usage and run a shader programm over
> > data residing in RAM?
> 
> You can run a shader over whatever you want. Newer graphics cards are
> generalized to such extent that you can also solve _huge_ matrices with them
> (GPUs are essentially massive parallel floating point processors). If you want
> to have the shader running on the GPU, you first have to upload the data to
> the graphics card memory, then run the shader, and then copy the result back
> to RAM. That adds some delay, especially the reading back to system RAM, which
> is slow on the AGP bus (much faster on PCI-Express). The compositing manager
> does not need to read the data back into system RAM, so don't worry, it does
> not have such delay.
> 
> > Assuming that the shader programm is some thiny blob, would it be wise to
> > provide this small programm by a CMM and thus influence the interpolation
> > algorithm, e.g. make the shader generation plugable?
> > 
> > Is the GPU shader, generated by a CMM, useable on the early rendering end
> > in a application?
> > 
> > Can a shader programm be written to files and shared by applications?
> 
> A glsl shader looks like a normal C source code, so you can do whatever you
> want with it: save it in a text file, share it between applications etc. An
> application can load the shader source code (which OpenGL compiles into a GPU
> assembler and loads it into the GPU) and run it on whatever data it wants.

Fine then we can plan about a CMM API, which converts a given CLUT 
into a shader text. The selected CMM will then decide how to generate the 
code. There seems to be enough possibilities to make this part plugable.

> Whoever can use OpenGL can also use the shaders, be it an application or the
> compositing manager, or even the xserver (now that we have accelerated OpenGL
> in the xserver).

... or use the traditional path for rendering pixels in the CPU. 
After the profiles are linked we have to take care for two colour 
conversion technologies, the CPU and the GPU one.
This sums up to 3 CMM API's.
1. device link from profile linking
2. shader generation from above device link
3. generic pixel conversion API with device link input from 1.

For the composite manager I should then define the first and second API.
The thierd API is for general colour computations.

Thanks for your input. It seems, an idea about integrating GLSL into 
the Oyranos CMM framework shapes up now.

> If the color conversion is just a matrix transformation, then that can be very
> easily done in a few lines of a shader program. However if it involves lookup
> tables and such additional data then the shader becomes a bit more
> complicated.
> 
> > Has the final call, to bring this shader programm in place and start the
> > colour conversion, realy influence on the result? Or is it more to see
> > like a switch to start the programm?
> 
> I don't understand this question.

Is the execution of the shader programm dependent on driver and/or 
hardware details?

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