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.
Wgpu-0.10 released: WebGPU implementation now in pure Rust
31–40 of 86 posts
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#32Earlier quoted context omitted.
> 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.…
> Given all this, what do you think is missing that makes it "too general" for use as the basis of a game engine?
My concern isn’t that wgpu’s level of generality makes it unsuitable for implementing a game engine. It’s of course perfectly suitable for implementing a game engine. The concern is around the pitfalls of not architecting your game engine in terms of your own limited graphics abstraction (which may backend to wgpu).
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#33So 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?
Then rust code using webgpu can compile to wasm. WebGPU does a bit of extra work to make it the safe to run code on the GPU from different domains. Also, Vulkan is not support on most platforms.
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#34Earlier quoted context omitted.
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.
And without knowing what those future APIs are like, you can't design a future-proof backend API to handle it. You'll design it for the past problems which will be different than future ones.
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#35So 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.
Ah nice, I see. Any particular reason for Rust being used? Just curious, because I would (naively) expect to see similar projects with Golang, C++ etc but I really only see Rust.
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#36Earlier quoted context omitted.
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.
There are only like 21 resource types in the whole WebGPU API. Which of these do you think are going to go away?
* Adapter, Device, Queue, Surface
* Buffer, Texture, TextureView, Sampler, QuerySet, BindGroup
* ShaderModule, BindGroupLayout, PipelineLayout, RenderPipeline, ComputePipeline
* CommandEncoder, RenderPassEncoder, ComputePassEncoder, RenderBundleEncoder, RenderBundle, CommandBuffer
Adapter, Device, and Surface are abstractions that would be needed no matter what the GPU architecture. What else is there that's even fishy... QuerySet, maybe? The various kinds of encoders are already abstractions on some platforms, and I guess there are cases where there might be better resource binding abstractions, but I'm not sure what could cause this set of supported features to change on the hardware other than completely dropping the rasterization pipeline (in which case you can just emulate everything with compute shaders and buffers anyway). And the relationships between these structures are pretty well-specified, I doubt that will change either.
So at that point, at least if you want to stay cross platform, you're talking about things like the specific implementation of buffer mapping or tracing or whatever, which is the sort of thing it's relatively easy to add as an extension (or refactor to make more configurable).
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#37WebGPU is going to be huge for Unity/Unreal browser games, and instrumental in architecting the open metaverse via the web.
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#38This 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!
Does wgpu finally support OpenGL?
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#39So 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?
It's cross-platform, safe, (reasonably) standardized, and fast (in roughly that order of priority). Even if you only care about the last three, there are not all that many competitors outside of maybe Metal, which is not the API what most people are thinking of when they say they don't care about working cross platform :P Vulkan emulation exists for some older machines, but it's generally slow and janky due to the impedence mismatch of trying to build a very low level API on top of a high level one.
Re: Wgpu-0.10 released: WebGPU implementation now in pure Rust
#40This 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!
Does wgpu finally support OpenGL?
Yeah, we support OpenGL ES-3.0 with a few major caveats.