Did you check if it's a regression in either vkd3d-proton or radv? Might also be worth trying with amdvlk, if it runs the game.
Did some more tests.
With vkd3d-proton 2.8 the flickering is present, 2.7 crashes on startup.
Surprisingly, AMDVLK runs the game (with terrible performance) but the flickering is present there as well (and on a side note, turning on RT caused a GPU hang)
This also happens on Nvidia GPUs with vkd3d-Proton. It only happens at that one spot in the game, so I never bothered to go back and see if I can reproduce it on Windows.
I just discovered that the problem is much more noticeable if you lower the resolution and resolution scale. At 720p with the lowest internal resolution the issue can be observed on many objects in that area, not just the terrain and decals.
@K0bin I noticed the problem in other chapters as well, are you sure you didn't have it too?
Not an issue with the native Windows amd d3d12 drivers (the door decals at least). Without vkd3d-proton.
Save game:
flicker_save.zip
Just run to the door that is located a bit further ahead to the right.
I just discovered that the problem is much more noticeable if you lower the resolution and resolution scale. At 720p with the lowest internal resolution the issue can be observed on many objects in that area, not just the terrain and decals.
I didn't notice it anywhere else but I also played the game at 4k.
@Blisto91 by native amd driver you mean the proprietary one?
Oh missed writing the Windows part. No i meant i tested it on Windows without vkd3d-proton. Edited my comment to make it more clear.
Turns out this is caused by lack of support for ROVs. When ROVs are not exposed, they fall back to a shader which is bugged and does UAV writes with overlapping pixel coverage. This obviously won't work, and that causes the glitch. Seems like we'll have to implement ROV to fix this glitch.
Good to know, looking forward to it :)
Thanks
@HansKristian-Work That's awesome! I wasn't expecting a fix so quickly.
I can't get it to work though, Mesa 23.1 keeps throwing this error:
ACO ERROR:
In file ../mesa/src/amd/compiler/aco_instruction_selection.cpp:9172
Unimplemented intrinsic instr: intrinsic begin_invocation_interlock () ()
RADV does not support fragment shader interlock atm. NV and ANV does though. When RADV implements it, it should just werk.
Oh no, that sucks, I was so excited about APTR finally rendering correctly on linux :(
Is there an environment variable to turn it off so that it at least starts?
Wait, so the game doesn't work at all anymore? Game doesn't check the feature?
Nope, crashes immediately at the intro videos
sigh ....
Works fine for me. Sure you didn't use any VKD3D_FEATURE_LEVEL= overrides to force 12.1+? That would probably crash.
Getting proper validation now when it's trying to use ROV shader on unsupported device:
0170:warn:d3d12_device_validate_shader_meta: Attempting to use rasterizer ordered views in shader 43ac471956827cb4, but this requires capability to be supported.
It seems to fall back as usual in this case.
Oh yeah, it was still set to 12_2 from when I was trying various settings last week.
It now renders correctly, nice work!
It's not supposed to render correctly though (still bugged on RADV) ... but ok.
Well, the flickering is gone in chapter 8 (it was full of flickery wall decals), I'd have to play through the whole game to be certain but I don't see anything immediately wrong with it like before. It's still kinda stuttery but I think that's just how the game is, it runs like crap compared to the first one.
What is the RADV bug you've metioned?
Possible the game now reacts to the failed PSOs and tries a correct fallback now. I only spot checked the door in chapter 1 and it still flickers, but that's a very minor issue all things considered.
Oh yeah, the decal on the door still flickers, no problems with blood, shadows or terrain though
I too have the same GPU as adolfintel but haven't seen flickering except the door one (had to download save game included and check, on my own playthrough didn't notice it) and also at chapter 9 on the wall outside the fort (before the northernmost gate i think but really wouldn't have noticed if not searching hard).
Other than these two haven't seen any other flickering (on shadows or anything else)... But I did have screen flickering sometimes.. (as if blinking your eye kind of feeling)
Thank you very much VKD3D team! Playing with 8 years old CPU and have quite good fps... some scenes drop to 30-40 or lower but overall 60-80 fps.. I wouldn't call this stuttery after playing Hogwarts Legacy though!!!
Yeah after @HansKristian-Work's patch the game renders almost correctly. The occasional "black frame" is actually caused by ambient occlusion, if you lower the quality it doesn't do it. It doesn't go completely black by the way, just the shadows on objects.
I don't know why this glitch happens but it only happens on linux so I guess it's a vkd3d or mesa problem.
At this point I'd say requiem is "playable if you have to": it requires tinkering to get it running properly, it has this constant stutter every few seconds (though admittedly not as bad as hogwarts legacy, that game is a disaster), the ambient occlusion thing and the occasional sound crackling. I'd recommend playing this on windows at the moment.
The occasional "black frame" is actually caused by ambient occlusion, if you lower the quality it doesn't do it. It doesn't go completely black by the way, just the shadows on objects.
I don't know why this glitch happens but it only happens on linux so I guess it's a vkd3d or mesa problem.
You mean like this? https://gitlab.freedesktop.org/mesa/mesa/-/issues/8371
@Blisto91 can you upload the video somewhere? It's downloading at 3.3kb/s
I can when i get home. But the embed is playable for me on the mesa page 🤔
I'll just try nodcc and see if it goes away
That seems to have done the trick. Thanks @Blisto91 :)
👍. Could i get you to make a mesa issue? I thought it was only a problem on rdna3
Yes, I'll try to open it when the site becomes usable again, right now it's atrociously slow. I'll see if i can make a good quality video with slowmo while I wait.
Is this with latest mesa-git btw?
Edit: actually nvm the work around for my issue was applied only to rdna3
@HansKristian-Work your latest enable_experiemental_features flag fixed the few remaining flickering decals (literally 3 small spots in the whole game, I counted them), however the game no longer detects ray tracing support for some reason.
That's caused by ROV now being supported by Mesa thanks to Triang3l's work.
Any idea of what's up with ray tracing? Is the game looking for some caps that are not exposed with this new flag?
No idea. Someone needs to bisect it.
I can do it but I can't go very far since you just added that flag yesterday. RT is detected and works without the flag
Please file a new issue about this.
proton 2.8x1 2023-02VKD3D_FEATURE_LEVELx1 2023-02RADV_PERFTEST=rt,gplx1 2023-02
As the title says, I'm testing A Plague Tale Requiem using VKD3D (current master, built from source) and I noticed that some decals, some shadows and some parts of the terrain have flickering squares on them.
System info:
Configuration:
I tried changing every setting that I could think of and I also tried tinkering with the application workarounds in device.c (tried every single flag) but nothing had an effect. The flickering is not present on Windows.
The problem can be observed about 10 minutes into the game when you're in the castle and a guy gets killed: the blood flickers, a shadow on the wall on the left also flickers, and the same thing can be observed in several other locations throughout the game.
Nothing interesting in the logs.
Here's a video of what it looks like on a decal on a door in chapter 1:
aptr flickering.webm