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