Closed doitsujin closed 6 years ago
The following environment variables will not be removed and can safely be used in the future
Why not to use them in config as well?
I'm using "Steam" prefix with this variables set to whole prefix in q4wine
settings. All games launched from steam acquires this settings, but sometimes one of a game need to be debugged/adjusted, than steam need to be restarted.
With per app config DXVK_LOG_LEVEL
(an other) only config file will require to be changed. Ideally it's good to have all of them in per-app config file.
If you know a game which requires one of these environment variables to be set, and is not listed here yet, please let me know in the comments.
JustCause2.exe : dxgi.fakeDx10Support
(for DXUP
).
Sleeping Dogs Definitive Edition needs DXVK_FAKE_DX10_SUPPORT
@gort818 What's the exact exe name for that game?
@pchome At some point it's time to get rid of the legacy cruft. Especially when it's so inconsistent (e.g. there was no environment variable for the stream output thing).
@doitsujin It should be sdhdship.exe
Edit: it is SDHDShip.exe
https://github.com/doitsujin/dxvk/issues/538#issuecomment-411542456
As gort818 shows sleeping dogs still needed DXVK_FAKE_DX10_SUPPORT and others case grandia II anniversary edition, age of mythologies extended edition
Maybe can allow DXVK_FAKE_DX10_SUPPORT for now until dxvk games databasee grow up more (lack of many games)
What about DXVK_FEATURE_LEVEL? Will it remain an env variable or will it transition to a config option.
@mrdeathjr28 I need the exact exe names for those games, just the name of the games doesn't help.
@Guy1524 it's something that should be moved to the config file, but I'm not sure how to do best do that.
@doitsujin
HKShip.exe for original Sleeping Dogs and sdhdship.exe for the definitive edition (they both require it)
And Grandia II Anniversary doesn't need FAKE DX10 support AFAICT (it boots and plays the first 10 minutes fine for me) unless there is something that breaks later in the game.
@doitsujin
Its more simple leave actual workaround DXVK_FAKE_DX10_SUPPORT because DX10 have around 50 titles and in database only have a few
@thirdeyefunction
I dont know what problem have with your setup both here runs without problem, tested around 2hr 30min
https://www.youtube.com/watch?v=5I6Pd3Jmzo8
System Specs Used in Test
Xubuntu 18.04 x64 - Kernel 4.15.0-22 generic (ubuntu mainline) -
CPUFreq: Performance
CPU: Core i3 8350K Tri-Core (Coffelake 14nm) 5.0Ghz + CoolerMaster Hyper T4
MEMORY: 8GB DDR4 2400mhz (4x2) Mushkin (dual channel: 37.5 gb/s)
GPU: Gigabyte Nvidia Geforce GTX 1050 OC (GP107 14nm: 640 Shaders / 40 TMUS / 32 ROPS) Windforce 2GB DDR5 7000Mhz 128Bit (110Gb/s)
MAINBOARD: ASUS Z370-P
@mrdeathjr28 what do you mean? I don't understand that sentence.
@doitsujin
Is more simple leave actual DXVK_FAKE_DX10_SUPPORT than build DX10 game database
But the workaround is still there? I just want to have it enabled for all games that need it by default so that users don't have to mess around with it.
@doitsujin
The Intention is good but environment variable prevent build game database (less work for you)
With variable the user can decide if need activate or not (however DXVK_FAKE_DX10_SUPPORT must stay as default or until DXUP stay integrated in DXVK)
You can find actual game exe name via https://steamdb.info/search/
App Type
to Game
S.T.A.L.K.E.R Call of Pripyat also needs DXVK_FAKE_DX10_SUPPORT. Game exe is: xrEngine.exe Edit: Process name is xrEngine.exe but logs created beside Stalker-COP.exe
Thanks for the entries so far. I will add them all at once shortly before tagging the next release.
I added DXVK_FEATURE_LEVEL
to the list of env vars to be deprecated. This change is not yet live, but it will be replaced by the config option d3d11.maxFeatureLevel
.
Edit: 1a4b17d607c5de1bc6ca8e235d5c173023c884ae implements that change.
in addition to Wow.exe
you should include WowB.exe
andWowT.exe
as well.
B stands for Beta and T for the "Public TEST Realm" executables where people participate in the testing of upcoming content.
As i am not particularly fan of "default enabled" stuff, MY opinion would be to remove ALL default "in-compiled-options" and make the config file pick up options based on .exe name (like is done in the source).
This way, dxvk could include the config in some default location (inside the dxvk install folder), unless overridden by the DXVK_CONFIG_FILE=
env variable.
Why? Cos its a lot easier to open that "default-installed-config" file and look at new default settings as they get updated vs. reading commit-messages or actual source. Having default settings hard-coded in the source is not the most elegant way of doing this.
What about this approach: IF env-variable set -> use spesified conf IF .conf located in game .exe folder -> use game .exe folder .conf Else Use default included .conf in dxvk-install-folder.
That way, you would still be able to include "out-of-the-box" working settings, AND users can choose to tweak themselves.
Yeah, as i said, i am aware that the .conf overrides the hard-coded settings, but keeping track of the different defaults is harder.
Example: Lets say i played WoW beta. Before the included fix, i had to use my own config, as WowB.exe was not hard-coded. Since i dont read source every day, i keep using my config. Then someone finds out some NEW setting that is needed to gain 20 fps in WowB.exe, and hard-codes this in the source, but i miss reading that 1 commit, and thus keeps using my custom .conf.
Just an idea :) Im all about "customer choice" while KISS :)
@SveSop that would require a config file to be present, which is incredibly bad news for anyone setting it up with Lutris or winetricks. Hard-coding some defaults for apps that need it is as simple as it gets.
@SveSop The only reason much of this hard coding is present to begin with is the fact that vulkan doesn't provide support for certain functions of DX they make my life easier with lutris when baked in but as soon as issue #26 on Vulkan-Ecosystem gets resolved all the bake code can be mopped up and it can function better as a general wrapper. Just another upstream waiting game.
Another thing to keep in mind is that some of these hacks are meant to be removed anway, That includes the "fake D3D10" toggle - I already have a (highly experimental) d3d10 branch up and as soon as it is ready to be mainlined, the option will be removed entirely, including the default entries.
0.65 is out and should include all the apps you reported (see commit 6e74db4c6f069201dca857fe3847bf44f3ea87bc).
Just here to report that S.T.A.L.K.E.R Call of Pripyat does not work by default. I had to create dxvk.conf file beside Stalker-COP.exe and override dxgi.fakeDx10Support = True. Perhaps xrEngine.exe should also be added in the commit. I think Stalker-COP.exe is acting like a launcher for the xrEngine.exe which is what process monitor shows as the game process.
@doitsujin I see there could be problems where the default .conf file is missing or otherwise placed in a wrong position.
Ill just have to browse through https://github.com/doitsujin/dxvk/blob/master/src/util/config/config.cpp too try to keep up :P
Raft.exe needs DXVK_FAKE_DX10_SUPPORT
No, it doesn't, unless you're running outdated dxvk versions.
Ah, I see that. There must be something else going on then, because now Raft doesn't work with DXVK
@abenson Depending on how you install DXVK (using script, or doing it manually), you could check that your wineprefix have the following dll-overrides:
d3d10
d3d10_1
d3d10core
d3dcompiler_43
d3d11
dxgi
They should all be set to "native".
I'm only asking this, cos you might (as i am) be setting this up manually, and with a new build where the DXVK_DAKE_DX10_SUPPORT is removed, DX10 is provided by the respective .dll's and is needed for those games that need dx10 support of sorts :) (Especially since it worked before)
PS. Remember also to create symlinks in system32(64 bit) and syswow64(32 bit) if you do it manually.
With the next release, support for most DXVK environment variables will be removed in favour of a per-game configuration file as described on the Wiki, which offers the same options as well as some new ones. This change is already implemented in the current
master
branch.The following environment variables, which sometimes need to be set in order to run a game, will no longer be available:
DXVK_FAKE_DX10_SUPPORT
DXVK_CUSTOM_VENDOR_ID
DXVK_CUSTOM_DEVICE_ID
DXVK_FEATURE_LEVEL
If you know a game which requires one of these environment variables to be set, and is not listed here yet, please let me know in the comments.
The goal is to enable the required options by default and improve out-of-the-box compatibility with those games, which should make life for e.g. Lutris users and maintainers a bit easier.
The following environment variables will not be removed and can safely be used in the future:
DXVK_LOG_LEVEL
DXVK_HUD