[Bug 44315] Buffer maps cause CPU-GPU synchronization (Guild Wars 2, The Witcher 3)

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=44315

--- Comment #43 from Kai Krakow <kai at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.