Add dxvk-gplasync as a compatibility tool

[NaiveInvestigator]

Describe the solution you'd like
To add this project dxvk-gplasync as an compatibility tool option.

It is an dxvk async fork which increases performance well beyond what the 2.0 version does and brings a signficant boost in performance on low end PCs. Way more than the async dxvk 2.0. Well atleast on my machine lol.

I hope you consider this feature request!

Also not related to this request lol but TYSM protonup-qt!! It helped a lot and was one of the main factors for me to try switching to linux full time.

[sonic2kk]

There is no existing logic that can fetch from GitLab, so it would take a bit of extra effort to implement, but it should be feasible to add this for Lutris. Once we figure out DXVK etc for Heroic it would also be possible to implement for Heroic as well.

It is probably possible to use this tool with Proton but it would involve modifying Proton builds' libs and their prefixes, so that part is probably out-of-scope. It would be possible to add for Lutris though provided it has the same folder structure as DXVK (which I assume it would). DXVK-Async with ProtonUp-Qt is currently only available for Lutris anyway, so restricting it to Lutris (and potentially extending to Heroic in future) is probably okay.

---

The main issue I see here is that the repository doesn't appear to distribute "packages" but rather stores archives on the repo itself, which is an unusual way of going about things. As a result of this, dxvk-gplasync would probably need to be a separate ctmod and wouldn't be easily derived from an existing one; it uses GitLab and uses VCS for storing the packages, so we'd need to clone the entire repo and extract the selected version. Which brings me to the next problem: How to go about fetching the versions as well as then selecting them. Maybe this is something to report upstream first, to ask them to use packages, and then we'd investigate using a GitLab API to fetch the releases that way. Though it seems GitLab may have an API for accessing repository files, I get the impression from a very quick glance that their API always expects an auth token (this may be for repo maintainers and not a public API, not 100% sure)

Turns out I was wrong 😛 I spent a long time trying to figure out how to navigate GitLab, and eventually found a small "releases" link. Indeed, this project does have regular releases: https://gitlab.com/Ph42oN/dxvk-gplasync/-/releases - And we can get the releases from the https://gitlab.com/api/v4/projects/43488626/releases" endpoint, and it does not need authentication. I am sure it's rate-limited but I am not sure what the limits are. GitLab documentation for this endpoint can be found here: https://docs.gitlab.com/ee/api/releases/

GitLab's API calls seem to consistently use pagination, however unlike for other parts of the docs, I can't see how many this API returns per-page. The standard for them seems to be 20, so it may return 20 releases. Currently there are not 20 releases, but this is a consideration for the future.

Since the API response will differ from GitHub's, we'll probably need a separate ctmod for this tool anyway. Extraction will probably mirror other similar files. I have been considering for a while to look into creating some generic helper methods to handle extraction, which we can call from ctmods, instead of having "loose" extraction logic around different ctmods. Perhaps when implementing this ctmod (if at all) we could look into creating some kind of "common" extraction code.

As well as this, the GitHub API check we use may need updated or extended in some way to check for GitLab rate limits, and we would probably also want to differentiate and mention when a GitLab API call fails versus when a GitHub API call fails - it's possible that a user could be rate-limited from downloading a bunch of tools from GitHub, but they'd still be able to download these GitLab tools fine.

---

Side note: I thought GPL was just an option that was enabled for RADV (and that it was on by default with Mess 23.1) but I'm not a graphics expert, so it's very possible I'm wrong here :-) The purpose of this tool is to allow async with the shaderPipeline option in newer DXVK versions, as currently DXVK-async will disable this extension because of an incompatibility. This tool allows DXVK-async to work with GPL. I should've read the repo more closely!

[sonic2kk]

As an aside, I am wondering what the likelihood of this being "upstreamed" into dxvkasync is. The same argument could be made and has been made for D8VK potentially eventually being merged upstream into DXVK, and we still include that.

[sonic2kk]

I wanted to take a look at this a while back, but work+other projects got on top of me a little bit.

Might take a look at it later this week if I can spare some time, the main thing is as mention allowing downloads from both GitHub and GitLab, since they are two different APIs. The extraction and general makeup of the ctmod should be similar, it just has to download from GitLab using that API.

A while ago I also looked a bit into creating some kind of base ctmod class, I think I ran into a couple of issues basically with the best way to break things apart. In my head I probably wanted to do that first, since then downloading would be more generic, but that all can probably wait as it would be a pretty big rework probably across at least a couple of PRs. I also wanted to try and merge the DXVK ctmods into one base like I did with Proton-tkg, but I think as well I ran into some problems, though I haven't done much contribution to ProtonUp-Qt in a while and can't remember any details 😅

I'd still like to look at it as the work I've been doing on other projects has subsided and my personal life has settle down a little bit, so if no one else is doing it I can make an attempt sometime this week unless someone is already doing so :-) I'll update if I don't get time or get anywhere.

---

To update on my comment from earlier, D8VK is actually in the process of being upstreamed, but it still has a bunch of review to go through by the looks of it. However I don't think there is any plans from either DXVK/Valve or the author of this DXVK fork to do any upstreaming work (hosting on GitLab as well would also make this a little more difficult).

[NaiveInvestigator]

@Ph42oN

[Ph42oN]

I think upstreaming of async was chosen to not happen by DXVK dev pretty long ago. It looks like most people think async is not needed anymore because of Graphics Pipeline Library. That seems to be true in most games but there are situations with more stutter than async. It made me think why not both, and thats why gplasync was created.

I think getting this to upstream DXVK is very unlikely.

Getting this patch to GE-proton is possibility, but i am in GE discord server and people don't seem to care about this.

[sonic2kk]

I'm taking a look at implementing this, hoping to get a draft PR up soon :-)

[sonic2kk]

PR is up at #302, it wasn't nearly as infeasible of a refactor as I thought, but it also wasn't trivial and may still change based on PR feedback :-) Feel free to take a look at the code if you'd like!