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

31–37 of 37 posts

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

#31

Post by Jweb_Guru »

pjmlp wrote: post #29
adamnemecek wrote: post #28

Earlier quoted context omitted.

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.

If you know of a way to portably expose ray tracing even on just the GPUs that actually support it, feel free to tell me (or anyone for that matter). AFAIK the problem of abstracting over the different stuff Nvidia and AMD call "ray tracing" is currently an open research problem. Of course you could respond that portability isn't important if you only care about delivering the best graphics you can on given hardware, but if you're really willing to write totally different pipelines for newer AMD cards, newer Nvidia cards, older cards, consoles, etc. you are probably not in the target audience for WebGPU.

(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).

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

#32

Post by pjmlp »

Jweb_Guru wrote: post #31
pjmlp wrote: post #29

Earlier quoted context omitted.

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.

If you know of a way to portably expose ray tracing even on just the GPUs that actually support it, feel free to tell me (or anyone for that matter). AFAIK the problem of abstracting over the different stuff Nvidia and AMD call "ray tracing" is currently an open research problem. Of course you could respond that portability isn't important if you only care about delivering the best graphics you can on given hardware,…

You can start by using Unreal 5 with Nanite.

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.

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

#33

Post by nxrabl »

capableweb wrote: post #22
nxrabl wrote: post #14

Earlier quoted context omitted.

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.

Yes, I think I misinterpreted the parent comment.

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

#34

Post by Jweb_Guru »

pjmlp wrote: post #32
Jweb_Guru wrote: post #31

Earlier quoted context omitted.

If you know of a way to portably expose ray tracing even on just the GPUs that actually support it, feel free to tell me (or anyone for that matter). AFAIK the problem of abstracting over the different stuff Nvidia and AMD call "ray tracing" is currently an open research problem. Of course you could respond that portability isn't important if you only care about delivering the best graphics you can on given hardware,…

You can start by using Unreal 5 with Nanite. 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.

First, you're talking about a full-fledged game engine (and one that's not actually free or usable by many projects, BTW!) by a huge team that can optimize individually for each platform (and doesn't actually support some platforms at all, e.g. Mac; you may not care about supporting such platforms, but that doesn't mean everyone can afford that luxury). I am talking about a portable low-level graphics API that smaller development teams can use to build their own stuff without needing to rewrite their pipelines for each new target platform.

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.

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

#35

Post by dmitriid »

Jweb_Guru wrote: post #30
dmitriid wrote: post #27

Earlier quoted context omitted.

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…

You're completely missing the point, aren't you?

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.

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

#36

Post by Jweb_Guru »

dmitriid wrote: post #35
Jweb_Guru wrote: post #30

Earlier quoted context omitted.

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…

You're completely missing the point, aren't you? 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 dat…

I don't think this is likely to be a productive conversation anymore, sorry.

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

#37

Post by blacha »

qchris wrote: post #3

Wow, I'm really excited for this! I'm actually currently rendering a MapLibre-based web map of some drone orthomosaics I've built on my personal site[1], which is using Rust on the backend to dynamically assemble the Javascript code running on the page for each new dataset. 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…

are your orthomosaics geo refernced?

You could look at storing them as a cloud optimised geotiff (COG) and then adding them directly into your web map.

Post reply on HN