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

Wgpu-0.10 released: WebGPU implementation now in pure Rust

gfx-rs.github.io

Post reply on HN
Print view View original

21–30 of 86 posts

Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust

#21

Post by kvark »

CyberRabbi wrote: post #19
_cart wrote: post #15

Earlier quoted context omitted.

Snarky answer first: my experience tells me that I won't regret this decision :) Real answer: You can use this argument to justify abstracting out literally anything. Clearly we shouldn't abstract everything and the details of each specific situation will dictate what abstractions are best (and who should own them). Based on the context that I have, Bevy's specific situation will almost certainly benefit from this de…

A situation will inevitably arise where you’ll be unable to support a new platform in a reasonable amount of time because implementing support for that platform yourself in wgpu would be a significant undertaking and/or distraction. Progress from the community on supporting that platform in wgpu will lag because either you might be the only stakeholder interested in that platform and/or modifying wgpu to support that…

> The core issue is that bevy uses a subset of wgpu so your own focused and limited abstraction layer will almost always be easier to implement and maintain

This isn't obviously true. WebGPU API surface is fairly small (unlike Vulkan), and Bevy may easily use most of it.

Generally speaking, depending on another library always involve some amount of trust. Going the path of zero trust is also possible, but is much less effective.

Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust

#22

Post by Jasper_ »

CyberRabbi wrote: post #19
_cart wrote: post #15

Earlier quoted context omitted.

Snarky answer first: my experience tells me that I won't regret this decision :) Real answer: You can use this argument to justify abstracting out literally anything. Clearly we shouldn't abstract everything and the details of each specific situation will dictate what abstractions are best (and who should own them). Based on the context that I have, Bevy's specific situation will almost certainly benefit from this de…

A situation will inevitably arise where you’ll be unable to support a new platform in a reasonable amount of time because implementing support for that platform yourself in wgpu would be a significant undertaking and/or distraction. Progress from the community on supporting that platform in wgpu will lag because either you might be the only stakeholder interested in that platform and/or modifying wgpu to support that…

As someone who's developed and maintained platform backends for all sorts of obscure platforms (actually, it's still my day job!), I don't think wgpu backends are going to be difficult to develop for any of the remaining platforms APIs still alive.

It's a pretty well-thought-out API that mirrors most of the modern rendering abstractions seen in game engines.

Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust

#23

Post by kvark »

danielvaughn wrote: post #14

So I'm familiar with WebGPU, but I'm not really sure why there would be a native (non-web) implementation of it. What are the practical uses of this, as opposed to just using something like Vulkan?

See prior discussion: https://news.ycombinator.com/item?id=23079200

Includes a link to the relevant Fosdem talk;)

Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust

#24

Post by CyberRabbi »

kvark wrote: post #21
CyberRabbi wrote: post #19

Earlier quoted context omitted.

A situation will inevitably arise where you’ll be unable to support a new platform in a reasonable amount of time because implementing support for that platform yourself in wgpu would be a significant undertaking and/or distraction. Progress from the community on supporting that platform in wgpu will lag because either you might be the only stakeholder interested in that platform and/or modifying wgpu to support that…

> The core issue is that bevy uses a subset of wgpu so your own focused and limited abstraction layer will almost always be easier to implement and maintain This isn't obviously true. WebGPU API surface is fairly small (unlike Vulkan), and Bevy may easily use most of it. Generally speaking, depending on another library always involve some amount of trust. Going the path of zero trust is also possible, but is much les…

> This isn't obviously true. WebGPU API surface is fairly small (unlike Vulkan), and Bevy may easily use most of it.

Small is not the issue. Generality is.

Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust

#25

Post by user-the-name »

danielvaughn wrote: post #14

So I'm familiar with WebGPU, but I'm not really sure why there would be a native (non-web) implementation of it. What are the practical uses of this, as opposed to just using something like Vulkan?

An API that is more usable than Vulkan, a better fit for modern hardware and faster than OpenGL, and that runs on top of already existing and well-supported platform APIs.

Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust

#28

Post by CyberRabbi »

Jasper_ wrote: post #22
CyberRabbi wrote: post #19

Earlier quoted context omitted.

