Adam Jackson wrote: > On Wed, 2019-01-16 at 17:58 +0000, Strasser, Kevin wrote: > > Adam Jackson wrote: > > > > > 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? > > I was thinking: > > a) Leave __DRI_ATTRIB_XXX_MASK in place, and simply set it to zero for > configs that don't fit in 32bpp > > b) New attribute(s) for __DRI_ATTRIB_XXX_SHIFT, whose value is the > right-hand side of the << operator you'd use to find that channel > > c) Fix dri2_add_config() and friends to work in terms of shifts not > masks > > This nicely avoids worrying about just how wide a pixel will ever get > (ie how many _HI attribs you'd need for fp32, fp64, etc), because the > left-shift is a whole 32-bit integer, and we're almost certainly not > worried about needing a billion bits per channel. The only other > flexibility masks would give you is allowing discontiguous bit ranges > for color channels, but that's not a feature of any hardware we do or > will care about (and I'm not sure was ever really a thing, tbh). > > Setting the MASK attribs to zero appears to magically DTRT when loading > a newer driver (with fp16 format support) on an older libEGL or > xserver; since the masks of the winsys' visuals will be non-zero, fp > formats will never match.
OK, thanks for explaining, I think I get it now. I'll see if I can get this working. Thanks, Kevin _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev