On Wed, Jan 30, 2013 at 11:58 AM, Michel Dänzer <[email protected]> wrote: > On Die, 2013-01-29 at 21:22 +0100, Marek Olšák wrote: >> On Tue, Jan 29, 2013 at 4:31 PM, Michel Dänzer <[email protected]> wrote: >> > On Die, 2013-01-29 at 14:43 +0100, Marek Olšák wrote: >> >> --- >> >> src/mesa/main/formats.c | 30 ++++++++++++++++++++++++++---- >> >> 1 file changed, 26 insertions(+), 4 deletions(-) >> >> >> >> diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c >> >> index 0273425..b86fb9e 100644 >> >> --- a/src/mesa/main/formats.c >> >> +++ b/src/mesa/main/formats.c >> [...] >> >> @@ -3264,12 +3270,17 @@ _mesa_format_matches_format_and_type(gl_format >> >> gl_format, >> >> return GL_FALSE; >> >> >> >> case MESA_FORMAT_SIGNED_R16: >> >> + return format == GL_RED && type == GL_SHORT && littleEndian && >> >> + !swapBytes; >> >> case MESA_FORMAT_SIGNED_GR1616: >> >> + return format == GL_RG && type == GL_SHORT && littleEndian && >> >> !swapBytes; >> > >> > GL_SHORT is in host byte order, so checking for littleEndian here >> > incorrectly excludes big endian hosts. >> >> Does that apply only to X16, or even to X16Y16, or even to X16Y16Z16W16? > > Hmm. AFAICT MESA_FORMAT_*1616 are currently defined as 32 bit packed > values, so the line you added for MESA_FORMAT_SIGNED_GR1616 is actually > correct. > > OTOH e.g. MESA_FORMAT_RGBA_16 appears to be defined as an array of 16 > bit values, so that could be treated the same way as > MESA_FORMAT_SIGNED_R16. > > I wonder if it wouldn't make sense to replace MESA_FORMAT_*1616 with > array based formats as well. AFAICT there's nothing like GL_INT_16_16 in > OpenGL.
I don't really get this distinction between array and non-array based formats. Most Mesa formats map to Gallium formats and most of Gallium ones are array-based regardless of how Mesa formats are defined, right? As a matter of fact, I added lots of Mesa formats over the years, e.g. MESA_FORMAT_SIGNED_GR1616, which may look like packed to you, but all I ever cared about was that it was equivalent to PIPE_FORMAT_R16G16_SNORM and I gave it a name which was consistent with the naming of other Mesa formats. The way I understand it, the component order in names of Mesa formats is written the other way around compared to gallium formats. E.g. MESA_FORMAT_RGBA8888 = PIPE_FORMAT_A8B8G8R8_UNORM. That's the case with most formats, except deviations in naming like MESA_FORMAT_RGBA_16, where the component order matches gallium. Marek _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
