Module: wine
Branch: master
Commit: 0ee74e9f815fbab8ef61eac724ba311b9f775b60
URL: https://gitlab.winehq.org/wine/wine/-/commit/0ee74e9f815fbab8ef61eac724ba31…
Author: Zebediah Figura <zfigura(a)codeweavers.com>
Date: Tue Jul 26 18:28:42 2022 -0500
d3d9: Cache the output mode list.
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.
---
dlls/d3d8/directx.c | 4 ++--
dlls/d3d9/directx.c | 11 +++++------
dlls/ddraw/ddraw.c | 2 +-
dlls/dxgi/output.c | 4 ++--
dlls/wined3d/directx.c | 21 +++++++++++++--------
dlls/wined3d/wined3d.spec | 4 ++--
dlls/wined3d/wined3d_private.h | 1 +
include/wine/wined3d.h | 4 ++--
8 files changed, 28 insertions(+), 23 deletions(-)
Module: wine
Branch: master
Commit: 8bddb9808eb5b79bc03a06c20a9b23fc34537d5e
URL: https://gitlab.winehq.org/wine/wine/-/commit/8bddb9808eb5b79bc03a06c20a9b23…
Author: Stefan Dösinger <stefan(a)codeweavers.com>
Date: Mon Jul 25 10:09:29 2022 +0300
ddraw: Don't account video memory for sysmem surfaces' draw textures.
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.
---
dlls/ddraw/surface.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c
index 421ce68fa1c..afba0d5ac4b 100644
--- a/dlls/ddraw/surface.c
+++ b/dlls/ddraw/surface.c
@@ -5998,6 +5998,7 @@ static HRESULT ddraw_surface_create_wined3d_texture(DDSURFACEDESC2 *desc, struct
draw_texture_desc = *wined3d_desc;
draw_texture_desc.bind_flags = bind_flags;
draw_texture_desc.access = WINED3D_RESOURCE_ACCESS_GPU;
+ draw_texture_desc.usage = WINED3DUSAGE_PRIVATE;
if (FAILED(hr = wined3d_texture_create(wined3d_device, &draw_texture_desc, layers,
levels, 0, NULL, texture, &ddraw_texture_wined3d_parent_ops, &draw_texture)))