Remaining RADV Vulkan Driver Bugs for Vega Being Addressed

[geearf]

Citation needed. I just ran some tests against my older Mesa builds. A build from Oct 21 showed very poor performance, and a build from Nov 18 had the fix. The 17.2.6 stable release (tagged Nov 26) and even 17.3.0-rc6 (which I built and tested just now) does *not* have the fix - so only recent builds against mesa-dev can play it.

I only discovered this last week - I get between 38 and 60 FPS with all video settings on and maxed out (except vertical synchronization obviously, as well as ambient occlusion due to a graphics corruption bug related to that option) at 2560x1440 on my Fury X. A couple of months ago I'd be lucky to get 25 FPS on average (with the minimum video settings and 1280x720), which is basically unplayable for this type of game. I intend to finally (finally!) complete the campaign over the upcoming holidays.

You might remember that I was quite vocal here about how disappointed I was, first when it wouldn't run (back when everyone thought it required compatibility profiles), and then about the performance when it did finally run. I was posting to the bug report on bugs.freedesktop.org last year. I know all about the history of this game and what a nightmare it has been up until now.

Hmmm, there's one user above your post agreeing, and one above this, do you really need more citation?
The fact that it (finally) works fine for you is unfortunately irrelevant to the fact that it does not work for everyone / on other systems.
As pete910 mentioned, we believe it's related to *buntu stuff, but what? no one knows. It may actually totally be unrelated to Mesa, since I have not tried with amdgpu-pro, nor have I ever seen anyone in these reports mentioning it, I have no idea, but it's definitely possible.

I'm one of them, refuses to play with mesa on Antergos regardless for mesa version. A friend of mine spent hours trying to work out why as it works in Ubuntu fine. Even pulled the source ect from the ubuntu package and compiled with same flags. Still didn't work.

I never understood either :'/
It's interesting that he tried to use with Ubuntu packages, which package did he try with? (just curious).
Have either of you try with the pro driver instead?

[airlied]

Thanks Samuel!

This is getting annoying now. I've been trying to run Wolfenstein II: The New Colossus under Wine using RADV. It can't be done right now (tested on a Fury X), as the graphics corruption make the game unplayable in some areas. For AMD GPU hardware owners, the only way to play is with AMDGPU Pro proprietary drivers. For now at least (as I see David has been looking into the situation).

I thought we were past the days of needing AMDGPU Pro for gaming. Particularly so with Dying Light working amazingly well under Mesa these days with surprisingly excellent performance - something I previously gave up on ever seeing on non-Nvidia hardware. But now we're seeing a number of Vulkan-only games getting released that aren't working right, and the promised code which was going to fix everything for users of the free software stack is nowhere in sight.

If it weren't for people like David (at RedHat) and Samuel (at Valve), AMD users would be completely screwed right now. Has there been any official word from AMD to explain what is going on?

Wierd I've been playing it for a while on rx480, though wine causes some of the problem, once I got wine patches up it seems to run for me pretty well.

Dave.

[boltronics]

Wierd I've been playing it for a while on rx480, though wine causes some of the problem, once I got wine patches up it seems to run for me pretty well.

Dave.

Hmm. The final cut scene just before the demo ends shows what looks like some light sources in a pitch black room. Nothing was rendered aside from white light(?) rays. There were other times where the game would randomly black out half or all of the screen for a few seconds, but I was able to get past them by just blindly running forward and hoping for the best. The lips on many of the NPCs when talking were messed up somewhat.

This was mesa-dev from last weekend, so maybe it's sorted now. Will re-test again tonight if I have time and upload the results to YouTube for comparison.

[boltronics]

Hmmm, there's one user above your post agreeing, and one above this, do you really need more citation?

Confirmation of git commits or dates and branches tested, and obviously the card used would be nice to know. Of course it's entirely possible it's only fixed for FIJI cards, but there's not enough information to make that determination so far. I might test on a R9 580 over the weekend for comparison.

[geearf]

Confirmation of git commits or dates and branches tested, and obviously the card used would be nice to know. Of course it's entirely possible it's only fixed for FIJI cards, but there's not enough information to make that determination so far. I might test on a R9 580 over the weekend for comparison.

So far I don't think it relates to a specific card, but to the distribution. Of course, with no system both failing and working, it's hard to say.
My card is a 280X I don't remember the various mesa builds I've used, but I've just tried on 98351.e0c6769ef5 with no change.

