Support upstream Wine
Opened this issue · 16 comments
Is there any plan to make wine-pba work with upstream Wine rather than staging?
Staging itself can introduce unwanted regressions to some games, so using upstream is always a preferred approach.
There is a thread going on here where it's rebased to wine-stable 3.3:
#26
I personally hope it remains on wine-staging, since a lot of games - including most Blizzard titles - require it. Because there is no before or after here, it's either/or. If wine-pba is applied to the upstream wine, then staging can't be applied after since staging relies on an almost untouched wine-development.
A separate branch where it's rebased to stable would probably be a good thing, though. And eventually I'm crossing my fingers for this patchset being included in the main wine project. 👍
A separate branch where it's rebased to stable would probably be a good thing, though.
I agree, that may be splitting it into branches would be useful. While staging has some benefits, it has downsides too, like above, and in general it's always good first to apply the project to upstream, and then make it work with staging if needed. It improves the chances of it being upstreamed itself.
Branching this off to "wine-stable" and "wine-staging" would be a good idea, as ppl could have a choice :)
Getting this picked up by wine-stable i guess is quite a different issue, as it took (afaik) a lot of work to implement wine-vulkan, and that was by no means "as intrusive" as pba is i guess :) But i for one vote for "it should be done" :)
I did start , but never completed, a wine-devel ( wine-3.4 ) branch
note: wine-stable is wine-3.0
I'll re-look at that
regards upstreaming, it shouldn't be all that hard. @acomminos 's most recent commit included an off switch and falls back to 'staging' if it fails to create geo and cb heaps
since that commit my laptop fails back to not using pba, previously it fell over.
I may look at crafting the patches to 'drop in to' fit staging patches , mostly for personal education
@FireRat Yeah.. going bonkers of the "git" "stable" "devel" "staging" stuff.. but yeah.. wine-devel :)
untested,
I just used git am -3 <patches> and git mergetool to fix conflicts ( not many )
wine-pba_for_wine_3.0_wine_3.4.tar.gz
Edit:
the wine_3.0 patches are broken, 3.4 is fine
actually, it looks like we can just break off the wined3d-csmt/Makefile.in into a separate patch, at least for the devel branch.
Edit:
the last patch ( 0010 ) is for staging only, ignore that one if you are applying to wine-devel
wine-pba-3.4.tar.gz
just debating with myself over the best way to present these patches
should probably have the STAGING-wined3d-csmt-update-Makefile.in-for-PBA.patch as the first in the series, since that is very unlikely to change, and then generate the rest starting at it's commit instead of the staging tag
non staging patchers just ignore patch 0001
as you can see, I have re-jigged the patchset a tiny amount
skip patch 0001 for wine-devel
it works currently, might not in the future
wine-devel with those patches compiles, but I havn't actually tested the build
https://github.com/Firerat/wine-pba/commit/56217eeda2b659cc35ac745791f72857cde99cc2
https://github.com/Firerat/wine-pba/tree/backports
it compiles, it boots
not heavily tested
Edit: for fun and education, I did 3.4 >> 2.21 , no real advantage over 3.4
So what's the story now, can I apply patches from this repo except for the first to regular Wine, or not yet?
well, staging 3.5 no longer has the wined3d-csmt, so the 3.5 rebase is easier to apply now
best way is to use git am --3way ( apply mailbox with 3 way merge )
some guidance here
https://github.com/Firerat/wine-pba/wiki/patch-rebase-and-conflicts
won't have all the answers, but should give you a head start
Is staging needed though? The goal was to avoid touching staging repo. Or it's caused by the fact that current repo is based on staging patched Wine?
give it a try, if you get stuck I will pull a clean wine-devel only repo and troubleshoot it for you
This step went smoothly, didn't show any conflicts:
git am --3way ../wine-pba/patches/*.patch
Applying: wined3d: Initial implementation of a persistent mapped buffer allocator.
Applying: wined3d: Add support for backing dynamic wined3d_buffer objects by a persistent map.
Applying: wined3d: Use ARB_multi_bind to speed up UBO updates.
Applying: wined3d: Use GL_CLIENT_STORAGE_BIT for persistent mappings.
Applying: wined3d: Disable persistently mapped shader resource buffers.
Applying: wined3d: Perform initial allocation of persistent buffers asynchronously.
Applying: wined3d: Avoid freeing persistent buffer heap elements during use.
Applying: wined3d: Add DISABLE_PBA envvar, some PBA cleanup.
Applying: wined3d: Add quirk to use GL_CLIENT_STORAGE_BIT for mesa.
Yep, resulting patches applied fine to wine 3.5, thanks! Building it now.