[Bug 60244] New: Deadfall Adventures crashes in new WoW64 on NVIDIA when opengl32 exhausts the BAR1 heap

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60244

            Bug ID: 60244
           Summary: Deadfall Adventures crashes in new WoW64 on NVIDIA
                    when opengl32 exhausts the BAR1 heap
           Product: Wine
           Version: 11.16
          Hardware: x86-64
               URL: https://store.steampowered.com/app/231330/Deadfall_Adv
                    entures/
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: opengl
          Assignee: [e-mail]
          Reporter: [e-mail]
  Target Milestone: ---
      Distribution: ArchLinux

Created attachment 81951
  --> http://bugs.winehq.org/attachment.cgi?id=81951
terminal output

'Deadfall Adventures' is a 32-bit D3D9 game.

With current new-WoW64 Wine + wined3d + proprietary NVIDIA, the game crashes
while loading the first level. The crash happens with graphical details set to
"Very Low" as well as with "Very High". The crash occurs with EGL and with GLX
backends too.

Reproduced with Wine-11.1, 11.7, 11.16, wine git 11.16-76-g3489c653109
NVIDIA drivers tested: 580.178.04, 595.91.07, 610.57.04.

The crash does not occur with:
-old-style WoW64 / multilib Wine
-nouveau
-DXVK d3d9.dll

Immediately before the crash:
err:opengl:create_buffer_storage vkAllocateMemory failed: -2
fixme:opengl:wow64_map_buffer GL_MAP_PERSISTENT_BIT not supported!

So then I asked AI what the issue might be...and it came up with a
workaround/diagnostic patch.

My NVIDIA GPU has a 256 MiB BAR1 aperture.
Vulkan exposes:
memory type 5:
  heapIndex = 2
  DEVICE_LOCAL | HOST_VISIBLE | HOST_COHERENT
heap 2:
  size = ~246 MiB

During reproduction:
main menu:      BAR1 Used = 65 MiB
second intro video:   BAR1 Used = 214 MiB
at crash:       BAR1 Used = 246 MiB

At that exact point vkAllocateMemory() returns
VK_ERROR_OUT_OF_DEVICE_MEMORY.

As a diagnostic test I changed the default Vulkan memory type selection in
create_buffer_storage() in dlls/opengl32/unix_wgl.c:

- uint32_t desired_type = type_mask;
+ uint32_t desired_type =
+     type_mask & ~VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT;

This makes Wine use the HOST_VISIBLE | HOST_COHERENT
non-device-local memory type instead.

With this one-line change:
BAR1 stays at ~19 MiB
the first level loads successfully
the game runs normally
Very Low and Very High graphics settings both work

Tested with
wine-11.16-76-g3489c653109
NVIDIA GeForce GTX 1660 SUPER
NVIDIA 610.57.04
OpenGL 4.60

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 60244] Deadfall Adventures crashes in new WoW64 on NVIDIA when opengl32 exhausts the BAR1 heap

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60244

Béla Gyebrószki <[e-mail]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|11.16                       |10.19
    Regression SHA1|                            |4c421edbff686993f7142374767
                   |                            |f615bda1a108e
                 CC|                            |[e-mail]
           Keywords|                            |regression, wow64

--- Comment #1 from Béla Gyebrószki <[e-mail]> ---
Further testing shows that this is actually a regression between Wine 10.18 and
10.19.

I identified the following commit as the first bad commit:
commit 4c421edbff686993f7142374767f615bda1a108e
opengl32: Take GL_CLIENT_STORAGE_BIT into account when picking vk memory type
in create_buffer_storage

The game does not crash with the parent commit. The commit does not revert
cleanly on the newer Wine source I tested.

Before this change, create_buffer_storage() selected the first memory type with
HOST_VISIBLE | HOST_COHERENT, regardless of the DEVICE_LOCAL bit. With this
commit, it preferentially selects HOST_VISIBLE | HOST_COHERENT | DEVICE_LOCAL
when GL_CLIENT_STORAGE_BIT is absent.

On my NVIDIA GTX 1660 SUPER, that memory type belongs to the small BAR1-backed
heap described in the original report. This is consistent with the observed
BAR1 usage increasing to approximately 246 MiB during loading.
The fallback introduced by the commit only relaxes the memory-type selection
criteria if no matching type exists. It does not retry with a non-device-local
memory type if allocation from the selected heap fails.

This also explains why the diagnostic change described in the original report
avoids the crash:
- uint32_t desired_type = type_mask;
+ uint32_t desired_type = type_mask & ~VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT;

With that change, BAR1 usage stays at approximately 19 MiB and the first level
loads successfully.

Wine-11.18

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.