[Openicc] Xorg low level buffers - colour conversion

[Kai-Uwe Behrmann]

Am 09.03.08, 14:11 +0100 schrieb Gerhard Fuernkranz:
> Hal V. Engel wrote:
> > My understanding is that CUDA is for using the GPU to do general purpose work 
> > such as math and science work.
> 
> Obviously, but IMO we have two potential use cases:
> 
>    1. Do the color transformation from e.g. working space to monitor
>       space in the graphics card (by a fragment shader program), when
>       displaying images on the monitor (I guess this would require that
>       applications (like image viewers, editors, etc.) use OpenGL for
>       displaying the image, and not "regular" X11 library calls, except
>       if the X11 library and the X server would be extended to support
>       color management, i.e. to accept images (and other objects) in
>       color spaces different from the native monitor color space)
> 
>    2. Do a GPU-aided color transformation only, without actually
>       displaying the resulting image on the monitor (e.g. for printing,
>       etc.), and IMO this is basically a general purpose application of
>       the GPU.

We can keep point 2 open to CMM's.

The frameworks module API's should then allow for:
* device linking
* pixel conversion
* preprocessing (fragment shaders, CTL ...)

For simplicity I'd vote for making only the first, the device linking CMM, 
selectable. This CMM API can cover, DL creation and conversion. This is 
oriented toward the state as is with CMM selection. If the CMM does its 
pixel conversion on the GPU with the help of e external fragment shader or 
uses a CPU fallback is up to the CMM according to availability and 
requirements. 
For instance, as I understood previous posts, a 16-bit CmykOG buffer would 
not easliy fit into a framebuffer layout.

Which of the available preprocessing modules a CMM uses to run the pixel 
conversion, including the coverage of fallbacks, can hardly be covered by 
the framework itself. It is too dependent from the used technology. The 
framework can just aid in deploying available code. Thus a lcms or Argyll 
CMM can easily render on GPU. General deploying of GPU would help in 
solving many problems application developers currently see. 

To create a highly flexible and transparent meta CMM, such CMM can present 
options to offer different linking and rendering paths, e.g. make GPU/CPU 
conversion a user choice. The meta CMM would probably be the right choice 
for most users. While certain CMM's will be prefered by some people to 
enshure certain quality critera.

> > Besides CUDA is not GPU agnostic and what we 
> > are talking about doing will be on systems with X11 and OpenGL.
> 
> Seems to be Nvidia only?
> 
> On www.gpgpu.org which Tom suggested as reading material, I also found a
> link to Brook (http://graphics.stanford.edu/projects/brookgpu/). So I'm
> wondering, what about Brook? The examples suggest that Brook streams are
> pretty easy to use .

Vendor independence would be highly desireable to provide something widely 
useable. A fallback to non GPU rendering is a must.


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