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