[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)

[crt0mega]

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! :)

[boberfly]

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.... :)

[jerbmega]

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.

[boberfly]

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

[cjwijtmans]

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 .

[boberfly]

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

[ryao]

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.

[nanonyme]

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

[ryao]

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.

[nanonyme]

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

[shanefagan]

@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

[nanonyme]

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.

[shanefagan]

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

[hungrymonkey]

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

[nanonyme]

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

[GloriousEggroll]

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

[nanonyme]

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

[shanefagan]

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

[Zeioth]

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

[rea987]

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.

[nanonyme]

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

[crt0mega]

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.

[shanefagan]

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.

[nanonyme]

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

[crt0mega]

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