Announcement

Collapse
No announcement yet.

Mozilla Proposes "Obsidian" Low-Level Graphics API For The Web, Based On Vulkan

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

  • #11
    Originally posted by juno View Post
    Vulkan is not "low level".
    Obsidian is not Vulkan.
    An API can be based on Vulkan, excluding critical stuff, including e.g. sane memory management etc.
    WebGL ain't much better either when there are crappy shader compilers with drivers hooked up deeply into the system that can't even parse shit and pull the entire system down instead.

    The same points as already discussed when Apple published their proposal, aside from the fact that noone is going to tell Mozilla to get lost because they don't support the APIs everyone else already agreed upon.
    What would you think about Web GPU API's splitting between OpenGL and Vulkan?
    WebGL continuing OpenGL ES but with support for things like SPIR-V, WebAssembly and WebIDL to make it programming language-independent and avoid those same crappy OpenGL (ES) compilers on the web.
    Obsidian or let's call it Websidian taking on the Mantle of Vulkan in Web GPU API's.
    Vulkan is a great API and making it safe and stable for the web will improve the Vulkan API in general,
    which is a good thing.
    Improving Vulkan and infusing it with webtechnologies such as WebAssembly and WebIDL to make it a programming language-independent GPU API for the web sounds a very interesting proposition.

    No one said you could only support one API or have only one Web GPU API.
    And let's make WebMetal it's own Web GPU API based upon Apple's Metal.
    Last edited by plonoma; 21 March 2017, 05:37 PM.

    Comment


    • #12
      Originally posted by dh04000 View Post
      The point of Vulkan was to get "bare-to-metal". This comes with the increased risk of something doing wrong and hosing your system since the application, not the driver, must do all the work.
      Arguably OpenGL drivers are a much bigger risk: they're large, complex and have often come with bugs so bad that most browsers ship with blacklists of driver versions on which WebGL will be automatically disabled because of how broken it would be.

      Comment


      • #13
        Originally posted by uid313 View Post
        Well Internet Explorer 11, Edge, and Chrome all have much better WebGL performance than Firefox. So I don't know if Mozilla is the right candidate to propose any graphics API.
        Yet Servo's WebRender kicks all of their asses. With Servo, they're following the "forget competing with MP3, we'll compete with MP3 + 2 and call it Opus" strategy at the same time as they struggle to "change out the engines while in flight" with Firefox without the forced switch to WebExtensions pissing off a critical mass of users and developers.

        Give it 12 months. Firefox has always been hamstrung by having an extension API that allows any random extension to manipulate just about any random implementation detail. While I might be on Chromium or SeaMonkey or Pale Moon by then, the combination of jettisoning the old API and piecemeal migrating to Rust to offload more work on the compiler is bound to make them much more agile.

        Comment


        • #14
          Unapproved comment.

          Comment


          • #15
            Originally posted by dh04000 View Post
            The point of Vulkan was to get "bare-to-metal". .
            No the point was to have lower CPU usage, and more efficiently used GPU. The way it achieved that was by going closer to the metal. But is it the lower overhead that also makes it more suitable on the web, with fewer API calls that reduced overhead is even more important with web-tech than C/C++ based OpenGL.

            Comment


            • #16
              Originally posted by jaxxed View Post
              I love it. Apple and MS try to push away Vulkan with a low-level abstraction, and Mozilla comes back in with a Vulkan based API.

              Thank you Mozilla, I love you.
              "The API has to be efficiently implementable in at least Vulkan and Metal, and likely D3D12 as well. Implementability on D3D11 and OpenGL is not a constraint."

              I've heard this before somewhere....

              Comment


              • #17
                Originally posted by uid313 View Post
                Well Internet Explorer 11, Edge, and Chrome all have much better WebGL performance than Firefox. So I don't know if Mozilla is the right candidate to propose any graphics API.
                Are you looking to showcase your brand in front of the gaming industry’s top leaders? Learn more about GamesBeat Summit sponsorship opportunities here.  It’s been more than a year since our last browser benchmark battle, and the competition remains fierce. Google Chrome, Mozilla Firefox, and Microsoft Edge have all gained a variety of new features […]


                higher is better
                FF Chrome Edge
                10000 9940 9920

                Please provide a citation for your claim.

                Comment


                • #18
                  Originally posted by liam View Post

                  http://venturebeat.com/2016/10/25/br...edge/view-all/

                  higher is better
                  FF Chrome Edge
                  10000 9940 9920

                  Please provide a citation for your claim.

                  Click on 4000 fish.

                  Firefox 52 gets 17-23 fps.
                  Chrome 58 gets 40-42 fps.
                  Edge gets 60 fps.



                  Click on 400 fish.
                  Firefox 52 gets 20-25 fps.
                  Chrome gets 42-44 fps.
                  Edge gets 50-53 fps.
                  Last edited by uid313; 22 March 2017, 06:17 AM.

                  Comment


                  • #19
                    Ah, this will probably piss off some people who recently commented that Vulkan is insufficient to work in web browsers.

                    Comment


                    • #20
                      Originally posted by ssokolow View Post
                      Give it 12 months. Firefox has always been hamstrung by having an extension API that allows any random extension to manipulate just about any random implementation detail.
                      Yeah, that's been hurting Firefox for a long time now. The power of the extension framework has been one of their strengths from the start, but with most of the browser internals exposed as de-facto API, that same framework badly limits their ability to make big changes. So the push towards WebExtensions is essentially a trade-off... sacrificing some of that traditional strength, in order to get the freedom to do long-overdue architectural re-work.

                      Comment

                      Working...
                      X