Summary: | Derivatives of gl_Color wrong when helper pixels used | ||
---|---|---|---|
Product: | Mesa | Reporter: | James Legg <jlegg> |
Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | Default DRI bug account <dri-devel> |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Test program
Apitrace trace of test program Appearance when test is failing |
Created attachment 123240 [details]
Apitrace trace of test program
Created attachment 123241 [details]
Appearance when test is failing
Hi James, thank you for the detailed report. I can reproduce this and am going to investigate. As a temporary workaround, the error should disappear when you run with the environment variable setting R600_DEBUG=mono. The cause is that with non-monolithic shaders, input interpolation happens in the prolog. However, when we compile the prolog we do not see the derivative computations and therefore fail to turn the helper pixels on. This is now fixed in Mesa Git b42bc90b6add0d0f81d915d49712761d32329afa with LLVM r272063. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 123239 [details] Test program Along the edges of triangles and around where fragments are rejected due to depth testing, the GLSL functions dFdx, dFdy, and fwidth return incorrect values when the argument is dependant on gl_Color or gl_SecondaryColor. I've attached a program reproducing the issue. It takes derivatives of a constant, which should be 0. It is expected to produce a black window. However, the edges of the triangle it draws are visible because of this bug. The error does not occur when environment variable LIBGL_ALWAYS_SOFTWARE is set to 1. I'm using Mesa git 0831eb9 with an AMD R9 270 on x86_64 Fedora 22.