[Mesa-dev] [RFC 1/6] dri: Support 64 bit rgba masks

Adam Jackson ajax at redhat.com
Wed Jan 16 15:07:18 UTC 2019


On Wed, 2019-01-16 at 04:41 +0000, Strasser, Kevin wrote:
> Emil Velikov wrote:
> > 
> > Please split this up a bit. I'm thinking of:
> >  - dri_interface
> >  - mesa
> >  - egl
> >  - gbm
> >  - glx - seems sparse on updates, guessting you're followed in laster patches?
> 
> Sure, I can break it up a bit more. I didn't modify glx much as it doesn't read
> the mask attributes directly, hence it can't handle configs with RGBA ordering.
> I don't know the background of that limitation, but I assume there just hasn't
> been any use cases for those formats outside of Android, and so handling hasn't
> been needed for glx... The intention of this series was to get fp16 working
> first for egl. Can we leave the glx side for if/when someone needs it there?

GLX handles RGBA ordering just fine. GLX doesn't expose channel
ordering because it inherits that from the X visual. But the only thing
you could do with fp16 in GLX is make a pbuffer out of it, because X
doesn't support >8bpc for windows or pixmaps, and there is no visual
corresponding to a pbuffer, so whatever channel order the hardware
wants is what you get.

That said, I note that GLX_ARB_color_buffer_float defines not just fp16
but fp32 formats, and EGL_EXT_pixel_format_float doesn't differ. If we
did want to support fp32 surfaces then simply widening attributes to 64
bits (or adding a "high" 32 bits) isn't going to be enough. Probably
what I'd do is only define those masks to non-zero for <=32bpp formats,
and add new attributes for channel left-shift instead. I realize this
contradicts what I said earlier, sorry about that.

- ajax



More information about the mesa-dev mailing list