On 09/17/2013 04:20 PM, Kristian Høgsberg wrote:
On Tue, Sep 17, 2013 at 1:49 PM, Chad Versace
<chad.vers...@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.vers...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
