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>
Parallel to a5efc1d5e0. Unlike with the Vulkan
backend, we cannot map chunks from the client thread, but we can access the
mapped pointer and increase the map count of already mapped chunks.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For download, vkCmdCopyImageToBuffer() is used, not
vkCmdCopyBufferToImage().
Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Currently this has no effect. Depending on whether wined3d_map_persistent()
returns true, either the client thread doesn't access the map pointer outside of
d3d map requests, or the BO is never unmapped. However, we'd like to be able to
let NOOVERWRITE maps be accelerated while still being able to unmap arbitrary
BOs at arbitrary times from the CS 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>
Some games wait for query results on the frame executing the query,
expecting that enough time have passed for it to be available. By
requiring that the entire command buffer is done, we risk stalling the
whole frame if it wasn't flushed along the way. This patch drops this
requirement.
Mainly, we need to ensure that we don't call vkGetQueryPoolResults()
before the reset command is executed, and accidentally retrieve result
from previous usage. Using host query reset doesn't quite solve the
problem, as it might get called too early, if the application decides to
reuse a query without waiting for results. Besides, we want to support
devices where host query reset is not available.
To make it work, when a Vulkan query is no longer needed, we queue it
for resetting at command buffer submission time, and only mark it free
for reuse after this command buffer is finished executing.
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We check if it's empty to put it back in.
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Regardless of whether we are mapping persistently. Matches the Vulkan backend.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Significantly reduces global heap lock contention in some games.
Signed-off-by: Jan Sikorski <jsikorski@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>
We will still block on a subsequent NOOVERWRITE map, so in practice this
probably doesn't remove any bottlenecks. However, it leads to clearer code, and
it matches what will need to be done for textures.
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>
Zebediah Figura