We would like to use two different textures for the CPU and GPU parts of managed
textures, which means that wined3d_resource_access_is_managed() as such will no
longer be useful.
Garou: Mark of the Wolves calls IDirect3D9::GetAdapterModeCount() on every
frame. This results in calling EnumDisplaySettingsExW() once per available mode,
which is a very slow operation, both on Windows and Wine.
Manual testing shows that Windows caches the mode list (as well as the adapter
list, which is already cached in Wine) in Direct3D 9 and lower. Calls to
GetAdapterModeCount() and EnumAdapterDisplayModes() are fast, and they also do
not change if monitors are added or removed.
DXGI behaves differently, however. The list of outputs attached to an adapter is
cached—that is, calls to IDXGIAdapter::EnumOutputs() are fast, and return stale
data. However, at least some other calls are slow and do not seem to be cached,
including IDXGIOutput::GetDisplayModeList() and IDXGIOutput::GetDesc().
ddraw is also slow and uncached. Since all testing was done on Windows 10 (for
lack of available older hardware to test with) it is not unlikely that ddraw was
reimplemented over dxgi on newer Windows, and that older Windows versions would
be fast and cached, but this is speculation. In any case I have not included
patches to cache ddraw modes.
Tests were done on Windows 10 21H2, both on real hardware with NVidia drivers
and on software drivers via qemu/KVM. In the latter case only speed could be
tested, but this was consistent with the results from the NVidia machine.
Star Trek Starfleet Academy does not like it when available video memory
goes down after creating a system memory resource. It destroys all its
textures and recreates them, and in some sitations forgets to recreate
one or another texture, resulting in rendering bugs.
I suspect the game is trying to detect focus loss by monitoring for
unexpected video memory changes.
When blitting from a staging texture in SYSMEM to an as-yet uninitialized GPU
texture, we want to avoid ever loading the source texture into TEXTURE_RGB, or
loading the destination texture into SYSMEM.
This isn't really a proper fix for the relevant tests; it just manages to avoid
the problematic code path.
This manages to fix test_yv12_overlay because it causes those blits to use the
upload path (whereas currently they go through the raw blitter, and before
1632b8e7a4 they would go through the CPU blitter), and
wined3d_texture_gl_upload_data() is one of the only functions to correctly
handle planar YUV formats.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52684
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
d4fdb1f62c broke test_cursor_clipping by accident. It added a requirement
that width, height and refresh rate are different from the old mode, but
test_cursor_clipping does not use DDEDM_REFRESHRATES, so all refresh rates
are 0.
Signed-off-by: Stefan Dösinger <stefan@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Unless DDSCL_NOWINDOWCHANGES was specified.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Signed-off-by: Stefan Dösinger <stefan@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fixes a regression introduced by f90d607c67.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50370
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Signed-off-by: Stefan Dösinger <stefan@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Mostly to avoid triggering the WARN() from
wined3d_texture_get_sub_resource_desc() every time this function is
called.
Signed-off-by: Matteo Bruni <mbruni@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Rémi Bernon reports an unspecified issue with gcc 11 related to
compute_sphere_visibility() expecting 12 input planes, but
d3d_device3_ComputeSphereVisibility() only providing 6. The actual number of
planes required depends on the "enabled_planes" mask. This patch should make
the code better reflect that, but I do not have a gcc 11 setup to verify it
resolves the issue there.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes stray lines in GameFace GUIs, e.g. in World of Tanks.
Signed-off-by: Stefan Dösinger <stefan@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
