Discussing address space for 32bit apps

[Axel Davy]

On 13/11/2018 16:33, Stefan Dösinger wrote:
>
>
>> Am 12.11.2018 um 23:57 schrieb Axel Davy <davyaxel0 at gmail.com 
>> <mailto:davyaxel0 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20181113/0f2c9e01/attachment.html>