Hacker News new | ask | show | jobs
by giornogiovanna 2332 days ago
> So WebGPU with SPIR-V will work in Apple's browsers

Yes, I think the idea is to embed a SPIRV-to-Metal compiler inside the browser.

At least, that's what it looks like https://github.com/gfx-rs/wgpu is doing right now.
1 comments
shmerl 2332 days ago
So Apple agreed after all? They were resisting it in the past.
link
giornogiovanna 2332 days ago
Never mind, I have no idea what Apple is doing. It looks like they're inventing yet another shading language.

https://webkit.org/blog/9528/webgpu-and-wsl-in-safari/

link
shmerl 2331 days ago
That's what I thought. They still want to sabotage SPIR-V usage in the browser.
link
pjmlp 2330 days ago
Yeah, that is why the only working WebGPU implementation for Chrome, from Google, only works on the Mac and Windows platforms, using Metal and DirectX, your favourite APIs.
link
giornogiovanna 2330 days ago
I'm getting some serious déjà vu here.

Anyway, pjmlp, if you have some time, could you please explain how WSL makes sense in a world where SPIR-V already exists?

Both are intended mainly to be compiler targets, and both will need verifiers for use in WebGPU. The main advantages of SPIR-V are that some tooling already exists (as opposed to none), most of the specification is already done, and it will end up being faster with Vulkan. The only advantage I've seen for WSL is that it's text-based, so you can cut and paste pieces of code together more easily. I don't know how that would even fit in with the idea that WSL is meant to be a compiler target, though.

link
pjmlp 2330 days ago
WSL also has some tooling, in Safari.

Given that Vulkan is only a viable option on post Android 10 devices, Linux and unsandboxed Win32 apps, being faster with Vulkan is a relative merit.

Now, if SPIR-V is part of the browser and does not require to bundle a JIT compiler, as apparently has been discussed then great.

Then again, maybe some tooling besides shaderc would be welcomed.

link