On 13/11/2018 16:33, Stefan Dösinger wrote:
Am 12.11.2018 um 23:57 schrieb Axel Davy <davyaxel0@gmail.com mailto:davyaxel0@gmail.com>:
I assume most games won't have any issues getting access to more than the 2GB when they are not large address aware, or accessing all 4GB (and not 3) when being large address aware. Do you think a Regedit workaround could be considered to 'lift' all 32 bits memory restrictions ? This should solve all the issues.
I found that games break in really weird ways if you ignore the 2GB limit. E.g. Starcraft (before the Starcraft remastered days) randomly gets stuck in endless loops. We'll replace "my game runs out of address space" with "my game randomly crashes" bugs.
Beyond that, the address space setup happens pretty early in the process startup before ntdll can reasonably read registry entries.
I once contemplated the idea of having Wine-internal alloc calls for allocations that will never be passed to the application, so that e.g. wined3d could allocate resources beyond the 2GB barrier. However, that doesn't go anywhere because resource mapping would then return those pointers. We'd have to make OpenGL (or nine, or vulkan) call those callbacks, and then be careful that glMapBuffer() doesn't return those buffers to the application. Somewhat impossible.
I assume on windows, OpenGL, d3d, etc all allocate in the 2GB. Thus I believe most of the difference is the space taken by the mapped library codes (llvm, libx11, etc), and eventually some libraries allocating more space than they should (pulseaudio).
If a register cannot be considered, do you have any suggestion (long term fix or short term workaround) to fix the issues our users are facing (the pulseaudio tip to reduce the space it takes is a good one, but we may need more).
If I understand correctly, windows maps some of its code onto the high 2GB, thus library code could be mapped there without bugs ?
Yours,
Axel Davy