Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
On 4 October 2013 15:02, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
Client storage only applies to GL textures, which won't be created for sysmem surfaces.
I don't think that's necessarily true at the moment. In particular, ddraw blits can in principle cause a texture to be created for sysmem surfaces. There might be restrictions in the ddraw API that prevent this from happening in practice, but even if there are, we certainly don't enforce them.
Am 04.10.2013 um 15:28 schrieb Henri Verbeet <hverbeet(a)gmail.com>:
On 4 October 2013 15:02, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
Client storage only applies to GL textures, which won't be created for sysmem surfaces.
I don't think that's necessarily true at the moment. In particular, ddraw blits can in principle cause a texture to be created for sysmem surfaces. There might be restrictions in the ddraw API that prevent this from happening in practice, but even if there are, we certainly don't enforce them. No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.)
Am 04.10.2013 um 15:51 schrieb Stefan Dösinger <stefandoesinger(a)gmail.com>:
No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.) Fwiw, the other patches are independent of this patch.
On 4 October 2013 15:51, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.)
I guess that makes it ok in practice, but I'd still feel happier about this kind of patch if we actually enforced resource access flags first. (At which point you could also just check the access flags instead of the pool.)
Am 04.10.2013 um 17:15 schrieb Henri Verbeet <hverbeet(a)gmail.com>:
I guess that makes it ok in practice, but I'd still feel happier about this kind of patch if we actually enforced resource access flags first. (At which point you could also just check the access flags instead of the pool.) My plan is to enforce this in resource_load_location similar to how it's currently done for volumes. That'd be at the end of my surface cleanup patchset though, and it'll need some additional work (downloading a texture to a bigger sysmem surface to handle get_front_buffer_data).
I think my surface patches should work ok without the assumption that client storage and user memory are mutually exclusive, so feel free to skip this patch for now. The other 4 patches in this series should work ok. Some later patches in the big patchset need minor adjustments though.
participants (2)
-
Henri Verbeet -
Stefan Dösinger