[Feature Request]: Gallium Nine Patches

[Mushoz]

Lots of (older) games still use dx9. Would it be feasible to use the Gallium Nine patches for Proton for the AMD and Intel GPU users to get near-native performance under Linux? I am seeing much better performance playing older games such as Assassin's Creed 1 through regular wine with Gallium Nine patches compared to Steam play with Proton.

[rkfg]

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.

[Mushoz]

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

[rkfg]

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.

[Mushoz]

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.

[mirh]

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

[rea987]

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.

[cjwijtmans]

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

[Mushoz]

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?

[Xalphenos]

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.

[seijikun]

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

[boombatower]

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.

[jerbmega]

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

[shoober420]

I personally vote for the all Vulkan approach.

[Mushoz]

@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.

[Xalphenos]

@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.

[shoober420]

@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.

[boombatower]

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.

[mirh]

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.

[boombatower]

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.

[mirh]

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)

[boombatower]

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.

[boombatower]

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.

[mirh]

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

[boombatower]

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.

[mirh]

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)

[mirh]

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

[nottux]

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.

[ovlx]

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.

[Francesco149]

i believe this is supported since proton 5

EDIT: nvm I'm thinking of d9vk

[crt0mega]

i believe this is supported since proton 5

EDIT: nvm I'm thinking of d9vk

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

[ergoithz]

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.

#173 (comment)
#255 (comment)
#355 (comment)
#554 (comment)
#770 (comment)
#1073 (comment)
#2704 (comment)

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.

[crt0mega]

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

[nottux]

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

[crt0mega]

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.

[jl452]

@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

[pedrofleck]

I'm trying to run Fallout New Vegas with Gallium Nine but with no success, performance with D9VK isn't good with my Intel HD 5500 GPU. I tried installing it with protontricks and running it with PROTON_USE_WINED3D=1 and it won't even run. I dumped the "run" script and tried with it and the game worked but had performance similar to D9VK, then I realised that the overlay was working and I probably had the regular OpenGL conversion and not GalliumNine, so I ran ninewinecfg and reenabled it and got the launcher running, but nothing happens when I hit "Play". GalliumNine is supposedly working because I get the green message. What can I do?

[nottux]

@pedrofleck try removing ;d3d11=n;d3d10=n;d3d10core=n;d3d10_1=n;d3d9=n from the line: WINEDLLOVERRIDES="steam.exe=b;dotnetfx35.exe=b;mfplay=n;dxvk_config=n;d3d11=n;d3d10=n;d3d10core=n;d3d10_1=n;d3d9=n" \ in the run script

[pedrofleck]

@tuxutku It didn't work :( I don't know if I should use a different version of Proton (I'm trying with 5.13), the launcher just quits when I hit play.

[nottux]

@pedrofleck you're supposed to run the script itself. Also make sure galliumnine is active by running ninewinecfg. Also 5.13 known to crash due to soldier runtime it comes with (don't know if its resolved yet). I don't know If you had 5.13 run before.

Your gpu is broadwell so it should support it with iris drivers

[pedrofleck]

@tuxutku I'll try again from the start, I create a script just by running the game with PROTON_DUMP_DEBUG_COMMANDS=1 %command%, grab the proton_[username] folder, remove those dll overrides from the file, check if Gallium Nine is working with ./run ninewinecfg and then run the command with ./run, right? Or do I need to run any environment variables?
Btw, I've noticed that sometimes Steam starts downloading the same 60,6 MB of shader cache, maybe this have something to do with the game not running? The other thing I've noticed is that in the Options menu in the launcher, the game recognizes my GPU as "Intel Haswell mobile" instead of the correct "Intel HD Graphics 5500" shown with D9VK.

[nottux]

@pedrofleck ./run ninewinecfg won't do anything and is wrong way of using ninewinecfg

First you should update the winetricks;
sudo winetricks --self-update

(you can find the WINEPREFIX in the ./run file) , install command should look like this;
WINEPREFIX="(prefix here)" WINE="(path to proton 5.13 binary)" winetricks galliumnine

finally run ninewinecfg like this;
WINEPREFIX="(prefix here)" "(path to proton 5.13 binary)" ninewinecfg

[pedrofleck]

