I haven't had the time to build my own custom wine-tkg build in weeks, so I'm rusty as hell at debugging issues like this but I think I found at least the direction of the problem.
Anyway, using no presets and trying to enable amd_fsr_fshack-alternative.mypatch from community-patches fails every time with prepare.log saying:
Applying your own patch amd_fsr_fshack-alternative.mypatch
patching file dlls/winevulkan/vulkan.c
Hunk #1 FAILED at 879.
Hunk #2 FAILED at 914.
2 out of 2 hunks FAILED -- saving rejects to file dlls/winevulkan/vulkan.c.rej
patching file dlls/winevulkan/make_vulkan
Hunk #1 FAILED at 3207.
1 out of 1 hunk FAILED -- saving rejects to file dlls/winevulkan/make_vulkan.rej
patching file dlls/winevulkan/vulkan.c
Hunk #1 succeeded at 1546 (offset -460 lines).
Hunk #2 succeeded at 1559 (offset -163 lines).
followed by a ton more lines reporting success.
If I remove -alternative and just try to use the original fsr patch, it applies cleanly. This is weird, because at least some of the lines that are failing are unchanged and are exactly the same in the original amd_fsr_fshack.mypatch. So that shouldn't be happening.
So I looked into it, and there has to be some hotfix or some other patch that is getting applied when the user specifies amd_fsr_fshack.mypatch in customization.cfg, but not when they specify amd_fsr_fshack-alternative.mypatch.
Both patches have this:
--- a/dlls/winevulkan/make_vulkan
+++ b/dlls/winevulkan/make_vulkan
@@ -3207,7 +3207,7 @@ class VkGenerator(object):
f.write(" * resolution; user_sz will contain the app's requested mode; and dst_blit\n")
f.write(" * will contain the area to blit the user image to in real coordinates.\n")
f.write(" * All parameters are optional. */\n")
- f.write(" VkBool32 (*query_fs_hack)(VkSurfaceKHR surface, VkExtent2D *real_sz, VkExtent2D *user_sz, VkRect2D *dst_blit, VkFilter *filter);\n")
+ f.write(" VkBool32 (*query_fs_hack)(VkSurfaceKHR surface, VkExtent2D *real_sz, VkExtent2D *user_sz, VkRect2D *dst_blit, VkFilter *filter, BOOL *fsr, BOOL *fsr_lite, float *sharpness);\n")
None of that code is in the upstream tree (or staging), the line that's being replaced doesn't exist. Grepping recursively through all the files in the wine-tkg-git/wine-tkg-git directory for content from those lines returns a ton of results, but nothing that adds the lines in the first place, so I haven't found where they originally come from. But hopefully you know what the issue is from my description and it's an easy fix. Once I get finished with my Regolith DE port updating to version 2.0 from 1.6 (which 2.0 changed literally everything about everything, so it's a nightmare and I'm the sole maintainer for all of Arch Linux for the Regolith Linux org, ugh), I plan to get back into helping out as much as I can with you, GE, and reporting and bisecting bugs in DXVK/VKD3D/etc.
I haven't had the time to build my own custom wine-tkg build in weeks, so I'm rusty as hell at debugging issues like this but I think I found at least the direction of the problem.
Anyway, using no presets and trying to enable
amd_fsr_fshack-alternative.mypatchfromcommunity-patchesfails every time withprepare.logsaying:followed by a ton more lines reporting success.
If I remove
-alternativeand just try to use the original fsr patch, it applies cleanly. This is weird, because at least some of the lines that are failing are unchanged and are exactly the same in the originalamd_fsr_fshack.mypatch. So that shouldn't be happening.So I looked into it, and there has to be some hotfix or some other patch that is getting applied when the user specifies
amd_fsr_fshack.mypatchincustomization.cfg, but not when they specifyamd_fsr_fshack-alternative.mypatch.Both patches have this:
None of that code is in the upstream tree (or staging), the line that's being replaced doesn't exist. Grepping recursively through all the files in the
wine-tkg-git/wine-tkg-gitdirectory for content from those lines returns a ton of results, but nothing that adds the lines in the first place, so I haven't found where they originally come from. But hopefully you know what the issue is from my description and it's an easy fix. Once I get finished with my Regolith DE port updating to version 2.0 from 1.6 (which 2.0 changed literally everything about everything, so it's a nightmare and I'm the sole maintainer for all of Arch Linux for the Regolith Linux org, ugh), I plan to get back into helping out as much as I can with you, GE, and reporting and bisecting bugs in DXVK/VKD3D/etc.