Created attachment 724289 [details] DMD output Running Vlad's big asm.js on Linux64, I get ~560 MiB of heap-unclassified. DMD tells me that ~500 MiB of that is due to WebGL and driver related stuff. I've attached the top 20 records from the DMD output. Note that 492 MiB of the unreported allocations have stack traces that contain this frame: mozilla::dom::WebGLRenderingContextBinding::genericMethod(JSContext*, unsigned int, JS::Value*) (/home/njn/moz/mi3slim/dmdo64/dom/bindings/WebGLRenderingContext Binding.cpp:10275) 0x7feeb1eec241 We could add reporters for a few of the smaller records, but most allocations are happening within the /usr/lib/x86_64-linux-gnu/dri/i965_dri.so driver, unfortunately.
Bug 814964 looks like a similar-ish issue, with an OOM crash inside _mesa_glsl_link_shader, there with the WebGL test suite.
mozilla::WebGLContext::LinkProgram(mozilla::WebGLProgram*) is the interesting stack frame.
bjacob, does this seem like a reasonable amount of memory for GL contexts? None of the MemShrinkers have any idea.
Not for shaders; but unfortunately this data isn't all that useful coming from Linux, especially with the Intel/Mesa drivers. :(
Indeed, as the big allocations here all are done by the Intel Mesa driver, we can call this a driver bug. Unless these shaders would be so big or complex that they would inherently require that much memory, but I don't suppose that that's the case. You could tell by looking at about:memory -> explicit allocations -> webgl -> shader, or by comparing to a run of the same application on another driver or OS.
Taras, do you know of people at Intel that we can talk to about closer integration between drivers and memory reporting and/or making the driver suck less?
(In reply to Nathan Froyd (:froydnj) from comment #6) > Taras, do you know of people at Intel that we can talk to about closer > integration between drivers and memory reporting and/or making the driver > suck less? Joe is my Intel people.
As Taras' Intel people, I will find someone in our Linux gfx drivers team who can help.
The recommended first path is to collect a trace using apitrace and submitting that as a bug. http://apitrace.github.com/ https://bugs.freedesktop.org/
(In reply to Joe Olivas from comment #9) > The recommended first path is to collect a trace using apitrace and > submitting that as a bug. > > http://apitrace.github.com/ > https://bugs.freedesktop.org/ Also, questions for apitrace are best sent to the mailing list for the fastest response. firstname.lastname@example.org
(In reply to Joe Olivas from comment #9) > The recommended first path is to collect a trace using apitrace and > submitting that as a bug. > > http://apitrace.github.com/ > https://bugs.freedesktop.org/ Nick, can you follow up on that?
Note that we cannot submit public apitrace info for this particular testcase. A public version of the demo should be coming in a few weeks. Once that's available it should be easier for the issue to be reproduced.
> A public version of the demo should be coming in a few weeks. > Once that's available it should be easier for the issue to be reproduced. I'll come back to this when that happens. (Though I'll be on vacation for all of May.)
Small ping. Did the demo become public?
> Small ping. Did the demo become public? http://www.unrealengine.com/html5/
(In reply to Nicholas Nethercote [:njn] from comment #15) > > Small ping. Did the demo become public? > > http://www.unrealengine.com/html5/ I was going to see if this bug was still valid, but the Unreal demo has disappeared :( That URL now contains a Flappy Bird clone.
They've decided to take it down, I'm afraid. Hopefully Flappy Bird is good enough to compare on; anyhow, new codebases using Unreal Engine will be closer to Flappy, so good to test on it.
With Tappy Chicken I get this: ├───81.72 MB (13.82%) ── heap-unclassified Probably not a fair comparison, but it's going to be hard to do anything more now.