Proton: [Feature Request]: Gallium Nine Patches

This is a much better option. And I heard it's getting merged to DXVK (eventually) so we'll have all D3D versions covered from 9 to 12. The older ones don't need Vulkan's features anyway, I believe the D3D 8 games could even be run on a software renderer in 60 FPS on modern hardware.

Very interesting! Where did you find it was going to be merged to DXVK?

Can't find anything about it so I might be mistaken. It's probably not going to be merged right into DXVK but rather supported along with it or merged into Wine. I vaguely remember these two project mentioned in the same context (which is not surprising) of replacing the D3D=>OGL translation or something like that. Anyway, I think the Vulkan overhead is negligible compared to Gallium Nine direct approach but the benefits are obvious — all players can use it, not just those with FOSS drivers. And it can be pushed even further, to Windows itself, so that Windows users could run games with possibly better performance due to better CPU utilization or run them at all as some older games don't work on modern Windows anymore but work on Wine.

I agree that VK9 or something similar would be the best solution/implementation. However, as far as I understand, the current version of VK9 is still a proof of concept and supports very little if any at all games. It can only render some simple directx9 tests.

Gallium Nine patches are ready, well-tested by many players and offer (near) native performance. Implementing this would be rather trivial, since the patches are already there. It would be a very welcome addition for all the AMD/Intel gamers for the time being, until VK9 reaches maturity.

VK9 is years from completion, and I think even the overhead of d3d-pba could be considered "negligible".
If any though, I'd like for proton (but even upstream wine) to have some kinds of priorities.
Say, first native (gallium) or vulkan (dxvk), then the other, last but not least wined3d (cause not every gpu out there supports vulkan)

p.s. Nine doesn't work for intel users

As there are hundreds of Direct3D 9 games still being played on Steam and as Gallium Nine has been proven to be way more efficient than traditional d3d9 Wine, it should be an optional feature at least via user_setting.py.

i would rather have valve merge VK9 with DXVK. so they have a uniform vulkan coverage.

Sure, in an ideal world. But VK9 doesn't run a single game so far and is only in the proof of concept phase. It can run some simple dx9 tests and that's it. Also, the guy working on it considers it a hobby project and doesn't put in nearly as much work as the guy that develops DXVK. It could take years before VK9 is ready to be used. In the mean time, why not use patches for AMD users that are well-tested and completely finished?

I agree Gallium 9 patches should be usable by AMD mesa users. It's part of mesa we just need the wine version to allow it's use.

Agreed. And who knows? Maybe in the near future it's not only radeonsi and nuveau that benefit from it?
https://www.phoronix.com/scan.php?page=news_item&px=Intel-Iris-Gallium

Had a lot of success with this myself and the patches are well maintained. Mesa packages are built on openSUSE and all works together. Generally goes from playable with lots of stutters to silky smooth while other games just get a black screen. Would have to be toggleable or two version of wine or somesuch with the defaults provided for supported games.

Gallium Nine has been nothing short of fantastic in my experience. It would be great to see it included in Proton.

I personally vote for the all Vulkan approach.

@shoober420 I would prefer that as well eventually. But a working dx9 to vulkan translational layer is year off from being completed if ever. Why not let AMD users enjoy native dx9 performance via Gallium Nine patches that are well-tested and completely finished? They only need to be merged for AMD users to be able to enjoy native performance right now.

@shoober420 I think we all prefer that route for proton. It's the logical step forward. We aren't asking valve to to forgo a vulkan implementation of d3d9. We are asking that they allow poeple on the open gallium based drivers to use what they already have. Gallium 9 is already a part of our driver stack. The "Gallium nine patches" for wine just skip over the default d3d9 api translation to opengl and instead feeds the api calls straight to the gpu. Avoiding performance loss due to api translation.

@Mushoz @Xalphenos

I see your guys point, you’re both right. I didn’t know VK9 was that far off. I then support the choice for more options. I may use an AMD or Intel one day.

I did the work to build all variations of wine, staging, and nine for openSUSE. Basically, just need to apply the relevant patch set from https://github.com/sarnex/wine-d3d9-patches and build like normal. So we need to compile wine twice and provide an option to a specific binary.

For reference, the openSUSE/wine package that builds all four flavors of wine.

• wine
• wine-nine
• wine-staging
• wine-staging-nine

Not sure what the situation is in proton relating to wine staging. If no one else gets to it and Valve isn't opposed I may give this is stab, but Steam would need a UI option to really add the polish.

What you are thinking about is #22. There might be someway a mechanism to add one's own runtime, but it's unknown for the moment.

But for me, wine, and proton, should just have a graceful mechanism of fallbacks. From vulkan to gallium, to opengl.. Depending on the most working fallback you could use on your system.

Related certainly, but this request will always have to be optional for the same reason wine upstream does not merge it...it doesn't work on all platforms and only with a subset of cards that can use the related Mesa drivers. This is rather different from the other changes made to wine in this repo (other than excluding older cards). #22 would allow someone with a wine-nine built to switch it out, but this issue is about having it part of official build.

