baldurk
commented
2 years ago I don't get the same reproduction as you describe.
On the branch provided I had to make some fixes so it would compile, but I then somewhat different results - when running with zink I got the same 'double vision' of the city, but when running without zink I got nothing rendered at all. Since you said it works fine for you on the plain GL driver, this seems strange to me.
When capturing with RenderDoc on the branch provided I got an empty background as you describe, but the buffers are not all zeros (at least the sparse buffer isn't). I did find a shader debugger error that caused some of the reads to come from the wrong buffer in the descriptor array, perhaps that's what you were seeing and misinterpreting?
I did see something which I didn't understand. Comparing the original GL shader from apitrace to the SPIR-V I don't see how it's supposed to work. At least a couple of the SPIR-V shaders are invalid - they have a small integer array at the start of the SSBO struct type which is indexed out-of-bounds, and the runtime array following that small array doesn't seem to ever be used. They're all the same type in an array binding even though the GL has different & incompatible bindings, but I'm not sure if that's something zink normally does and is expected to remap somehow.
FWIW I also tested on the main branch initially when things failed to compile, and while I got the same results without zink (nothing rendering) it rendered correctly with zink - the only case I was able to get it all to work. When capturing in RenderDoc I got results like this:
zmike
Description
When trying to examine https://gitlab.freedesktop.org/mesa/mesa/-/issues/7087 on zink+radv I came across a weird problem: capturing frames from this trace in renderdoc does not yield the same visual result as what I see when I capture the trace.
As in screenshots from the linked issue, when I capture the frame with zink+radv, I see the misrendered city drawn twice. When I open the same capture in renderdoc, however, all I see is the blue background and the hud. Looking at the texture viewer for the compute pass, the shader image output is solid white. Debugging the compute shaders reveals that the sparse ssbos used by the compute pass all contain zeroes when read back by renderdoc, so I think there is some sort of issue related to sparse buffer handling (possibly if there's a separate sparse binding queue in use?).
Steps to reproduce
This is slightly tricky to repro at present because it depends on unmerged mesa patches, so the main repo can't be used. I'll update this ticket as those patches are merged, but for now, you will want to build mesa from
https://gitlab.freedesktop.org/zmike/mesa.git use branch
renderdoc-bugThen download this apitrace file
https://gitlab.freedesktop.org/mesa/mesa/uploads/c7f0d68d003a7726961f0a5b9a804e05/frames4k.zip
Replay the trace with
MESA_LOADER_DRIVER_OVERRIDE=zink glretrace --min-frame-duration 10000 frames4k.traceYou should see the same misrendered city towards the end of the trace. If you capture a frame from glretrace with this misrender visible, opening it should yield the same result that I've described above, where the city render is not visible.
Environment
I tried capturing this on GL to compare, since radeonsi is able to render the city correctly, but it seems the GL capture in renderdoc doesn't support all the extensions required.