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

RESOLVED INCOMPLETE

Status

()

Core
Canvas: WebGL
RESOLVED INCOMPLETE
4 years ago
3 years ago

People

(Reporter: njn, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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.
(Reporter)

Comment 3

4 years ago
bjacob, does this seem like a reasonable amount of memory for GL contexts?  None of the MemShrinkers have any idea.
(Reporter)

Updated

4 years ago
Whiteboard: [MemShrink] → [MemShrink:P2]
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?
Flags: needinfo?(taras.mozilla)

Comment 7

4 years ago
(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.
Flags: needinfo?(taras.mozilla) → needinfo?(joseph.k.olivas)

Comment 8

4 years ago
As Taras' Intel people, I will find someone in our Linux gfx drivers team who can help.
Flags: needinfo?(joseph.k.olivas)

Comment 9

4 years ago
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

4 years ago
(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

4 years ago
(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?
Flags: needinfo?(n.nethercote)
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.
(Reporter)

Comment 13

4 years ago
> 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.)
Flags: needinfo?(n.nethercote)

Comment 14

4 years ago
Small ping. Did the demo become public?
(Reporter)

Comment 15

4 years ago
> Small ping. Did the demo become public?

http://www.unrealengine.com/html5/
(Reporter)

Comment 16

3 years ago
(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.
(Reporter)

Comment 18

3 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.