Deep Color support

[Wolfgang Draxinger]

On Sun, 27 Apr 2014 12:11:39 +0200
John Kåre Alsaker
<john.kare.alsaker at gmail.com> wrote:

> I implemented support for ABGR16161616 framebuffers in mesa/wl_drm.
> My patch has bit-rotted a bit now, but it gives you an idea about
> what to do:
> https://github.com/Zoxc/mesa/commit/73f39f1366287bab02c993cb3537980e89b3cdca
> 
> My motivation for this was to have clients render with linear gamma.

Well, unless there's a nonlinear scanout LUT, so far with current
technology and software the values in the backing store go to the
display linearly.

Not that this was particularly sane; the sane thing would be to
associate a color profile with the backing store and have the graphics
system apply a color transform close to scanout – a task trivially to
implement in a compositor.

I recently double checked with an oscilloscope, that all GPU/driver
combinations I own (Intel/intel, NVidia/nvidia, NVidia/nouveau,
AMD/fglrx, AMD/radeon), are well behaved, and they are. But of
course you can see the staircase with only 8 bits per channel.

One of the scope traces ended up in the StackOverflow answer
http://stackoverflow.com/a/23030225/524368
 
> One thing to note is that EGL clients usually will pick the highest
> color depth by default.

Which is a very sane rationale.

> We'd likely want to prevent this somehow, even though it goes against
> EGL spec.

Why? Today we're no longer constraint by lack of graphics memory. The
only valid argument would be the performance hit caused by increased
memory bandwidth load. However you're normally not limited by
framebuffer fill bandwidth, but by texture fetch bandwidth (and modern
GPU's memory controller are full-duplex capable). And in
render-to-texture situations you normally explicitly select the desired
internal format for the textures, as the task at hand demands it.


Regards,

Wolfgang