Mapr: Native cross platform maps in Rust using WebGPU
github.com
github.com
It's not the prettiest, and writing the initial Javascript code is that I'm using as the template for adding data is kind of a pain, so possibly being able to write the entire application in native Rust would be really awesome.
Vector tiles are just much cooler! :D
You could look at storing them as a cloud optimised geotiff (COG) and then adding them directly into your web map.
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 data streaming.
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.
(BTW, the biggest reason stuff like wgpu-rs doesn't support geometry shaders on non-Metal is that they're horribly slow on a bunch of GPUs, with vendors indicating that they found it super hard to profitably support them in hardware. That's why Metal removed them entirely. I think all the features of geometry shaders that are actually reliably fast, as well as the stuff required to integrate with tessellation shaders, will almost certainly come eventually in other forms. This is an example of why if you care about performance and portability you shouldn't just dump every feature under the sun into your abstraction layer).
Yes it isn't quite the same thing, it is however a good example of what Web 3D APIs will never offer, not in 2022, or even in a decade.
Unreal 5 with Nanite doing pixel streaming via Azure Cloud Gaming, or WebGPU 1.0, I know which one I would rather play with.
Second, you're also talking about a game engine that does not portably expose ray tracing GPU features; stuff like Nanite that optimistically takes advantage of the hardware where it's available to accelerate ordinary software rasterization is not even close to the same thing. This is a really weak argument. The truth is that neither you, nor I, nor (right now) anyone else knows how to expose that hardware portably, it's all incredibly custom and will probably need big rewrites for each new hardware release. You're complaining about an API not doing something that nobody actually knows how to do yet.
Finally, not every application wants to or is able to be rendered in the cloud. It's incredibly expensive to rent out GPUs if you're not being subsidized, and in fact even most AAA attempts haven't worked out economically. Plus not every application can deal with the server latency, or wants to be beholden to an always-online server, or has clients who can tolerate the bandwidth required, or a myriad of other things. So that isn't a solution to a portable low-level graphics API either.
I'm not saying WebGPU is perfect, but driveby comments like yours that imply it's missing obvious stuff or handicapped or whatever are pretty annoying. It's a very good attempt at a very difficult goal (efficient, portable, low-level graphics) that has value to a lot of people. It isn't going to be everything to everybody (and neither is UE5, incidentally). When there is a portable way to expose raytracing functionality I have no doubt it will come to WebGPU, but until then it's basically a meaningless gotcha.
Some Rust folks are pushing to run WebGPU outside of the browser, that is all.
Native OS 3D APIs are the same business as always.
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.
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
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.
You argued that this isn't the xkcd situation.... and proceeded to literally describe "Situation: There are now 15 standards". But sure, you don't care because "transpilers exist". I wish people cared.
> WebGPU does not exist solely because Apple didn't like Vulkan.
Apple released first version Metal before Vulkan was even a thing on anyone's radar:
- Metal release date: June 2014.
- The Khronos Group began a project to create a next generation graphics API in July 2014
But sure, "Apple doesn't like Vulkan".
And the whole "WebGPU does not exist solely because Apple didn't like Vulkan" is a sentence that has literally zero sense. Pre-WebGPU prototype was literaly proposed as a joint effort by Apple and Mozilla, and it was Apple's idea to create a working group to work on the new graphics API.
The rust community needed a cross-platform layer and built it.
badass, perfect. get that hardware cranking! another very excellent use for wgpu!
Mapr seems to be really great if you want to use the same framework for each platform you're building for