[Piglit] [PATCH] New testsuite for ARB_color_buffer_float (v2)

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luca Barbieri wrote:
> This in an updated version of the test I posted, now split into 8 tests
> sharing a common header file.
> 
> It now features testing of multiple render targets and fog.
> 
> Test output logs and results on GeForce 8xxx, GTX 2xx or ideally GTX 4xx
> with the proprietary drivers would be really welcome.
> 
> The files are put in "spec/arb_color_buffer_float" with the idea of
> starting a convention of writing testsuites for each new extension
> to be implemented in Mesa, putting it in "spec/<extension_name>".
> 
> The tests now fail on any bugs in the default mode.
> If "-xfail" is passed, then known bugs on ATI and nVidia will be ignored,
> and all tests will then succeed.
> 
> The driver bugs don't seem due (solely) to hardware limitations, but may
> be due to software fallbacks being improperly implemented.
> 
> There are two areas where the specification seems unclear, as far as I
> understand it.
> 
> I'm not sure what the process to ask for clarification is, and suggestions
> would be welcome here.
> 
> This first issue is whether, when fragment clamping is set to FIXED_ONLY
> and the FBO has some fixed-point and some floating-point buffers attached,
> gl_FragData[n] is never clamped, or is clamped only for the fixed point
> buffers.

Issue #2 in the spec at least implies that only fixed-point outputs
would get the clamping.

    2. Should the clamp controls be automatically inferred based on
       the format of the color buffer or textures used?

       RESOLVED:  Explicit controls should be supported -- this allows
       the use of floating-point buffers to emulate fixed-point
       operation, and allows for operating on unclamped values even
       when rendering to a fixed-point framebuffer.

       However, a default clamping mode called "FIXED_ONLY" is defined
       that enables clamping only when rendering to a fixed-point color
       buffer, which is the default for fragment processing.  This is
       done to maintain compatibility with previous extensions
       (ATI_pixel_format_float), and to allow applications to switch
       between fixed- and floating-point color buffers without having
       to change the clamping mode on each switch.

> Note that while blending on fixed-point clamps the color anyway, alpha
> test and polygon smoothing happen before blending, and should be affected
> by whether gl_FragData[n] is clamped or not.
> 
>>From the OpenGL 4.1 spec, it seems that the intent is that fragment
> clamping does not depend on the target, especially because it can be
> bound dynamically due to user-defined varyings.
> 
> None of the hardware I have access to supports such dishomogeneous FBOs,
> so I have no idea what the proprietary drivers do.
> 
> Current nVidia cards might shed light on this.
> 
> The second issue is whether disabling fragment clamping disables the
> clamping done before fog application in fragment shaders with ARB_fog_*
> options (or whether this is undefined)
> 
> This happens in the fixed pipeline, but making it happen for shaders too
> would contradict the rationale of adding ARB_fog_* to shaders, which
> is to avoid recompilation.

The rationale wasn't to avoid recompilation.  The rational was to enable
use of fixed-function fog hardware.  ATI and, if I recall correctly,
Matrox wanted this because it could save them a couple instructions in
fragment shaders.  If the clamp before fog is disabled in
fixed-function, then the clamp before ARB_fog_* in a fragment program is
also disabled.  Your guess is as good as mine whether or not
implementations actually do this correctly.

> All the hardware I have access to has fixed function fog (all existing
> Radeons seem to have it), and here the disabling applies to fragment
> programs too, as a "naive" implementation would result in.
> 
> Again, current nVidia cards might shed light on this.

Summary results from an NVIDIA GTX 260 are at:
http://people.freedesktop.org/~idr/NVIDIA-ARB_cbf/.  It looks like
clear, drawpixels, getteximage, mrt, and render all pass.  probepixel,
queries, and readpixels all fail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx8VDIACgkQX1gOwKyEAw8smwCglbGJpnOGzhu/8gMCecpazBsL
uHUAnRKw0paT6kEgYAXOBLRjoe2dTUyA
=HuqY
-----END PGP SIGNATURE-----