Instead of using wined3d_texture_update_desc(). This is safe, because:
* ddraw never exposes wined3d textures directly, and always retrieves them
directly from wined3d when rendering.
* d3d8 and d3d9 (non-extended) will only resize buffers during a reset, and
resetting is forbidden if the application holds any references to the
backbuffers. RTVs are also replaced during a reset, so there is no concern
about retrieving the old RTVs from the device state.
* d3d9ex allows resetting while holding references to the backbuffers, but tests
(fixed by this patch) show that the backbuffers should in fact be recreated.
* dxgi forbids holding references to back buffers during ResizeBuffers(),
including indirect references via command lists or device contexts.
In d3d8, setting texture filters to invalid values does not yield an
error when calling IDirect3DDevice8::ValidateDevice. Some applications,
such as Worms Blast, rely on this behaviour.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54898
I was unable to write tests for this; it seems it doesn't consistently work on
Windows. However, Rayman 3 seems to rely on it; it maps the same buffer twice
immediately after creation, with DISCARD flags on both maps, and expects the
same address to be returned.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53752
This was probably added on the assumption that
IDirect3DDevice8::CopyRects() behaves like the similar
IDirect3DDevice9::UpdateSurface(), but it does not.
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.
Bloodrayne: Terminal Cut (and Bloodrayne 2: Terminal Cut, and probably other
games in the series) streams from a SYSTEMMEM index buffer, updating it and
drawing from it every frame. This is currently slow on Wine, since each map
needs to wait for the previous upload (on the CS) to complete.
There are a few ways to avoid waiting, but this patch takes the approach of
effectively uploading from the SYSTEMMEM buffer on the client side, while using
a dynamic buffer to avoid client/CS synchronization. This brings performance
from 20-30 FPS to a (locked) 60, on NVidia GL drivers.
