Why not just use the DXVK_STATE_CACHE_PATH environment variable to specify a directory?
There is no reliable way for DXVK to determine the path to the app's executable, and writing somewhere to the user's 'home' directory (on the Windows side) is not an option because it's a) fragile and b) the Windows APIs involved are completely retarded.
Why not just use the DXVK_STATE_CACHE_PATH environment variable to specify a directory?
That would require user intervention for each game/wine prefix.
My implementations scans for executables in passed directories and queries the server for available cache entries for them, it would be nice for that to just work in a default setup instead of the user having to either manually specify file locations for each game or set DXVK_STATE_CACHE_PATH for each wine prefix.
There is no reliable way for DXVK to determine the path to the app's executable
https://stackoverflow.com/questions/2647429/c-windows-path-to-the-folder-where-the-executable-is-located wouldn't work?
Sorry, I'm having trouble building mingw to try myself :(
You could likely add DXVK_STATE_CACHE_PATH to the user’s ~/.profile. It would require a log out / log in after installation though to ensure that it is reflected.
@ryao: sure, but that would affect all wine prefixes, and I wouldn't be able to tell games apart that have the same executable name.
Also, setting it as global variable would probably(from a quick glance at the code) result in DXVK sharing the same state cache across games with the same executable name.
Which distribution are you using? There might be instructions on how to get mingw for it in an existing issue (open or closed) on the tracker.
would probably(from a quick glance at the code) result in DXVK sharing the same state cache across games with the same executable name.
That's not too common, and DXVK doesn't really care if you mix entries from multiple different games.
@doitsujin ok, thanks :)
I assume the .state-cache would have to grow to a respectable size for DXVK to run into problems?
Would additional heap be used apart from the structs size?
In that case I'll go ahead and simply merge all DxvkStateCacheEntry's with the same name.
Overwatch players get cache files in excess of 45 MB, so yeah, they can get fairly big without causing too much trouble in practice.
Got it, thanks.
https://github.com/rcpoison/dxvk-cache-pool/commit/df619164cca0d2fe439e156b8c78d8f382cf49e9
PS: That overwatch cache file sounds interesting for testing purposes if someone wants to send it to me.
Sharing DXVK cache files is insecure, so I would advise against using cache files from people that you do not know.
@ryao https://github.com/rcpoison/dxvk-cache-pool#security
I know it's insecure.
I don't think I can secure it in the near future. Or ever.
Even if you only accepted entries from people you trust their entries might be from a third party and inherently you'd end up with a web of trust.
A web of trust is great unless you can not validate the subject, which in this case I don't think is ... easy.
So, should I abandon the project? Does the usefulness outweigh the risk?
I'm currently studying the code to find attack vectors, but so far, from my (still very limited) understanding the only one is DxvkStateCacheEntry.DxvkGraphicsPipelineStateInfo.
If that's even feasible.
(Please excuse my English, I already had a few beers)
You did not mention who the contributors would be when you opened this. I just wanted you to know rest before you take a cache file from someone that you do not know. I think that you should have people PGP sign their caches so that trusted individuals who contribute cache files can at least have the origin of their contributions verified.
For example, I have a fairly well trusted PGP key. If I were to send you my cache file for overwatch and sign it with my key, I would be asserting that it is not malicious at the risk of my reputation if that should turn out to not be the case. That implies that it is trustworthy to the extent that people trust that I am not going to throw my reputation away to compromise them.
It would be a problem when someone’s key is not in the chain of trust (asserting that their identity was verified in person), but I suppose that you could just refuse to take contributions from people who have not done key signings to get into the boarder community’s chain of trust.
My overwatch cache file is not 45MB though. It was 25MB at last look.
@ryao I don't think you got my point:
A web of trust is great unless you can not validate the subject
There's currently no way to validate the cache entry.
Your signature means nothing if you sign something you yourself can not validate.
Hence you shouldn't sign said message in order to not tarnish your reputation.
@ryao the cache files have little entropy and thus compress well. Providing me a download would be nice. Thanks.
@ryao I don't think you got my point:
A web of trust is great unless you can not validate the subject
There's currently no way to validate the cache entry.
Your signature means nothing if you sign something you yourself can not validate.
Hence you shouldn't sign said message in order to not tarnish your reputation.
I can state that I generated it myself.
@ryao the cache files have little entropy and thus compress well. Providing me a download would be nice. Thanks.
A download URL has the problem that once I put it up and link to it, I will feel obligated to host it forever, and I don’t want to volunteer infrastructure space for a cache file. Send an email to my @gentoo.org address asking for it and I will reply with the cache file as an attachment.
@rcpoison It occurred to me that it is possible to attach files to github comments. Here is my
Overwatch dxvk-cache file. It is 31MB (binary bytes) uncompressed. The compressed version has sha256 fa34bff4ee406fbd7da30dc27ff53249353b60ed7cb7586c5b0f5cb4760825e3.
By the way, if we had a way of validating cache entries, we would not need to trust people because we could check what they uploaded. I consider the web of trust to be the fallback for when people cannot do that.
And how do you want to reasonably validate them? Reimplementing all Vulkan validation rules for pipeline creation just isn't viable, it's guaranteed to introduce bugs and break games, while at the same time it's guaranteed to let some potentially invalid pipeline states get through to the driver.
I'm strongly against anything like that and would just recommend not using the state cache if that's a concern.
@doitsujin I don't seem to be able specify a state cache dir outside of the wine prefix:
export DXVK_STATE_CACHE_PATH=/home/poison/.cache/dxvk
warn: DXVK: No state cache file found
warn: DXVK: Failed to open state cache file
is this working as inteded? Does steam/proton have a patch to write the caches to SteamApps/shadercache/*/DXVK_state_cache ?
Or is there some symlinking going on that I cant see?
Sorry for bothering you again :/
mkdir -p "$DXVK_STATE_CACHE_PATH" ?
@pchome Of course the directory exists. And is writable by my user.
Use drive z: to access out of the wine prefix.
@rcpoison Your wine prefix must be set up in such a way that Windows apps can access the target directory. That should be possible by default, and works just fine for me.
DXVK_STATE_CACHE_PATHx4 2018-09DXVK_STATE_CACHE_PATH=/home/poison/.cache/dxvkx1 2018-09
I'm developing a pool/repository for the state caches and have a small request.
Would you consider changing the default location for .dxvk-cache file to either:
instead of $CWD.
Otherwise I have no way of reliably determining the target directory for a .dxvk-cache based on the exe's name+path.
In case that is not something you want to implement, would there be noticable side-effects in DXVK if I merged the DxvkStateCacheEntry's from different games (with the same executable name)?