Yes.. and I don't see what's hard in checking which driver is being used, on which hardware, and calling it a day (same for vulkan or opengl anyway)

I don't either, never said it wasn't. Just responding to #22 which is specifically about choosing custom builds outside of proton which is not what I am proposing nor this issue about.

Given the extensive nature of the diff from ValveSoftware/wine (3.7) vs wine/wine (3.7) and approach Valve is taking it likely makes the most sense to merge it directly into their wine fork. It would then either a) have to be toggleable at run-time (possibly automatically) or build twice (believe patches already include a compile-time toggle).

The 3.7 tag patches do not apply cleanly to ValveSoftware/wine.

error: patch failed: configure.ac:1261
error: configure.ac: patch does not apply
wine-d3d9.patch:5385: new blank line at EOF.
+

It may be simple, but I imagine this would be an on going problem that likely would be another reason to merge directly to there fork.

They are going to update it as soon as they handle "launch issues"

... besides, maybe it would be more productive if you worked to first get that in staging

Updating wine version wasn't what I asked or needed as I applied patches for 3.7. As for staging this has been a long-term request that wine upstream is not interested in primarily because it does not work on Mac and not all Linux hardware. Hence proton is integrating a variety of performance improvements that limit the scope of hardware...so this might be of interest to them.

Having it in wine staging or wine proper would be great, but you can find plenty of prior issues indicating that will not happen in our lifetime.

Mac is not an issue, nor hardware compatibility (_especially_ after last intel rumors).
You can see my links for why the most.. concerning actual problem at least for the moment is just lack of acknowledgement in the first place.
(for as much as, who knows, maybe they already reach a consensus on IRC)

Even if VK9 would be ready for Proton, I'd prefer the most efficient solution. Until Proton offers that, I keep sticking to my old and trusted nine-patched wine for games depending on d3d9.

I am fully aware that Gallium Nine won't (and will probably never be) the most efficient solution for everyone, but that's not my point here. Having it as an option for those who happen to run a Gallium driver would be great! :)

Here's the solution:
https://www.phoronix.com/scan.php?page=news_item&px=Zink-Gallium3D-OpenGL-Vulkan
https://gitlab.freedesktop.org/kusma/mesa/tree/zink/src/gallium/drivers/zink

Basically Gallium3D was always a thin abstraction between various state trackers and the drivers, so just shoe-horn in Vulkan as a driver and bam, you get all the state trackers supported including Gallium nine and Mesa's OpenGL. The shader bytecode lifecycle will be DX9 HLSL bytecode from game->TGSI->NIR->SPIRV wow, if it works it works.... :)

The only thing I can see this being a "solution" to is a temporary stop-gap for Nvidia cards before VK9 is ready. This certainly wouldn't be faster on AMD.

@jerbear64 Gallium Nine is already quite battle-tested though from what I see, at least on the amdgpu driver. I was often thinking this could've been done from the beginning even with DXVK's case it could've just been a state tracker inside of Mesa as well and then just write something like ZINK on the end for closed drivers or use the native hardware directly where possible. Not complaining though... :)

Not everyone uses mesa.

On Wed, 26 Sep 2018, 20:35 Alex Fuller, notifications@github.com wrote:

@jerbear64 https://github.com/jerbear64 Gallium Nine is already quite
battle-tested though from what I see, at least on the amdgpu driver. I was
often thinking this could've been done from the beginning even with DXVK's
case it could've just been a state tracker inside of Mesa as well and then
just write something like ZINK on the end for closed drivers or use the
native hardware directly where possible. Not complaining though... :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/66#issuecomment-424824077,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAipRw-R-g3DJOiWzHdR5SOHBu2X-xCxks5ue8jigaJpZM4WHXpZ
.

@cjwijtmans well with this everyone can that has an existing vulkan driver, it would just be a lib to link to like DXVK...

Here is another way to go:

https://github.com/GabrielMajeri/d3d9-to-11

dgVoodoo already implements direct3d 1 through 7 plus 8.1 to 11 among other things, so that project’s reimplementation of direct3d9 in direct3d 11 would allow all of the older direct3d versions to just run through DXVK.

@jerbear64 that sounds backwards. Nine is useless on nVidia proprietary only. With AMD you use Mesa predominantly. Intel is also building a new Gallium3D driver so this will be Intel+nouveau+AMD solution at some point in the future.

It seems that dgVoodoo is working on D3D9 support:

https://www.vogons.org/viewtopic.php?f=59&t=34931&start=3780#p705374

It is limited to shader model 1.x. This means that games that use D3D9 with shader model 1.x could be run on top of DXVK with its next release. The downside to this is that dgVoodoo is not open source.

For what it's worth we now got support for Mesa part of Gallium Nine now in Steam Flatpak due to demand by other Flatpak applications

