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>
I.e., those used with wined3d_cs_init_object() and
wined3d_cs_destroy_object().
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
A typical case would be between using a texture as render target and using it
as a shader resource.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In particular, some implementations may not support the combination of
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT and VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
for all buffer types, or at all.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Unsurprisingly, reading for uncached memory may be very slow.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We don't typically need these to be in VRAM, and VRAM may not be mappable.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Now that we handle DISCARD maps ourselves, this happens implicitly.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Analogous to the Vulkan adapter. This is slightly awkward in OpenGL
because it doesn't have explicit command buffers like Vulkan, but
calling wined3d_context_gl_submit_command_fence() on swapchain present
works well enough in practice. The main advantage of this approach is that it
avoids using a separate fence for each usage of each bo.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Matteo Bruni <mbruni@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Analogous to the wined3d_bo_vk structure for Vulkan.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Note that the constants like WINED3D_ALLOCATOR_CHUNK_SIZE and
WINED3D_ALLOCATOR_MIN_BLOCK_SIZE are somewhat arbitrary, rather than the
result of careful tuning. That's mostly because we have a couple of
known stalls in e.g. the command stream that would largely invalidate
such tuning.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We may get coherent memory anyway, but we don't require it.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>