Announcement

Collapse
No announcement yet.

Experimental Code Allows Vulkan-Accelerated Gecko/Firefox On Linux

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Experimental Code Allows Vulkan-Accelerated Gecko/Firefox On Linux

    Phoronix: Experimental Code Allows Vulkan-Accelerated Gecko/Firefox On Linux

    With some out-of-tree code of Firefox Nightly with a modified version of Gecko using GFX-RS, it's possible to use the web-browser powered by the Vulkan API on Linux...

    http://www.phoronix.com/scan.php?pag...al-Vulkan-Code

  • #2
    Stop doing all this experimental stuff and ship FF with Wayland support enabled by default already.

    Comment


    • #3
      Awesome, can't wait to test this out. Vulkan support in Firefox sounds very promising. Sure, Mozilla should take Wayland now as well a little serious. Most of it is done at the moment by just one developer.

      Comment


      • #4
        Originally posted by cl333r View Post
        Stop doing all this experimental stuff and ship FF with Wayland support enabled by default already.
        you assume that this developer has anything to do with getting wayland working?

        Comment


        • #5
          Originally posted by phoronix
          This is part of the effort to run Gecko with GFX-RS. GFX-RS, of course, is the Rust portability initiative with low-level graphics abstractions to map to Vulkan, Metal, Direct3D, etc, depending upon the platform.
          I understand why you would want to avoid an extra abstraction layer to avoid using MoltenVK on macOS, but I do not understand why they would want to support yet another graphics API on Windows since DirectX 12 doesn't really have any benefits over Vulkan. Just seems like more maintenance to me and I would hope that Mozilla would support open standards over closed ones when they can without any consequences.

          Comment


          • #6
            Originally posted by cl333r View Post
            Stop doing all this experimental stuff and ship FF with Wayland support enabled by default already.
            Shocking news: there is more than one developer working on firefox.

            Comment


            • #7
              Originally posted by johanb View Post

              I understand why you would want to avoid an extra abstraction layer to avoid using MoltenVK on macOS, but I do not understand why they would want to support yet another graphics API on Windows since DirectX 12 doesn't really have any benefits over Vulkan. Just seems like more maintenance to me and I would hope that Mozilla would support open standards over closed ones when they can without any consequences.
              According to a Reddit user D3D allows better integration with hardware-accelerated video decoding. Perhaps that's the reason.

              Using D3D under the covers allows better integration with hardware-accelerated video decoding and Direct2D-accelerated canvas drawing. I think we...

              Comment


              • #8
                Originally posted by johanb View Post
                I understand why you would want to avoid an extra abstraction layer to avoid using MoltenVK on macOS, but I do not understand why they would want to support yet another graphics API on Windows since DirectX 12 doesn't really have any benefits over Vulkan. Just seems like more maintenance to me and I would hope that Mozilla would support open standards over closed ones when they can without any consequences.
                Universal Windows Platform + Microsoft Store. They do not provide Vulkan API for rendering (even though Windows graphics drivers may). Hence Vulkan Portability Initiative exists in the first place – to make sure one can write using an open API – Vulkan – and still deploy to as many platforms as possible, not bothering about their respective in-house APIs.

                gfx-rs through gfx-hal (gfx hardware abstraction layer) provide Rust graphics API very similar to Vulkan, while gfx-hal implementations (“backends”) translate it into: Vulkan, Metal, D3D12, and after the recent GSoC also D3D11 (and OpenGL backend is planned).

                And then there is gfx-portability project, which is Khronos-blessed Vk Portability Initiative implementation that aims to provide implementation of the Vulkan API (or portable subset thereof) as a shared C-ABI library using gfx-hal to translate it to all the proprietary ones.

                This way they actually promote the open API – one can use one Vulkan or gfx-rs renderer and deploy it to not only platforms with Vulkan drivers (Linux, most Windowses), but also to macOS, iOS, and Windows 10 S (which allows installation only of MS Store apps) or Xboxes.
                Last edited by silmeth; 08-31-2018, 09:00 AM.

                Comment


                • #9
                  Originally posted by johanb View Post

                  I understand why you would want to avoid an extra abstraction layer to avoid using MoltenVK on macOS, but I do not understand why they would want to support yet another graphics API on Windows since DirectX 12 doesn't really have any benefits over Vulkan. Just seems like more maintenance to me and I would hope that Mozilla would support open standards over closed ones when they can without any consequences.
                  According to a Reddit user D3D allows better integration with hardware-accelerated video decoding: https://old.reddit.com/r/firefox/com...ng_on/e53ei4u/

                  Comment


                  • #10
                    Originally posted by johanb View Post

                    I understand why you would want to avoid an extra abstraction layer to avoid using MoltenVK on macOS, but I do not understand why they would want to support yet another graphics API on Windows since DirectX 12 doesn't really have any benefits over Vulkan. Just seems like more maintenance to me and I would hope that Mozilla would support open standards over closed ones when they can without any consequences.
                    The problem with this is that the future of Windows is believed to be more and more heavy reliance on UWP which doesn't support Vulkan. If they eventually need to target DX12 to support Windows users it's better to hedge their bet now and build the abstraction layer with DX in mind.

                    Comment

                    Working...
                    X