https://bugs.winehq.org/show_bug.cgi?id=45901
--- Comment #8 from Henri Verbeet hverbeet@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:
- Optimize GetTexImage() in Mesa.
I think we want this.
- 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.