AMD and Proton

[Naib]

So some time ago I jumped to AMD from nvidia and the main reason for a new gpu was my 7+ year nvidia was starting to fail (tearing etc...). likewise as I was using wayland more and more as a daily drive, nvidia was just meh so I jumped

I stuck with nv for years because while it is closed source, it did work and certain things I needed for (ie CAD) but I jumped and it was quite simple to get working... add the kernel stuff, add mesa with suitable use and bam...

desktop worked, ogl worked and so did vulkan.

Recently however I have started playing windows games via Proton (namely Dune:spicewars) and well it does not work ;(

If I launch steam using: VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/amd_icd32.json:/usr/share/vulkan/icd.d/amd_icd64.json steam (ie using amdvlk or amd_pro) then windows games work ONLY if using dx AND winD11 and none of the DXVK (or ogl) work

if I use the radeon vk json then it just does not work. I have spent the last couple of months trying but I am at a loss. Anyone got proton working with gentoo and dxvk ? all the GoL lot uses Fedora or Arch and it "just works"

[Ralphred]

In proton, DX10 and 11 are using DXVK, unless you have messed with the prefix (it replaces some native dll's with the vulkan translation layer). DX12 does kind of use DXVK, but the code is built into wine. The only time I've had issues with DXVK is when it was immature, and had to manually "upgrade" the DLL's, but not had issues in years TBH.
The only thing I've never used is AMDGPU-PRO, because ROC was available when I wanted OpenCL functionality.

I wonder if because I've always had wine-[various] installed with the vulkan use flag it's pulling in something in the deptree?
If you want to know if your DXVK is working at all, then use `DXVK_HUD="full" %command%` for steam game launch options, you can't miss the overlay.

List some DX10/11 games that don't work, maybe I have one and we can compare builds.

[Naib]

This is one of the downsides of Gentoo, the configurability means that something could be missed for these "out of tree" packages and it relies on someone figuring it out for the rest. Normally I am quite good (unpicked pipewire for instance and now the wiki is flourishing) but this one has me stumped, especially since I am a legacy nvidia

I have wine for the odd windows only program but it might not have everything enabled to pull in some common missing dep - ill rebuild shortly.

As mentioned, OGL and Vulkan native work (dota2, csgo player etc...) and equally these work with either RADV, AMDVLK or AMD-PRO drivers (although AMDVLK will crash dota-vulkan but that's a bug )


the Proton stuff however I had no reason to try when I jumped to amd about 6months ago and only went to try as I Dune:SpiceWars was in closed beta (great game!!! early access now) and I only got it working using AMD{VLK,PRO} and via OGL and this is far from ideal.

So I would say every game and the best testgame is "Floating Point" it is free, small and it is what Valve use to diagnose Proton issues. it has a native linux so once you force it to use a proton compat layer thats when I run into issues - proton logs indicate aspects of wine crash early and steam sits there waiting to configure

[Ralphred]

So Floating Point works fine, with proton 7.0-2, GE7.9 and experimental (my experimental is on "bleeding edge").
But it's a 32bit executable, how much of your graphics stack is built with abi_x86_32 enabled? TBH it's one of the reasons I keep wine-staging around as a package, so if any new deps get pulled in over time they get the 32bit treatment too.

I'm assuming your vkcube works?
If there is anything you want published (config etc) just ask.

[Naib]

ok so the fact it works for you is a good thing ... it should just be a case of finding what's missing
This has 100% felt like a driver issue from day one (vs waiting for mesa to catch up with this card)

I even went and used gentoo-kernel-bin just incase there was a kernel conf issue missing but that still has the issue so the kernel might be ruled out. I have the latest firmware and it is loaded during boot

dmesg | grep firmware
[ 5.062875] Loading firmware: amdgpu/dimgrey_cavefish_sos.bin
[ 5.064167] Loading firmware: amdgpu/dimgrey_cavefish_ta.bin
[ 5.164136] Loading firmware: brcm/BCM20702A1-0a5c-21e8.hcd
[ 9.113479] Loading firmware: amdgpu/dimgrey_cavefish_smc.bin
[ 9.114185] Loading firmware: amdgpu/dimgrey_cavefish_dmcub.bin
[ 9.114702] [drm] Loading DMUB firmware via PSP: version=0x0202000C
[ 9.114710] Loading firmware: amdgpu/dimgrey_cavefish_pfp.bin
[ 9.115339] Loading firmware: amdgpu/dimgrey_cavefish_me.bin
[ 9.115784] Loading firmware: amdgpu/dimgrey_cavefish_ce.bin
[ 9.116230] Loading firmware: amdgpu/dimgrey_cavefish_rlc.bin
[ 9.116606] Loading firmware: amdgpu/dimgrey_cavefish_mec.bin
[ 9.117502] Loading firmware: amdgpu/dimgrey_cavefish_mec2.bin
[ 9.118351] Loading firmware: amdgpu/dimgrey_cavefish_sdma.bin
[ 9.118759] Loading firmware: amdgpu/dimgrey_cavefish_vcn.bin
[ 9.119410] [drm] Found VCN firmware Version ENC: 1.18 DEC: 2 VEP: 0 Revision: 14
[ 9.119416] amdgpu 0000:29:00.0: amdgpu: Will use PSP to load VCN firmware

as to abi_x86_32, everything is built with this (gfx the lot) as I

emerge mesa -va

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] media-libs/mesa-22.1.0::gentoo USE="X d3d9 gles1 gles2 llvm opencl osmesa unwind vaapi valgrind vdpau vulkan vulkan-overlay wayland xa xvmc zink zstd -debug -lm-sensors (-selinux) -test" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="sse2" VIDEO_CARDS="radeonsi (-freedreno) -intel (-lima) -nouveau (-panfrost) -r300 -r600 -radeon (-v3d) (-vc4) -virgl (-vivante) -vmware" 0 KiB

this is really confusing

[Ralphred]

Your mesa looks similar to mine, I have radeon set too though, thing is that's probably a throwback from having an 18yr old OS.
Because the birth of DXVK and vulkan happened in real time for me I can't think of any single resource I used to set it up first time round, it's just layers upon layers, though the DXVK readme page was always a good place to go.
If you want I can tar up my /etc/portage and .config for you to poke around in?

[Naib]

Well it seems there is a clash between my system and proton...
running proton-6.x and stuff works while proton-7 or experimental crashes.

[Ralphred]

You tried any of the GloriousEggroll protons? The "install instructions" are a bit sparse, but mainly because once you know to just extract the archive(s) into ~/.local/share/Steam/compatibilitytools.d/ and restart steam it's a bit of a no-brainer.

Also I've neglected to ask if you use STEAM_RUNTIME[_HEAVY] or not, even when I went through the pain of configuring portage to allow games-util/steam-whatever to install with the steamruntime use flag unset, it still didn't work properly. I know it's a bit of a cop out to effectively have an mini ubuntu chroot laying around, but by the time it comes to GUI/Game stuff I just go with path of least resistance, it's my underlying Gentoo system I *really* care about.

At the risk of sounding like the BBC and repeating myself, do a

Code: Select all

ACCEPT_KEYWORDS="~amd64" emerge -pv wine-staging

, and adjust your portage config, and allow the install to go ahead, just to be belt and braces about your wine support stuff being intact.

I find myself at somewhat of a disadvantage, in that my system has been "fondled" and "working" for so long, including throughout protons infancy, that I don't know if "what I used to have to do" is actually relevant anymore; that said a "too old" wine-mono has caused issues in the past.

Good to see you are making at least a modicum of progress though, and as with all things Gentoo, once it's sorted, you'll probably never have to think about it again, until someone else has a similar problem