37 ms·

Security issues aside, why wouldn't we want "WebVulkan"? I suspect there would be some interest from various parties in making a WebAssembly compatible cross pl

by iLoch 10y ago

Security issues aside, why wouldn't we want "WebVulkan"? I suspect there would be some interest from various parties in making a WebAssembly compatible cross platform 3D library. Being able to create something with Unreal Engine, for example, while targeting both web, mobile and desktop seems like it would be incredibly powerful.

flohofwoe 10y ago
Vulkan is a more like a driver-level API, an API to write other 3D-APIs with. You need over a thousand lines of code to render a triangle. It doesn't abstract the underlying GPU enough that you can have a single code path that gives you best performance across GPU vendors (at least that was the state a couple of months ago, I don't know if this has changed). I think this is the wrong approach for a 3D API that should be usable by more people than a very small group of highly specialised rendering engineers. Metal is an API that fills that gap very well, it is easy to use and is a modern low-overhead API. A proper modern 3D web API should be agnostic to the underlying native API (a bit similar to how WebGL runs on top of D3D on Windows, but with much less 'conversion overhead' since most state is compiled into immutable objects).
- exDM69 10y ago
  I am going to respectfully disagree with you here. Yes, Vulkan is a difficult API to work with and it's not at all beginner friendly. But simplicity and ease of use should not be guiding the decisions, the emphasis should be on providing a way to run Unity, Unreal, and other engines (new and old) on the Web. Even if Vulkan is a difficult API to work with, a low level 3d API should be available in a browser. It could be used as a building block to create frameworks and engines that are easy to use. Even WebGL is "too low level" for most application developers, which is why three.js and other frameworks are popular.
  - flohofwoe 10y ago
    Yes there are also valid points for having an really low level 3D-API like a WebVulkan in the browser, and the 'big-engine-makers' seem to be fond of this idea. But I see this more in the realm of a 'compilation target', more for WebAssembly then JS. Translating Vulkan 1:1 to D3D12 or even Metal would be challenging though, I think most of the advantages of having a real bare-metal API would be lost in this translation-layer I guess.
    - grovesNL 10y ago
      The Altai example is great but they can already be implemented in JavaScript with very low overhead. If the performance is a concern then we should be moving more towards lower level APIs such as Vulkan, and let JS libraries implement their own API on top of that when that extra performance is needed. There is also the possibility that performance improvements to WebGL could always be made (i.e. supporting command queues or SPIR-V).
      - flohofwoe 10y ago
        I think that Metal / WebGPU is just at the right abstraction level for a modern 3D API. It's like a successor to D3D11 (which is a mighty fine 3D-API). Vulkan and D3D12 are really not a lot of fun to work with. I'd rather maintain an thin API wrapper on top of 3 different 3D-APIs at the complexity level of D3D11 or Metal, instead of having to maintain a single wrapper for D3D12 or Vulkan (and you need to support multiple 3D APIs anyway, since none of them exists on all relevant platforms). But that is strictly IMHO, I guess there's also people who enjoy working in D3D12 or Vulkan ;)
        exDM69 10y ago
        The problem with the WebGpu proposal is that it is difficult to implement with Vulkan efficiently as the spec is now. I'm sure the spec can still be changed to be a better fit, though.
  - cwyers 10y ago
    It's not about being too low-level for developers, it's about it being too low-level for implementation. Vulkan is lower level than DX12 or Metal; you can't implement it on top of those platform APIs, like ANGLE runs OpenGL ES on top of a compatibility shim over DirectX or desktop OpenGL. A cross-platform graphics API in the browser needs to be high-enough level to abstract over all of Vulkan/DX12/Metal and provide a consistent interface so that developers don't have to know which one their application is running on. Either that, or in addition to WebVulkan you need WebDX12 and WebMetal.
    - erichocean 10y ago
      > you can't implement [Vulkan] on top of [DX12 or Metal] http://lmgtfy.com/?q=vulkan+metal http://lmgtfy.com/?q=vulkan+metal First result: "MoltenVK is an implementation of Vulkan that runs on Apple's Metal graphics framework on iOS and macOS."
