AMD GPU corrupted rendering

[dotlogix]

AMD GPU corrupted rendering

[MrJul]

I had a long debug session two weeks back trying to understand the issue.

Long story short, Estragonia/Avalonia/Skia writes to a render target correctly, but that target is discarded by the driver before Godot uses it (as seen in RenderDoc). It really smells of bad Vulkan synchronization. I've tried a number of Godot barriers calls, to no avail. The same Vulkan queue is used by Skia and Godot, but they have different command buffers, which I suppose is the core of problem.

Since then, I've read a lot about Vulkan barriers, fences and semaphores and have a few new ideas to try, but didn't have time to do so yet. It involves setting up some Vulkan barriers manually, hoping I can get that right since we don't control Skia nor Godot.

It also doesn't help that SkiaSharp 2 is stuck on milestone 88, which is 3 years old. Newer Skia versions have new options regarding GPU synchronization (SkiaSharp 3 will help, but it will take a while before all dependencies in the chain get updated).

[dotlogix]

@MrJul It looks like one issue is the OnDraw call in the _Draw method.
If you remove it it rerenders after a resize you still have the issue in the initial render though.

I could solve it by ignoring the clear if the view was never rendered. It is an ugly hack though. I also tried InvalidateVisual in various places but didn't help.

[MrJul]

I've pushed a workaround forcing re-render for the first frames, to counter the clear. Not the best solution, but it will do for now :)
Package 1.2.0-preview1 has been published with all the changes, targeting Godot 4.3.0-beta1.

I'm closing this issue as we can't do better for now. Feel free to reopen/ping me if there's anything not working on Godot 4.3.

[MrJul]

Hello and thanks for reporting.

Unfortunately I can't reproduce it with Godot 4.2 Dev 4: everything works fine for me on Windows 11 22H2 with a RTX 3080.

However, I've read that 4.2 changed a few things regarding synchronization inside the rendering server, so there might be changes needed, not all Vulkan drivers are the same.

• Can you please confirm that you can run HelloWorld and GameMenu fine in Godot 4.1?
• What's your OS, GPU and GPU driver version?

[dotlogix]

Hm seems like it is the same issue on 4.1.

Os: Windows 11 Pro 64-bit (10.0.22621 Build 22621)
Cpu: AMD Ryzen 7 3700X 8-Core Processor
Gpu: AMD Radeon RX 6700 XT
Resolution: 1440p

Latest drivers are installed of course :)
Could it be a timing issue? I noticed Godot changed the threading part of the RenderingServer lately. Also it could be possible to change your code to use the new Texture2Drd instead od a custom viewport. I tried to implement that, but unfortunately I don't have much experience with Skia.

As a sidenote I also use avalonia at work, and there I don't experience any visual issues.

[dotlogix]

@MrJul this seems to be the underlying issue: godotengine/godot#56687

[MrJul]

It's also possible that a barrier is simply needed here, I can try experimenting with Texture2DRD to see if this fixes the issue (thanks for pointing me to it). The main problem here is for me to be able to reproduce the issue to see if it's some missing synchronization from Estragonia, or a real bug in Godot, as linked.

As a simple experiment, if you change this line:

Estragonia/src/JLeb.Estragonia/GodotVkSkiaGpu.cs

Line 96 in 5669f75

RenderTargetClearMode = SubViewport.ClearMode.Never,

from Never to Always, does the problem still exist? It shouldn't be normally needed, as Avalonia is already clearing the render target itself.

[dotlogix]

I assume it is a barrier issue somewhere. I tried experimenting with the clear mode and it seems like
var gdTexture = gdViewport.GetTexture();

does not return a clean texture on AMD devices. If I debug through it very slowly the issue is gone. So I assume there is access from multiple threads or the old surface still writes to the same VRam used by the new Viewport.

Unfortunately I wasn't able to find the place where it actually writes to the texture. Not very familiar with Skia tbh.

[MrJul]

does not return a clean texture on AMD devices

At this point in the code (in GodotVkSkiaGpu.CreateSurface) I wouldn't worry about it, the texture won't be clean until the render pass.

When Avalonia starts rendering, it clears the render target then queues the various draws commands to the SkSurface. Those commands are flushed to the GPU here:

Estragonia/src/JLeb.Estragonia/GodotSkiaGpuRenderSession.cs

Line 28 in 5669f75

=> Surface.SkSurface.Flush();

