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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
