[Openicc] questions about Compiz

[Kai-Uwe Behrmann]

Am 31.01.11, 09:38 -0000 schrieb Richard Hughes:
> On 30 January 2011 21:17, Jan-Peter Homann <homann at colormanagement.de> wrote:
>> - RGB 2 CMYK
>> - CMYK 2 CMYK
>
> You can certainly do this in lcms on the CPU, but the GPU methods are
> limited to 3 channels. When doing the GPU transform, we create a 7 or
> 8 bit three dimensional cube of the pre-computed transform and store
> it in the GPU as a 3d texture. It's a pretty huge lump of texture
> memory 8x8x8xsizeof(float) for the default precision (~16Mb) and so
> even if the GPU could support 4D textures the resulting precomputed
> map would be over 1Gb in size.

8x8x8xsizeof(float) == 2048 bytes
A grid size of 8 would be too very few quality. Thats for handhelds?

I described the memory footprint in CompICC here:
http://oyranos-cms.blogspot.com/2011/01/speeding-up-compicc.html
It uses around 1.5 MB for a 64 grid raster. Thats not much memory.

> Stealing 16Mb of texture space might upset some people, we probably
> want people to be able to unload (or disable and reload) the texture
> memory when playing full screen OpenGL games.
>
> Something else close to my heart is the amount of additional power
> this will also use. For me, on my low power Intel 965GM using a GLSL
> shader on a 1680x1050 LVDS display increased my power usage by over
> 15% when idle. A few hundred mW of power on one system isn't much at
> all, but when you multiply a few hundred mW by several hundred
> thousand workstations you're talking in fractions of power stations.

With compiz I see no additional idle usage. 10%-15% more power usage come 
during movie playback or other full frame animations, where each frame 
must be transformed. Whether your window manager needs optimisation I can 
not say. At least Compiz has this optimisation and works needs power only 
when something must be redrawn.

Playing movies and colour transform them through CPU is prohibitly 
expensive in cost of perfomance and surely in cost of energy. The web is 
getting more animations not less. For real content, compositing will 
likely happen in a blending space different from the output device space. 
My guess is, that this use case makes conversions on the CPU non trivial.

> Maybe we can achieve the same per-area or per-window (rather than
> per-display) gamut scaling without using the GPU at all..? Something
> to think about.

I have talked with the Xorg developers years ago about that ;-)
Ideas are welcome for making the desktop bazar colour managed.

> Richard.

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