@jerbear64 that sounds backwards. Nine is useless on nVidia proprietary only. With AMD you use Mesa predominantly. Intel is also building a new Gallium3D driver so this will be Intel+nouveau+AMD solution at some point in the future.

Well it's useless to Nvidia users but it doesn't break compatibility with it. It's alright giving something to open source graphics users and not Nvidia if it's available

Wait, it doesn't? I thought the Wine part (which is discussed here) did. Anyhow, would probably be nice to get this built and shipped even if it's not used by default.

Wait, it doesn't? I thought the Wine part (which is discussed here) did. Anyhow, would probably be nice to get this built and shipped even if it's not used by default.

It detects if galliumnine is present when starting up the game and redirects to the other implementation if needed

@shanefagan Non gallium nine enabled GPU may be the minority in the future.
Intel has expressed interest in supporting Gallium 3d on all future GPU.

@hungrymonkey I don't think @shanefagan claimed anything in contrary. Also nVidia GPU's with proprietary drivers occupy massive share of Linux desktop usage still.

@nanonyme gallium nine does not affect nvidia proprietary drivers or usage at all. It checks if the driver in use is capable of g9, and if not, it is not used. Specifically it checks if mesa has g9 enabled, and then checks what mesa driver is in use. If no mesa driver is in use it literally cannot use g9 functionality and is ignored completely.

@GloriousEggroll it seems we're not speaking in the same language. This was just explained a couple of posts up.

A good note for the patch is the developer of it has been keeping the WINE patches up to date with work up to 3 days ago. I'd say it would be good to at least build it and have selection as a setting for some systems which get dx3d9 performance issues (like me with games like SC2 without heavy modification).

Anyway it's good to link the patches since I didn't see any links https://github.com/sarnex/wine-d3d9-patches

@Mushoz It runs Unreal Tournament by now. During 2019 _might_ be fully functional. You have the roadmap here.

Skipping native drivers and tools which are already in use and ready to go in favour of transition layer which is under heavy development doesn't look wise. If anything, Gallium Nine which is already ready should be presented as an option for AMD users; once/if VK9 arrives it can still remain as an option.

I would see the main downside being multiple codepaths potentially making supporting games harder. Then again, test results even now aren't applicable between GPU vendors

VK9 won't work on non-amdgpu-devices / pre-GCN-GPUs. Gallium-Nine on the other hand could possibly run on old r300g stuff and even up to GPUs like my VEGA10. But yeah, these old r600g-driven VLIW GPUs which some of my friends are still relying upon are considered obsolete.

Just like D3D9 itself.

I would see the main downside being multiple codepaths potentially making supporting games harder. Then again, test results even now aren't applicable between GPU vendors

Well it's a benefit if it works, negligible if it doesn't. Like you could make the default still WINE's implementation but allow users to set it as a environment variable if they want to try it. They already do this if you get better performance from WINE itself instead of DXVK so it's not really a tooling problem from them for config. They just have to work it into place. They could even hire the guy who makes the patch to tie up the last 10% to get it there.

The difference here is WineHQ doesn't sell you games and be liable to needing to do refunds

I thought that's why we've got a whitelist...

The whitelist won't work if you have complicated branching of operational modes, surely

"Complicated"

The whitelist won't work if you have complicated branching of operational modes, surely

Well it could be an option that is only enabled by users themselves if they want to try it out if the game performance isn't great

The whitelist won't work if you have complicated branching of operational modes, surely

Well it could be an option that is only enabled by users themselves if they want to try it out if the game performance isn't great

Sounds fair enough to me.

I think you'll need to get libd3dadapter9-mesa into the Steam runtime first.

I think you'll need to get libd3dadapter9-mesa into the Steam runtime first.

Hows does libd3dadapter9 work? I know that GalliumNine is in Mesa proper and the patches to WINE point to that. I seen that it's in Ubuntu as of 18.10 but I never actually used that lib.

How does libd3dadapter9 work? I know that GalliumNine is in Mesa proper and the patches to WINE point to that. I seen that it's in Ubuntu as of 18.10 but I never actually used that lib.

It's just addressing Mesa's D3D9 state tracker just like Wine's opengl32.dll.so does with common OpenGL state trackers for example¹.
Edit: Sorry, I confused libd3dadapter9 with the DLL built for Wine. Didn't have enough coffee that day. The library in question implements a D3D9 state tracker for Mesa. Simplified: It offers native D3D9 support without additional translation layers like WineD3D or VK9. Take a look at this presentation if you're interested.

¹: Warning: Answer might be inaccurate.

I was able to build proton with nine patches as local arch linux build with --no-steam-runtime. The only game i tested so far is Valkyria Chronicles 1 and that was behaving strangely with this local build e.g. RX 480 was detected as R9 290 in the settings, controls where not working properly at times and settings set trough Valkyria Chronicles configuration tool did not get saved at all.

Although those issues may be related to proton being built with --no-steam-runtime rather then the nine patches.

