AMD 780M Vulkan renderer leads to corrupted textures #1176
Comments
|
Edited to update: Seems like VK_EXT_attachment_feedback_loop_layout is necessary on modern AMD architectures. There is a fork with a non-optimal implementation over at |
|
Something you can do to help in the meantime is upload a Vulkan validation log. The steps to do this are:
|
Thank you for getting back. I had a similar line of thought and I found this very strange, as I am unable to replicate this on RDNA 2 As per AMDs own documentation, their vulkan implementation is the exact same on both RDNA 2 and 3. I wish I had a discrete RDNA 3 card to test this, but if a future driver update from AMD remedies the issue, I will update or close this ticket As it stands, I am disappointed at amd, as all handheld devices use AMD Apus, and I am unable to distinguish if this is an APU driver or RDNA 3 issue PS: I tried seperate driver versions and ddu with no success. Thank you for keeping an eye on this |
The last version I tried which is this was broken However, 2.0-78 has seemingly fixed the issue! Heres the log attached below with vulkan debugger What I can conclude is the last version I had downloaded (2.0-46) just did not play nice. Strangely my 6800xt never had issues with any version (including 1.2.6), so its rdna3 driver related bug on older builds Image of 1.2.6 corruption: Thank you for walking me through this |
|
Welp, @Exzap turns out Cemu2.0-78 only fixes the pebbles or greatly reduces the amount of initial corruption. After further playing the game and wind waker, the issue is still present. I have recorded a video for reference and the prior vulkan debug log is still valid As usual, I'm unable to replicate this on my desktops with rdna2 and ampere cards and can reliably repeat this on any 780m based device like Ally/Win. The only fix is using OpenGL and rolling back drivers doesn't change anything Kindly let me know if you require further logs or information, kind regards vulkan.bug_1.mp4 |
Their Hardware ISA however, is not. More recent findings have come to light regarding the Gfx11 Delta colour changes and their assumption of a general compressed layout for resources + abitrary reinterpretation for DCC introduced somewhat of a perfect storm for graphical misbehavior if assumptions have been made, or if a particular sampler needs a particular layout when attempting to reuse it in a feedback loop. RDNA2 is affected under very specific conditions, the van gogh in the steam deck for instance has artifacts in WWHD, and the same set of extensions that should resolve RDNA3's texture layout misbehavior resolved similar troubles DXVK had with RDNA2 in games such as GTA4, with RDNA3 no known operations will result in a DCC being disabled, which was not highlighted in the ISA manual but had to be dug out of their PAL or MESA commits. GPU-Open has not been updated for these ISA changes either. |
Hey, thank you for clarifying that and filling in the gaps. I assumed 2 and 3 used the same ISA but that certainly explains the discrepency here As far as I can tell, all RDNA3 cards are affected including someone I know with a 7900XTX. Seems like its a waiting game for RDNA 3 users which is a shame, as a lot of portables are/will be based on RDNA 3/3.5 |
|
Just fyi, similar issue was recently fixed in ryujinx and sudachi. Tested on BOTW. Dont know if it is exactly the same issue, but the artifacts/ glitches looked exactly the same in the switch version like they look in cemu. So there might be a way to fix it despite the fact that it is probably RDNA driver related? |
|
They implemented the For context ryujinx' PR: https://github.com/Ryujinx/Ryujinx/pull/7226 |
Even though you guys cant work on it anytime soon, I appreciate the heads up with this being on your radar. As more gaming handhelds ship with amd apus, this being broken on 24.8.1 still mean the most popular gaming handhelds are locked out (Rog ally, legion go, acer, zotac devices) But i appreciate the ongoing improvements that go into cemu and the work that contributors put in. I am hopeful this will be resolved one day |
|
I've experimented with |
Hi just tested, and I want to report back, that fork completely solves the issue! First boot was weird, with app losing 60% of its frametime, but subsequent boots have been flawless. Here are some screenshots: By default, it has "Accurate barriers (vulkan)" enabled under Debug. Keeping that off seem to cause no issue, with enabled costing 2-3 miliseconds in frametime vs off (in action) 
Overall, I plan on using this build for a longer session after this. Texture corruption from pebbles and all the aliasing seem to be resolved for now. Thank you the heads up, I will be passing this onto some personal acquintances that have been waiting for a cemu resolution, and so far so good I tried finding a log file, there was none. But if you require any further info/logs, please let me know😊. @dstrnad might also find this useful, if they have a similar use case |
|
I can also confirm that this fork seems to completely fix the issue. No black/ colourful glitches anymore. I tested on Rog Ally. Accurate barriers settings on/off makes no difference now, the issue is gone. Good job @goeiecool9999 and thanks for the heads up @Not4ce. I will finally try to play the game now, if I can test anything else just let me know. It would be awesome if this could get merged at some point. |
|
Bad news, the fork sometimes crashes when opening or exiting inventory and map menus. Weird is that I can open or close the map/ inventory couple of times (even like 10,20,30 times) and it is ok, but then it randomly freezes the whole game and cemu crashes. |
|
@goeiecool9999 I’m on 24.3.1. I plan to test it under linux, so we can rule out any windows driver related issues. |
where can i download this build? |
@TheOneEyedGrimReaper |
lel. |
This would be very much appreciated. Sorry for the late reply, @dstrnad is correct and testing on linux would help which i am unable to do Cemu crashes after 30 minutes of use with exception x0409, which to my understanding is a stack buffer overrun, so something gets corrupted around 20-30minutes. As far as i can tell, the driver may not be the issue. I have tried 6 driver versions so far, ranging from 24.3.1 to 24.8.1 (including 3 seperate devices, and the technical preview drivers from amd) 
I will also attach the actual crash log here, which i suspect may not help too much? But why not. If you need anything else, please let me know @goeiecool9999. So far, the crashes can happen at any time in shrine/overwold/zone, looks to be related to how long cemu was running |
|
@Not4ce I'm not very familiar with the windows event viewer and I don't know if it contains useful information. If you could send cemu's log.txt after a crash instead that's more likely to contain a helpful clue. I'm mainly interested in seeing the stack trace at the end of the file. |
|
@goeiecool9999 It tries to eat more than my actualy allocated vram and then freezes up my rog ally completely. |
I didn't change anything related to GPU memory allocation. Are you sure you're running out of VRAM and not regular memory? |
|
Hi, tested your build, works like a charm for me. I'll test it further this week. thanks for sharing this |
yep i'm sure of it. |
|
I found a memory leak and fixing it appears to make GPU memory usage stable. Let me know if this improves stability. |
|
I think you fixed it. I’ve been testing for an hour on linux (bazzite, Rog ally) and memory seems stable, no crashes so far and no glitches. I will test more, but good job 👍 |
I haven't been entirely scientific. I merged some changes from main that happened after the release of 2.2. So it could be one of those as well. Anyways, if the new driver really does make the problem go away that's preferable because like I said before, I'm not very happy with the implementation of my fix using the extension. I would probably want to rewrite it to get it in a merge-able state. |
|
@goeiecool9999 Regarding difference between your previous build and a new one dcdfa82
5640d58
SummaryOn average I'm getting around 5 frames more than I did on previous build, sometimes dcdfa82 jumps to 160 as well but it doesn't happen to keep that number and drop to 145-150-155 while 5640d58 is able to jump even higher to 163 and keep itself around 155 stable without random drops to 145 for 0 reason. |
|
The performance penalty for the image memory barriers seems to be far less with mesa compared to windows. I would say that tiny of a difference is probably not statistically significant. The difference that Valkyr2 reported is more in line with my expectations. |
|
Anyway I assume that I'm cpu-necked so it's not like my renderer is overloaded with anything, GPU is under 50% load while couple of my cpu cores go up to 100%. Maybe that's why I can't see much of a difference. |
|
The term bottleneck really only applies when you're dealing with parallel processes where one process depends on the output of another (or a chain of processes). The CPU and GPU are effectively parallel processes. While the GPU is processing one frame the CPU can work on the next frame simultaneously. This means that a frame can take up to 1/fps seconds to process on the CPU AND 1/fps seconds to process on the GPU before you see stutters. Like with all pipelines there's a latency increase but the performance improvement of having both processors do work simultaneously is worth it in the vast majority of cases. If the GPU is the bottleneck (assuming no FPS cap) it would be active 100% of the time and the CPU would be idle some percent of the time waiting for the work queue to have space for the frame it just processed. If the CPU is the bottleneck the CPU is active 100% of the time and the GPU idles some of the time waiting for the work queue to be non-empty. I'm going off of what others tell me but Breath of the Wild's engine on Wii U is designed in such a way where the CPU waits for the GPU to be completely idle somewhere during the frame. That means that the GPU will always be idle for some time during the frame until the CPU submits more work, no matter how fast or slow the CPU or GPU are. So even if the GPU was a potato you would not see 100% utilisation. You can improve the time between the CPU resuming when GPU is idle and the CPU submitting more work by getting a faster CPU, but you can also decrease the amount of time the CPU has to wait for the GPU to become idle by getting a faster GPU. Without measuring which of these delays is longer it's difficult to tell which component would give the biggest performance improvement (and even when you do it might not be obvious). To tie it back to my point about the term "bottleneck": Normally if one component is a bottleneck upgrading the other wouldn't make a difference. In this scenario upgrading either can have a positive impact. So neither can be said to be a true bottleneck. (PS: I think GPU utilisation actually becomes a proxy for those delays I mentioned earlier. As the GPU approaches infinite speed GPU utilisation approaches zero. As the CPU approaches infinite speed GPU utilisation approaches 100%. So if GPU usage is 50% the CPU and GPU are evenly matched, when it's at 75% that means it's slower and may be worth upgrading. if GPU usage is 25% you might consider upgrading the CPU. I'm not sure. That part might be blatant misinformation 😅) |
|
@goeiecool9999 @Not4ce @Squall-Leonhart @Valkyr2 I'm back with some.. Let's just say I'm not sure if this is good or a bad thing that I'm about to report. I'm now writing from my Windows 11 Pro 24H2 (OS Build 26100.2033) instance on the same exact PC, specs of which you can see above in this message. This exact driver has nothing to offer regarding Vulkan emulation issues on it's release notes which you can find here. As well I downloaded Cemu 2.2 from latest releases again from here which also doesn't have any fixes regarding Vulkan emulation. You already feel where I'm leading, right? Not a single artefact problem on Cemu 2.2 on Windows 11 24H2 with 24.10.1 AMD GPU driver: On Linux, on the other hand Mesa and Vulkan-Radeon packages got updated recently so I checked that out as well - no changes I'm still artefacting. Both Cemu are set up identically on both machines with the same resolution, graphics packs, etc. Here's my latest installed packages on Linux: [aasda@arch ~]$ sudo pacman -Q | grep mesa
lib32-mesa 1:24.2.6-1
libva-mesa-driver 1:24.2.6-1
mesa 1:24.2.6-1
mesa-utils 9.0.0-5
[aasda@arch ~]$ sudo pacman -Q | grep vulkan
lib32-vulkan-icd-loader 1.3.295-1
lib32-vulkan-radeon 1:24.2.6-1
vulkan-headers 1:1.3.295-1
vulkan-icd-loader 1.3.295-1
vulkan-radeon 1:24.2.6-1Least to say - I'm confused. I have tons of questions, perhaps everyone here as well. |
|
it's worth noting (and something i've seen in Switch emulation too) that once a pipeline is cached in a good state, artifacts that occured on a bad build may not occur with that bad build after a good build has updated the cache. |
|
Well I removed all of my shaderCache folder and nothing really changed on Linux. |
|
@goeiecool9999 The water in Gerudo town is still cracked on 5640d58 |
|
that requires accurate barriers turned on. |
|
@Squall-Leonhart Uh, yeah, that seems like a solution.
|
|
the red dots back O_O |
|
@Squall-Leonhart easier to show than explain: https://www.twitch.tv/player_killer_paradigma/clip/WonderfulFitKathyNinjaGrumpy-4z-7KcYDoG9nqUpA Here's its lowkey BLACK, but if I would get somewhat blue sky it would be red.
|
|
i didn't see that in the clip... wtf. |
It's hard to catch if you have low refresh rate monitor like 60 for example, because I stream at 90 frames per second, but if you are at least 90hz you can easily catch this one single frame with black dot (easier to see on 0.25x speed but even there it's hard to get this exact frame) It's not AS annoying as artifacts so I can even ignore it however that is.. here and I never saw anyone mentioning this. And I mean it appears quite rarely and only in the distance, so if you don't happen to look far and have some wall infront of you - it's a non issue. But if you look far that happens often, here's number 2: |
So this version (appimage) fixes my issue with MK8 stuttering, it goes from a solid 60fps to sutter to 55fps then back up to 60fps. Not sure if this helps, but all the textures were fine in MK8, just this very noticable stutter. |
|
24.12.1 has resolved the crashing issues, and seem to be generally better vulkan drivers then amd has released since about 24.3.1 (I mean, starcitizen is fixed too so yeah) so testing should be performed on those from now on. |
This build also fixes visual glitches on AMD GPU in Paper Mario: Color Splash |
@goeiecool9999 This build fixes both the texture corruption and the frame pacing issues I have in BOTW. |
Is there any update on the merge of this issue please? Been testing the last version from @goeiecool9999 for several months now, works great, fixes the issue, but would be nice to be able to officially update Cemu again. Thx |
|
I switched from the flatpak to appimage and the issue went away. I'm sure I could have found a newer vulkan for mint os, but path of least resistance wins. |
|
I started having the texture corruption problem once I got a whqd monitor (with a 7700xt)... is there any update on the merge with main? Or could someone upload the @goeiecool9999 latest build, because the download's options are all expired. Thanks |
|
Also surprised why it is not merged to master. |
Could you pass me the windows version? Thank you very much |
@layard32 So far as I tested months ago, it's fixed on windows drivers for RDNA3 gpus, the issue remains on Linux with any driver vulkan implementation eg amdvlk / radeon-vulkan. So on Linux you play with the build mister @goeiecool9999 created (thanks you SO MUCH), on windows you can play official cemu and things should be fine. Just make sure you have the latest adrenaline driver installed. You can read my post about my windows vs linux tests here: #1176 (comment) |
|
one reason this isn't merged as is, is it decimates performance on the nvidia driver.
Absolutely, is not. |
|
@Squall-Leonhart uuh... how do you explain #1176 (comment) then? no offence just trying to grasp your point |
can be added as options to turn on and off ? |
|
I am not sure what the current state of @goeiecool9999's fork is exactly but from what I understand it's not optimal and it can hurt performance on some drivers and it may not even cover all the cases where there is an actual feedback loop. The latter is a problem outside the scope of the fork, there are design decisions in Cemu's Vulkan renderer code that make it hard to implement the feedback loop extension. I believe the better way forward, which is in line with what modern Vulkan wants us to do, is to also adopt This will all happen eventually but there are too many unknowns to give any sort of ETA. In the meantime you can use the fork. |
Current Behavior
Enabling vulkan on rdna 3 based cards, such as 780m igpus break pebbles and textures in-game. Also broken shadows that eventually garble and have corrupted textures. Observed in MK8 and BOTW. No graphical or texture enhancements applied, can be replicated on two seperate 780m devices
Vram allocation does not change anything. Only fixed by changing renderer to OpenGL, and seems to be Rdna3/780m specific. Was unable to test on a discrete rdna3 card, no issue on Rdna2 and Nvidia counterparts (6800xt and 3070)
Expected Behavior
Nil graphical issues and not garbled textures
Steps to Reproduce
Enabling vulkan renderer
Playing any game: Breath of the wild etc
System Info (Optional)
OS: Windows 11 22631.3374 KB5035942
GPU: 780M on Ryzen Z1 Extreme and 7840u
Emulation Settings (Optional)
Default with no mods or changed
Also Tested with:
BCML enabled
Second Wind enabled
No graphical mods or changes on 1.2.6 and 2.0 cemu
Logs (Optional)
log.txt
Tested with OpenGl that had no issues, followed by switching to Vulkan with issues (UMA frame buffer set to 6gigs on system)
The text was updated successfully, but these errors were encountered: