Live data from Hacker News

Wgpu-0.10 released: WebGPU implementation now in pure Rust

gfx-rs.github.io

81–86 of 86 posts

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

#81
post #56

Earlier quoted context omitted.

You’ve made like 15 comments on this thread with this idea. Cart is intent on sticking to his approach even after listening to your point of view. I feel like we could just put this conversation on ice and check back in after 6-12 months. Bevy release notes always reach the top of HN. If they go back to creating an abstraction over wgpu, you can say “I told you so” then. And similarly, if Bevy is able to use this app…

> You’ve made like 15 comments on this thread with this idea. Yet other people beside Cart in my thread still fail to properly understand the idea and instead think I am suggesting not using wgpu at all. > you can say “I told you so” then My aim isn’t to say “I told you so” it’s to make sure people accurately understand the point I am making. Cart seems to understand the point I am making therefore I have made no fur…

I understand your point, but I don’t think there’s any value in including an extra layer of abstraction before you need it. Sometimes it’s clear that you need it from the start. But sometimes it’s not.

And if you end up needing to support something sufficiently different from what can fit into wgpu’s API, the right point of indirection might just be the rendering system. E.g., you might just write a separate renderer for the new platform, so you can write to its model in the most efficient way.

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

#82
post #6

Earlier quoted context omitted.

Yup wgpu has a WebGPU backend, but it also has first-class native backends for Vulkan, Metal, DX12, and OpenGL ES (with upcoming support for DX11 and WebGL). It is designed to be a cross platform graphics API. It isn't "web based", just "web compatible". And it has super solid "feature detection" that enables you to opt in to "native only" features like push constants.

So then why is this being advertised as a WebGPU implementation if it isn't the focus? The title is misleading in that case and instead should just be titled Graphics implementation now in pure Rust.

WebGPU is a specification for safe, efficient, cross-platform access to the GPU. It is intended to provide a small set of core primitives that are widely implementable without compromising safety or performance: attention is paid to both use from many client platforms (such as Rust, C, JavaScript, and WASM) and to implementation on many graphics backends (not only in terms of Metal / DirectX 11/12 / Vulkan / OpenGL drivers, but also in terms of trying to choose core features that are actually implemented on things like mobile GPUs, which are often left out of powerful modern graphics abstractions).

wgpu-rs is an end-to-end implementation of that spec, for a Rust frontend and many backends. It is designed so that the same code can be used on the web (via WASM) or on native, with no changes to the implementation; however, you can happily ignore the WASM compilation target and just use it natively. It also includes some extensions for widely supported features that aren't available on all GPUs, that you can request if you are willing to restrict the platforms you run on (this is especially helpful on native).

As you can see, the fact that it implements the WebGPU spec is very relevant because it inherits all the nice properties of the spec (efficiency, safety, and portability), as well as because there is a specification that you can refer back to in order to figure out (mostly) what the behavior is supposed to be. There is nothing misleading going on here about saying it's a WebGPU implementation. If there's anything misleading, it's probably the name of the spec (but that ship has long since sailed).

The other two major components of the system are:

* wgpu-core. A cross-platform, safe, efficient, pure-Rust implementation that is used by wgpu-rs, but does not actually implement the full WebGPU spec, and is not really designed for ease of use. It is mostly intended as the basis of other implementations of WebGPU frontends, such as wgpu-rs, wgpu-native (C bindings), and implementations of backends in larger systems like Deno and Servo.

* wgpu-hal. A cross-platform, efficient, unsafe, pure-Rust implementation that primarily exists to abstract away differences between platforms targeted by wgpu-core. The lack of attention to safety means it can often approach or match the performance of the native drivers, but also makes it extremely hard to use, and the exposed API is very closely tied to whatever wgpu-core needs (this is a big difference between it and the older gfx-hal, which was intended to a broader unsafe abstraction layer for independent use).

These two systems are not as cleanly tied to WebGPU, but they are still primarily intended for use by clients that implement the WebGPU spec. That said, this is not a requirement--there are a few other abstractions built directly on top of wgpu-core or wgpu-hal, and they do not consider themselves as WebGPU implementations (because they aren't!).

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

#83
post #29

Earlier quoted context omitted.

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 a…

Since other commenter had concerns about the PS4/PS5/other consoles wgpu being proprietary due to SDK restrictions (and consequently, Bevy PS4/PS5/other consoles port being proprietary), I will ask: does this mean that Bevy for consoles will cost money? (apart from the console SDK cost). Will Bevy for consoles be source available, as in, developed exactly like current Bevy but under a non-open source license? Or actu…

We will need to restrict access to console backends to comply with console developer contracts. We would only be able to give our code to other people who have been approved to look at the "proprietary console code".

That being said, there isn't a requirement to charge for the code. Kha (another open source project much like wgpu) offers free console support. You just need to reach out to them and request access. I would like to follow their model if I can. But it all really depends on who does the work and the terms they decide to release it under.

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

#84

I first thought wgpu was WebGPU, i googled and it is not https://www.w3.org/TR/webgpu/ Naming is important, you want to avoid confusing as much as possible

wgpu is an implementation of WebGPU.

that's exactly what i am saying, they want to confuse people

why deny

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

#85

Earlier quoted context omitted.

wgpu is an implementation of WebGPU.

that's exactly what i am saying, they want to confuse people why deny

Where on earth do you get "they want to confuse people"?

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

#86
post #63
post #31

I've been using the previous version for months. Underneath Rend3, which handles some of the queuing and threading issues for Wgpu. Not for a web client; for complex 3D content on Linux. It's working well. With the new version, I should be able to cross-compile Rust to Windows as well as Linux, and generate a Windows executable without having to use any Microsoft products.

What's your current opinion on Rust viz-a-viz Go? I remember that you had a few complaints about Rust.. I wonder if that has changed? :)

Long subject. Short version: for server-side webcrap, use Go. All the standard parts needed for that are in good shape. For complicated stuff with real-time or graphics aspects, use Rust.
Post reply on HN