[Openicc] Xorg low level buffers - colour conversion
Graeme Gill
graeme at argyllcms.com
Wed Mar 12 07:29:01 PDT 2008
Kai-Uwe Behrmann wrote:
> 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.
If all you want to do is implement an isolated GPU shader program,
then this is quite easily "pluggable" - simply select the right
shader program. But the implications are that doing color management
is a separate step, requiring separate, temporary destination
memory and more processing time. If the color transformation is
integrated into the other operations that happen during
compositing, such as transparent blending, projection, scaling
etc. etc., then I can't imagine such a simple approach being feasible.
You'd really have to do source code modifications of the shader
programs being used.
> ... 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
Shouldn't be necessary, since the link information should be
table data, not GPU shader code. The GPU shader code should
be static.
> 3. generic pixel conversion API with device link input from 1.
> Is the execution of the shader programm dependent on driver and/or
> hardware details?
Shader programs are very dependent on the actual GPU. In fact, highly
optimized shader source code can have quite a deal of conditional
compilation code in it to adapt it to the different capabilities
of the succeeding generations of GPU's, and that source code is then
compiled and optimized for a particular chip and the resources
it has available.
Graeme Gill.
More information about the openicc
mailing list