[Piglit] [PATCH] fbo-blending-snorm: new test for testing snorm blend behavior

[Roland Scheidegger]

Am 22.11.2017 um 19:45 schrieb Eric Anholt:
> sroland at vmware.com writes:
> 
>> From: Roland Scheidegger <sroland at vmware.com>
>>
>> The existing fbo-blending-formats test is mostly useless for anything but
>> unorm formats, since it does not test any values outside [0,1] (neither for
>> src, dst, intermeidate calculations, blend result).
>> I tried to enhance it but it got too complex, in particular because I really
>> want to test snorm, not floats (which aren't really validated much neither),
>> because if you actually use int math for them it's difficult to handle and
>> llvmpipe had lots of bugs. And it's not even obvious from the GL spec when
>> clamping actually happens (in particular, the inverse blend factors will be
>> in range [0,2]). snorm blending is sort of semi-supported in GL, the
>> presence of EXT_texture_snorm doesn't guarantee it (and nvidia doesn't support
>> the extension, presumably because they can't or don't want to deal with the
>> legacy alpha/luminance/intensity formats), and while GL 3.1 introduces the
>> snorm formats too it isn't guaranteed for rendering neither (for GLES OTOH
>> there's a EXT_render_snorm extension), so the format handling of the
>> fbo-blending-formats test isn't really sufficient and not easily extensible.
>> So, this test will test actual blend behavior with values which will need
>> clamping, and where the intermediate and final values will be negative (and,
>> for the inverse blend factors, be even larger than one).
>> This passes (now) on llvmpipe, and nvidia blob. softpipe is a complete
>> failure (if there's clamping it will always clamp to [0,1] for starters),
>> and as a matter of fact, softpipe doesn't get the clamping right even with
>> unorm neither, since values outside [0,1] won't get clamped in the tile
>> cache when there's no clamping, hence they'll enter the blend later when
>> blend is enabled unclamped - but there's no test for this (note this is
>> only an issue if the fragment color clamp is disabled).
> 
> I thought the ARB_color_buffer_float/render test was trying to cover
> this.
> 

You are quite right, I missed this one also covers blend functionality
(and also covers snorm formats).
It does not however test the really interesting blend combinations,
because it only really tests one/zero blend factors. The really
interesting ones are those with inverse blend factors.
And it looks quite complex to change too (this test actually just draws
one rectangle and relies on the clear color for the dst values).

Roland