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

Chad Versace chad.versace at linux.intel.com
Tue Sep 17 13:49:53 PDT 2013


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

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


More information about the mesa-dev mailing list