| Summary: | RTT write->read->write gets reordered in some frames | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Lauri Kasanen <cand> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED NOTOURBUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 8.0 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Screenshot of the issue, bad camera angle
Same scene, good camera angle Another screenshot |
||
Created attachment 65892 [details]
Same scene, good camera angle
Apitrace (60mb): http://www.ziddu.com/download/20164691/fragcoord.trace.zip.html Renamed as a zip to let it be uploaded. I'm also able to reproduce this on Intel hardware with i965_dri.so. Since this doesn't seem specific to r600 hardware or even to Gallium-based drivers, I'm switching the component to 'Mesa core'. In the trace, it looks like the frames that produce the expected results always disable GL_BLEND right before using the gl_FragCoord shader. The frames that don't produce the expected results don't disable it. If blending is erroneously enabled, that would explain the unexpected on-screen results. Can you produce a smaller test case that exhibits this issue? Sorry, I couldn't make anything smaller that also triggered the issue. Though, since the RTT is always cleared to black before rendering that sphere, blending should have no effect (it's set to GL_ONE, GL_ONE, and supposed to be enabled there)? Created attachment 65909 [details]
Another screenshot
Attaching a screenshot from the app in a normal run, with about the same camera angle.
Nothing is moving, not the camera, not the objects, but in this cam angle, black dots start to run to the right from dark places in the picture, like the dark seams.
It's a very curious kind of corruption indeed.
Okay, the corruption is due to the occlusion queries. I found that disabling those removed the corruption in all cases. fglrx shows the same behavior. Progress - I found it's an ordering bug. 1. Render scene to rttFinal 2. Bind and clear to gray rttTMP 3. Multiply rttTMP into rttFINAL using blending 4. Render other things into rttTMP In the buggy frames, the multiplication of step 3 is done after step 4. But there's absolutely no such order change in my code. I have yet to find what exactly triggers the bug, so can't create a small testcase yet. The occlusion queries need to be enabled and the camera needs to be at a proper angle, but that of course says nothing of the real issue. I'm in really unforeign territory here. If anyone has hints on what could cause the driver to ignore the given draw call order like that, I'd appreciate the pointers. My bug, sorry for the disturbance. |
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 65891 [details] Screenshot of the issue, bad camera angle In certain camera angles, gl_FragCoord.xy seem to have bogus/corrupted values. I tried to make a simple example but couldn't, so uploading an apitrace of the bigger app and screenshots. The apitrace is 60mb XZ-compressed, that's why the need to use a third-party service - upload limits here. This shader: void main() { gl_FragColor = vec4(gl_FragCoord.xy / vec2(640, 480), 0.0, 0.0); } should always create values from 0 to 1 in a window of that size. In the apitrace the only difference is that the size is passed in an uniform. This bug happens on both r600g and llvmpipe. I didn't have the patience to wait for softpipe to render it. I don't have anything else on this machine to compare to (swrast, blobs). Mesa 8.0.3 Linux 3.2.23