Deep Color support

[Wolfgang Draxinger]

On Sun, 27 Apr 2014 11:30:18 +0300
Pekka Paalanen <ppaalanen at gmail.com>
wrote:


> > I'm still trying to get an GBM configuration working that targets
> > an off-screen buffer so that OpenGL operations are carried out
> > toward it on the GPU but without attaching it to a CRTC.
> 
> I think you should do that with an FBO in GL, not GBM directly.

Well, to create an FBO in OpenGL you need a context first. Technically
nothing in the OpenGL specification forbids creating a context without
a main framebuffer. Just no implementation supports it.

> If you instead mean a buffer backing a window, then the limitations
> are just what the GPU can render and texture, which I would assume
> is much less restrictive than the supported scanout formats.

That one!

> By main framebuffer, I assumed you were talking about the buffer
> that gets scanned out, that is the final composite.

No, by "main" framebuffer I mean the memory area "clients" write to,
i.e. the memory area that's read from the clients by the compositor. In
OpenGL terms the framebuffer with the id 0 (i.e. where things get
rendered to after a glBindFramebuffer(0) call; or by default).

With GLX (and wgl) there are PBuffers; unfortunately those are tied to
the graphics server as well. That's quite annoying, because if you
switch to a different X server, then all OpenGL contexts will operate
into "nirvana".

If you do, what I do at work for example (we're doing realtime
visualization of interferometric signals) and just want to render to a
video in the background, you must not switch to a different X11 server
so that the video doesn't get corrupted. BT;DT. This is one of the
incentives for me to look into creating OpenGL backing stores tied to a
GPU (instead of OS-Mesa softpipe), that are not tied to a scanout
buffer or even a display server.

> Apps would be working with window backing buffers, and the
> compositor then after or during compositing needs to convert those
> to scanout-able format.

Exactly. And of of course scanout-able formats are much more restricted
by hardware capabilities (NVidia is actually pushing for deep color
displays to enter the consumer market).

> So, adding deeper formats to the EGL Wayland platform for clients
> to use is certainly possible, but will of course need some work in
> the EGL implementation and possibly in the EGL-private Wayland
> protocol extension (wl_drm for Mesa).

My thinking.

> However, I think Kristian got a A2R10G10B10 like format to work on
> Intel, but I haven't heard of deeper than that being tried. Maybe
> that one is still scanout-able on some hardware.

Indeed this is the format which I referred to in my opening post of
this thread; although I didn't use the alpha channel.

> I'm not sure if EGLConfigs can express floating point formats, but
> I assume it would have no trouble expressing e.g. a 16-bit per
> channel integer RGBA formats.

Well floating point is not that much important. HDR is one thing, Deep
Color a wholly different one.

At 8 bits per channel every color space will have some regions where
quantization is easily visible (mostly anything grayscale). The human
eye can resolve about 33dB of lightness variation, i.e. about 2000
steps within the area of focus. So you need at least 11 bits grayscale
to cover that. So that's where Deep Color is required.

HDR on the other hand is about covering the full scale of vision
capabilities where the eye as a whole can adapt to illumination
conditions which is a much larger range. That's what you'd use floats
for.

Hmm, HDR composition sounds interesting. But I think most applications
can perfectly fine live with doing HDR tonemapping themselves; in fact
it's highly desireable for applications to do this, for example in a
game the HDR tonemapping is usually controlled by where the player
currently looks at.

Valve made a very nice interactive presentation for the Layman on how
HDR in games works: "Half-Life2: Lost-Coast" (also available for Linux).

> Btw. weren't FBConfigs a GLX thing?

No, XRender actually; GLX just piggybacks on that.


Thanks,

Wolfgang