[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Public WebGL] Centroid sampling makes conformance tests fail?

Hi all,

I'm a contributor to the ANGLE project, which implements OpenGL ES 2.0 on Windows using Direct3D 9, and is used by Chrome and Firefox for implementing WebGL. Me and others have recently run into some issues which turn out to be caused by centroid sampling. But it doesn't appear that ANGLE is strictly speaking at fault, so I'm looking for some input on how to best deal with the issues...

The first one is that ANGLE "fails" to pass the WebGL conformance test for OES_standard_derivatives, on some hardware: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/extensions/oes-standard-derivatives.html. Although the resulting images are very dark, there is actually a different output along the diagonal. This is due to anti-aliasing being on (which is the default for WebGL), and Direct3D 9 can use centroid sampling in this case, which also affects the derivatives (which compute the difference in varying value between neighboring pixels). The second issue is closely related: http://code.google.com/p/angleproject/issues/detail?id=340. Because centroid sampling moves the location where the pixel is evaluated, and then applies the result to all covered samples, some places may appear to have shifted texels. And because the derivatives are also used to determine the mipmap LOD level, centroid sampling may affect that as well.

Using centroid sampling appears to be entirely within spec. The OpenGL ES 2.0 specification section 4.3.5 on varyings states that: "If single-sampling, the interpolated value is for the fragment center. If multi-sampling, the interpolated value can be anywhere within the pixel, including the fragment center or one of the fragment samples." Also, the OES_standard_derivatives extension suggests, but does not require, that "Functions should be evaluated within the interior of a primitive (interpolated, not extrapolated)."

This means that when anti-aliasing is enabled, there is a lot of leeway in what the result can look like! Hence I believe that the majority of the WebGL conformance tests should not be using anti-aliasing, unless that's explicitly part of the test. The alternative would be to not test values near the edges of polygons, although that seems quite haphazard and there's still no guarantee that all anti-aliasing implementations will evaluate the pixel at the center even when nowhere near an edge (think of quincunx anti-aliasing for instance).

It seems rather unfortunate to me that WebGL defaults to enabling anti-aliasing, given how much it can make the result differ between fully compliant implementations. Also, while it's possible to prevent ANGLE from using centroid sampling, it's not an easy thing to do, and there are actually cases where centroid sampling is valuable (which is why it exists in the first place).

So I'd like to know what other people's take on this is. Is it correct that the conformance tests make wrong assumptions and ANGLE is compliant? Or should we do whatever is necessary to prevent ANGLE from using centroid sampling? How can the issue of getting unexpected results because anti-aliasing is on by default be dealt with?

Thank you for your input!

Kind regards,
Nicolas Capens

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl