Particularly for applications that use dynamic buffers without
WINED3D_MAP_DISCARD/WINED3D_MAP_NOOVERWRITE.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Mostly to avoid making things worse for applications that map dynamic buffers
without WINED3D_MAP_DISCARD/WINED3D_MAP_NOOVERWRITE.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For f32tof16 and f16tof32 instructions.
Signed-off-by: Józef Kucia <jkucia@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of trying to replicate the wined3d_buffer_map() logic in
wined3d_buffer_unmap().
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It might seem like a good idea to try to use glMapBufferRange() in
buffer_direct_upload(), but it really isn't. The interesting cases for
glMapBufferRange() are GL_MAP_INVALIDATE_BUFFER_BIT or
GL_MAP_UNSYNCHRONIZED_BIT, but the only way for those to be set here
would be for the buffer to be mapped with WINED3D_MAP_DISCARD or
WINED3D_MAP_NOOVERWRITE before the buffer object was created. In that
case the GPU is obviously not using the buffer object, so
glMapBufferRange() doesn't help. On the other hand, if the buffer is
currently in use by the application and neither WINED3D_MAP_DISCARD nor
WINED3D_MAP_NOOVERWRITE is set, glMapBufferRange() would need to wait
for the GPU to finish using the buffer object, while glBufferSubData()
may decide not to.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The ordering doesn't matter, so this avoids creating some redundant shader
variants.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This should be unused now that surface_load_ds_location() is gone.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This should be unused now that "AlwaysOffscreen" is gone.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a regression introduced by commit
f6dde70624.
Signed-off-by: Józef Kucia <jkucia@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Commit b62f4139ed introduced implicit padding in
the wined3d_ffp_vs_settings structure. This causes redundant shader variants
to be generated. Although easy to avoid, there's also something to be said for
being more robust against padding.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Matteo Bruni <mbruni@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise the application may keep spinning on wined3d_query_get_data() in
case the query wasn't submitted to the GPU yet when wined3d_query_get_data()
was called. This issue was exposed by commit
70889d6866. Note that this won't fix the issue
if the query was created in a different GL context.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a regression introduced by commit
4a9304305a.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Version 1 and version 2 surfaces don't keep references to the ddraw interface
that created them, so such surfaces may get destroyed after the corresponding
ddraw object was destroyed. Wined3d requires that the device is destroyed
after all its resources are destroyed. In principle this issue always existed,
but it was probably made worse by changes in the texture cleanup code.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>