The original patch from https://github.com/sarnex/wine-d3d9-patches/blob/wine-d3d9-3.16/wine-d3d9.patch only needed a fix for the context in configure.ac see https://gist.github.com/raetiacorvus/8bf19a733ac131d744030788030941c4 only line 72 and 73 where removed from the original patch.

You still need to apply https://github.com/sarnex/wine-d3d9-patches/blob/wine-d3d9-3.16/d3d9-helper.patch first and run autoreconf in wine folder after having applied both patches.

In addition i had to add -with-d3d9-nine-module=/usr/lib32/d3d/d3dadapter9.so to the wine32 configuration in the following file but that may be a result of not setting up the build environment correctly? https://github.com/ValveSoftware/Proton/blob/83871c7bf93b785b23b987956b7cc3608d6998b3/build/makefile_base.mak#L713-L726

Also don't forget that you need to enable gallium nine trough winecfg for each pfx.

https://github.com/ValveSoftware/Proton/issues/66#issuecomment-447569917

This is great news! Despite initial setbacks, having a somewhat functional build is a significant progress. Since I am not well versed with coding, can you please elaborate, why did you build with --no-steam-runtime argument? Doesn't the Proton that you build work with Steam client? Cause, whole point of Proton is to run Steam games which requires Steam DRM with native Steam client instead of Windows version.

@raetiacorvus

I have a considerably large game collection on Steam. Please let me know, if you need to test more games, so I can try to arrange it.

The only game i tested so far is Valkyria Chronicles 1 and that was behaving strangely with this local build e.g. RX 480 was detected as R9 290 in the settings

This is normal Gallium Nine behavior, my RX 580 does the same thing on my wine-staging-nine builds.

Seems like none of the problems i encountered are gallium nine related but either caused by --no-steam-runtime or the game itself.

@rea987 --no-steam-runtime means proton is built against local libraries instead of the patched ones from the steam runtime docker container. It still is a valid steam compatibility tool and can be used as a replacement of valve provided proton releases. One problem so far is that it lacks the patched controller mapping from the runtime resulting in the problem I had with Valkyria Chronicles. You could probably work around that by using some of the tools available for wine to map controllers correctly.

@raetiacorvus It would be wonderful if you provide a step by step Gallium Nine for Proton compiling guide. Also, how about making a pull request so perhaps @ValveSoftware merges it with one of the branches. If that turns out to be functional build, I will seriously consider switching to AMD. @raetiacorvus My offer to provide more games for testing still stands.

I made my own fork of Proton with the patches :

https://github.com/popsUlfr/Proton (checkout the branch proton_3.16_gallium_nine_extras and just follow the readme)

git clone https://github.com/popsUlfr/Proton.git
cd Proton
git checkout proton_3.16_gallium_nine_extras
git submodule update --init

It also works with the steam runtime, I had to add this slightly ugly block of mesa stuff : https://github.com/popsUlfr/Proton/commit/0397af03059c32a6ac5e0213d39769e33f2914df

I added an environment variable PROTON_USE_GALLIUM_NINE=1 which you can use to easily enable Gallium nine if your card supports it (also can be enabled via the staging tab in winecfg)

Features :

• Gallium Nine obviously
• Path of Exile dx11 patch : https://bugs.winehq.org/show_bug.cgi?id=42695
• Force wined3d11 if there's no Vulkan support : #1749
• Enable ffmpeg by default and build FAudio with it : #2082
• GLSL toggle to disable GLSL shaders and use ARB shaders instead to reduce stuttering with wined3d

Here's a build to test :
~Proton_3.16-5_Gallium_Nine_Extras.tar.xz~
~Proton 3.16-5 Gallium Nine Extras 0.1.0~
~Proton 3.16-5 Gallium Nine Extras 0.1.1~
~Proton 3.16-6 Gallium Nine Extras 0.1.1~
~Proton 3.16-6 Gallium Nine Extras 0.1.2~
Proton 3.16-6 Gallium Nine Extras 0.1.3

$ mkdir -p ~/.steam/root/compatibilitytools.d
$ tar xf Proton_3.16-6_Gallium_Nine_Extras_0.1.3.tar.xz -C ~/.steam/root/compatibilitytools.d

In your steamplay tab it should show up as Proton 3.16-6 Gallium Nine Extras

By the way, I added this to the README, after the configure step you need to run make all dist instead of just make dist or you'll just end up with win64 wine and nothing else. So this seems to be an error in the README of the official proton or just acting like that on my own system, I'm not sure.

Great job @popsUlfr!

Will you have generic 32 bit, 64 bit and/or multiarch releases in the GitHub page of your fork?

Thanks for the effort and fork!

@rea987 Like this ? https://github.com/popsUlfr/Proton/releases/tag/proton-3.16-5-gne-0.1.0

Tell me if it works ok for you, I don't have access to an amd card to test this thoroughly :/

Hrm I followed the instructions but it looks like Steam is not picking up whatever is in the created dir. Compatibility tool drop-down only shows the "regular" Steam releases.

