For the purposes of wined3d_cs_map_upload_bo().
That is, if a buffer was just created or just discarded [e.g. with
wined3d_device_evict_managed_resources()], and then subsequently mapped with
WINED3D_MAP_NOOVERWRITE, treat it as if it had been mapped with
WINED3D_MAP_DISCARD instead, thus allowing the adapter_alloc_upload_bo callback
to allocate a new buffer from the client thread.
This was the source of a bunch of stalls in Grand Theft Auto V, although it's
hard to measure a difference in performance.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
That is, don't just flush it, but unmap it as well.
As of d8e8ab21c0, we can get here even when
!wined3d_map_persistent(). Thus we currently end up leaving BOs mapped when
performing an accelerated DISCARD map. Try to avoid that.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Be consistent with wined3d_cs_map_upload_bo(). This may change in the future,
but for now we depend on this logic in the Vulkan backend.
This fixes test_dynamic_map_synchronization() on 32-bit architectures with the
Vulkan backend, which is currently broken because we try to perform accelerated
NOOVERWRITE maps while unmapping the same BOs.
Fixes: d8e8ab21c0
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The practical effect of this is to defer clearing buffers until they are used.
Under normal circumstances the buffer will be initially discarded, in which
case we need not clear it at all, and may even avoid ever allocating sysmem.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of checking whether a BO already exists.
This will end up allocating a BO earlier in some cases. This is not particularly
impactful by itself, since we already would have sysmem available and thus could
use it without a performance penalty. However, we would like to avoid ever
allocating sysmem where not necessary, in particular by deferring allocation of
any location at all until the resource is written to.
This also has the side effect of fixing test_map_synchronization() on 64-bit
architectures, broken since 194b47b4fd. The test
creates a buffer, maps it once, then maps it again with NOOVERWRITE while the
GPU is still drawing, expecting the new data to be read by the GPU during the
draw. On 32-bit machines, and 64-bit machines before the offending commit, we do
the following:
First map: uses SYSMEM since the BO is not created yet
Draw: upload to VBO
Second map: map the existing VBO with GL_MAP_UNSYNCHRONIZED_BIT
After 194b47b4fd, we don't use GL_MAP_UNSYNCHRONIZED_BIT since the buffer has
READ access, which means that the second map will be synchronized and wait for
the draw to complete.
After this patch, we do the following:
First map: create and map a VBO (not unsynchronized, but coherent and
persistently mapped)
Draw: use mapped VBO
Second map: write to existing (coherent) VBO, which is unsynchronized
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
wined3d_buffer_load_location() can handle loading from
WINED3D_LOCATION_DISCARDED just fine, so use it instead of duplicating the
functionality here.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
That is, no longer allocate a wined3d_bo_gl as part of the wined3d_buffer_gl
structure.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
That is, no longer allocate a wined3d_bo_vk as part of the wined3d_buffer_vk
structure.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
So as to allow the "buffer_object" field to point to other another
wined3d_bo_vk; namely, one allocated and still in use by the client thread.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It might still be bound in GL.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Using a registry setting. Games sometimes use DEFAULT usage and no CPU
access combined with UpdateSubresource() for often-changing constants,
causing us to interrupt the render pass and transfer through a staging
buffer on each update. In such cases forcing the buffers to be mappable
greatly increases performance.
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Guard against the most recent write operation instead. Accumulate read
bindings to a) not issue unnecessary barriers when a resource has
multiple read-only usages, and b) synchronize with all previous read
bindings when writing.
This is motivated by an issue where a program using a single buffer to
store both indices and vertex attributes causes superfluous barriers on
each draw call.
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some implementations do not support this combination.
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Allow things like wined3d_format_copy_data() to work on them.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This can't currently happen. However, we'd like to use
wined3d_buffer_get_memory() in wined3d_cs_exec_update_sub_resource(). This would
probably also help in implementing ID3D11DeviceContext1::DiscardResource().
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Alexandre Julliard