Re: [Mesa3d-dev] How do we init half float tables?

[Jose F. <jfo...@vm...>]

Thanks Luca.

Concerning u_format_test.c, I'm not sure the problem is lossiness or ambivalence in the format or a bug in the compressor, but there was logic in u_format_test.c to skip the DXT1_RGBA packing -- all other tests were passing. Lossiness by itself doesn't explain the test failure because we're feeding to the compressor the RGBA data that resulted from decompressing. Given that DXT compression works by interpolating colors in a line segment of the RGB color space, when re-feeding the decompressed output to the compressor it should quickly find the line as all colors points lie exactly on it. "Exactly" is a too string word, as there is rounding, which could be in the root of the differences.

Jose
________________________________________
From: luc...@gm... [luc...@gm...] On Behalf Of Luca Barbieri [lu...@lu...]
Sent: Saturday, April 03, 2010 1:48
To: Jose Fonseca
Cc: mes...@li...
Subject: Re: [Mesa3d-dev] How do we init half float tables?

The s3tc-teximage test seems fixed by the two line change I put in
gallium-util-format-is-supported.

s3tc-texsubimage prints:
Mesa: User error: GL_INVALID_VALUE in glTexSubImage2D(xoffset+width)
Probe at (285,12)
  Expected: 1.000000 0.000000 0.000000
  Observed: 0.000000 0.000000 0.000000

which seems to be due to a Mesa or testcase bug.

As for u_format_test.c, it looks like it simply fails to account for
DXTn being lossy.