Interestingly, in my case, I get a black screen with a growing white line at the bottom left of my screen; it will grow till the right of the screen and then the whole thing will sigsev.

Here's the backtrace:
Thread 1 "DyingLightGame" received signal SIGSEGV, Segmentation fault.
0x00007ffff1d8e05f in CTextManager::Initialize() () from Dying Light/libengine.so
(gdb) bt
#0 0x00007ffff1d8e05f in CTextManager::Initialize() () from Dying Light/libengine.so
#1 0x00007ffff1d8e1b0 in CreateTextMgr() () from Dying Light/libengine.so
#2 0x00007ffff1d7ba9c in CRenderer::LoadResources() () from Dying Light/libengine.so
#3 0x00007ffff18711b0 in CGame::Initialize(char*, int, void*, void*, unsigned int, unsigned int, IProgressIndicator*) ()
from Dying Light/libengine.so
#4 0x000000000043dfb5 in main ()

[boltronics]

So far I don't think it relates to a specific card, but to the distribution. Of course, with no system both failing and working, it's hard to say.
My card is a 280X I don't remember the various mesa builds I've used, but I've just tried on 98351.e0c6769ef5 with no change.

Fair enough. It appears that e0c6769ef5 is a three day old commit, so you would surely have tested the fix I was talking about. Unfortunately I don't have a card that old that still meets the minimum game requirements to test with. The closest I have is a R9 285, but it's a newer architecture which the amdgpu kernel module was designed to support right from the start, so probably not a meaningful test.

Interestingly, in my case, I get a black screen with a growing white line at the bottom left of my screen; it will grow till the right of the screen and then the whole thing will sigsev.

That's actually normal - it's how the game loads up. Well, not the sigsev bit - it's supposed to go to a Techland logo clip immediately after that.

But I've been able to play the game ever since around the time Mesa introduced the drirc profiles for it, so this is definitely a different bug. Come to think of it, I think I may have even had it working on the 285 at one point. Sorry, I know that's not helpful.

If it is distribution related, my setup is Debian Stretch, I'm currently running a 4.15.0-rc1 kernel, running LLVM 5.0.1 using the official LLVM apt repository at http://apt.llvm.org/, libdrm and xserver-xorg-video-amdgpu are also built from git master. Everything else is whatever Debian stable ships.

[boltronics]

Wierd I've been playing it for a while on rx480, though wine causes some of the problem, once I got wine patches up it seems to run for me pretty well.

Dave.

I've got a video uploading to YouTube (here) which should be ready in the next hour or so showing the various glitches I experienced under Mesa/RADV, which I also pointed out in the video description.

You're probably already aware of the issue with the lighting and faces, but skip to the end of the video to see how bad it eventually gets. Tested on Mesa 17.4.0-devel (git-392638d6b5).

[geearf]

That's actually normal - it's how the game loads up. Well, not the sigsev bit - it's supposed to go to a Techland logo clip immediately after that.

Oooh I always thought it was something bad.

But I've been able to play the game ever since around the time Mesa introduced the drirc profiles for it, so this is definitely a different bug. Come to think of it, I think I may have even had it working on the 285 at one point. Sorry, I know that's not helpful.

It most likely is a different bug indeed

If it is distribution related, my setup is Debian Stretch, I'm currently running a 4.15.0-rc1 kernel, running LLVM 5.0.1 using the official LLVM apt repository at http://apt.llvm.org/, libdrm and xserver-xorg-video-amdgpu are also built from git master. Everything else is whatever Debian stable ships.

Now that's interesting, I think you're the first one I've read to get it working on a non *buntu distribution.
Maybe it's because of some of the base packages (gcc, glibc, etc). I wish I could see something relevant in the backtrace to try but really no...

strace has way too much stuff for me to follow through.

[geearf]

Well using Solus' Steam snaps I was able finally to run the game!
Now it'll be interesting to see what's in the snap, and which package in there is the savior.

[Grim85]

Wierd I've been playing it for a while on rx480, though wine causes some of the problem, once I got wine patches up it seems to run for me pretty well.

Dave.

I'm also getting issues with the patched wine on my R9 Nano with a recent mesa-git build


https://www.youtube.com/watch?v=f0EzOxs_Ofc <-- not my video, but I get exactly the same corruption that GloriousEggroll gets