Any ideas what I might be doing wrong? I'm on KDE NEON 18.04 (basically Ubuntu) if that changes anything?

@popsUlfr Precisely! That's more clear and explanatory way to distribute it. Yeah, I also need an AMD card to test it properly. :-/

@AndrewLoom Is your Steam installation located in ~/.local/share/Steam or ~/.steam directory? Cause I needed to use the later to make it work.

Thanks rea987! D'Oh, so obvious now but still didn't think of it. :-)

@AndersDala No problem, that's an issue which confuses many people as of recently. Perhaps, @popsUlfr can edit the Install guide to point out ~/.steam directory as well?

I own an AMD Radeon Vega 56. I have successfully installed it and selected it to be used with all windows games, but it seems that games like A Hat in Time or Dragon Age: Origins won't work if I enable Gallium Nine with PROTON_USE_GALLIUM_NINE=1 (with clean prefix), a window doesn't even appear. With PROTON_USE_GALLIUM_NINE=0 they run fine.

I own an AMD Radeon Vega 56. I have successfully installed it and selected it to be used with all windows games, but it seems that games like A Hat in Time or Dragon Age: Origins won't work if I enable Gallium Nine with PROTON_USE_GALLIUM_NINE=1 (with clean prefix), a window doesn't even appear. With PROTON_USE_GALLIUM_NINE=0 they run fine.

Same GPU and same result for me. The games (Dishonered, Dead Space) won't start with Gallium.

@Mastergatto, @archfan Have you installed Gallium Nine enabled Mesa drivers?

https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

Yes, I'm on Arch and I've installed mesa-git from the AUR. It comes with Gallium Nine enabled.

@archfan All right, tomorrow, I will try it on my old AMD laptop which hopefully supports Gallium Nine.

Yes, as Gallium Nine is enabled by default with the mesa package, at least for AMD cards on ArchLinux. I have also wine-staging-gallium, in which Gallium Nine works as intended.

Can you look at the output when it's run with gallium nine on ?
So in the launch options for the game add :

PROTON_DUMP_DEBUG_COMMANDS=1 PROTON_USE_GALLIUM_NINE=1 %command%

Run the game.
This will drop some proton scripts into /tmp/proton_<username>
Launch ./run to the see the output.

Also just to make sure, switch to another proton, restart steam. Now switch to the gallium nine proton.

EDIT: to not pollute this thread I think it would be better to discuss it here : https://github.com/popsUlfr/Proton/issues/2

Also sorry if this got your hopes up and doesn't work out of the box. I maintained this locally, the gallium nine part was more a 'what if' in case I could test on amd. I decided to share it anyway seeing this discussion getting more prominent and it might be useful to get something going about gallium nine support in proton :)
The other features baked in might also be useful so...

Gallium Nine works in Proton with https://github.com/dhewg/nine

Unsurprisingly, this breaks the Steam overlay, but it otherwise works fine.

Gallium Nine works in Proton with https://github.com/dhewg/nine

Unsurprisingly, this breaks the Steam overlay, but it otherwise works fine.

hey, nice!

could you provide a guide of what you did? I'm a little lost.

@tatsujb

https://github.com/popsUlfr/Proton/releases

Another project to be looked into as an alternative to this https://github.com/Joshua-Ashton/d9vk

apparently we should be using protontricks to get all those goodies?

anybody know about that?

apparently we should be using protontricks to get all those googdies?

anybody know about that?

Good call. I'd honestly prefer a solution without protontricks but I'm gonna try that asap.

I did this :

wget https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks
chmod +x winetricks
wget https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks.bash-completion
sudo mv winetricks /usr/bin
sudo mv winetricks.bash-completion /usr/share/bash-completion/completions/winetricks
python3 -m pip install --user pipx
~/.local/bin/pipx ensurepath
eval "$(cat .bashrc | tail -n +10)"
pipx install protontricks
pipx upgrade protontricks
protontricks 9420 galliumnine

but now the game (that was working) gives me and error box saying : "Failed to create direct3d device"

@tatsujb I don't think that's the correct page for this but here it goes. Are you using Ubuntu 18.04 or Mint 19? Cause oibaf's Mesa drivers for those versions of Ubuntu/Mint is broken for Gallium Nine since December/January. I had the same issue, switched to Ubuntu Mate 19.04 and now it works.

@rea987 I'm using ubuntu 19.04, i'll try again. EDIT nah it doesn't help. what else did you do? what run arguments do you have and what game is working for you?

@tatsujb Honestly not much.

• I avoided third party Mesa PPAs since Oibaf's Mesa drivers' Gallium Nine compatibility is broken since December, I am not sure it that's fixed.
• I made sure both libd3dadapter9-mesa and libd3dadapter9-mesa:i386 are installed.
• Manually replaced /usr/bin/winetricks with latest version: https://wiki.winehq.org/Winetricks
• Cleared ~/.cache/winetricks
• Reinstalled Gallium Nine Standalone (latest) via Protontricks.

