Deep Color support

[Pekka Paalanen]

On Sun, 27 Apr 2014 00:03:19 +0200
Wolfgang Draxinger <wdraxinger.maillist at draxit.de> wrote:

> 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 think you should do that with an FBO in GL, not GBM directly. Use
GBM to create the final framebuffer for scanout, and convert from
the high-depth FBO render target / texture to a format that is
suitable for scanout. This would happen in the compositor on
Wayland.

I believe GBM formats are mostly limited to what can be scanned out.

> > 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.

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

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. Window
buffer formats are what Wayland is concerned about, and the
scanout framebuffer is just a compositor implementation detail.

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

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).

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.

> > 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'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.

Color management is something that has been discussed recently
again, and that would likely be communicated in Wayland, outside of
EGL.

Btw. weren't FBConfigs a GLX thing?

> [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.

I think writing such extensions would be completely possible. On
the Wayland side, one approach would be to define a new wl_buffer
factory, which supports multiple storage buffers per set of window
content (wl_buffer). The hard part is getting compositors to
support that, and expose the feature to applications in a standard
API.

But if you can hack both compositors and apps, there is nothing
preventing you from trying that already. I think there is one
person already who wants to make window content have both stereo
color channels and stereo depth maps. We talked a bit, and I think
his current hack is to just use a buffer with twice the width and
height, and manually set a flag via Wayland, that this is his
special 4-in-1 format, and his compositor will then handle it
properly.


Thanks,
pq