search

DavidoTek / ProtonUp-Qt

Install and manage GE-Proton, Luxtorpeda & more for Steam and Wine-GE & more for Lutris with this graphical user interface.
https://davidotek.github.io/protonup-qt
GNU General Public License v3.0
1.25k stars 40 forks source link

D8VK: Fix fetching new artifacts #273

Closed sonic2kk closed 1 year ago

sonic2kk commented 1 year ago

D8VK has changed how it builds and thus names artifacts, and so newer builds are not being detected with ProtonUp-Qt. This PR fixes the issue and allows newer D8VK builds to download again by checking on the new dxvk artifact name, whereas previously we checked on d8vk.

Background

Originally, D8VK builds packaged two artifacts:

The D8VK and DXVK native builds have different folder structures, and DXVK native builds would not be applicable when using Proton, so we made sure to download the D8VK artifact by checking the artifact name. If this sounds familiar, when DXVK 2.0 came out, #140 was needed to make sure we downloaded the correct DXVK artifact and not the DXVK native one. So the rationale around checking the branch name with D8VK made sense at the time.

You can see an example of how D8VK builds used to look here: https://github.com/AlpyneDreams/d8vk/actions/runs/5445176587 - You can see that they have the two mentioned artifacts.

image

All this to say, in short, currently on main we're checking for artifacts that have d8vk in them.

Problem

Recently, D8VK changed its build system and now only packages one artifact. This artifact contains both the native Linux libraries and the Windows DLLs for Proton. This artifact uses the name dxvk-<branch>-hash. But because ProtonUp-Qt is looking for the old d8vk artifact names, when it checks newer builds, it can't find any artifacts with that name and so it doesn't download any artifacts because it doesn't think there are any valid ones available.

Solution

The fix for this is to check for both dxvk and d8vk (for legacy artifacts and backwards compatibility). This is probably not wholly necessary because going forward all builds will likely just use dxvk, but this should also cover us in case they switch back to a different archive name (imo it makes a bit more sense to name the artifacts d8vk and I could see the name changing, but that's just my opinion :wink:).

Checking for dxvk now as well fixes the issue and allows D8VK builds to download successfully. Woohoo! You can see an example of a new D8VK build here: https://github.com/AlpyneDreams/d8vk/actions/runs/5456804847

image

The D8VK folder structure now looks like this:

image

Previously, the usr folder was in the separate artifact (this is why #140 broke DXVK, the folder structure and such was incorrect). This would've been in the dxvk artifact, and the x32 folder was part of a separate d8vk artifact.

Now, we only have one artifact which contains both builds of D8VK.

Hope that makes it clear why this change is necessary :-) I came across this because I was trying to download D8VK with ProtonUp-Qt and was very confused as to why it wasn't working, as it had been working recently. Dang build system changes! :smile:

sonic2kk commented 1 year ago

Had to update the commit and PR title which I messed up, that's what I get for making PRs at 1am :sweat_smile:

DavidoTek commented 1 year ago

I came across this because I was trying to download D8VK with ProtonUp-Qt and was very confused as to why it wasn't working

Good you noticed that. I haven't used D8VK at all lately ;)

The fix for this is to check for both dxvk and d8vk

I think it will work fine for the new versions, but if both dxvk and d8vk are available it will pick one at random (depending on which comes first in the list of artifacts). I did some tests and found a solution. I will add a commit.

in case they switch back to a different archive name (imo it makes a bit more sense to name the artifacts d8vk and I could see the name changing

I think the logic I implemented should also consider this.

Thanks!