On Mit, 2013-12-25 at 20:35 -0800, Mark Mueller wrote: > 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
That would be more consistent with the current PIPE_FORMAT naming convention, but some of the component size sequences look a bit weird, your original proposal actually makes more sense for those... > 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? Maybe? Hard to be sure without actually trying it and working out all the issues. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