You might want to try adding a RenderingServer.GetRenderingDevice().FullBarrier() call right after the Flush one to see if it solves the problem (warning: that will probably tank performance).

Note that I can have access to an integrated AMD GPU to further debug the issue but I probably won't have the time to do so before next week.

[dotlogix]

Nope it does not resolve the issue. But yeah it is not super high prio for me. Will propably design sth else myself :) more in the direction of vuejs for godot. But pls keep me posted if you can resolve it because I really appreciate your effort.

[schragnasher]

Dang just ran into this on my AMD card. Its ok though I can still make progress on what I wanted to do, hopefully it gets resolved.

[MrJul]

I can reproduce with the iGPU from a Ryzen 7700X, that's a start.
Now to debug...

[schragnasher]

Once you have possible fix ill pull it and give it a test

[schragnasher]

Any updates on this issue?

[schragnasher]

Gotcha, thanks for your work.

[MrJul]

FYI, I wanted to try Godot 4.3 dev version since the new acyclic command graph should ensure that Godot's Vulkan commands are correctly ordered, to see if it still reproduces or if I can now find a solution.

However, I couldn't complete my tests, currently blocked by godotengine/godot#89979

[schragnasher]

dang, lol ill be looking out here for an update once you have something to test.

[schragnasher]

looks like its in a PR, so shouldnt be long now

[UQuark]

Today I encountered this bug and found this thread. Unfortunately, the bug still persists in Godot 4.3
Also, a suggested workaround with Update mode: When parent visible did not work either.
Is there some other way to render a 2D progress bar into a 3D scene in a billboard-like way?

[dotlogix]

@MrJul So I spend a few days on this issue again, even rewrote most of the synchronization logic and updated everything to the latest versions.

I also managed to use Texture2Drd instead of viewports and to render using the RenderingServer directly. Basically I really tried everything.

But for some reason the first image I receive after resizing is ALWAYS corrupt. I am not sure if this is an issue with Avalonia, Skia or Godot but I think I am done with this.
Propably an issue with proper VkFences somewhere.

RdTextures in Godot actually use Fences, but I guess Avalonia / the SkiaSurface does not. No Idea how to fix this.

I guess I will go back to my original Plan and actually create an alternative UI library myself :)

[MrJul]

@dotlogix Sorry, I didn't push it earlier because it's still WIP but have a look at the godot43 branch, and use Godot 4.3-dev6.

There are no more warnings from the Vulkan validation layer, thanks to additional fences added manually, and corruption is fixed on AMD GPU, at least in my tests. Can you confirm?

The only downside is that the UI disappear for a couple frames while resizing, because of an extra clear needed. It comes back as soon as resizing is finished, which is an acceptable workaround IMO.

Note that the exact same code doesn't work in Godot 4.2, so the acyclic command graph really helps here.

[dotlogix]

@dotlogix Sorry, I didn't push it earlier because it's still WIP but have a look at the godot43 branch, and use Godot 4.3-dev6.

There are no more warnings from the Vulkan validation layer, thanks to additional fences added manually, and corruption is fixed on AMD GPU, at least in my tests. Can you confirm?

The only downside is that the UI disappear for a couple frames while resizing, because of an extra clear needed. It comes back as soon as resizing is finished, which is an acceptable workaround IMO.

Note that the exact same code doesn't work in Godot 4.2, so the acyclic command graph really helps here.

IT WORKS!!!

Thank you sooooo much. I really have to check what you have done to fix it because I obviously couldn't :D

Finally no need to use the "crappy" Godot UI :D

[dotlogix]

@MrJul When do you expect to update the nuget package?
Would be nice to have this even if it is an alpha/beta prerelease for now :)

[dotlogix]

@MrJul So I tried around a bit and there is one flaw I guess.

If you remove the animation in the HelloWorld example it doesn't render anything.
So for example if you just create a UserControl add a TextBlock and start the App it renders nothing.

[MrJul]

@MrJul When do you expect to update the nuget package?
Would be nice to have this even if it is an alpha/beta prerelease for now :)

I was about to release a preview for this change.

If you remove the animation in the HelloWorld example it doesn't render anything.
So for example if you just create a UserControl add a TextBlock and start the App it renders nothing.

Thanks for the report, it definitely requires more testing!
I can't reproduce currently with the HelloWorld: it renders correctly even with the animation disabled. Let me try with a simpler view.
Edit: reproduced