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

71–80 of 86 posts

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

#71

Post by CyberRabbi »

wtetzner wrote: post #70
CyberRabbi wrote: post #52

Earlier quoted context omitted.

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.

The thing about graphics in general is that typically you want to use whatever the underlying hardware gives you to get the best performance. This can conflict with the law of least power, but so what? You can’t optimize for everything, so you decide what tradeoffs make the most sense.

I think you and likely most people reading this discussion are missing the point. Wgpu is fine and even great as a general purpose API but it’s inappropriate as an application-specific abstraction for a graphics backend. It should absolutely be used to implement the latter.

Compare this to the Rust compiler. Rust uses MIR as its intermediate compiler IR for Rust-specific optimizations, because it retains Rust-specific semantics, before it compiles down to LLVM bitcode. If it used LLVM bitcode as its native IR then it would be difficult to implement Rust-specific optimization passes. In this case an application specific graphics API is analogous to MIR and wgpu is analogous to LLVM.

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

#72

Post by CyberRabbi »

danShumway wrote: post #55
CyberRabbi wrote: post #53

Earlier quoted context omitted.

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

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

It’s an example

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

#73

Post by kvark »

rhn_mk1 wrote: post #59
kvark wrote: post #40

Earlier quoted context omitted.

Yeah, we support OpenGL ES-3.0 with a few major caveats.

Is 3.0 a hard requirement, or can 2.0 also work?

We have to draw the line somewhere. ES 3.0 is already complicated, adding a number of "downlevel" features and limits. ES 2.0 would just be more work that we can't take right now.

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

#74

Post by CyberRabbi »

nindalf wrote: post #56
CyberRabbi wrote: post #32

Earlier quoted context omitted.

> 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 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 further comments to him.

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

#75

Post by kvark »

kangz wrote: post #68
kvark wrote: post #44

Earlier quoted context omitted.

For all we know, Safari on Windows(!) is going to use Dawn. But anything on Apple platforms isn't quite clear. They may get their own implementation.

I think you meant WebKit on Windows (used for other browsers than Safari). Once Dawn is integrated in WebKit for one OS, it should be easy to extend WebKit to use it on other OSes so maybe it will be a quick way to have WebGPU implemented in Safari?

Thanks for correcting! For a moment I started wondering if I exposed any confidential info here, phew!

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

#76

Post by CyberRabbi »

jokethrowaway wrote: post #66
CyberRabbi wrote: post #9

Earlier 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

That depends. I would agree if it were a dependency on third party closed source solution, but wgpu is a thriving and well maintained OSS project. Nothing prevents you from forking it and treating it like your own code in a catastrophic scenario.

> Nothing prevents you from forking it and treating it like your own code in a catastrophic scenario.

It’s much easier for deployment and distribution purposes to add a level of indirection in your codebase than maintain a fork of a large project. Maintaining a fork is a full time job in itself, especially for active projects where you’ll need to constantly be merging new changes and keeping up with the evolution of the internals of the project via the mailing list or other means.

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

#77

Post by Jweb_Guru »

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

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.

wgpu's recent license change was specifically done to allow these implementations to exist for consoles.

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

#78

Post by encryptluks2 »

_cart wrote: post #6
encryptluks2 wrote: post #2

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

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.

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

#79

Post by ComputerGuru »

adamnemecek wrote: post #50
ComputerGuru wrote: post #43

Earlier quoted context omitted.

That’s awesome. Wgpu did not support a single Linux machine I tried it on, all with various hardware/driver combos, back when OpenGL wasn’t available and later when it was first previewed. It was the only reason I used a different abstraction.

What abstraction did you use?

gfx/gfx_hal but that was before the complete pivot disguised as a series of updates that left anyone using it for its original purpose SOL.

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

#80

Post by wtetzner »

CyberRabbi wrote: post #71
wtetzner wrote: post #70

Earlier quoted context omitted.

The thing about graphics in general is that typically you want to use whatever the underlying hardware gives you to get the best performance. This can conflict with the law of least power, but so what? You can’t optimize for everything, so you decide what tradeoffs make the most sense.

I think you and likely most people reading this discussion are missing the point. Wgpu is fine and even great as a general purpose API but it’s inappropriate as an application-specific abstraction for a graphics backend. It should absolutely be used to implement the latter. Compare this to the Rust compiler. Rust uses MIR as its intermediate compiler IR for Rust-specific optimizations, because it retains Rust-specifi…

Sure, but if you’re never going to do any MIR-level optimizations, then there’s no reason to implement it.

Similarly for graphics APIs. If at some point in the future you need to support a platform not supported by wgpu, you can add the abstraction layer at that time. Doing it before then doesn’t really buy you anything. You might never need it, and if you do, you’ll have a much better idea of what it should look like once you know what the new platform actually looks like.

Post reply on HN