Am 22.11.2017 um 20:46 schrieb Ilia Mirkin: > 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.
Yes, they will (it's a required dx11 feature). They just don't bother with the legacy formats (alpha/intensity/luminance), even for texturing - if they can't or they just don't want to bother, I don't know (trying to create a a8_snorm texture will indeed generate a gl error). So you can use snorm formats just fine (as it's a gl 3.1 feature for texturing), even for rendering/blending (which isn't guaranteed by gl in any version), just not the legacy ones, since EXT_texture_snorm isn't supported. Roland _______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
