Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Other browser vendors should adopt WebGPU only when Apple adopts Vulkan. Apple's stubbornness is the only reason why Khronos is even considering this "portable" low-level API with fewer features in the first place (even though Vulkan was supposed to be that portable API - again, thanks Apple!):

https://www.khronos.org/3dportability

In the meantime, Mozilla has proposed its own low-level web graphics API that the other browser vendors can back:

https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...



Yeah, Apple is trying to sidestep Khronos and go through W3C. I think the Khronos solution should succeed over the W3C one in this case. W3C doesn't seem to have a grasp of the power plays and politicking involved in the 3D graphics driver ecosystem.


We have all major browser vendors on board with discussing these things in the W3C's GPU for the Web Community Group, and we expect to end up with a final result based on multiple prototypes as inputs.

Submissions so far include:

Apple's WebGPU proposal: https://github.com/gpuweb/proposals/tree/master/WebGPU-Apple

Google's NXT proposal: https://github.com/gpuweb/nxt-chromium

We expect Mozilla to be submitting their proposal to gpuweb soon too.

Khronos only has two of four browser vendors on board. It remains to be seen what will happen, but I doubt it will lead to a cross-browser standard. Browsers are more relevant for web standards than 3d graphics drivers.


W3C do not have a grasp on politicking, period.

Just watch them rubberstamp a web spec for DRM...


Microsoft will never support Vulcan on the web either. For the same technical reason.

Vulcan cannot be implemented on top of DirectX12 or Metal.

So it's never going to happen.


> Microsoft will never support Vulcan

People said the same about WebGL. Today Microsoft is a member of Khronos.

Vulkan can be implemented on anything. It's just a matter of performance. And since Microsoft defines DirectX, they can add any features they need to improve the performance of a Vulkan implementation if they so choose.


In a way, Vulkan is already implemented on top of Metal (https://moltengl.com/moltenvk/). Porting it to DirectX12 should be a little easier.


What are the issues with Vulkan-on-DX12? Metal is missing geometry shaders and the tesselation shaders are kind of weird, plus GPU heap allocation is iOS only so I understand the difficulties there (although as kvark mentioned there is a decent Vulkan-on-Metal implementation for the rest of the API in the works). AFAIK DX12 has all of that.

Also Windows GPU drivers already support Vulkan (all the way back to the 600 series in Nvidia's case IIRC), so I don't see why that would be a technical deal breaker. And it definitely won't be a "political" deal breaker for Firefox or Chromium on Windows.


> Vulcan cannot be implemented on top of DirectX12 or Metal.

Ehh I don't believe this for a second; somewhat more correctly, "Vulcan may not be able to be efficiently implemented on top of other APIs."

I also believe that Apple has a vested interest in keeping Metal around, so of course they're going to push hard and fast for their standard...


Well yes, anything can be done, but doing it in a way that doesn't throw away all the potential gains of a low level api is hard.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: