Where is my address space?

[Snorri Sturluson]

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 at gmail.com> wrote:
> 
> On 2 September 2016 at 16:52, Snorri Sturluson
> <snorri.sturluson at 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.