Deep Color support

[Wolfgang Draxinger]

On Sat, 26 Apr 2014 17:10:38 -0400
"Jasper St. Pierre" <jstpierre at mecheye.net> wrote:

> Outside of an X11 environment, the only standard is EGL, with a
> Wayland backend for Wayland apps, or a GBM backend for native
> modesetting.

Well, GBM is just another backend for EGL. In my GBM experiments I
copy'n'pasted this code (among other things) to setup a EGL context:

	gl.display = eglGetDisplay(gbm.dev);

	if (!eglInitialize(gl.display, &major, &minor)) {
		printf("failed to initialize\n");
		return -1;
	}

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 don't know whether the Intel drivers have support for
> 64-bit textures on either of these backends. Writing a little test
> app is probably the easiest way to finding out.

Textures are the one thing. But having main framebuffers with deep
colors is much more important (you can always emulate deep color
texturing with an appropriate shader and multitexturing (a high and a
low bits texture); when it comes to main framebuffers you normally have
only one per displayed window (image) (two in the case of stereoscopic
formats)^1.

> FBConfigs are separate, but they're generic enough where you can just
> iterate through the list of FBConfigs on Wayland / GBM and see if you
> get a 16-bit visual there. I can't imagine you would, though.

I'll test that. But having deep color FBConfigs is a very desireable
feature. For example it would in one stroke eliminate any color
management issues on the client side: Clients would simply select a
contact color space (XYZ would be the natural choice) FBConfig and the
compositor could then apply the right color transformations for each
target output device. There's of course the issue of which rendering
intent to use for out-of-gamut colours, but that boils down to IPCing
with the Compositor to select a mode.

I recently experimented with this using XComposite and XRandR (using
the EDID information to either build an in-situ color profile from
the chromacity information in the EDID data or by ICC profile
database lookup) -- the drawback is, that within current X11
implementations you have just 32 bits per pixel tops and for a contact
color space this simply doesn't cut it. You end up with very prominent
banding artifacts like you have them in R5G(5|6)B5 pixel formats;
R8G8B8 also creates banding (just think a grayscale gradient from black
to white covering a 1024 pixels wide screen; this produces a nice
staircase of each value being 4 pixels wide; you can of course dither
it, but dithering is a kludge).

So I think, that it should be a high priority to support deep color
FBConfigs with each driver that also provides deep color texture
formats; after all the code is already there and the hardware supports
it. And when it comes to actual graphics operations there's no
difference between texture being render target or main framebuffers;
they're all just hunks of memory in view of the renderer (be it a GPU or
software).


Regards,

Wolfgang

[1] actually for some applications like light field displays it would
be cool if a window could register for an arbitrary number of
framebuffers. The technology is not yet quite there for high resolution
light field displays, but NVidia recently showed a low resolution
demonstrator.