2028252 - WebGPU - Not enough memory left (DOMException)

Status: RESOLVED FIXED

(Core :: Graphics: WebGPU, defect, P1)

Description

[tmilic [:sonorousfreq]]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36

Steps to reproduce:

Go to https://webgpu.github.io/webgpu-samples/?sample=rotatingCube
The WebGPU loads and rotates the Rotating cube, for few hundred milliseconds, then loses the device and crashes

Mozilla/5.0 (X11; Linux x86_64; rv:151.0) Gecko/20100101 Firefox/151.0.

This happens on Linux Firefox Nightly, I am using AMD 9070XT 16GB GPU with 64 GB of RAM.

I can provide some other diagnostic and logs, but there is no obvious why this happens, after the crash firefox needs to be restarted to be able to use the GPU again.

See detailed comparison of adpaters for windows at this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=2001989

Actual results:

The app/webgpu crashes with:
Uncaught Error: uncaught exception, please report a bug!
https://github.com/webgpu/webgpu-samples/issues/new
OperationError: Not enough memory left.
fail util.ts:228
<anonymous> util.ts:8
util.ts:228:11
Uncaught DOMException: Not enough memory left.

Expected results:

The simple rotating cube should not crash.

Comment 1

[Andy Leiserson [:aleiserson]]

Do you know whether this is a regression? And if so, do you know whether it was introduced by the change for bug 2001989?

Comment 2

[tmilic [:sonorousfreq]]

Hi,

not sure really, perhaps I would need to build previous versions to find out.

But I think it wasn't because of a fix for that bug, since I've had similar outcome before updating to nightly which 'fixed' that other bug.

Comment 3

[Erich Gubler [:ErichDonGubler] (he/him)]

:sonorousfreq: No need to build Firefox, you can instrument downloads of it to bisect using the mozregression tool!

Comment 4

[Jim Blandy :jimb]

I'm pretty sure this is just a piece of our general presentation problems on Linux. I've seen it too. We'll have to fix this before we can ship on Linux.

Comment 5

[Jim Blandy :jimb]

Andy also suspects wgpu#9206.

Comment 6

[Jim Blandy :jimb]

Unassigning myself; I need to focus on bug 1870699 for the time being.

Comment 7

[tmilic [:sonorousfreq]]

(In reply to Erich Gubler [:ErichDonGubler] (he/him) from comment #3)

:sonorousfreq: No need to build Firefox, you can instrument downloads of it to bisect using the mozregression tool!

Oh, sorry, didn't know about that one, did some testing, but it doesn't work, at least in my current environment on any tested versions.
They are all bad, going back to v141 and similar.

https://postimg.cc/XrKSMWqn.

Not sure if something changed in my environment or this never worked for me, but you should try some AMD GPUs I guess, in combination with Linux and similar environments.

Let me know if I can provide some more testing.

Comment 8

[tmilic [:sonorousfreq]]

I have done some Windows testing as well (https://postimg.cc/HrztsnFF), for my app: https://chaos-matters.chaos-master.deno.net/

The issue there is a bit different, that is the app works, webgpu works but it freezes in Firefox Nightly with my profile,
on any firefox ran on mozregression tool, it never freezes, but the preview flickers like so (canvases go dark):
https://postimg.cc/Cd2XSPbb,

It doesn't happen when cautiously creating multiple canvases and cleaning/destorying them properly.

So I suspect environment because the issue is present for more than 6 months at least.

Firefox v135 works much slower on WebGPU renderings, so cannot really tell.
Firefox v143 works faster but flickers on many canvases.
Firefox v149 stable works the same, flickering happens
Firefox v151 nightly works weirdly by freezing, but only on my profile / env, tried refreshing nightly and reinstalling but same thing happens:
https://postimg.cc/FdygfxRH <- stuck at this a lot of time before it unfreezes or on changing tab.

So, for Windows seems like implementation matters, even though it mostly works, and the flicker is present on all implementations so far.

Comment 9

[brandmairstefan]

On my Windows 11 machine with a fresh Firefox Developer Edition, https://webgpu.github.io/webgpu-samples/?sample=helloTriangleMSAA consistently results in the same kind of error.

Uncaptured error:
Not enough memory left

If one looks at the task manager, one can rapidly see the memory usage rise.

Comment 10

[Andy Leiserson [:aleiserson]]

:brandmairstefan, I suspect your problem is something different than the original issue in this bug. Can you file a separate bug, attaching the contents of about:support, and check whether there are any errors reported in the console? A profile might also be informative if you are able to capture one. We've seen simple applications like that exhibit runaway memory usage because they are re-rendering faster than the display refresh rate (typically because there's an error and the error behavior is to try re-rendering immediately, but maybe there are non-error cases where that could happen as well).

Comment 11

[brandmairstefan]

(In reply to Andy Leiserson [:aleiserson] from comment #10)

Done, I filed it at https://bugzilla.mozilla.org/show_bug.cgi?id=2039025 . As always, I am more than happy to dig deeper into it or to provide additional information if there is anything that would be helpful.

Comment 12

[Sotaro Ikeda [:sotaro]]

:sonorousfreq, can you attach about:support to this bug?

Comment 13

[tmilic [:sonorousfreq]]

Attachment: aboutSupport

Comment 14

[tmilic [:sonorousfreq]]

Hi,

sure, added above.

Also, take a look at this other bug, which make it a bit more clear why and how that happens: https://bugzilla.mozilla.org/show_bug.cgi?id=2040218

Best

Comment 15

[tmilic [:sonorousfreq]]

Hi, just to note here, not sure what you did, but with few last nightly releases, onnx runtime and also webgpu rendering in the app was quite workable, didn't see any OOMs, performance quite good, not sure if MESA did some changes or firefox but as soon as I see any crash I will report, so far, nothing is breaking, even on wayland.

Comment 16

[Andy Leiserson [:aleiserson]]

Glad to hear it. I had been waiting for a fix for bug 2037013 before asking to re-check the current behavior, but this was likely improved by https://github.com/gfx-rs/wgpu/pull/9747. If you have the latest mesa you could also have picked up their fix for the underlying issue.

Assuming nothing else comes up, can we consider this bug and bug 2040218 fixed?

Comment 17

[tmilic [:sonorousfreq]]

Hi,

yes, I think so, RAM is still reported as 0, but I don't think this affects the performance.

I did have some weird crashes unrelated to webpgu (I think) in firefox nightly, e.g., the firefox would just be completely stuck and unresponsive, and any dropdowns would simply not work, to the point it would feel like an infinite loop when you try to click on a dropdown, and I had to force shut it down or just move to chrome to continue working. I understand its a nightly, and I do quite a lot of different things on the PC, but I think this has never been the case before, during this whole year, while I was using the nightly.

I will try to reproduce this and report it, you may even have gotten some 'crash' reports from those unresponsive scenarios, that I always submit, but let's discuss this on another ticket.