[Mesa-dev] [PATCH 0/6] Support for 10 bpc EGLSurface

[Kristian Høgsberg]

On Tue, Sep 17, 2013 at 1:49 PM, Chad Versace
<chad.versace at linux.intel.com> wrote:
> On 09/15/2013 12:16 AM, Kristian Høgsberg wrote:
>>
>> Hi,
>>
>> This little series adds support for creating EGLSurfaces with color
>> buffers
>> using the ARGB2101010 pixel format.  We the new KMS addFB2 ioctl we can
>> create KMS framebuffers with that format and this series ends up adding
>> the pixel format to gbm so we can generate buffers with that format.
>>
>> The first two patches make sure we don't advertise ARGB2101010 configs
>> that
>> you can use with an ARGB8888 X window.  The X visual to EGL config
>> matching just compares visual depth and EGL config buffer size, and
>> they're
>> both 32 bits for those two pixel formats.  Unless we match on the
>> pixel layout, we will advertise EGLConfigs with 10 bpc that you can use
>> with a ARGB8888 X window.
>>
>> With this patch series, I can run weston on KMS in 10 bpc, but anything
>> that
>> uses gbm will benefit from this.  We also add support for 10 bpc
>> GLX pixmaps and pbuffers.
>>
>> Kristian
>
>
> (CC'ing Ian to alert him about the EGLConfig sort order.)
>
> This series looks good to me.
> Reviewed-by: Chad Versace <chad.versace at linux.intel.com>
>
> Something to note is that eglChooseConfig(r=8, g=8, b=8) sorts the
> RGBA1010102 EGLConfigs *before* the RGBA8888 configs. I confirmed
> this on GBM. The EGL spec requires that behavior, but I find it
> surprising.
>
> Someone else found it surprising too and complained
> loudly to Khronos, resulting in Footnote 8 on page 26 of the
> EGL 1.4 2013-02-11 spec:
>
> "[fn8] This rule places configs with deeper color buffers first in the list
> returned by eglChooseConfig.
> Applications may find this counterintuitive if they expect configs with
> smaller buffer sizes to be
> returned first."

Yup, I hit that with weston too.  It's not surprising that it works
that way, but I think a lot of applications assume that there will be
no 10 bit configs.  For gbm, I'm thinking that we may want to put the
GBM format code into the EGL_NATIVE_VISUAL_ID config attribute so you
can choose a config, then read out the id and use it when creating the
GBM surface.  Or alternatively, pick a GBM format first and then look
for a config where the visual ID matches.

> Luckily for now, this surprise will hurt no one on X because X/EGL
> advertises no RGBA1010102 configs.

It does and GLX does too with these patches.  The configs are only
usable with pixmaps or pbuffers, not windows (unless the window visual
is 10 bit too).  This could still break things under X where an
application may pick an EGLConfig or GLXFBConfig and get a 10 bit
config and then use that to create a GLXPixmap, then later try to
XCopyArea or such from the pixmap.  It may be safer to disable this
under X...

Kristian