search

rcpoison / dxvk-cache-pool

Client/server for sharing DXVK pipeline caches
Other
35 stars 2 forks source link

Concept: integration into Lutris platform (discussion) #16

Closed felixblaschke closed 5 years ago

felixblaschke commented 5 years ago

Thank you for your work you put into dxvk-cache synchronization tool. It's sad to see the Lutris project doesn't want to integrate it because of Java. I want to discuss how the Linux community can profit of your work.

I just tell you about the concept I have in mind:

  1. A pool of trusted players can easily collect dxvk-cache data (by using your client) for a certain game and synchronizes them with a cache-pool server
  2. At the certain point the cache-pool server compiles all entries of an executable into a single cache file (f.e. Overwatch.exe_DXVK_Cache)
  3. The cache file is going to be published to a static file hosting service
  4. Lutris scripts will wget the files during it's install routine

This procedure has some advantages:

What do you think about it?

rcpoison commented 5 years ago

Thank you for your work you put into dxvk-cache synchronization tool.

You're welcome ;)

It's sad to see the Lutris project doesn't want to integrate it because of Java.

It's not my project and I'm not trying to sell anything.

I want to discuss how the Linux community can profit of your work.

Running the client manually isn't that hard. Helping set up a debian repo would be a good start by giving more users easy access.

I just tell you about the concept I have in mind:

  1. A pool of trusted players can easily collect dxvk-cache data (by using your client) for a certain game and synchronizes them with a cache-pool server
  2. At the certain point the cache-pool server compiles all entries of an executable into a single cache file (f.e. Overwatch.exe_DXVK_Cache)
  3. The cache file is going to be published to a static file hosting service
  4. Lutris scripts will wget the files during it's install routine

The client decides on trust, not the server. The server merely holds the cache entries and their signatures and wouldn't know which entries to include.

I also dislike the idea of fragmenting the cache by having a private server which wouldn't benefit non-Lutris users.

If you wanted something like this it'd be better to contribute to the official cache and wrap the client to export entries from your trusted public keys. Only fetching entries for white-listed public keys is already supported by the server and client - just not (yet) exposed via the CLI. This would still require all of the cache to be built by a few select users. I don't know if anyone wants to play through a game multiple times on all permutations of the possible GFX settings(different settings can and do emit different shaders).

This procedure has some advantages:

  • no new "evil" runtime dependencies to the Lutris project

... optional wicked, bad, naughty, evil dependency the user can decide if he wants ^^

  • secure to players because there is no way in corrupting in files afterwards

No. Unless someone has enough CPU time to compute SHA256 collisions plus multiple ECDSA collisions it's already pretty much secured against corruption. On the other hand, once you write the .dxvk-cache you strip all the signatures and end up with something completely unsecured.

In case you meant cache poisoning instead of entry corruption, that's what trusted users and a web of trust are meant to solve.

felixblaschke commented 5 years ago

Okay I see have a good plan for project. Keep it up :-)

rcpoison commented 5 years ago

Mal schaun o/

Zeioth commented 5 years ago

@felixblaschke This feature is planned for Lutris 1.0+.