pjmlp 10y ago
You can already do that, that is the whole point of a game engine, to abstract way the underlying platforms, while providing higher level tooling. Also a reason, why outside communities like HN, most game developers don't really care about API wars.
rubber_duck 10y ago
>Security issues aside I don't think you can really put those aside - that's the whole point of web as a platform - that visiting a link won't let you take over my PC (and that's hard enough as is in practice). Just use native apps if you want native access.

by iLoch 10y ago

flohofwoe 10y ago

Vulkan is a more like a driver-level API, an API to write other 3D-APIs with. You need over a thousand lines of code to render a triangle. It doesn't abstract the underlying GPU enough that you can have a single code path that gives you best performance across GPU vendors (at least that was the state a couple of months ago, I don't know if this has changed). I think this is the wrong approach for a 3D API that should be usable by more people than a very small group of highly specialised rendering engineers. Metal is an API that fills that gap very well, it is easy to use and is a modern low-overhead API. A proper modern 3D web API should be agnostic to the underlying native API (a bit similar to how WebGL runs on top of D3D on Windows, but with much less 'conversion overhead' since most state is compiled into immutable objects).

exDM69 10y ago
I am going to respectfully disagree with you here. Yes, Vulkan is a difficult API to work with and it's not at all beginner friendly. But simplicity and ease of use should not be guiding the decisions, the emphasis should be on providing a way to run Unity, Unreal, and other engines (new and old) on the Web. Even if Vulkan is a difficult API to work with, a low level 3d API should be available in a browser. It could be used as a building block to create frameworks and engines that are easy to use. Even WebGL is "too low level" for most application developers, which is why three.js and other frameworks are popular.
- flohofwoe 10y ago
  Yes there are also valid points for having an really low level 3D-API like a WebVulkan in the browser, and the 'big-engine-makers' seem to be fond of this idea. But I see this more in the realm of a 'compilation target', more for WebAssembly then JS. Translating Vulkan 1:1 to D3D12 or even Metal would be challenging though, I think most of the advantages of having a real bare-metal API would be lost in this translation-layer I guess.
  - grovesNL 10y ago
    The Altai example is great but they can already be implemented in JavaScript with very low overhead. If the performance is a concern then we should be moving more towards lower level APIs such as Vulkan, and let JS libraries implement their own API on top of that when that extra performance is needed. There is also the possibility that performance improvements to WebGL could always be made (i.e. supporting command queues or SPIR-V).
    - flohofwoe 10y ago
      I think that Metal / WebGPU is just at the right abstraction level for a modern 3D API. It's like a successor to D3D11 (which is a mighty fine 3D-API). Vulkan and D3D12 are really not a lot of fun to work with. I'd rather maintain an thin API wrapper on top of 3 different 3D-APIs at the complexity level of D3D11 or Metal, instead of having to maintain a single wrapper for D3D12 or Vulkan (and you need to support multiple 3D APIs anyway, since none of them exists on all relevant platforms). But that is strictly IMHO, I guess there's also people who enjoy working in D3D12 or Vulkan ;)
      - exDM69 10y ago
        The problem with the WebGpu proposal is that it is difficult to implement with Vulkan efficiently as the spec is now. I'm sure the spec can still be changed to be a better fit, though.
- cwyers 10y ago
  It's not about being too low-level for developers, it's about it being too low-level for implementation. Vulkan is lower level than DX12 or Metal; you can't implement it on top of those platform APIs, like ANGLE runs OpenGL ES on top of a compatibility shim over DirectX or desktop OpenGL. A cross-platform graphics API in the browser needs to be high-enough level to abstract over all of Vulkan/DX12/Metal and provide a consistent interface so that developers don't have to know which one their application is running on. Either that, or in addition to WebVulkan you need WebDX12 and WebMetal.
  - erichocean 10y ago
    > you can't implement [Vulkan] on top of [DX12 or Metal] http://lmgtfy.com/?q=vulkan+metal http://lmgtfy.com/?q=vulkan+metal First result: "MoltenVK is an implementation of Vulkan that runs on Apple's Metal graphics framework on iOS and macOS."

pjmlp 10y ago

You can already do that, that is the whole point of a game engine, to abstract way the underlying platforms, while providing higher level tooling. Also a reason, why outside communities like HN, most game developers don't really care about API wars.

rubber_duck 10y ago

>Security issues aside I don't think you can really put those aside - that's the whole point of web as a platform - that visiting a link won't let you take over my PC (and that's hard enough as is in practice). Just use native apps if you want native access.