893865 - Memory reporter for OpenGL data (e.g. gl::GLLibraryEGL::fCreateContext)

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Andrew McCreight [:mccr8]]

Attachment: DMD log excerpt

This is the fifth largest source of heap-unclassified (memory not reported to the memory reporters) in a 30-ish hour automated run on B2G, so it would be nice to get it added to the reporter.

There's only a single block of memory for the largest one of these, so I assume it isn't a leak, but is just some kind of memory rendering or whatever needs.

Comment 1

[Andrew McCreight [:mccr8]]

The full log is in bug 893172.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Hmm, adding it to the reporter will be hard -- this is internal memory created by the platform's GL driver for data for each GL context.  It's a good chunk, but the amount of data allocated will vary significantly between devices and even possibly driver versions on the same device.

Not sure what we can do, short of looking at memory allocated before we call eglCreateContext and comparing to after, and attributing that delta to GL contexts?  Can we do something like that easily?  It won't be 100% accurate, but will get us in the ballpark.

Comment 3

[Justin Lebar (not reading bugmail)]

We've been discussing something like setting a TLS variable before we call into external code (e.g. the GL driver).  Then we wrap malloc/free/etc, so it checks that TLS variable, and increments/decrements a counter.

I think that's basically the only way we're going to get reporters for code we don't control.

Comment 4

[Nicholas Nethercote [inactive]]

Bug 813843 was already open for this.  I'll dup that bug to this one because this bug has a DMD log.

Bug 813783 comment 14 has details of an idea on how to track this, involving malloc wrapping and a TLS variable to track the amount of memory allocated by the GL driver.  jlebar and I just discussed it and there are a couple of tricky aspects.

- If we use replace-malloc, does that prevent us from using replace-malloc elsewhere?  If it does, this will be a problem for DMD, because DMD already uses replace-malloc.

- We'd have to wrap all the places that call into the GL drivers and cause allocations/frees.  If we missed any of them we could end up with incorrect counts.  I.e., we have the usual problems with counter-based memory reporters.

Comment 7

[Gregory Pappas [:gregp]]

Closing old B2G bugs