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.