Advertisement Jump to content
  • Advertisement
  • 03/21/17 05:50 PM
    Sign in to follow this  

    Mozilla Proposes "Obsidian" Web Graphics API


    • Posted By khawk

    The Khronos Group recently setup a staging area for WebGL-Next proposals on Github, and this morning Mozilla submitted Obsidian as the first proposal. Obsidian is a low-level API intended to provide a maximum features set of the GPU to web applications. Similar to Vulkan, it's designed for WebAssembly, modern GPUs, and a multi-threaded environment.

    From the readme:

    • The need for a more efficient graphics API for the Web is clear. What is not clear is the look and design of such API. Previous mailing lists discussions were split into two groups: one that considered Metal as a good baseline for the new API, due to it simpler and higher level abstraction, which is easier to provide safely on the Web. Another group saw Vulkan as an ultimately portable API that just needs to be re-defined on the Web with some feature cuts.

      We built a prototype into Servo, providing a Metal-like API in WebIDL (for JavaScript), backed by Vulkan. It exposed the problems of communicating with the graphics backend via the process barrier, transcoding the commands between different APIs, and briefly touched the security aspect. We found this way to be reachable, but we also realized that this is an unique opportunity for the Web to get so much more.

      Providing render passes, for example, would open the door to efficient graphics on mobile. Having secondary command buffers can vastly increase the fidelity of the content being rendered. Even exposing the resource layout can make execution on AMD hardware (in particular) more predictable. And even if it imposes a bigger CPU overhead for sanitizing the commands, it gets faster when it reaches the GPU. Thus, we decided to focus on the capability of the API instead of the simplicity.

      Within the next-gen APIs, Vulkan is the most feature rich, and Metal is the simplest. The advanced shader syntax (e.g. pointer semantics) of Metal don't map well to other APIs. Thus, we started with Vulkan and SPIR-V, and for each feature (that it has over other APIs), we evaluated the cost of emulating it on the other APIs versus the benefit of exposing it.

      Report Story
    Sign in to follow this  

    User Feedback

    There are no comments to display.

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!