wine runner dxvk-cache-pool integration

[rcpoison]

Hi :)

Would there be any interest integrating my cache-pool for dxvk state cache sharing in the wine runner?

Integration would involve running the pool client with the executable as parameter and setting the DXVK_STATE_CACHE_PATH env var before running the game.

Users would benefit by not having to build up the state cache themselves.

I planned on taking a stab at it myself but wine.py looks a bit intimidating to a non-python dev.

https://github.com/rcpoison/dxvk-cache-pool

[tannisroot]

IMO integrating a Java component into a Python application feels messy. I think creating the same thing but in Python would be better for Lutris.

[rcpoison]

It's just another cli application lutris could optionally run, there wouldn't be any java code in lutris.

[Zeioth]

I also think Python would be a better solution (Imagine if every developer uses his favourite language, we would end with several runtime dependencies). The problem here is... How hard it would be to port dxvk-cache-pool to python? Because the project is only 25 days old, but it's maybe 10-15k lines of code to port. It could take about 2-4 weeks for one person. If it's too much work, give us some classes, maybe we can help you to port them.

Also, linking https://github.com/rcpoison/dxvk-cache-pool/issues/14

[rcpoison]

I also think Python would be a better solution (Imagine if every developer uses his favourite language, we would end with several runtime dependencies).

This is an external project, unrelated to and independent of lutris. Also, my point still stands, it's just an CLI program that lutris could optionally run, if present on the system, if it so desired. I don't see how it matters what language an external CLI application is written in as you don't have to interface with any of the APIs.

If it's too much work, give us some classes, maybe we can help you to port them.

I will not port it to Python because it's not a language I really know. I could port it to C/C++ but that's so not worth the effort (to me) and it would still not be Python so I guess the same arguments would apply.

[felixblaschke]

Imagine if every developer uses his favourite language, we would end with several runtime dependencies

I think Java shouldn't be a showstopper here. Java is a Tiobe top 5 language (like python) so there a many developers that can help contributing / validate code. Installing java runtime on linux is very easy (openjre).

You should consider the value of this caching service contributing to the Lutris project. To be honest. The typical gamer will just paste the terminal stuff and expects to run games smoothly. He won't question about another runtime dependency.

[Sukid]

I agree that it should be fine as long as it's an optional thing that Lutris can integrate with if it's present but isn't going to demand that you install. Like gamemode. Lutris doesn't make you install that, it just has an option to work with it if it's there.

[Zeioth]

Related issue: https://github.com/lutris/lutris/issues/1384

[strycore]

pretty sure this kind of fuckery isn't needed anymore

[tannisroot]

@strycore it is, Lutris def needs to implement state cache sharing at some point.

[strycore]

Wasn't sure, guess I'm good to re-implement a Java project in Python then :sweat_smile:

[romulasry]

Interesting.

[Zeioth]

Valve is already providing its own pool of shader caches. This ticket is still relevant for those games running outside of Steam. Hosting costs should be considered before implementing this feature.

[strycore]

can someone offer some kind of rough prototype of how this would be done? doesn't have to be python.