On Wed, Dec 25, 2013 at 7:25 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> On Mit, 2013-12-25 at 15:19 -0800, Mark Mueller wrote: > > > > ---------- Format Base Type P: Packed ---------- > > MESA_FORMAT_[[component list,bit width][storage type*][_]][_][storage > > type**] > > * when type differs between component > > ** when type applies to all components > > > > > > examples: > > MESA_FORMAT_R5G6B5_UNORM /* RRRR RGGG GGGB BBBB */ > > > > MESA_FORMAT_B4G4R4X4_UNORM /* BBBB GGGG RRRR XXXX */ > > This is slightly confusing in that the PIPE_FORMATs use this convention > for naming the components of 'array' formats, packed formats use > BGRXnnnn (just like packed MESA_FORMATs do now). Beware that not all > PIPE_FORMATs have been updated yet according to that distinction. > Is this what you are suggesting then? ---------- Format Base Type P: Packed ---------- MESA_FORMAT_[[component list][bit width per component]_[storage type*]][_][storage type**] * when type differs between component ** when type applies to all components examples: MESA_FORMAT_RGB565_UNORM /* RRRR RGGG GGGB BBBB */ MESA_FORMAT_BGRX4444_UNORM /* BBBB GGGG RRRR XXXX */ MESA_FORMAT_Z32_FLOAT_SX824_UINT MESA_FORMAT_RGBA1010102_UINT MESA_FORMAT_RGBE9995_FLOAT > > > I'm afraid there also needs to be a way to encode endianness, either > explicitly or via something like _REV to indicate the inverse byte order > of the host byte order. This would apply to the packed values as a whole > and to any multi-byte components of array formats. > I have seen the gallium discussion on this. Since my current focus is i965, I'm safely immune from big endian problems and I'm not aware of the details around the issue. Is it not sufficient to maintain a flag within the individual texture object or image, or a global flag per context to indicate host big endianess? My work with cleaning up the mesa format names is a precursor to adding more formats without associated pack and unpack functions (in other words, beyond MESA_FORMAT_COUNT). If a slew of big endian formats need to be added, they could be included in the same way. Mark
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
