On Wed, Nov 22, 2017 at 2:19 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 22.11.2017 um 20:17 schrieb Roland Scheidegger: >> Am 22.11.2017 um 19:45 schrieb Eric Anholt: >>> srol...@vmware.com writes: >>> >>>> From: Roland Scheidegger <srol...@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.
The (NVIDIA) DX10 series didn't support snorm blending. I think the DX11 ones do though -- not completely sure. -ilia _______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
