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?
Best regards, Snorri Sturluson CCP Games
On 19 August 2016 at 11:56, Snorri Sturluson snorri.sturluson@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.
2016-08-19 12:09 GMT+02:00 Henri Verbeet hverbeet@gmail.com:
On 19 August 2016 at 11:56, Snorri Sturluson snorri.sturluson@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.
On Aug 22, 2016, at 5:03 AM, Matteo Bruni matteo.mystral@gmail.com wrote:
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.
Were you thinking of vmmap? (Or vmmap32 for 32-bit processes on modern versions of the OS.)
-Ken
2016-08-22 17:39 GMT+02:00 Ken Thomases ken@codeweavers.com:
On Aug 22, 2016, at 5:03 AM, Matteo Bruni matteo.mystral@gmail.com wrote:
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.
Were you thinking of vmmap? (Or vmmap32 for 32-bit processes on modern versions of the OS.)
Yes, of course... BTW, that was your suggestion at the time so thanks and credits to you :)
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@gmail.com wrote:
2016-08-19 12:09 GMT+02:00 Henri Verbeet hverbeet@gmail.com:
On 19 August 2016 at 11:56, Snorri Sturluson snorri.sturluson@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.
On 2 September 2016 at 16:52, Snorri Sturluson snorri.sturluson@ccpgames.com wrote:
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?
It depends on the specific application, but I don't think it's necessarily unusually large. It would perhaps be useful to split those numbers out by resource type (buffers/textures) and pool (sysmem/managed/default).
There's of course not a lot we can do for sysmem resources, but for managed and default pool resources we could perhaps be more aggressive about evicting things from system memory. The way it currently works, those resources initially get system memory allocated, which gets freed once the resource gets moved to the GPU. It would perhaps be possible to move resources to the GPU right after creation, and in some cases avoid allocating system memory for them entirely. That won't necessarily make things better though, depending on what the OpenGL driver does internally it may just move allocations from wined3d to the OpenGL driver.
Hm, I’m now tracking only resources of type WINED3D_RTYPE_TEXTURE_2D - the numbers are slightly lower, but as expected, the bulk is coming from textures.
I’m fairly certain I don’t have any textures loaded that are not actively used for rendering so it’s not clear to me why they would reside in system memory.
I just want to rule out that the textures aren’t allocated still in system memory as well as by OpenGL.
On 02 Sep 2016, at 15:28, Henri Verbeet hverbeet@gmail.com wrote:
On 2 September 2016 at 16:52, Snorri Sturluson snorri.sturluson@ccpgames.com wrote:
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?
It depends on the specific application, but I don't think it's necessarily unusually large. It would perhaps be useful to split those numbers out by resource type (buffers/textures) and pool (sysmem/managed/default).
There's of course not a lot we can do for sysmem resources, but for managed and default pool resources we could perhaps be more aggressive about evicting things from system memory. The way it currently works, those resources initially get system memory allocated, which gets freed once the resource gets moved to the GPU. It would perhaps be possible to move resources to the GPU right after creation, and in some cases avoid allocating system memory for them entirely. That won't necessarily make things better though, depending on what the OpenGL driver does internally it may just move allocations from wined3d to the OpenGL driver.
On 2 September 2016 at 17:56, Snorri Sturluson snorri.sturluson@ccpgames.com wrote:
Hm, I’m now tracking only resources of type WINED3D_RTYPE_TEXTURE_2D - the numbers are slightly lower, but as expected, the bulk is coming from textures.
I’m fairly certain I don’t have any textures loaded that are not actively used for rendering so it’s not clear to me why they would reside in system memory.
I just want to rule out that the textures aren’t allocated still in system memory as well as by OpenGL.
Check the texture flags, textures with WINED3D_TEXTURE_RGB_VALID or WINED3D_TEXTURE_SRGB_VALID set generally shouldn't have system memory allocated. The "download_count", "sysmem_count" and "texture_rgb.name" fields are also potentially interesting.
The attached patch may help clarify. It tags Wine's VM allocations in such a way that vmmap32 can report. It will change some of the VM_ALLOCATE entries to something more usage-specific. See the commit log for how to relate vmmap32's output to Wine's use.
-Ken
On Sep 2, 2016, at 9:52 AM, Snorri Sturluson snorri.sturluson@ccpgames.com wrote:
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@gmail.com wrote:
2016-08-19 12:09 GMT+02:00 Henri Verbeet hverbeet@gmail.com:
On 19 August 2016 at 11:56, Snorri Sturluson snorri.sturluson@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.
-
Henri Verbeet -
Ken Thomases -
Matteo Bruni -
Snorri Sturluson