<div class="gmail_quote">On Wed, Aug 25, 2010 at 11:44 PM, Brian Paul <<a href="mailto:brianp@vmware.com">brianp@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div><div class="h5">On 08/25/2010 08:57 AM, Luca Barbieri wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> A new test for ARB_color_buffer_float is attached, which currently has no tests in either mesa-demos or piglit. ARB_texture_float is required to test 16-bit and 32-bit floating point targets, and otherwise only 8-bit fixed-point will tested. Mesa does not support this extension, but the proprietary drivers from both nVidia and ATI advertise it, and have been used to write this test. Note that both nVidia and ATI drivers are nonconformant in serious ways (and the bugs are all different between them). This test detects nVidia and ATI drivers and ignores all knows bugs, so that it should pass on both (but it still loudly complains about the bugs). This is intended to allow to check that the test itself is correct, until an actually conformant implementation becomes available. Note that the nVidia driver was tested on nv40, and the situation might be better on nv50 and Fermi. The ATI driver was instead tested on Cypress, and thus is most likely broken on all cards. The main (and essentially only) feature of this extension is the ability to control clamping to [0, 1] in several places. This is really tricky to get right (as ATI and nVidia's failure to do so shows), and thus the test tries a lot of variations to try to maximize confidence in the correctness of an implementation. It would be nice to test that the alpha test and polygon smoothing are correct too (i.e. they happen after fragment clamping and before blend clamping, if any), and improvements in this direction would be welcome. Tests for other target formats would also be nice to have, especially for different cases like unnormalized integer and unsigned floating point. The test is somewhat preliminary and could use some code cleanups, as well as testing on i965, r300, r500, nv50, Fermi with the proprietary drivers. Also having a conformant implementation would help in making sure the test is really correct: for now testing on both nVidia and ATI drivers kind of approximates that. It includes relevant quotes from the specification, which I believe is OK under fair use and the fact that it's available on a public server anyway. They can be easily removed if desired. Is this OK for inclusion? </blockquote> </div></div> In addition to Vinson's comment, I'd suggest breaking up the test() function into smaller, simpler functions to aid debugging. Also, I think printf() calls should only be made when there's an error or when not running in -auto mode. Otherwise, any unexpected output would be seen as an error (IIRC). </blockquote></div> stdout is ignored and tests with unignored stderr messages have the "warn" status, which means "pass" but there is some stuff in stderr. printf is a nice way to say what subtest is being run (see e.g. draw-vertices), so that you can easily assign failed pixels to a subtest. Concerning the test, I'd rather follow the GL specification and ignore that proprietary drivers fail. I am starting to think that ATI/NVIDIA don't have their internal test suite like we have piglit. Marek