[Piglit] [PATCH] New testsuite for ARB_color_buffer_float (v2)
idr at freedesktop.org
Mon Aug 30 18:00:35 PDT 2010
-----BEGIN PGP SIGNED MESSAGE-----
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
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/
-----END PGP SIGNATURE-----
More information about the Piglit