Last Comment Bug 850545 - ~500 MiB of heap-unclassified in big asm.js demo, mostly due to WebGL and drivers
: ~500 MiB of heap-unclassified in big asm.js demo, mostly due to WebGL and dri...
Status: RESOLVED INCOMPLETE
[MemShrink:P2]
:
Product: Core
Classification: Components
Component: Canvas: WebGL (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks: DarkMatter
  Show dependency treegraph
 
Reported: 2013-03-12 22:49 PDT by Nicholas Nethercote [:njn]
Modified: 2014-08-25 18:58 PDT (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
DMD output (56.20 KB, text/plain)
2013-03-12 22:49 PDT, Nicholas Nethercote [:njn]
no flags Details

Description Nicholas Nethercote [:njn] 2013-03-12 22:49:17 PDT
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.
Comment 1 Andrew McCreight [:mccr8] 2013-03-12 23:05:54 PDT
Bug 814964 looks like a similar-ish issue, with an OOM crash inside _mesa_glsl_link_shader, there with the WebGL test suite.
Comment 2 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2013-03-19 16:31:18 PDT
mozilla::WebGLContext::LinkProgram(mozilla::WebGLProgram*) is the interesting stack frame.
Comment 3 Nicholas Nethercote [:njn] 2013-03-19 16:32:15 PDT
bjacob, does this seem like a reasonable amount of memory for GL contexts?  None of the MemShrinkers have any idea.
Comment 4 Vladimir Vukicevic [:vlad] [:vladv] 2013-03-19 16:55:20 PDT
Not for shaders; but unfortunately this data isn't all that useful coming from Linux, especially with the Intel/Mesa drivers. :(
Comment 5 Benoit Jacob [:bjacob] (mostly away) 2013-03-19 17:02:00 PDT
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.
Comment 6 Nathan Froyd [:froydnj] 2013-03-20 02:27:23 PDT
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?
Comment 7 (dormant account) 2013-03-20 06:53:00 PDT
(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.
Comment 8 Joe Olivas 2013-03-20 09:47:52 PDT
As Taras' Intel people, I will find someone in our Linux gfx drivers team who can help.
Comment 9 Joe Olivas 2013-03-20 15:27:46 PDT
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/
Comment 10 Joe Olivas 2013-03-21 09:26:24 PDT
(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.

apitrace@lists.freedesktop.org
Comment 11 (dormant account) 2013-04-08 10:10:17 PDT
(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?
Comment 12 Vladimir Vukicevic [:vlad] [:vladv] 2013-04-08 14:55:36 PDT
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.
Comment 13 Nicholas Nethercote [:njn] 2013-04-09 13:18:04 PDT
> 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.)
Comment 14 Guilherme Lima 2013-12-17 15:31:44 PST
Small ping. Did the demo become public?
Comment 15 Nicholas Nethercote [:njn] 2013-12-17 15:36:13 PST
> Small ping. Did the demo become public?

http://www.unrealengine.com/html5/
Comment 16 Nicholas Nethercote [:njn] 2014-08-24 21:56:57 PDT
(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.
Comment 17 Alon Zakai (:azakai) 2014-08-25 12:40:29 PDT
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.
Comment 18 Nicholas Nethercote [:njn] 2014-08-25 18:58:49 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.