WebRender currently has - 1 renderer thread - N low priority worker threads (N = core count) - N high priority worker threads (N = core count) - W render backend threads (W = number of windows) - W High priority scene builder threads (W = number of windows) - W Low priority scene builder threads (W = number of windows) - W* SwComposite threads (W* = number of SWGL windows) A Window can be a browser window but also a popup like the awesomebar's or the hamberger menu, so for a typical browsing session with a single main window, W = 4 is typical. When the number of broswer windows go up, we can end up with a lot of threads. It's worth noting that we saw in telemetry that only a very small percentage (I don't remember the number) of Firefox users use more than a single browser window, so the issue is as rare as it is spectacular. ## The ideal threading configuration in my opinion would look like: - A fixed amount of renderer threads (like, 4), one of which being dedicated to all windows that are marked as popups, other windows being randomly assigned to the other threads when initializing the renderer. - The same fixed amount of SwComposite threads - No render backend thread (it's merged with the renderer) - A single High priority scene builder thread - A single low priority scene builder thread - The high and low priority thread pools with N = core count threads each (as long as we use rayon, a signle thread pool would do if we had something better but that's lower priority). ## How to get there A bit unclear, it's going to be a lot of untangling complicated event loop interactions, a fair bit of work for sure.
Bug 1728116 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
WebRender currently has - 1 renderer thread - N low priority worker threads (N = core count) - N high priority worker threads (N = core count) - W render backend threads (W = number of windows) - W High priority scene builder threads (W = number of windows) - W Low priority scene builder threads (W = number of windows) - W* SwComposite threads (W* = number of SWGL windows) A Window can be a browser window but also a popup like the awesomebar's or the hamberger menu, so for a typical browsing session with a single main window, W = 4 is typical. When the number of broswer windows go up, we can end up with a lot of threads. It's worth noting that we saw in telemetry that only a very small percentage (I don't remember the number) of Firefox users use more than a single browser window, so the issue is as rare as it is spectacular. ## The ideal threading configuration in my opinion would look like: - A fixed amount of renderer threads (like, 4), one of which being dedicated to all windows that are marked as popups, other windows being randomly assigned to the other threads when initializing the renderer. - The same fixed amount of SwComposite threads - No render backend thread (it's merged with the renderer) - A single High priority scene builder thread - A single low priority scene builder thread - The high and low priority thread pools with N = core count threads each (as long as we use rayon, a signle thread pool would do if we had something better but that's lower priority). Another route that was mentioned in a meeting is to not assign renderers to fixed threads and instead let them live in a thread pool, which would mean that a frame could be processed on a certain thread and the next frame in another thread. For this to work we would still need a single dedicated GL command submission thread (what the renderer does today). Bonus point if we can do this within the rayon thread pool because submitting work from within the thread pool is a lot cheaper than from outside so we could use rayon a bit more. The upside is that we would get a higher chance of keeping a good frame rate when multiple windows are rendering at the same time, however it makes profiling harder as frames are distributed randomy between threads, and it would be hard to share the texture cache between multiple windows. ## How to get there A bit unclear, it's going to be a lot of untangling complicated event loop interactions, a fair bit of work for sure, perhaps some of it can be done incrmentally, for example having a single scene builder thread for all windows could probably be done without the rest, etc.