WebRender newsletter #44

WebRender is a GPU based 2D rendering engine for web written in Rust, currently powering Mozilla’s research web browser servo and on its way to becoming Firefox‘s rendering engine.

WebRender on Linux in Firefox Nightly

Right after the previous newsletter was published, Andrew and Jeff enabled WebRender for Linux users on Intel integrated GPUs with Mesa 18.2 or newer on Nightly if their screen resolution is 3440×1440 or less.
We decided to start with Mesa is thanks to the quality of the drivers. Users with 4k screens will have to wait a little longer though (or enable WebRender manually) as there are a number of specific optimizations we want to do before we are comfortable getting WebRender used on these very high resolution screens. While most recent discreet GPUs can stomach about anything we throw at them, integrated GPUs operate on a much tighter budget and compete with the CPU for memory bandwidth. 4k screens are real little memory bandwidth eating monsters.

A week in Toronto – Part deux

In the previous newsletter I went over a number of the topics that we discussed during the graphics team’s last get-together in Toronto. Let’s continue here.

WebRender on Android

We went over a number of the items in WebRender’s Android TODO-list. Getting WebRender to work at all on Android is one thing. A lot of platform-specific low level glue code which Sotaro has been steadily improving lately.

On top of that come mores questions:

Which portion of the Android user population support the OpenGL features that WebRender relies on?

Which OpenGL features we could stop relying on to cover more users

What do we do about the remaining users which have such a small OpenGL feature set available that we don’t plan to get WebRender in the foreseeable future.

Among the features that WebRender currently heavily relies on but are (surprisingly) not universally supported in this day and age:

texture arrays,

float 32 textures,

texture fetches in vertex shaders,

instancing,

We discussed various workarounds. Some of them will be easy to implement, some harder, some will come at a cost, some we are not sure will provide an acceptable user experience. As it turns out, building a modern rendering engine while also targetting devices that are everything but modern is quite a challenge, who would have thought!

Frame scheduling

Rendering a frame, from a change of layout triggered by some JavaScript to photons flying out of the screen, goes through a long pipeline. Sometimes some steps in that pipeline take longer than we would want but other parts of the pipeline sort of absorb and hide the issue and all is mostly fine. Sometimes, though, slowdowns in particular places with the wrong timing can cause a chain of bad interactions which results a back and forth between a rapid burst of a few frames followed by a couple of missed frames as parts the system oscillate between throttle themselves on and off.

I am describing this in the abstract because the technical description of how and why this can happen in Gecko is complicated. It’s a big topic that impacts the design of a lot of pieces in Firefox’s rendering engine. We talked about this and came up with some short and long term potential improvements.

Intel 4K performance

I mentioned this towards the beginning of this post. Integrated GPUs tend to be more limited in, well in most things, but most importantly in memory bandwidth, which is exacerbated by sharing RAM with the CPU. When high resolution screens don’t fit in the integrated GPU’s dedicated caches, Jeff and Markus made the observation that it can be significantly faster to split the screen into a few large regions and render them one by one. This is at the cost of batch breaks and an increased amount of draw calls, however the restricting rendering to smaller portions of the screen gives the GPU a more cache-friendly workload than rendering the entire screen in a single pass.

This approach is interestingly similar to the way tiled GPUs common on mobile devices work.
On top of that there are some optimizations that we want to investigate to reduce the amount of batch breaks caused by text on platforms that do not support dual-source blending, as well as continued investigation in progress of what is slow specifically on Intel devices.

Other topics

We went over a number of other technical topics such as WebRender’s threading architecture, gory details of support for backface-visibility, where to get the best Thaï food in downtown Toronto and more. I won’t cover them here because they are somewhat hard and/or boring to explain (or because I wasn’t involved enough in the topics do them justice on this blog).

In conclusion

It’s been a very useful and busy week. The graphics team will meet next in Whistler in June along with the rest of Mozilla. By then Firefox 67 will ship, enabling WebRender for a subset of Windows users in the release channel which is huge milestone for us.

Enabling WebRender in Firefox Nightly

In about:config, enable the pref gfx.webrender.all and restart the browser.

Reporting bugs

The best place to report bugs related to WebRender in Firefox is the Graphics :: WebRender component in bugzilla.

14 thoughts on “WebRender newsletter #44”

WebRender will be part of the build on Windows Linux and Mac, but only enabled by default for a small subset of Windows users in 67. You will be able to enable it manually on any of these platforms using the “gfx.webrender.all” pref.

Instanced arrays in part of GLES 3.0. on GLES 2 the required extension is GL_EXT_instanced_arrays. You appear to be able to fetch texture memory in vertex shaders (with up to 16 bound textures which is more than we need).
I don’t have the numbers handy but I think that a reasonable amount of Android devices support most of our requirements (except texture arrays which are the first thing we’ll build an alternative for).
There are still a number of low end android devices that will either force us to maintain the non-webrender backend for or we’ll have to build some kind of low end ES2 webrender backend which is a more involved project. These and also presumably some devices with the right feature set but buggy drivers.

Just for the reference, I’ve been using WebRender in Firefox beta on Linux for quite a while already (forcing it with environment variable) both on Intel Kabylake GT2 integrated GPU and AMD Vega 56 discrete GPU (using latest Mesa release). It works very well.

My only complaint is lack of accelerated video encoding / decoding, since these GPUs support it through VAAPI. This basically kills performance of WebRTC video conferencing on laptops. I suppose switch to WebRender itself is a prerequisite for enabling hardware accelerated video support on Linux?

WebRender is mostly independent to how video is decoded, although you would need to be using either WebRender or the OpenGL compositor backend otherwise the cost of transfering video frames from the GPU to the CPU would negate the benefits of hardware video decoding.
I’m not really up to speed with the status of hardware video deconding in Firefox on linux, though. Maybe something that the media team will tackle once WebRender is enabled for a large enough number of users.

Hello @Nical.
Thank you for post every week articles about Web Render and Firefox future.
I will like know if Web Render will increase Firefox DOM speed.
Maybe I don’t have minimum hardware requirements, but I have activated Web Render (Nightly, Linux) and I don’t see a notable change on Speedometer test results.
Can you tell me more about it?