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.
Roland _______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
