[Bug 45901] Avoid GPU synchronization due to GPU-CPU transfer (Overwatch)

wine-bugs at winehq.org wine-bugs at winehq.org
Fri Sep 28 09:53:57 CDT 2018


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

--- Comment #8 from Henri Verbeet <hverbeet at gmail.com> ---
(In reply to Józef Kucia from comment #7)
> I think that one problem with your patch is that it doesn't solve the issue
> completely. It fixes the problem only when the source resource is a render
> target. Otherwise, we still use the slow GetTexImage() path.
> 
> Other possible ways to fix the issue:
> 1) Optimize GetTexImage() in Mesa.
I think we want this.

> 2) Use OpenGL resources for staging resources in wined3d. I think it could
> avoid the issue completely. CopyResource() would be a normal raw blit
> between 2 GL textures. However, it isn't something that we should change
> lightly. It needs some consideration, and I'm not sure if it's a very good
> idea.
Well, one issue with that approach is that you're moving the GPU stall to
mapping the staging texture, since now the staging texture stays on the GPU
until it's mapped.

I think using PBOs (instead of textures) to back staging resources may be ok,
but you're right that that's a major change. I'm thinking we could then have
texture2d_download_data() download directly into the destination PBO, similar
to how wined3d_texture_upload_data() takes a wined3d_bo_address for its
destination data. texture2d_blt() could then handle downloads the same way it
handles uploads. That still potentially stalls on mapping the staging texture,
but only if the copy hasn't finished yet by the time we try to map the PBO,
which I think may be the expected behaviour.

-- 
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.


More information about the wine-bugs mailing list