----- Original Message ----- > On Mon, 2013-02-04 at 20:17 +0100, Michel Dänzer wrote: > > > > [...] how about something like this: > > > > Define the packing to be in the host byte order. However, do not define > > array formats as packed values (which makes little sense e.g. for > > *32*32*32*32 anyway) but really just as arrays. 16- or 32-bit components > > of arrays are again packed in host byte order. Array components of 4, 2 > > or 1 bits occupy bits [0,n-1] of byte 0, then bits [n,2n-1] of byte > > 0, ..., bits [0,n-1] of byte 1, and so on. > > > > To make the distinction between packed and array formats clear, they > > should probably use different naming schemes. The current scheme makes > > more sense for packed formats I think, so I'd propose separating array > > components e.g. by an additional underscore, and ordering components > > from lower memory address left to higher address right. As an example, > > PIPE_FORMAT_R8G8_UNORM would become PIPE_FORMAT_R8_G8_UNORM. It would > > probably make sense to define packed naming aliases for array formats > > where possible, e.g. PIPE_FORMAT_R8_R8_UNORM would alias to > > PIPE_FORMAT_R8G8_UNORM (which would be identical to MESA_FORMAT_GR88) on > > little endian and PIPE_FORMAT_G8R8_UNORM (== MESA_FORMAT_RG88) on big > > endian hosts. (That's using the current component ordering for packed > > formats; IMHO the reverse order would actually make more sense for > > those, but that might require more invasive changes...) > > Actually, on second thought this means it's probably better to keep the > current naming scheme for array formats. Maybe the component names and > sizes could be packed together to indicate packed formats, e.g. > PIPE_FORMAT_B5G6R5_UNORM would become PIPE_FORMAT_RGB565_UNORM and would > be defined identically to MESA_FORMAT_RGB565.
> For my example above, PIPE_FORMAT_R8G8_UNORM would alias to > PIPE_FORMAT_GR88_UNORM (== MESA_FORMAT_GR88) on little endian and to > PIPE_FORMAT_RG88_UNORM (== MESA_FORMAT_RG88) on big endian. I like this naming better, as I'd prefer the array formats to match D3D10, and also to prevent confusion with subsampled formats (like R8G8_R8B8). Either way the renaming is just syntactic sugar and is neither urgent nor a requirement for the semantic changes. But I believe we are forming some consensus on how to move forward/ Ajax, does the above sound good to you too? I think it's not very different from your initial suggestion. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev