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

[Strasser, Kevin]

Adam Jackson wrote:
> 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.

Ah, understood.

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

Like I said, my immediate goal is to get fp16 working, but I'm all for picking
the design that will work over the long run, especially for hard to change ABI
boundaries.

I suppose *_HI and *_LO attributes don't make any sense if we might be talking
about masks that exceed 64 bits. Is __DRI_ATTRIB_RED_MASK_LSHIFT32 and
__DRI_ATTRIB_RED_MASK_LSHIFT64 and so on what you had in mind?

> Probably what I'd do is only define those masks to non-zero for <=32bpp 
> formats,

Not sure if I understood this statement. Do you mean if we keep the _HI and _LO
attributes, only make them valid for formats that are <=64bpp, like fp16?

Thanks,
Kevin