Adam Jackson wrote: > > On Fri, 2019-01-11 at 15:01 +0000, Emil Velikov wrote: > > > > > > @@ -460,6 +464,14 @@ driGetConfigAttribIndex(const __DRIconfig > > *config, > > > > else > > > > *value = 0; > > > > break; > > > > + case __DRI_ATTRIB_RED_MASK_HI: > > > > + case __DRI_ATTRIB_GREEN_MASK_HI: > > > > + case __DRI_ATTRIB_BLUE_MASK_HI: > > > > + case __DRI_ATTRIB_ALPHA_MASK_HI: > > > > + /* upper 32 bits of 64 bit fields */ > > > > + *value = *(unsigned int *) > > > > + ((char *) &config->modes + attribMap[index].offset + > > > > + 4); > > > > > > Is the "+ 4" going to work on big endian systems? > > > > No. > > > > I think I'd prefer to just expand config attribute values to 64-bit across > > the board > > internally, rather than have paired 32-bit attributes like this.
Emil is right, big endian wouldn't work with my patch as-is, but I suppose I could incorporate some macros to make it work. I experimented with changing getConfigAttrib/indexConfigAttrib to allow for 64-bit values, like you suggest, but doing so without breaking ABI got pretty ugly - required adding new functions (getConfigAttrib2/indexConfigAttrib2), and checking the driver's extension version level at every call site. However, given the issue with endianness, I'm now more inclined to go in that direction. Thanks, Kevin _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