I ran
WINEPREFIX="/home/pedrofleck/.local/share/Steam/steamapps/compatdata/22380/pfx/" WINE="/home/pedrofleck/.local/share/Steam/steamapps/common/Proton 5.13/proton" winetricks galliumnine
And got, in the end:
warning: /home/pedrofleck/.local/share/Steam/steamapps/common/Proton 5.13/proton cmd.exe /c echo '%AppData%' returned empty string, error message "Proton: No compat data path?"
I don't know if I got the Proton 5.13 binary wrong or what. But are you sure that ./run ninewinecfg doesn't work? Because running ./run winecfg does run the Proton version of winecfg. I installed galliumnine earlier with protontricks 22380 galliumnine

[nottux]

@pedrofleck
sudo winetricks --self-update

WINEPREFIX="/home/pedrofleck/.local/share/Steam/steamapps/compatdata/22380/pfx/" WINE="/home/pedrofleck/.local/share/Steam/steamapps/common/Proton 5.13/dist/bin/wine" winetricks galliumnine

WINEPREFIX="/home/pedrofleck/.local/share/Steam/steamapps/compatdata/22380/pfx/" "/home/pedrofleck/.local/share/Steam/steamapps/common/Proton 5.13/dist/bin/wine" ninewinecfg

Also don't forget to;

@pedrofleck try removing ;d3d11=n;d3d10=n;d3d10core=n;d3d10_1=n;d3d9=n from the line: WINEDLLOVERRIDES="steam.exe=b;dotnetfx35.exe=b;mfplay=n;dxvk_config=n;d3d11=n;d3d10=n;d3d10core=n;d3d10_1=n;d3d9=n" \ in the run script

If you have further problems e-mail me

[surfaceflinger]

Mesa 21.2 now has crocus driver that is gallium based driver for older Intel iGPUs. I've tested Gallium Nine on Intel HD Graphics 4000 with Need For Speed Underground 2 and it works almost like it did on Windows. It was very slow on both wined3d and D9VK and on Gallium Nine I can set everything except from antialiasing to max and I still have 60fps.

Including Gallium Nine will definitely benefit everyone with older laptops that have Intel iGPUs and should be literally set as the default option for dx9 on them.

[crt0mega]

Including Gallium Nine will definitely benefit everyone with older laptops that have Intel iGPUs and should be literally set as the default option for dx9 on them.

I've still got an old AMD laptop lying around which did Mass Effect 3 or Dragon Age: Origins pretty well with Gallium-Nine but its GPU isn't capable of Vulkan, so no D*VK on that device.

Alas, this issue is open for ages now and nobody has been interested in fixing it by adding support for native D3D9. I don't think we'll ever see it.

[surfaceflinger]

There is now a very good reason to include it though, Sandy Bridge/Ivy Bridge GPUs are very popular thanks to people recommending thinkpads xx20/xx30 everywhere. I'm not sure about Sandy Bridge HD 3000, but HD 4000 can even launch Witcher 3 through DXVK and run Zink, but Vulkan on those iGPUs is just very slow and crashes after enabling things like antialiasing.

[siyia2]

There is now a very good reason to include it though, Sandy Bridge/Ivy Bridge GPUs are very popular thanks to people recommending thinkpads xx20/xx30 everywhere. I'm not sure about Sandy Bridge HD 3000, but HD 4000 can even launch Witcher 3 through DXVK and run Zink, but Vulkan on those iGPUs is just very slow and crashes after enabling things like antialiasing.

+1 i also use an HD 3000 for some light gaming in steam and it doesnt make sense to not include gallium-nine with proton, just because nvidia drivers dont support it, gallium 9 works fine with HD 3000 and crocus.

[nesper8]

would love to see gallium nine support as it now also support intel gpus

[crt0mega]

would love to see gallium nine support as it now also support intel gpus

Valve will add gallium-nine support when pigs fly. Sad but true.

[Weirdo1312]

I know this is an old request and it's getting less relevant every day but i'd still appreciate it if valve added it
people on older Intel/AMD machines who don't have vulkan support would benefit a lot from it

[fallenguru]

It also works better with some older games, and having a third D3D9 implementation available is nice for testing and reporting bugs. I'm not saying support support it, not even to the level Proton is or isn't supported, but I don't see how quietly introducing another env variable can hurt.