Serious performance regression of workers on Windows 10 in 88
Categories
(Core :: Graphics: CanvasWebGL, defect, P3)
Tracking
()
People
(Reporter: nige, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0
Steps to reproduce:
Visit https://atomirex.com/gamefuntemp/prod/ in Firefox 88 on a Win10 64 bit machine.
This uses a web worker to update the state which is rendered in webgl in the main thread by using transferable buffers over the message channel every frame.
Actual results:
In 88:
CPU appears throttled inappropriately leading to a bad framerate. Task manager shows about 6% of CPU usage on an otherwise idle machine.
Expected results:
In 87:
CPU is allocated appropriately and framerate is fine. Task manager shows about 13% usage on an otherwise idle machine (the same machine!)
(I did verify this by rolling back to 87 and installing all the extensions etc.)
Reporter | ||
Comment 1•4 years ago
|
||
I should add that the worker uses the wasm port of ammo.js (the public build) in case that is relevant.
Comment 2•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Canvas: WebGL' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 3•3 years ago
|
||
Sounds like a facet of bug 1657125.
Adding gl.flush()
might help.
This is an octo-core machine with HT, right? 16 hardware threads?
I don't think the CPU is throttled, but rather work is piling up for dispatch on the Content process, and it's only being sent to the WebGLParent process for execution in big chunks, so most of the time cores are sitting idle.
Maybe we could be more pro-active about flushing commands multiple times a frame, but this is a power-use hit.
Description
•