[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