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

61–70 of 86 posts

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

#61

Post by nextaccountic »

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

The commenter said about DoS but what about the fact that GPU memory isn't protected? What if two different shaders run at the same time at the gpu - will one be able to read the other's private memory?

There are GPUs that support IOMMU but they cost a fortune. (or is IOMMU a separate feature than just having virtual memory for GPU memory?)

Running user-supplied shaders seems like a security nightmare.

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

#62

Post by nextaccountic »

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.

Wgpu-rs doesn't rely on the web. The API is just a simplified Vulkan. The API can be implemented for the web (and Firefox uses wgpu-rs) but it is also adequate for native applications. See https://news.ycombinator.com/item?id=23079200 (that was posted elsewhere in this thread) for more details.

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

#63

Post by mikevm »

Animats wrote: 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? :)

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

#64

Post by skocznymroczny »

Good news. I switched to WebGPU from OpenGL for my homemade game engine and I am very happy with it. I don't use Rust though, but D, the only time I see Rust code is in the stacktraces when I get an error.

Personally, I think there is a lot of potential for WebGPU outside of web/Rust ecosystems. WebGPU provides a great balance between awkwardness of OpenGL (global state, suboptimal resource binding patterns) and the verbosity and expertise required for Vulkan (barriers, synchronization, everything are needed even for a basic triangle and it only gets harder from there).

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

#65

Post by skocznymroczny »

porphyra wrote: post #12
efnx wrote: post #8

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

It's much better when you use a debug context, although as usual with OpenGL the details vary between graphics card drivers. I had very good debug messages with Nvidia.

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

#66

Post by jokethrowaway »

CyberRabbi wrote: post #9
_cart wrote: post #4

As 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

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.

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

#67

Post by garaetjjte »

nextaccountic wrote: post #61
gfxgirl wrote: post #58

Earlier quoted context omitted.

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…

The commenter said about DoS but what about the fact that GPU memory isn't protected? What if two different shaders run at the same time at the gpu - will one be able to read the other's private memory? There are GPUs that support IOMMU but they cost a fortune. (or is IOMMU a separate feature than just having virtual memory for GPU memory?) Running user-supplied shaders seems like a security nightmare.

All modern GPUs have MMUs that prevent shaders from accessing arbitrary memory. In rare cases where it is absent (like VC4 on Raspberry Pi) driver needs to statically analyze shaders and ensure that all memory accesses are clamped.

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

#68

Post by kangz »

kvark wrote: post #44
jms55 wrote: post #41

Earlier quoted context omitted.

This implementation is developed by firefox (at least, last I checked). Google has an implementation along similar lines in C++ called dawn, and I'm pretty sure webkit plans to use dawn. So you see them in Rust/C++, but no one has written an implementation in go afaik.

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?

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

#69

Post by kangz »

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.

Other comments explain how that's challenging/impossible in the general case because GPU don't have as good preemption as CPUs and because of the halting problem. However for the VRChat use case you could imagine disallowing unbounded loops so you can estimate the number of instructions and put a reasonable cap on them. This would take care of the DOS and the WebGPU runtime would take care of the rest of the security (OOB, uninitialized data, etc)

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

#70

Post by wtetzner »

CyberRabbi wrote: post #52
dralley wrote: post #49

Earlier quoted context omitted.

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.

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.

Post reply on HN