Developing Games on Intel Graphics
If you are gaming on graphics integrated in your Intel Processor, this is the place for you! Find answers to your questions or post your issues with PC games
547 Discussions

Framebuffer content in Vulkan using dynamic rendering local read are corrupted on ARC

AscendedFern
Beginner
4,019 Views

Hello,

I initially wrote a support ticket for this issue and was redirected here. The issue is easier to illustrate using the attached renderdoc capture, but essentially:

Context: I wrote a deferred renderer using Vulkan and dynamic rendering with local read, it was working fine on a RTX2060 and a A4500 systems, but fails (with no validation issue) to write to accumulation buffers on my B580.
Issue: The content of my framebuffers (except the first one I write to) gradually degrades to black over the course of the pass. 

My guess: The local read memory barrier might not be working as intended on ARC.

I will try to reproduce it in a small project this weekend, but any pointers to diagnose the issue in the mean time would be appreciated.

Note that aside from the texture viewer itself, other debugging options (like pixel shader debugging and pixel history) indicates that this should work like intended. The artifacts on the texture viewer can vary in size, shape and location, probably because this is a synchronization related issue.

Here is my ticket for reference:

I wrote a simple Vulkan Deferred renderer for training using Vulkan 1.3 and Dynamic rendering with local read (the latter might be the source issue) and have had trouble making it work on my B580. I've tried many little tweaks but I think it might be a driver bug.

There seems to be a problem with writing to accumulation buffers (you can see some artifact appearing on the second light draw on the attached render doc capture (event 31)) and the buffer being completely garbled on the next draw call beyond the memory barrier (event 40). Deactivating blending removes the early artifacts but the buffer still "collapses" towards black after the second memory barrier (event 32). Only the first attachment(normal and smoothness) seems unaffected by this, maybe because it is written to early and is only read from after. Debugging shaders or checking pixel history on render doc will give the expected values (mismatched with the texture viewer). No Vulkan validation layer is triggered (except a few best practice ones triggered by steam or renderdoc layers, but it doesn't seem possible to rule it out completely), I've checked that the renderer works on several NVIDIA cards (I don't have access to AMD hardware at the moment). Here is a link to the file where the command buffer is recorded: https://github.com/Basil42/Osmium/blob/master/OsmiumGL/ShaderUtilities/src/MainPipeline.cpp (see RenderDeferredFrameCmd()) The file where initialization is done (using vk-bootsrap): https://github.com/Basil42/Osmium/blob/master/OsmiumGL/Core/src/DynamicCore.cpp (see Initialize() and RenderFrame()) 

Labels (4)
0 Kudos
2 Replies
karen_intel
Moderator
3,984 Views

Hello @AscendedFern and welcome to our Game Developer Support forum

Thank you for sharing, I ran the RD capture and I can see the artifacts on the texture viewer.

We might need to open an internal report for this so, having the reproduction project you will work on, will be great to escalate this case.

Also, aside from the project, could you share your SSU file? 

Make sure to check all the boxes please and keep us posted on your progress

I'll be assisting you in this case, have a great day

 

Karen

 

0 Kudos
AscendedFern
Beginner
3,834 Views

Hello,

Haven't had the time to do a minimal repro yet, perhaps during the weekend.

I've attached my SSU file in the meantime.

I've also just updated my driver, with no change to the issue.

Best,

0 Kudos
Reply