Using the current state of the RADV driver for starting DOOM 2016 ends up in a green screen, during launch and in the game menu which is actually not visible because of the driver. Setup: * Arch Linux (up-to-date) * Packages: lib32-llvm-libs-svn 292523-1 lib32-mesa-demos 8.3.0-2 lib32-mesa-git 88288.de0b0a3a9c-1 lib32-mesa-libgl-git 88288.de0b0a3a9c-1 lib32-vulkan-icd-loader 1.0.37.0-1 lib32-vulkan-radeon-git 88288.de0b0a3a9c-1 llvm-libs-svn 292518-1 llvm-svn 292518-1 mesa-demos 8.3.0-2 mesa-git 88288.de0b0a3a9c-1 mesa-libgl-git 88288.de0b0a3a9c-1 opencl-mesa-git 88288.de0b0a3a9c-1 vulkan-icd-loader 1.0.37.0-1 vulkan-radeon-git 88288.de0b0a3a9c-1 I'm also aware of this repository: https://github.com/airlied/mesa/tree/radv-wip-doom-wine/src/amd/vulkan I think it's exactly because of this (and maybe other) problem(s), but it hasn't seen much progress since last year.
Forgot to add: Using RX480 - 8GB.
Supposedly it's because the game is doing something illegal: https://lists.freedesktop.org/archives/mesa-dev/2016-December/138955.html However because all the binary drivers handle it, and Doom (which I'd call Vulkan "killer app") relies on it, I'd say it's in the "de facto" Vulkan standard now and it'd be better if mesa handled it. I suspect others will disagree though...
(In reply to Grazvydas Ignotas from comment #2) > Supposedly it's because the game is doing something illegal: > https://lists.freedesktop.org/archives/mesa-dev/2016-December/138955.html > > However because all the binary drivers handle it, and Doom (which I'd call > Vulkan "killer app") relies on it, I'd say it's in the "de facto" Vulkan > standard now and it'd be better if mesa handled it. I suspect others will > disagree though... Handling broken behavior is exactly how the vendor GL drivers got into a mess so do you want that to happen to Vulkan also? Why not try to contact the game vendor with a detailed report how they can patch their shader code.
Good luck getting in touch with any of the devs of an AAA game company. And I can't imagine why they'd want to fix it and have to redo the whole QA just for some obscure platform the game is not supposed to work on in the first place.
The developers are already aware of the problem; it'll probably get addressed in the next major update for DOOM.
[re-posting with proper account] The developers are already aware of the problem; it'll probably get addressed in the next major update for DOOM.
Created attachment 129081 [details] attachment-2481-0.html I know that some proprietary drivers used to replace shaders of games with more optimized versions for the hardware platform. Can't Mesa, do that as well. This will not need to include workarounds in the core, but merely new shaders, that can be later removed if the vendor fixes their code. On Sat, Jan 21, 2017 at 4:42 AM, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 6 <https://bugs.freedesktop.org/show_bug.cgi?id=99467#c6> on > bug 99467 <https://bugs.freedesktop.org/show_bug.cgi?id=99467> from > Pierre-Loup A. Griffais <pgriffais@valvesoftware.com> * > > [re-posting with proper account] > > The developers are already aware of the problem; it'll probably get addressed > in the next major update for DOOM. > > ------------------------------ > You are receiving this mail because: > > - You are the assignee for the bug. > - You are the QA Contact for the bug. > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > >
As has been said already, the developers are aware of the specific problem of the invalid shaders. However I don't think this is the cause of the green screen/fog, as even with the workaround in mesa that still happens. It is still a problem with that hack and the cause has yet to be found.
Has there been any communication made yet with the game devs or any approach to workaround (hack) and bypass the specs to make this work?
Please retest with the radv-wip-doom-wine branch. It should be rendering properly now.
(In reply to Dave Airlie from comment #10) > Please retest with the radv-wip-doom-wine branch. > > It should be rendering properly now. Works perfect! I don't experience any issues and I also tested with Ultra settings. Awesome :) I guess this will have hard time getting into upstream?
No improvement here compared to radv-wip-doom-wine from Dec 23, still suffering random fog/glare.
(In reply to Grazvydas Ignotas from comment #12) > No improvement here compared to radv-wip-doom-wine from Dec 23, still > suffering random fog/glare. Well, the reason is in your comment -> Dec 23.
(In reply to Bogomil Vasilev from comment #13) > Well, the reason is in your comment -> Dec 23. What do you mean? Both the old branch and radv-wip-doom-wine from Feb 3 are suffering random fog/glare, hence the "no improvement" comment.
(In reply to Grazvydas Ignotas from comment #14) > (In reply to Bogomil Vasilev from comment #13) > > Well, the reason is in your comment -> Dec 23. > What do you mean? > Both the old branch and radv-wip-doom-wine from Feb 3 are suffering random > fog/glare, hence the "no improvement" comment. Since Dave requested me to test with the update branch, I have no problems with rendering. This is the PKGBUILD I used (and also modified for my needs): https://paste.smirky.net/view/raw/595da629
I've pushed a new radv-wip-doom-wine branch which clears VRAM on kernels 4.9 and above. If you can test this with a kernel > 4.9 and see if the colors are still randomly crap.
The new patches work great for me. No more brightly colored fog which occurred randomly and often made the game impossible to play. I'm on Gentoo with a 4.9.9 kernel, RX 460 card. Thank you for the amazing work!
I can confirm the same. The blurry colors are gone. The game works perfect so far. David, are you polishing the patches before pushing them? I'm asking is because I don't see any reason not to submit it to mainline mesa, except that "illegal" use of the API.
I would like to see these patches go mainline as well so we can all play.
(In reply to Sebastian Jug from comment #19) > I would like to see these patches go mainline as well so we can all play. I believe the issue is whether Doom Vulkan implementation follows the standard. In case it does not, the game should be fixed. We _really_ shouldn't start going down the road of workarounds with Vulkan like we did with OpenGL...
Created attachment 130211 [details] attachment-25980-0.html Since workaround is not that big, can't it be committed and activated with ENV var switch, until Id fixes the game. This will allow stressing the RADV driver with the most demanding Vulkan game we have, and polishing other parts of the driver. On Mon, Mar 13, 2017 at 7:56 PM, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 20 <https://bugs.freedesktop.org/show_bug.cgi?id=99467#c20> on > bug 99467 <https://bugs.freedesktop.org/show_bug.cgi?id=99467> from Vedran > Miletić <vedran@miletic.net> * > > (In reply to Sebastian Jug from comment #19 <https://bugs.freedesktop.org/show_bug.cgi?id=99467#c19>)> I would like to see these patches go mainline as well so we can all play. > > I believe the issue is whether Doom Vulkan implementation follows the standard. > In case it does not, the game should be fixed. We _really_ shouldn't start > going down the road of workarounds with Vulkan like we did with OpenGL... > > ------------------------------ > You are receiving this mail because: > > - You are the QA Contact for the bug. > - You are the assignee for the bug. > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > >
(In reply to Drago from comment #21) > Since workaround is not that big, can't it be committed and activated with > ENV var switch, until Id fixes the game. This will allow stressing the RADV > driver with the most demanding Vulkan game we have, and polishing other > parts of the driver. > That would be the equivalent of drirc with OpenGL. Again, I don't think that's the path we should take, but it's ultimately maintainer's decision.
Does this branch work still? I've tried to use it and got green screen.
FYI on archlinux if you apply the following two patches to mesa 17.1 and recompile with llvm 4.0 from official repo the game works perfectly, no green screen or black textures: https://github.com/airlied/mesa/commit/cfe39ca4a4d922a063ff120f5c0db53ff347349c https://github.com/airlied/mesa/commit/a163083b481d924a476cfa2fdf8e3b8f398fb62a Much better than messing around with mesa-git and llvm-svn. Now if only those patches could be merged ... :)
(In reply to Marcin Bujar from comment #24) > FYI on archlinux if you apply the following two patches to mesa 17.1 and > recompile with llvm 4.0 from official repo the game works perfectly, no > green screen or black textures: > > https://github.com/airlied/mesa/commit/ > cfe39ca4a4d922a063ff120f5c0db53ff347349c > https://github.com/airlied/mesa/commit/ > a163083b481d924a476cfa2fdf8e3b8f398fb62a > > Much better than messing around with mesa-git and llvm-svn. Now if only > those patches could be merged ... :) Thanks! That works!
The compiler patches have been merged: https://cgit.freedesktop.org/mesa/mesa/commit/?id=1bd0acab21c250b263604a52ca6694941a6f02e0 Is further changes needed for radv?
I've created a PPA for getting doom running on Southern Island GPUs and have included these two patches. https://launchpad.net/~cheako/+archive/ubuntu/doom2016 The target release is Artful, but I plan on using these pkgs on Stretch.
(In reply to Sven Arvidsson from comment #26) > The compiler patches have been merged: > https://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=1bd0acab21c250b263604a52ca6694941a6f02e0 > > Is further changes needed for radv? Not in my setup, works fine on plain mesa master on rx470. I think this can be closed, feel free to reopen if it still has problems. but state your mesa/kernel versions and the hardware you use.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.