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: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca Barbieri [l...@luca-barbieri.com] Sent: Saturday, April 03, 2010 1:48 To: Jose Fonseca Cc: mesa3d-...@lists.sf.net 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. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
