http://bugs.winehq.org/show_bug.cgi?id=60244 Béla Gyebrószki <gyebro69@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|11.16 |10.19 Regression SHA1| |4c421edbff686993f7142374767 | |f615bda1a108e CC| |jacek@codeweavers.com Keywords| |regression, wow64 --- Comment #1 from Béla Gyebrószki <gyebro69@gmail.com> --- 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.