Where is my address space?

[Snorri Sturluson]

Thanks for these hints - been looking at this a bit more and would appreciate more input.

I’ve added tracking in wined3d/resource.c to give me the total memory in use allocated via wined3d_resource_allocate_sysmem.

In a very simple scene (hangar view in EVE) vmmap32 reports a total of 2.3G in use, with IOKit clocking in at 442M and VM_ALLOCATE at 1.4G. The system memory allocated in resource.c is 180M.

Going into character customisation with a highly detailed character the total is 2.5G, IOKit at 498.8M and VM_ALLOCATE at 1.6G, with sysmem allocs at 360M.

Presumably the sysmem allocs are a subset of VM_ALLOCATE.

Is it normal that the sysmem sits this high? Shouldn’t the textures be managed by OpenGL?

> On 22 Aug 2016, at 10:03, Matteo Bruni <matteo.mystral at gmail.com> wrote:
> 
> 2016-08-19 12:09 GMT+02:00 Henri Verbeet <hverbeet at gmail.com>:
>> On 19 August 2016 at 11:56, Snorri Sturluson
>> <snorri.sturluson at ccpgames.com> wrote:
>>> I’m trying to understand the memory usage of Wine. My focus is to make EVE Online run on the Mac as smoothly as possible, and one of the issues I’m running into is that the game runs out of memory in heavy scenes, especially when running at high resolutions on Macs with Retina screens.
>>> 
>>> On Windows, a scene with 300 ships in space may be running in 2.1GB of page file usage, but the same scene under Wine will show a Virtual Memory size of 3.5GB or more. Once the Virtual Memory size (as shown by the Activity Monitor) gets too close to the 4GB mark I start getting errors from Wine, failing to allocate memory, usually leading to a crash.
>>> 
>>> There is a significant difference even when running at the same resolution on both Windows and Mac, and further pronounced if I run in the full 5k resolution of an iMac.
>>> 
>>> Can anyone explain this big difference in memory use between the Windows and Wine sessions? Or give me ideas on how I can figure it out? Or better yet, have suggestions on how to reduce it?
>>> 
>> 
>> I think Matteo most recently looked at this on OS X. IIRC the bottom
>> line was that the biggest offender was the OS X OpenGL stack, but
>> there may be some hacks that can free up some additional address space
>> for specific applications. Careful profiling may find places where
>> Wine itself can be improved. In the longer term though, even on Window
>> a 32-bit address space is a bit tight for modern games, and you'd want
>> to look into switching to a 64-bit application.
> 
> That's pretty much it. I looked at this in particular for another game
> but it's likely that the conclusions are general enough and the fact
> that the screen resolution makes things worse for you strongly hints
> towards the OpenGL drivers as the main culprit.
> I couldn't find any obvious way to make macOS behave better in that
> regard (for the game I was looking into, at least). The various other
> macOS frameworks which end up being pulled into the process also took
> a significant amount of addressing space, but way distant from the
> OpenGL stuff. I also found some small room for improvements in wined3d
> (specifically, IIRC, we might end up allocating system memory for d3d9
> "NULL" render targets) but it wasn't earth-shattering by any means. I
> plan to fix that at some point though.
> 
> I've found pmap to be pretty useful for profiling memory usage on
> macOS. AFAIR, in my case the VM space used by the OpenGL stack was
> mostly accounted under the "IOKit" name.
> 
> Also FWIW, under Linux VM usage looked a lot better, with the specific
> OpenGL driver in use not having a significant effect.