https://bugs.winehq.org/show_bug.cgi?id=42732
--- Comment #12 from nospam@kota.moe --- I've attached the /proc/.../maps of the benchmark in various circumstances (and with ASLR turned off to make things a bit more comparable).
The most major change between the loading screen and the scene itself are lots of added "/dev/dri/renderDxxx" and "/drm mm object (deleted)" maps.
Using the following command line to count the number of bytes mapped in by these maps: grep -E '/(dri|drm)' | cut -d' ' -f1 | awk -F- '{print strtonum("0x" $2) - strtonum("0x" $1)}' | tr '\n' + | sed -E 's/+$/\n/' | bc
We get the following numbers (loading, running/crashed, difference): dGPU: 62, 77, 15 MiB iGPU (unpatched): 199, 350, 151 MiB iGPU (patched): 199, 529, 340 MiB
So indeed the dGPU seems to use less virtual memory than the iGPU, and the crash is caused by failing to allocate the final 340 - 151 = 189 MiB of memory.
What strikes me as odd is in the unpatched case, all the dri/drm maps are allocated in the lower 2 GiB of memory (in contrast to the patched case, where most of it is in high memory). Isn't the native linux graphics driver allocating this memory? Why would it be affected by the address space limitations that wine imposes on Windows binaries?