Re: [PATCH 4/5] wined3d: Use unsynchronized buffer updates only if there has been at least one buffer map.
On 4 November 2016 at 13:43, Józef Kucia jkucia@codeweavers.com wrote:
Fixes bc019fcbbd7f0014280a292bc58ef618cfbe34c7. We cannot use unsynchronized updates when the application haven't called map at all.
Mostly out of curiosity, how is this triggered in practice? Also, would it make sense to track synchronised/unsynchronised in buffer_invalidate_bo_range() instead?
On Mon, Nov 7, 2016 at 3:31 PM, Henri Verbeet hverbeet@gmail.com wrote:
On 4 November 2016 at 13:43, Józef Kucia jkucia@codeweavers.com wrote:
Fixes bc019fcbbd7f0014280a292bc58ef618cfbe34c7. We cannot use unsynchronized updates when the application haven't called map at all.
Mostly out of curiosity, how is this triggered in practice? Also, would it make sense to track synchronised/unsynchronised in buffer_invalidate_bo_range() instead?
It probably cannot be triggered in the current git. Before commit 6ced2a82930f11a80695ff0a3290e6125af52cd6 it could possibly be triggered by wined3d_buffer_copy() followed by wined3d_buffer_load(). It was possible because wined3d_buffer_copy() was invalidating the BUFFER location (the SYSMEM location was preferred four double-buffered buffers). This isn't strictly the issue introduced by commit bc019fcbbd7f0014280a292bc58ef618cfbe34c7.
I'm not sure if tracking synchronised/unsynchronised in buffer_invalidate_bo_range() makes sense. I'll look into this, and I'll send a patch if I've come up with something reasonable.
On 8 November 2016 at 14:19, Józef Kucia joseph.kucia@gmail.com wrote:
I'm not sure if tracking synchronised/unsynchronised in buffer_invalidate_bo_range() makes sense. I'll look into this, and I'll send a patch if I've come up with something reasonable.
Yeah, I'm not sure it will end up being better or not either. The idea though is that keeping track on the kind of invalidation we're doing may be more natural to work with than the concept of WINED3D_BUFFER_MAP.
-
Henri Verbeet -
Józef Kucia