@rea987

• Manually replaced /usr/bin/winetricks with latest version: https://wiki.winehq.org/Winetricks

yeah that was the trick. I'd figured it out since then, thanks!

it would be nice to have both galliumnine and d9vk btw. I compared them on hat in time today and galliumnine runs much better (20% or more higher fps) and doesn't stutter the first time you visit a new area. having both would result in higher chances to run a given directx9 game with good performance as some titles might break with one or the other.

In an ideal world the renderer would gracefully fallback from native, to vulkan to opengl (or switch the priority of the first two if d9vk was eventually supposed to have some intrinsic advantage, but still).
Instead Valve (and even codeweavers given all the sneer around Nine) seems focused to just create a nice "well enough" garden for the latest cards rather than having everything and the kitchen sink working. They won't even add the automatic check for cards that lack vulkan at all

Here are my 20 cents:

Now that we have Gallium Nine standalone, it is pretty easy to use because you no longer need any patches for wine. All you need to do is: (1) install mesa-libd3d9 from your distro's package manager (2) install Nine to your wine prefix using winetricks or the installer script.

With regards to which is the "better" option: I do not intend to start a flame war here, so I'll just share what I found so far: https://github.com/Joshua-Ashton/d9vk/issues/95#issuecomment-492651741 ― that of course only means that on my system Nine was faster with the titles I tried so far, which may not be representative of how they would work on other people's computers. EDIT: I realize that Nine is currently not an option for NVidia users, but it works reasonably well with AMD (radeonsi) and Intel (iris), and will improve on NVidia once zink becomes mature enough.

Nine standalone is a cakewalk to use indeed absolutely.
Somehow though, *everytime* you point this out to devs it seems to fall on deaf ears.
I don't know if perhaps discussions couldn't have happened behind doors/IRC and I don't want to flame either - but I don't know what else to say to get them acknowledge the *present* state of affairs of the damn code, rather than whatever caricatural image they have in their minds about what the project was half a decade ago.

I realize that Nine is currently not an option for NVidia users, but it works reasonably well with AMD (radeonsi) and Intel (iris), and will improve on NVidia once zink becomes mature enough.

It also runs well on r600g. GPUs supported by r600g lack Vulkan support btw.

on nvidia for now I switch between an ubuntu with 418 installed and an ubuntu with Nouveau installed so that I can enable mesa and gallium nine. the performance with native linux games that can run under nouveau is acceptable and the wine-gallium-nine games run real well.

But obviously I can't wait for mesa to support Nvidia also.

I think this is solved by D9VK now. I tested it out with SC2 and a few other games and it works very well. Hopefully that will get integrated into DXVK in the future and the patches pushed to Proton too.

d9vk still performs much worse than gallium nine, but yes even just d9vk support built in would be awesome as that's already harder than gallium nine to integrate into an existing proton install

also another tricky part of shipping d9vk is that it requires latest mesa. not just the latest release, it's based on mesa-git. so to make it accessible to a wide variety of distros you might even have to ship mesa-git with it or instruct users to figure out how to get mesa-git for their distro

@shanefagan No, d9vk is an much, much slower than nine, see my findings in my previous post.

There is a standalone version that's easy to install. Maybe they can be shipped with Proton and enabled with an argument. D9VK is great, but as others have stated it's slower, and often uses bleeding edge drivers. Installing Gallium through winetricks works, but having an integrated option would be really nice.

Standalone: https://github.com/iXit/wine-nine-standalone

Hello!~ Does anyone else experience silent crashes on 4.11-6 when launching games with Gallium Nine Standalone installed?

@Bryophyllum same, game won't launch after installing galliumnine via protontricks.
Worst part is that there is no easy way of telling if galliumnine is running in the first place.

Actually after some try and error this worked:

Can you look at the output when it's run with gallium nine on ?
So in the launch options for the game add :

PROTON_DUMP_DEBUG_COMMANDS=1 PROTON_USE_GALLIUM_NINE=1 %command%

Run the game.
This will drop some proton scripts into /tmp/proton_<username>
Launch ./run to the see the output.

Also just to make sure, switch to another proton, restart steam. Now switch to the gallium nine proton.

EDIT: to not pollute this thread I think it would be better to discuss it here : popsUlfr#2

Also sorry if this got your hopes up and doesn't work out of the box. I maintained this locally, the gallium nine part was more a 'what if' in case I could test on amd. I decided to share it anyway seeing this discussion getting more prominent and it might be useful to get something going about gallium nine support in proton :)
The other features baked in might also be useful so...

If i launch from steam it pop-ups "Installing drivers" or something like that and disables galliumnine before launching the game.
However launching the game via dumped scripts doesn't disable galliumnine and game launches with it.

@tuxutku Some of games I've tried Gallium Nine Standalone with on Proton 4.11 would either crash silently, or, regardless of this issue, start as usual, but with Wine's DX9-to-OpenGL translation layer used instead. They all work fine on 4.2-9 with Gallium Nine Standalone installed.

