Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mapr: Native cross platform maps in Rust using WebGPU

github.com

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Mapr: Native cross platform maps in Rust using WebGPU

#21

Post by ben-schaaf »

pcwalton wrote: post #10

I find it interesting that the Web platform ended up being the catalyst to finally get all the OS and GPU vendors to sit down and write a single interoperable API. The existence of wgpu is a very nice outcome for all graphics programmers, even those who don't work on the Web.

Considering it's a web API for JavaScript, not something provided by the OS/drivers, WebGPU is hardly any different to WebGL. It still requires the native OpenGL/Vulkan/Metal/DirectX APIs to be built on top of. As such it really hasn't moved the needle whatsoever in regards to API interoperability, only provided yet another cross-platform abstraction (at least outside the web).

Re: Mapr: Native cross platform maps in Rust using WebGPU

#22

Post by capableweb »

nxrabl wrote: post #14
chimen wrote: post #11

Quoted post unavailable.

Here, stick this in your uBlock config: news.ycombinator.com##.athing:has-text(in Rust) news.ycombinator.com##.athing:has-text(in Rust) + tr news.ycombinator.com##.athing:has-text(in Rust) + tr + tr

Doesn't this filter the submission itself, hiding the story completely? Rather than just hiding the "In Rust" part of the titles.

Re: Mapr: Native cross platform maps in Rust using WebGPU

#24

Post by Jweb_Guru »

ben-schaaf wrote: post #21
pcwalton wrote: post #10

I find it interesting that the Web platform ended up being the catalyst to finally get all the OS and GPU vendors to sit down and write a single interoperable API. The existence of wgpu is a very nice outcome for all graphics programmers, even those who don't work on the Web.

Considering it's a web API for JavaScript, not something provided by the OS/drivers, WebGPU is hardly any different to WebGL. It still requires the native OpenGL/Vulkan/Metal/DirectX APIs to be built on top of. As such it really hasn't moved the needle whatsoever in regards to API interoperability, only provided yet another cross-platform abstraction (at least outside the web).

From an operational standpoint, however, WebGPU is a much better fit for Vulkan/Metal/DirectX than OpenGL is, since it (mostly) exposes abstractions that all three actually support efficiently (and more generally, was designed with modern GPUs in mind, so unless GPU design fundamentally changes it's unlikely that it will require doubling or tripling the API surface to keep up, unlike OpenGL). That represents a pretty significant improvement over OpenGL (particularly the older versions of OpenGL that you have to use if you actually care about portability), and also over solutions like MoltenVK (it's hard to efficiently implement a lower-level API on top of a higher-level one).

This doesn't invalidate your point, I just think when you say "yet another cross-platform abstraction" you're implying that this is an xkcd "now there are 15 standards" situation, when in reality the competition is basically just ancient versions of OpenGL. And OpenGL is effectively deprecated--Khronos has no plans to release any more major updates. Unfortunately, without the browser usecase bringing many of the stakeholders on board, there is not a lot of money in this kind of work, which is why there aren't any serious competitors.

Re: Mapr: Native cross platform maps in Rust using WebGPU

#26

Post by jokethrowaway »

pcwalton wrote: post #10

I find it interesting that the Web platform ended up being the catalyst to finally get all the OS and GPU vendors to sit down and write a single interoperable API. The existence of wgpu is a very nice outcome for all graphics programmers, even those who don't work on the Web.

This didn't happen.

The rust community needed a cross-platform layer and built it.

Re: Mapr: Native cross platform maps in Rust using WebGPU

#27

Post by dmitriid »

Jweb_Guru wrote: post #24
ben-schaaf wrote: post #21

Earlier quoted context omitted.

Considering it's a web API for JavaScript, not something provided by the OS/drivers, WebGPU is hardly any different to WebGL. It still requires the native OpenGL/Vulkan/Metal/DirectX APIs to be built on top of. As such it really hasn't moved the needle whatsoever in regards to API interoperability, only provided yet another cross-platform abstraction (at least outside the web).

