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

DXVK-Cache as a part of a game profile distribution? (discussion) #764

Closed
felixblaschke opened this issue Nov 13, 2018 · 14 comments
Closed
Labels

Comments

@felixblaschke
Copy link

First of all: thank you for your work within this large project. I really appreciate it.

I read inside the gaming on linux topic and a common problem is stuttering while the DXVK cache is generating. Do you think it is a good idea to provide "mostly filled cache files" within for example a Lutris script?

Or is it a bad idea?

@doitsujin
Copy link
Owner

doitsujin commented Nov 13, 2018

As far as I know it's already being done in Lutris for a small number of games. So yes, the idea is good in my opinion.

But keep in mind that some people have raised security concerns in case the cache file does not come from a trusted source (I don't really want to reiterate on that, TL;DR is that a tainted cache might trigger undefined behaviour in the graphics driver).

@felixblaschke
Copy link
Author

felixblaschke commented Nov 13, 2018

in case the cache file does not come from a trusted source.

I guess most people doesn't verify the Lutris script either. They expect a one-click solution.

Can you tell us something about the security impact when such cache files are manipulated? Can it run arbitrary code? Or does it "only" crashes?

@doitsujin
Copy link
Owner

doitsujin commented Nov 13, 2018

That would depend on what the driver does when it receives invalid pipeline state. Do note that tainted entries are not going to get used for rendering, they are only used when compiling pipelines.

I personally don't think there's anything to worry about as long as you provide your own cache file along with the Lutris installer and would be very much in favour of distributing them, just be aware that there will probably be one person on reddit complaining that neither DXVK nor drivers have undergone extensive security audits (not even kidding, already happened). Just don't distribute random files from random people and it should be fine.

@kakra
Copy link

kakra commented Nov 13, 2018

There's this project (tho, I personally don't like the java approach and thus didn't bother to test it):
https://github.com/rcpoison/dxvk-cache-pool

It has some sort of weak trust checking (with a simple heuristic) and uses signed cache files. But it can be setup to share a cache among people trusting each other by not using the "official" server.

@felixblaschke
Copy link
Author

There's this project (tho, I personally don't like the java approach and thus didn't bother to test it):
https://github.com/rcpoison/dxvk-cache-pool

That project goes into a good direction. But it need some spaming prevention. "Evil clients" can spam the server with invalid cache entries that get synced to clients. There must be something like trusted cache entries contributors.

@kakra
Copy link

kakra commented Nov 13, 2018

Well, you can opt-in to become a trusted user and - separately - also only use cache entries from trusted users.

@felixblaschke
Copy link
Author

I started a new discussion about how to utilize the dxvk-cache-pool for Linux gaming at rcpoison/dxvk-cache-pool#16

@doitsujin Does Nvidia users get other cache entries then AMD users?

@doitsujin
Copy link
Owner

doitsujin commented Nov 14, 2018

@felixblaschke No, the cache entries are identical, unless the game itself uses different shaders for the two vendors (this does happen, but it's uncommon). However, entries may differ when switching in-game settings, particularly when there's an MSAA option.

@felixblaschke
Copy link
Author

@felixblaschke No, the cache entries are identical, unless the game itself uses different shaders for the two vendors (this does happen, but it's uncommon). However, entries may differ when switching in-game settings, particularly when there's an MSAA option.

What is the behavior of the cache files? Are they purely additive or is there a moment when they get reseted by DXVK?

@doitsujin
Copy link
Owner

They can be reset if they are corrupt for some reason (i.e. have incomplete entries or entries with incorrect checksums). DXVK will however restore any valid cache entry that could still be read from the file in that case.

@massatt212
Copy link

is it up to nvidia amd and intel to make DXVK cashe better or will be stuck on stutters when we first launch a game ?

@asumagic
Copy link

asumagic commented Dec 3, 2018

The state cache is a DXVK thing @massatt212, the driver developers are not responsible for these. State caches are vendor neutral.

Caching would have to be implemented by a 3rd party program/library (e.g. Lutris).

@massatt212
Copy link

So will it always be stuttering at first or optimization can be made for smoothness similar to windows ?

@kakra
Copy link

kakra commented Dec 4, 2018

@massatt212 The problem is DirectX allows individual shader compilation on the fly while Vulkan requires compilation of the whole pipeline as far as I understood. This cannot be worked around and the state cache is already a great improvement because it allows compilation ahead of time when an application previously used this shader.

As for the stuttering, I lately saw less stuttering (probably due to the priority patch that has gone into DXVK when combined with the realtime patches of wine-staging) but at least in SOTTR I instead see objects popping in late now, at least in the in-game benchmark: The second scene starts to render the mountains only late while the camera moves over to the village view instead of stuttering or halting the rendering. On a second run, everything is rendered immediately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants