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

51–60 of 86 posts

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

#51

Post by Jasper_ »

CyberRabbi wrote: post #48
epage wrote: post #34

Earlier quoted context omitted.

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.

What you can do is design a backend for your project that is less general and tailored to your specific problems so as to increase the likelihood that it is easier to implement on new platforms that may arise. This is why I mentioned the “rule of least power” For example using drawTriangle(p1, p2, p3) instead of drawPolys(TYPE_TRIANGLE, point_list, n_points). The former is unequivocally easier to implement, the latte…

I know you don't really want to hedge too much on your example, but do note that in your attempt to simplify, you accidentally turned an API which can, in theory, draw many triangles into one that only can draw one triangle at a time. What if I want to parallelize the work of drawing triangles?

Trying to aggressively simplify without understanding the full design space or surface area is not really a great idea.

In the worst case, if you never use, for instance, Timestamp Queries in your engine, you can half-ass a backend and just nop the implementation. Lots of game engines do that kinda thing. So many game engines where half the graphics API implementations were no-op stubs because we never needed the functionality on that platform.

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

#52

Post by CyberRabbi »

dralley wrote: post #49
CyberRabbi wrote: post #48

Earlier quoted context omitted.

What you can do is design a backend for your project that is less general and tailored to your specific problems so as to increase the likelihood that it is easier to implement on new platforms that may arise. This is why I mentioned the “rule of least power” For example using drawTriangle(p1, p2, p3) instead of drawPolys(TYPE_TRIANGLE, point_list, n_points). The former is unequivocally easier to implement, the latte…

And it has been explained to you repeatedly that wgpu is already more or less "least power" - that Bevy already uses most of the API surface and will soon be using nearly all of it.

Wgpu is the equivalent of “Turing complete” for a graphics API. I think you’re not fully groking the principle of least power if you consider that a “least power” graphics abstraction.

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

#53

Post by CyberRabbi »

Jasper_ wrote: post #51
CyberRabbi wrote: post #48

Earlier quoted context omitted.

What you can do is design a backend for your project that is less general and tailored to your specific problems so as to increase the likelihood that it is easier to implement on new platforms that may arise. This is why I mentioned the “rule of least power” For example using drawTriangle(p1, p2, p3) instead of drawPolys(TYPE_TRIANGLE, point_list, n_points). The former is unequivocally easier to implement, the latte…

I know you don't really want to hedge too much on your example, but do note that in your attempt to simplify, you accidentally turned an API which can, in theory, draw many triangles into one that only can draw one triangle at a time. What if I want to parallelize the work of drawing triangles? Trying to aggressively simplify without understanding the full design space or surface area is not really a great idea. In t…

> What if I want to parallelize the work of drawing triangles?

What if your specific application cannot provide inherently parallel workloads and has no need for an abstraction that can accommodate parallel rendering? In that case porting your app to a new platform requires implementing functionality your application does not need.

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

#55

Post by danShumway »

CyberRabbi wrote: post #53
Jasper_ wrote: post #51

Earlier quoted context omitted.

I know you don't really want to hedge too much on your example, but do note that in your attempt to simplify, you accidentally turned an API which can, in theory, draw many triangles into one that only can draw one triangle at a time. What if I want to parallelize the work of drawing triangles? Trying to aggressively simplify without understanding the full design space or surface area is not really a great idea. In t…

> What if I want to parallelize the work of drawing triangles? What if your specific application cannot provide inherently parallel workloads and has no need for an abstraction that can accommodate parallel rendering? In that case porting your app to a new platform requires implementing functionality your application does not need.

> What if your specific application cannot provide inherently parallel workloads and has no need for an abstraction that can accommodate parallel rendering?

Okay, but... what if it does?

It's one thing to talk about "this could be simpler if you don't need more general functionality." But that's also just kind of an assumption that the functionality actually isn't needed. The odds that you have to support a platform/application that both can't handle parallelization and that will be substantially held back by the option even just existing -- I'm not sure that those odds are actually higher than the odds that you'll run into a platform that requires parallelization for decent performance.

It feels kind of glib to just state with such certainty that a cross-platform game engine is never going to need to draw arbitrary polygons. That doesn't seem to me like a safe assumption at all.

I agree with GP here:

> Trying to aggressively simplify without understanding the full design space or surface area is not really a great idea.

In many cases, needing to no-op some functionality for one or two platforms may end up being a lot better than a situation where you need to hack a bunch of functionality on top of an API that fundamentally is not designed to support that. It's a little bit annoying for simpler platforms, but simpler platforms are probably not your biggest fear when thinking about support. The first time that you need to do something other than linearly draw triangles, for any platform you want to support at all, even just one of them, then the API you propose suddenly becomes more complicated and harder to maintain than a single `drawPols` method would be.

This is not saying that abstraction or narrowing design space should never happen. It's just saying, understand what the design space is before you decide that you're never going to need to support something. I expect that the Bevy core team has spent a decent amount of time thinking about what kinds of GPU operations they're likely to need for both current and future platforms.

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

#56

Post by nindalf »

CyberRabbi wrote: post #32
Jweb_Guru wrote: post #30

Earlier quoted context omitted.

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

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 approach to provide support for Android, iOS and web (in addition to existing support for windows, Linux and Mac) then you need to own up to that.

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

#57

Post by gfxgirl »

_cart wrote: post #29
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…

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…

I think wgpu is amazing. But, if I want to take the previous commenter seriously I'd think about PS5, Switch/Switch2, etc as places where someone will have to write a wgpu implementation (non open source since those SDKs don't allow it) if you ever decide to ship on those platforms.

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

#58

Post by gfxgirl »

devwastaken wrote: post #10

Does 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.

That's arguably not wgpu's responsibility. It's usually the OS's. Windows will reset the GPU if it doesn't return. Chrome tries to catch it before the OS IIRC.

In any case, other than resetting the GPU there is no way to stop DOS via shaders. I can easily write a 3 line shader that has a legit use at 1x1 pixels but will DOS your machine at 2000x2000 pixels. It's basically the halting problem. The only known solutions are (a) reset the GPU or (b) design preemptable GPUs

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

#60

Post by nextaccountic »

_cart wrote: post #29
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…

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 actually: is it feasible to license console-specific Bevy code as MIT/Apache and have the only proprietary bits be the console SDK? (This means having Bevy, an open source project, call a console SDK in the open - is that allowed?)

For me those are my main concerns regarding Bevy.

Post reply on HN