Worst part is that there is no easy way of telling if galliumnine is running in the first place.

Not quite. If you run Steam Client from CLI, you will see a message from Gallium Nine in either in green or red when a game starts; however, in this case, nothing is outputed.

With PROTON_LOG=1 I get this error when attempting to run GTA SA:

10264.098:0031:0032:err:module:import_dll Library d3d9.dll (which is needed by L"Z:\\var\\home\\user\\.local\\share\\Steam\\steamapps\\common\\Grand Theft Auto San Andreas\\gta-sa.exe") not found

I do not know what causes it, nor how do I fix it, but, hopefully, someone can make the root of this issue out by piecing all clues together.

I am going to open a new issue about steam client disabling galliumnine before game launches, i am having this issue on another game

Hello @tuxutku, this feature request is the right place to discuss the new behavior. It sounds like the change happened at the same time that d9vk was added to Proton and may be a side effect from Proton managing that.

Worst part is that there is no easy way of telling if galliumnine is running in the first place.

Not quite. If you run Steam Client from CLI, you will see a message from Gallium Nine in either in green or red when a game starts; however, in this case, nothing is outputed.

With PROTON_LOG=1 I get this error when attempting to run GTA SA:

10264.098:0031:0032:err:module:import_dll Library d3d9.dll (which is needed by L"Z:\\var\\home\\user\\.local\\share\\Steam\\steamapps\\common\\Grand Theft Auto San Andreas\\gta-sa.exe") not found

@Bryophyllum its not as easy as to see if Native Direct3D 9 v0.5.0.356-release is active. For more information visit https://github.com/iXit/wine-nine-standalone is posted.
For example when launching 2013 tomb raider game from dumped ./run command it posts the line because the launcher uses directx9, but not game. I had to tweak a register with regedit to play the game with galliumnine

Games with VAC used to work with wine afaik. but now they don't for some reason. CSGO complains about file signatures not matching. TF2 doesn't give any specific reason.

For some reason PROTON_DUMP_DEBUG_COMMANDS=1 didn't worked on Team Fortress 2 and i had to copy and modify a script from another game.

#!/bin/bash
#Run game or given command in environment

cd "/home/utku/took/happytosharemysteamapps/steamapps/common/Team Fortress 2"
DEF_CMD=("/home/utku/took/happytosharemysteamapps/steamapps/common/Team Fortress 2/hl2.exe" "-steam" "-dev" "-secure" "-game" "tf" "-w" "1366" "-h" "768")
PATH="/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/bin/:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/bin:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/bin:/home/utku3/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/utku3/.local/bin" \
    TERM="xterm" \
    WINEDEBUG="-all" \
    WINEDLLPATH="/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib64//wine:/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib//wine" \
    LD_LIBRARY_PATH="/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib64/:/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib/:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_32:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_64:/usr/lib/x86_64-linux-gnu/libfakeroot:/lib/i386-linux-gnu:/usr/local/lib:/usr/local/lib/libstrangle/lib32:/usr/local/lib/libstrangle/lib64:/lib/x86_64-linux-gnu:/lib32:/libx32:/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib:" \
    WINEPREFIX="/home/utku/took/happytosharemysteamapps/steamapps/compatdata/440/pfx/" \
    WINEESYNC="1" \
    SteamGameId="440" \
    SteamAppId="440" \
    WINEDLLOVERRIDES="steam.exe=b;mfplay=n;d3d11=n;d3d10=n;d3d10core=n;d3d10_1=n;dxgi=n;d3d9=n" \
    STEAM_COMPAT_CLIENT_INSTALL_PATH="/home/utku2/.local/share/Steam" \
    "/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/bin/wine" steam.exe "${@:-${DEF_CMD[@]}}"

TF2 output

csgo output

Also ere is the script automaticly generated by PROTON_DUMP_DEBUG_COMMANDS=1:

#!/bin/bash
#Run game or given command in environment

cd "/mnt/WD-green/common/Counter-Strike Global Offensive"
DEF_CMD=("/mnt/WD-green/common/Counter-Strike Global Offensive/csgo.exe" "-steam")
PATH="/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/bin/:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/bin:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/bin:/home/utku3/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/utku3/.local/bin" \
    TERM="xterm" \
    WINEDEBUG="-all" \
    WINEDLLPATH="/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib64//wine:/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib//wine" \
    LD_LIBRARY_PATH="/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib64/:/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib/:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_32:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_64:/usr/lib/x86_64-linux-gnu/libfakeroot:/lib/i386-linux-gnu:/usr/local/lib:/usr/local/lib/libstrangle/lib32:/usr/local/lib/libstrangle/lib64:/lib/x86_64-linux-gnu:/lib32:/libx32:/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib:" \
    WINEPREFIX="/home/utku/took/happytosharemysteamapps/steamapps/compatdata/730/pfx/" \
    WINEESYNC="1" \
    SteamGameId="730" \
    SteamAppId="730" \
    WINEDLLOVERRIDES="steam.exe=b;mfplay=n;d3d11=n;d3d10=n;d3d10core=n;d3d10_1=n;dxgi=n;d3d9=n" \
    STEAM_COMPAT_CLIENT_INSTALL_PATH="/home/utku2/.local/share/Steam" \
    "/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/bin/wine" steam.exe "${@:-${DEF_CMD[@]}}"

