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

[Chad Versace]

On 09/17/2013 04:20 PM, Kristian Høgsberg wrote:
> 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.

Storing the GBM format in EGL_NATIVE_VISUAL_ID sounds like a good idea.

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

I don't think the existence of the 1010102 GLXFBConfigs will
cause any problems, because glxinfo shows that they are sorted
after the 8888 configs.

I'm unable to find any 1010102 EGLConfigs under X/EGL. Here's the proof,
where I print the result of eglGetConfigs. (And yes, I restarted the Xserver
after installing Mesa).

   i:  id   r   g   b   a
-----------------------------
   0:  14   8   8   8   8
   1:  18   8   8   8   8
   2:  36   8   8   8   8
   3:  50   8   8   8   8
   4:  52   8   8   8   8
   5:  54   8   8   8   8
   6:  56   8   8   8   8
   7:  78   8   8   8   8
   8:  82   8   8   8   8
   9: 100   8   8   8   8
  10: 114   8   8   8   8
  11: 116   8   8   8   8
  12: 118   8   8   8   8
  13: 120   8   8   8   8

Ditto for Weston. I see no 1010102 configs. Am I doing something wrong?
GBM was able to find one, because according to the Weston log it's
using a 1010102 EGLConfig.

   i:  id   r   g   b   a
-----------------------------
   0:   7   8   8   8   8
   1:   9   8   8   8   8
   2:  18   8   8   8   8
   3:  25   8   8   8   8
   4:  26   8   8   8   8
   5:  27   8   8   8   8
   6:  28   8   8   8   8