WebGL and fgx acceleration on Wayland

fishes
WebGL on Wayland running in full speed.

Firefox on Linux have suffered by poor WebGL performance for long, long time. It was given by missing general acceleration on Linux as there are always broken gfx drivers on X11, various hacks and different standards, closed source drivers and so on. Long story short – to do gfx acceleration seriously on Linux have been PITA. For instance Chrome (which supports gfx acceleration on Linux/X11) shows long list of active exceptions and workarounds listen at chrome://gpu/ page.

It’s also reason why Firefox never enabled it by default although it also implements gfx acceleration – Mozilla does not have resources to spend too much time on every broken gfx card / driver.

Fortunately situation was changed with Wayland. Working gfx acceleration is a sort of prerequisite to even start a decent Wayland compositor like Mutter or Plasma so when Firefox is launched on Wayland we can pretty much expect working GL environment. Also dmabuf is widely supported by Wayland compositor so we finally have all pieces together to build fully accelerated browser on Linux which is equal to its Windows siblings.

Firefox supports two acceleration modes – WebRender and GL compositor. WebRender is the new one and it’s superior in web content rendering. GL compositor is the former one, less advanced but it’s still faster for some scenarios where bits are heavily shifted from one side to another one – video playback and WebGL.

Both WebRender and GL compositor have implemented dmabuf back end which means textures used by WebRender/GL compositor can be created directly at GPU and shared  without copy among compositor / GPU browser processes. Such GPU memory can be in the same time mapped as EGL framebuffer so we can render WebGL frames directly to GPU memory, handle them from webgl process to chrome process and render it as a texture to a web page.

All those pieces are tied together in recent nightly where we finally have full WebGL support on Wayland and it will be shipped as Firefox 75. If you run Fedora/Gnome you can try it by yourself. Just grab latest nightly from Mozilla, enable HW acceleration, set widget.wayland-dmabuf-webgl.enabled to true at about:config, restart browser and open your favorite WebGL application like maps.google.com or WebGL samples.

