[Piglit] [PATCH] New test for ARB_color_buffer_float

[Marek Olšák]

On Wed, Aug 25, 2010 at 11:44 PM, Brian Paul <brianp at vmware.com> wrote:

> On 08/25/2010 08:57 AM, Luca Barbieri wrote:
>
>> 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?
>>
>
> 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).
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20100826/14ae4ea7/attachment.htm>