> gfx-rs community’s goal is to make graphics programming in Rust easy, fast, and reliable. Yet one of their main projects involves reliance on the web for graphics programming. This is the opposite of their stated goal in my opinion.
[deleted]
Wgpu-0.10 released: WebGPU implementation now in pure Rust
11–20 of 86 posts
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#12This is great. I switched my renderer from OpenGL to wgpu for my engine and I cannot exaggerate how much better the error reporting is. Instead of "working incorrectly" or simply not working and providing a vague error code (like OpenGL), wgpu tells me exactly what I did wrong, which is a life saver. Also - types. Thanks wgpu team!
Ah yes, OpenGL's error reporting is notoriously bad. If you forget to call disable on a vertex attribute you might just get a random error 1282 (invalid operation) somewhere down the line in a totally irrelevant part of the code, lol.
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#13Can/will this be used in Firefox at some point?
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#14So 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?
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#15As Bevy Engine's lead developer (which uses wgpu), this release excites me for a number of reasons: * A smaller (and less abstracted) codebase means that we can more easily extend wgpu with the features we need now and in the future. (ex: XR, ray tracing, exposing raw backend apis). The barrier to entry is so much lower. * It shows that the wgpu team is receptive to our feedback. There was a point during our "new ren…
> This means that wgpu is no longer a "bevy_render backend". It is now bevy_render's core gpu abstraction. Experience has shown me that you will eventually regret this decision
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 decision. Bevy needs an "abstract gpu layer". We are currently maintaining our own (more limited) "abstract gpu layer" that lives on top of wgpu. Both my own experience and user experiences have indicated that this additional layer provides a worse experience: it is harder to maintain, harder to understand (by nature of being "another layer"), it lacks features, it adds overhead. Wgpu _is_ a generic abstraction layer fit for an engine. If I was building an abstract layer from scratch (with direct api backends), it would look a lot like wgpu. I understand the internals. I have a good relationship with the wgpu project lead. They respond to our needs. The second anything changes to make this situation suboptimal (they make massive api changes we don't like, they don't accept changes we need, they add dependencies we don't like, etc) I will happily fork the code and maintain it. I know the internals well enough to know that I couldn't do better and that I could maintain it if push comes to shove. The old Bevy abstraction layer adds nothing. In both situations we are free to extend our gpu abstraction with new features / backends. The only difference is the overall complexity of the system, which will be massively reduced by removing the intermediate layer.
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#16Does WebGPU protect against DOS via shaders, crashes, etc? Games like VRChat, where a user can just make shaders in Unity and have them ran on everyone elses computer - could really benefit from such a thing. There's an increase in games that are marketed as being able to create your own content that is displayed for other users in a game.
If there is too much GPU work thrown at a WebGPU implementation, the best it could do is terminate the logical device on timeout.
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#17So 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?
Cross platform. You could build a rust app with a WebGPU target that runs across web and native.
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#18Can/will this be used in Firefox at some point?
Yes, in fact in two different ways.
1. Firefox uses wgpu for implementing WebGPU. 2. Applications on wgpu can be compiled in wasm for the web and ran in Firefox Nightly.
This is harmed by the fact WebGPU API is still not stable. Hopefully, not for long!
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#19Earlier quoted context omitted.
> This means that wgpu is no longer a "bevy_render backend". It is now bevy_render's core gpu abstraction. Experience has shown me that you will eventually regret this decision
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 platform may require significant internal restructuring to support the platform in a non-hacky way or it would slow down or increase the complexity of the other main platforms. This is a hypothetical situation but it’s likely it will eventually happen.
Maintaining a fork of wgpu simply for your own project will also likely be more effort than necessary since wgpu is a more general API than bevy requires.
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. Some call this “the rule of least power” https://www.w3.org/2001/tag/doc/leastPower.html
The meta-core issue is that you and the wgpu team aren’t 100% aligned on your goals. Maybe you’re aligned on 80% but the 20% will eventually come back to haunt you.
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#20I first thought wgpu was WebGPU, i googled and it is not
Naming is important, you want to avoid confusing as much as possible