28 thoughts on “WebGL and fgx acceleration on Wayland

  1. Is the config “widget.wayland-dmabuf-webgl.enabled” the only one necessary to enable this feature, or should WebRender be enabled as well?

    Like

    1. You also need to enable GL compositor (by layers.acceleration.force-enabled) or WebRender (gfx.webrender.enabled and gfx.webrender.all). But WebRender it enabled by default on some nightly, you can check that at about:support page at “Compositor” field.

      Liked by 1 person

      1. Hardware is not an issue. Wayland itself have no requirement on hardware, on other side, compositors implementing Wayland rely on OpenGL by their choice.

        It’s great that we finally getting some fruits from Wayland development.

        Liked by 2 people

  2. > on Linux as there are always broken gfx drivers on X11, various hacks and different standards, closed source drivers and so on

    Ehm… Is it really true? Though I personally haven’t been with GNU/Linux long enough, but a decode ago Dolphin developers praised all GNU/Linux drivers except the prorietary fglrx of AMD https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/ And Mesa devs are both responsive regarding regressions and have a great test-suite. Regarding fglrx, it has been discontinued and died in preference of Mesa.

    So what you’re saying sounds very odd to me.

    Liked by 2 people

      1. Well, it’s just a personal blog of one developer, and people happen to be wrong. I think it’s incorrect to generalize one developer opinion to that of a company. Red Hat in general are cool guys, because they are one of the major contributors to the Linux ecosystem. And Martin in particular is a great contributor that helped Linux version of Firefox a lot, so kudos to him either way.

        Like

  3. Thanks for the great work!
    One question: I assume FF 75 will get the features, but not the defaults? When does Firefox plan to flip various kinds of hardware acceleration “on” by default?

    Like

  4. “You can verify that VA-API is enabled by running Firefox with MOZ_LOG=”PlatformDecoderModule:5″ env variable and check in the log output that VA-API is enabled and used.”

    Where is this log located. I read the bugzilla post about enabling this but I can’t find any information about this magic log that will confirm if it is working.

    Like

  5. Firefox 75.0 landed on Arch testing repo and i decided to give it a spin. The good news are that the hover/focus issues that plagued the previous versions on Wayland are gone. It seems in pretty good shape now to me.

    The bad news are that the new dmabuf options that appeared in this version don’t seem to work for me. dmabuf-backend.enabled works fine since the previous version, dmabuf-webgl.enabled just makes WebGL Aquarium appear grey/not show anything on screen (it works fine, although slow, with the setting disabled), and all other dmabuf options (basic-compositor, vaapi, textures) make all the tabs crash as soon as i click on them. Sometimes even firefox itself crashes.

    I am running Archlinux with the latest stable Gnome and Mesa, on an AMD R9 380 gpu. I don’t know if there is something wrong with the distro packages or with the driver, just wanted to share my experience. Still, i want to thank you for your excellent work! It means a lot to us all Linux users!

    Like

  6. I tested the latest nightly 77.0a1 for a bit. Seems dmabuf-vaapi and dmabuf-webgl can be enabled now for me without crashing, though dmabuf-textures still crash every tab almost instantly if enabled. Didn’t find any toggle for dmabuf-backend so i suppose it was removed? Anyway playing videos with vaapi doesn’t crash now but i am not sure it uses hardware acceleration on my gpu. How can i be sure? i am getting this on terminal:

    MESA-LOADER: failed to retrieve device information
    MESA-LOADER: failed to retrieve device information
    amdgpu: drmGetDevice2 failed.

    As for webgl, in aquarium sample i am still getting a grey screen with this log:

    MESA-LOADER: failed to retrieve device information
    MESA-LOADER: failed to open amdgpu (search paths /usr/lib/dri)
    failed to load driver: amdgpu
    WebGL(0x7fb6d9681000)::LoseContext(0)

    By the way when dmabuf-textures is enabled and tabs insta-crush i am getting similar failed to load messages plus i am getting a ton of these:

    [GFX1-]: Failed to create DrawTarget, Type: 3 Size: Size(1680,33), Data: 0, Stride: 0

    and these

    ###!!! [Parent][MessageChannel] Error: (msgtype=0x5A001C,name=PHttpChannel::Msg_DeleteSelf) Channel error: cannot send/recv

    Perhaps something is missing from Archlinux packages? VAAPI and 3D accel work perfectly fine outside Firefox for me. Maybe something is not configured right? About:support has no issue finding my driver though

    Active Yes
    Description AMD Radeon (TM) R9 380 Series (TONGA, DRM 3.36.0, 5.6.3-zen1-1-zen, LLVM 9.0.1)
    Vendor ID 0x1002
    Device ID 0x6939
    Driver Vendor mesa/radeonsi
    Driver Version 20.0.4.0
    RAM 2048

    Like

    1. dmabuf-textures is useless and it’s here for testing purposes only. It’s actually removed from beta/release builds.
      For the rest please file a bug at bugzilla.mozilla.org under Core/Graphics and CC me there, needs to be investigated.
      Thanks.

      Like

      1. I am late to the party but i tried the latest nightly this morning (with the intention of opening a bug report of none present) and everything now works as it should i think. No crashes, webgl is fast and stable, same with vaapi. Running with MOZ_LOG=”PlatformDecoderModule:5″ ./firefox does not seem to produce any message when running a video or executing a webgl sample, so i suppose this is a good thing. Any chance these fixes land with 76 stable? I tried finding a relevant bug report, to report that things now work fine, but i couldn’t find any, so i am telling you here.

        Overall i fiddled around with many websites and it seems really fast and with no issues at all. I am impressed. Seems to me it won’t be long until you can enable these by default. Great job! Thank you!

        Liked by 1 person

      2. Update: the fix didn’t make it into Mesa 20.1.0, but is in 20.1.1, which should become available on Arch in about a week.

        Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Design a site like this with WordPress.com
Get started