Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Gallium Nine Patches #66

Open
Mushoz opened this Issue Aug 22, 2018 · 83 comments

Comments

Projects
None yet
@Mushoz
Copy link

Mushoz commented Aug 22, 2018

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 comment has been minimized.

Copy link

rkfg commented Aug 22, 2018

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

This comment has been minimized.

Copy link
Author

Mushoz commented Aug 22, 2018

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

@rkfg

This comment has been minimized.

Copy link

rkfg commented Aug 22, 2018

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

This comment has been minimized.

Copy link
Author

Mushoz commented Aug 22, 2018

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

This comment has been minimized.

Copy link

mirh commented Aug 22, 2018

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

This comment has been minimized.

Copy link

rea987 commented Aug 22, 2018

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

This comment has been minimized.

Copy link

cjwijtmans commented Aug 22, 2018

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

@Mushoz

This comment has been minimized.

Copy link
Author

Mushoz commented Aug 22, 2018

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

This comment has been minimized.

Copy link

Xalphenos commented Aug 22, 2018

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

This comment has been minimized.

Copy link

seijikun commented Aug 22, 2018

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

This comment has been minimized.

Copy link

boombatower commented Aug 22, 2018

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.

@jerbear64

This comment has been minimized.

Copy link

jerbear64 commented Aug 23, 2018

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

@shoober420

This comment has been minimized.

Copy link

shoober420 commented Aug 23, 2018

I personally vote for the all Vulkan approach.

@Mushoz

This comment has been minimized.

Copy link
Author

Mushoz commented Aug 23, 2018

@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

This comment has been minimized.

Copy link

Xalphenos commented Aug 23, 2018

@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

This comment has been minimized.

Copy link

shoober420 commented Aug 23, 2018

@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

This comment has been minimized.

Copy link

boombatower commented Aug 24, 2018

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

This comment has been minimized.

Copy link

mirh commented Aug 25, 2018

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

This comment has been minimized.

Copy link

boombatower commented Aug 25, 2018

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

This comment has been minimized.

Copy link

mirh commented Aug 25, 2018

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

This comment has been minimized.

Copy link

boombatower commented Aug 25, 2018

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

This comment has been minimized.

Copy link

boombatower commented Aug 25, 2018

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

This comment has been minimized.

Copy link

mirh commented Aug 25, 2018

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

This comment has been minimized.

Copy link

boombatower commented Aug 25, 2018

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

This comment has been minimized.

Copy link

mirh commented Aug 26, 2018

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)

@shanefagan

This comment has been minimized.

Copy link

shanefagan commented Nov 9, 2018

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.

@crt0mega

This comment has been minimized.

Copy link

crt0mega commented Nov 9, 2018

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.

@raetiacorvus

This comment has been minimized.

Copy link

raetiacorvus commented Dec 15, 2018

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?

# 32-bit configure
$(WINE_CONFIGURE_FILES32): SHELL = $(CONTAINER_SHELL32)
$(WINE_CONFIGURE_FILES32): $(MAKEFILE_DEP) | $(WINE_OBJ32) $(WINE_ORDER_DEPS32)
cd $(dir $@) && \
STRIP=$(STRIP_QUOTED) \
CFLAGS=-I$(abspath $(TOOLS_DIR32))"/include -g $(COMMON_FLAGS)" \
LDFLAGS=-L$(abspath $(TOOLS_DIR32))/lib \
PKG_CONFIG_PATH=$(abspath $(TOOLS_DIR32))/lib/pkgconfig \
CC=$(CC_QUOTED) \
CXX=$(CXX_QUOTED) \
../$(WINE)/configure \
$(WINE32_AUTOCONF) \
--without-curses \
--disable-tests --prefix=$(abspath $(WINE_DST32))

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

@rea987

This comment has been minimized.

Copy link

rea987 commented Dec 15, 2018

#66 (comment)

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.

@jerbear64

This comment has been minimized.

Copy link

jerbear64 commented Dec 15, 2018

@raetiacorvus

This comment has been minimized.

Copy link

raetiacorvus commented Dec 20, 2018

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.

@rea987

This comment has been minimized.

Copy link

rea987 commented Dec 20, 2018

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

@popsUlfr

This comment has been minimized.

Copy link

popsUlfr commented Dec 21, 2018

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 : popsUlfr@0397af0

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.

@rea987

This comment has been minimized.

Copy link

rea987 commented Dec 21, 2018

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!

@popsUlfr

This comment has been minimized.

Copy link

popsUlfr commented Dec 21, 2018

@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 :/

@AndersDala

This comment has been minimized.

Copy link

AndersDala commented Dec 21, 2018

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?

@rea987

This comment has been minimized.

Copy link

rea987 commented Dec 21, 2018

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

@AndersDala

This comment has been minimized.

Copy link

AndersDala commented Dec 21, 2018

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

@rea987

This comment has been minimized.

Copy link

rea987 commented Dec 21, 2018

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

@Mastergatto

This comment has been minimized.

Copy link

Mastergatto commented Dec 21, 2018

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.

@archfan

This comment has been minimized.

Copy link

archfan commented Dec 21, 2018

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.

@rea987

This comment has been minimized.

Copy link

rea987 commented Dec 21, 2018

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

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

@archfan

This comment has been minimized.

Copy link

archfan commented Dec 21, 2018

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

@rea987

This comment has been minimized.

Copy link

rea987 commented Dec 21, 2018

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

@Mastergatto

This comment has been minimized.

Copy link

Mastergatto commented Dec 21, 2018

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.

@popsUlfr

This comment has been minimized.

Copy link

popsUlfr commented Dec 21, 2018

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

@jerbear64

This comment has been minimized.

Copy link

jerbear64 commented Jan 7, 2019

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

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

@tatsujb

This comment has been minimized.

Copy link

tatsujb commented Feb 26, 2019

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.

@rea987

This comment has been minimized.

@Ember2528

This comment has been minimized.

Copy link

Ember2528 commented Mar 5, 2019

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

@tatsujb

This comment has been minimized.

Copy link

tatsujb commented Apr 16, 2019

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

anybody know about that?

@crt0mega

This comment has been minimized.

Copy link

crt0mega commented Apr 19, 2019

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.

@tatsujb

This comment has been minimized.

Copy link

tatsujb commented Apr 19, 2019

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"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.