i haven't tried csgo but tf2 runs and doesn't have vac issue under wine steam

@tuxutku why are you testing with games that have native linux ports?

@tuxutku
What does this have to do with Gallium 9?

I was asking because I'm genuinely curious. quit the downvotes

@tuxutku why are you testing with games that have native linux ports?

because source 1 games don't run well enough on linux?
They did worse in with galliumnine but that doesn't mean native ports are doing well. They do very bad compared to windows counterparts.
CS:GO's new danger zone maps are straight up unplayable (~15fps) on amd a10-9620p + rx 540.
When there is too much geometry in the scenery frame rate heavily drops in all source 1 games i have tested so far (nuclear dawn, cs:go, tf2, half-life 2,half-life 2 team death match).
left4dead2 is an exception and it actually utilizes gpu well enough

the assumption is "the code is bad" rather than "the calls are being interpreted through GL rather than vulkan", right?

if you have a functional vulkan-native game would the results not be better 100% of the time in native?

Given this is available externally from proton with protontricks I'd say this feature request is pretty superseded.

If being fixable manually called it a day, then we could close half of the issues in here.

Given this is available externally from proton with protontricks I'd say this feature request is pretty superseded.

Steam itself always disables galliumnine when launching the game or confirming cache, Also there is no proton flag to enable it and it requires manual updates.

I have found that galliumnine is often not only faster than the default wined3d translation (on r600), but it seems to fix issues with fullscreen for many games (supreme commander FA for instance), Adding it to proton seems like it would be pretty easy given the standalone version, I wouldn't say it should be a "supported" option, but it would be nice to have it built-in as a workaround/enhancement.

i believe this is supported since proton 5

EDIT: nvm I'm thinking of d9vk

i believe this is supported since proton 5

EDIT: nvm I'm thinking of d9vk

Yeah ... d9vk won't work with r600, unfortunately. :/

This is issue should be considered, we should be able to enable gallium nine without of resorting on hacks (such as protontricks) just by environment variables.

It's easy to fix (you guys already got plenty of forks and workarounds to fix this), Gallium Nine has now better GPU support (now works with Intel latest drivers), and gives 1.5-2x performance boost over DXVK and wined3d.

And you already got a bunch of reports of games talking about improved compatibility just by using Gallium Nine.

https://github.com/ValveSoftware/Proton/issues/173#issuecomment-499869941
https://github.com/ValveSoftware/Proton/issues/255#issuecomment-415997284
https://github.com/ValveSoftware/Proton/issues/355#issuecomment-415972910
https://github.com/ValveSoftware/Proton/issues/554#issue-354016973
https://github.com/ValveSoftware/Proton/issues/770#issue-354455950
https://github.com/ValveSoftware/Proton/issues/1073#issuecomment-473703760
https://github.com/ValveSoftware/Proton/issues/2704#issuecomment-518029014

I know this is probably not a priority for you since this only applies to old games, but come on, there is a huge catalog of great games that will benefit of Gallium Nine.

Any update on this topic? @popsUlfr unfortunately stopped to provide fresh Proton builds with native D3D9 support more than a year ago.

Any update on this topic? @popsUlfr unfortunately stopped to provide fresh Proton builds with native D3D9 support more than a year ago.

I have been using normal proton + gallium nine standalone. I have been installing it with winetricks and disable DXVK

I have been using normal proton + gallium nine standalone. I have been installing it with winetricks and disable DXVK

Good to know! Which Proton version did you use and how did you disable DXVK? WineD3D was interfering the last time I've tried that.

@crt0mega galliumnine ("d3d9") will be always replaced by dxvk or wined3d

Proton-5.9-GE-8-ST/proton:
            if "wined3d" in g_session.compat_config:
                dxvkfiles = ["dxvk_config"]
                wined3dfiles = ["d3d11", "d3d10", "d3d10core", "d3d10_1", "d3d9"]
            else:
                dxvkfiles = ["dxvk_config", "d3d11", "d3d10", "d3d10core", "d3d10_1", "d3d9"]
                wined3dfiles = []

it must be fixed...

or we can use Proton-5.9-GE-8-ST/dist/bin/wine without proton (and without steam's games)
ps: setup galliumnine:
WINE="./Proton-5.9-GE-8-ST/dist/bin/wine" WINEPREFIX=~/.steam/steam/steamapps/compatdata/372000/pfx/ ./Proton-5.9-GE-8-ST/protonfixes/winetricks --force galliumnine