From an operational standpoint, however, WebGPU is a much better fit for Vulkan/Metal/DirectX than OpenGL is, since it (mostly) exposes abstractions that all three actually support efficiently (and more generally, was designed with modern GPUs in mind, so unless GPU design fundamentally changes it's unlikely that it will require doubling or tripling the API surface to keep up, unlike OpenGL). That represents a pretty…

It is xkcd though.

WebGPU as proposed by Apple was basically Metal. Naturally other vendors weren't keen on implementing this, so they arrived at a compromise which is a bastard child of Metal and Vulkan.

They couldn't even adopt an existing shader language and invented a new one. That goes as far as invent new and unprecedented language constructs https://github.com/gpuweb/gpuweb/issues/569

Re: Mapr: Native cross platform maps in Rust using WebGPU

#28

Post by adamnemecek »

pjmlp wrote: post #20
adamnemecek wrote: post #15

Earlier quoted context omitted.

It makes sense. The standardization effort is pretty involved, I don’t know what besides the Web would have been able to twist their arms into doing it.

Except the end result are fossilized 3D APIs. WebGL 2.0 is a subset of OpenGL ES 3.0, meaning 2011 mobile GPUs. WebGPU 1.0 is a subset of Vulkan/Metal/DX 12, meaning 2016 GPUs. And on top, you get a new C++/Rust flavoured shading language, throwing away all shaders created for WebGL. If you want top graphics on the Web, the answer is surprise, surprise, server side rendering to textures with native 3D APIs alongside…

How would the api be different if it was targeting 2022 gpus?

Re: Mapr: Native cross platform maps in Rust using WebGPU

#29

Post by pjmlp »

adamnemecek wrote: post #28
pjmlp wrote: post #20

Earlier quoted context omitted.

Except the end result are fossilized 3D APIs. WebGL 2.0 is a subset of OpenGL ES 3.0, meaning 2011 mobile GPUs. WebGPU 1.0 is a subset of Vulkan/Metal/DX 12, meaning 2016 GPUs. And on top, you get a new C++/Rust flavoured shading language, throwing away all shaders created for WebGL. If you want top graphics on the Web, the answer is surprise, surprise, server side rendering to textures with native 3D APIs alongside…

How would the api be different if it was targeting 2022 gpus?

It would be exposing stuff like ray tracing and mesh shaders for example.

Or having a shading language with C++ like capabilities.

WebGL still cannot do compute or geometry shaders, for example. Nor it will ever be able to do them.

Re: Mapr: Native cross platform maps in Rust using WebGPU

#30

Post by Jweb_Guru »

dmitriid wrote: post #27
Jweb_Guru wrote: post #24

Earlier quoted context omitted.

From an operational standpoint, however, WebGPU is a much better fit for Vulkan/Metal/DirectX than OpenGL is, since it (mostly) exposes abstractions that all three actually support efficiently (and more generally, was designed with modern GPUs in mind, so unless GPU design fundamentally changes it's unlikely that it will require doubling or tripling the API surface to keep up, unlike OpenGL). That represents a pretty…

It is xkcd though. WebGPU as proposed by Apple was basically Metal. Naturally other vendors weren't keen on implementing this, so they arrived at a compromise which is a bastard child of Metal and Vulkan. They couldn't even adopt an existing shader language and invented a new one. That goes as far as invent new and unprecedented language constructs https://github.com/gpuweb/gpuweb/issues/569

Shader language squabbles and throwaway accusations aside (for my own purposes I don't really care about WGSL, since there are transpilers back and forth to other shader languages for native use, but loop/continue is not exactly an example of some crazy unprecedented language construct), Metal isn't a cross-platform standard of any sort. It pretty much explicitly exists so Apple can control it (it would be nice if it was Metal-on-Vulkan instead, but I think that ship has sailed). I don't really see how the existence of Metal is a relevant example of what I'm talking about: a portable modern graphics abstraction that is efficient on modern hardware. It's just not true that there are a bunch of those out there, when you're talking about production-quality stuff there's basically just WebGPU.

Even if your argument was that Vulkan was supposed to be that standard (which it isn't in practice), Vulkan is pretty much impossible to use safely without building a higher-level abstraction on top. It was desperately in need of a standard higher level API that programmers with limited resources (i.e. not Epic, browser vendors, etc.), or programmers who need to run in sandboxed environments (mostly browsers) can reasonably target, and I think WebGPU serves that purpose nicely. Exposing Vulkan (or DirectX 12, or any similarly low-level API) directly to browsers would have been pretty much a non-starter from a memory safety perspective, WebGPU does not exist solely because Apple didn't like Vulkan.

Post reply on HN