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

[Roland Scheidegger]

Am 22.11.2017 um 20:17 schrieb 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).
> 
Oh and FWIW this one also requires EXT_texture_snorm (which at least
nvidia doesn't support) for snorm format testing.

Roland