850545 - ~500 MiB of heap-unclassified in big asm.js demo, mostly due to WebGL and drivers

Status: RESOLVED INCOMPLETE

(Core :: Graphics: CanvasWebGL, defect)

Description

[Nicholas Nethercote [inactive]]

Attachment: 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]]

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 (Exited; not receiving bugmail, old account, do not use)]

mozilla::WebGLContext::LinkProgram(mozilla::WebGLProgram*) is the interesting stack frame.

Comment 3

[Nicholas Nethercote [inactive]]

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] (needinfo me, slow to respond)]

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)]

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]]

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)]

(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]

As Taras' Intel people, I will find someone in our Linux gfx drivers team who can help.

Comment 9

[Joe Olivas]

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]

(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.

[e-mail]

Comment 11

[(dormant account)]

(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] (needinfo me, slow to respond)]

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 [inactive]]

> 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]

Small ping. Did the demo become public?

Comment 15

[Nicholas Nethercote [inactive]]

> Small ping. Did the demo become public?

http://www.unrealengine.com/html5/

Comment 16

[Nicholas Nethercote [inactive]]

(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)]

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 [inactive]]

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.