https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #43 from Kai Krakow kai@kaishome.de --- (In reply to Zebediah Figura from comment #42)
(In reply to Kai Krakow from comment #41)
It looks like pba requires inclusion of many (if not all) d3d staging patches - which includes the deferred context patches. Apparently, these also depend on the nvapi patches which is a no-go if you want to allow using dxvk: While it works, it slows dxvk down because it has to deal with command streams in games then (resulting from nvapi) and it cannot do so and complains loudly. There is no support for this in Vulkan so it's unlikely to be supported in dxvk any time soon.
For what it's worth, the dependency here is artificial; it was a sledgehammer solution to the problem that the two patches kept interacting poorly during rebases (in specific, I believe git kept trying to apply the nvapi patches in the wrong place).
This is good news and makes me want to experiment with this.
And yes, I see this a lot with Git... Parts of function bodies may end up in the wrong function after merge due to very similar structure of nearby functions, especially with rerere enabled. A solution here is to refactor out the similarities into helper functions or move the invasive patch into its own file and just reference that with a function call.
I found that meld is a very nice tool to help with that. I used kdiff3 before which is very convenient because it does a lot of stuff automatically but it is often also very wrong with its decisions. The meld tool was which finally enabled me to rebase the fullscreen hacks properly and discover that actually one git revert was missing to add back in what was refactored out before.
BTW: I don't think there's a chance to get pba upstreamed into wine any times soon without the inter-dependencies with wine-staging being resolved and making the changes to the code more easy to follow. But this only means we should work on it.
Indeed, I suspect Henri et al. would be very happy to help work together with people to optimize buffer mapping—whether that takes a similar form to Andrew's patchset or not.
I'll look into it and try to understand what it does but I'm not sure if I'll be successful with it because I lack the time to deeply work into the wine code and DX in general. I think I only got a very small glimpse of that while I rebased proton 3.7 to wine 3.16. Maybe we can start with adjusting the code to no longer show these rebase conflicts - but this is probably where my help would end currently.