A situation will inevitably arise where you’ll be unable to support a new platform in a reasonable amount of time because implementing support for that platform yourself in wgpu would be a significant undertaking and/or distraction. Progress from the community on supporting that platform in wgpu will lag because either you might be the only stakeholder interested in that platform and/or modifying wgpu to support that…

As someone who's developed and maintained platform backends for all sorts of obscure platforms (actually, it's still my day job!), I don't think wgpu backends are going to be difficult to develop for any of the remaining platforms APIs still alive. It's a pretty well-thought-out API that mirrors most of the modern rendering abstractions seen in game engines.

> platforms APIs still alive.

The APIs that currently exist are not the cause of the potential issue I am raising.

Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust

#29

Post by _cart »

CyberRabbi wrote: post #19
_cart wrote: post #15

Earlier quoted context omitted.

Snarky answer first: my experience tells me that I won't regret this decision :) Real answer: You can use this argument to justify abstracting out literally anything. Clearly we shouldn't abstract everything and the details of each specific situation will dictate what abstractions are best (and who should own them). Based on the context that I have, Bevy's specific situation will almost certainly benefit from this de…

A situation will inevitably arise where you’ll be unable to support a new platform in a reasonable amount of time because implementing support for that platform yourself in wgpu would be a significant undertaking and/or distraction. Progress from the community on supporting that platform in wgpu will lag because either you might be the only stakeholder interested in that platform and/or modifying wgpu to support that…

Adding new "backends" to an abstraction always includes the risk of not being compatible with the current abstraction and requiring re-architectures. This would be true with our own abstractions as well. I agree that two separate projects often have different goals, but wgpu's goals are an (almost) complete subset of our goals: cross platform modern gpu layer that cleanly abstracts Vulkan/Metal/DX12 and best-effort abstracts older apis, rust-friendly api surface with RAII, limited "lowest common denominator" defaults that run everywhere with opt-in support for advanced features and lifting lowest-common-denominator limits. The biggest divergence is their increased need for safety features to make wgpu a suitable host for WebGPU apis in browsers, but this is something that still benefits us, because it might ultimately allow Bevy apps to "host" less trusted shader code.

We've been building out the new renderer and we have already used a huge percentage of wgpu's api surface. It will be close to 100% by the time we launch. This proves to me that we do need almost all of the features they provide. Bevy's renderer is modular and we need to expose a generic (and safe) gpu api to empower users to build new render features. Wgpu's entire purpose is to be that API. I know enough of the details here (because I built my own api, thoroughly reviewed the wgpu code, and did the same for alternatives in the ecosystem) to feel comfortable betting on it. I'm even more comfortable having reviewed bevy-user-provided wgpu prs that add major new features to wgpu (XR). If you have specific concerns about specific features, I'm happy to discuss this further.

You can link to as many "rules" as you want, but solving a problem in the real world requires a careful balance of many variables and concerns. Rules like "the rule of least power" should be a guiding principle, not something to be followed at all costs.

Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust

#30

Post by Jweb_Guru »

CyberRabbi wrote: post #24
kvark wrote: post #21

Earlier quoted context omitted.

> The core issue is that bevy uses a subset of wgpu so your own focused and limited abstraction layer will almost always be easier to implement and maintain This isn't obviously true. WebGPU API surface is fairly small (unlike Vulkan), and Bevy may easily use most of it. Generally speaking, depending on another library always involve some amount of trust. Going the path of zero trust is also possible, but is much les…

> This isn't obviously true. WebGPU API surface is fairly small (unlike Vulkan), and Bevy may easily use most of it. Small is not the issue. Generality is.

Keep in mind that wgpu is intended to be something you can write a game engine in and achieve at least comparable performance to going through something like Vulkan directly. The WebGPU API is intended to be optimizable enough that even low-level applications don't need to reach for their own solutions, and the WebGPU team have worked very hard to find universal and efficient abstractions over the underlying drivers. It also provides unsafe opt-out functionality for cases where the goal of safety clashes too much with the performance needs of some applications (such as using precompiled shaders).

Given all this, what do you think is missing that makes it "too general" for use as the basis of a game engine? Many of the features you're probably thinking of are a nonstarter if you want to be cross-platform, and being efficient cross-platform is a key motivating reason to use wgpu in the first place.

Post reply on HN