HN Theater @HNTheaterMonth

My recent talk at Fosdem started with a rant about OpenGL/WebGL. Cant express this better still:

https://fosdem.org/2020/schedule/event/rust_webgpu/

⬐ adamnemecek

Check out wgpu (https://github.com/gfx-rs/wgpu-rs) the Rust implementation of the WebGPU standard.

WebGPU is a nice API, Rust is amazing too. It's the stack of the near future. You can use it on the desktop. WebGPU a fast API on top of the underlying platforms. And it supports spirv, fuck glsl or hlsl.

There's also a dedicated wgpu channel on matrix if you want to join. https://matrix.to/#/%23wgpu:matrix.org

⬐ mrec

Minor nitpick - wgpu is the implementation (written in Rust but exposing a C API), wgpu-rs is an idiomatic-Rust wrapper around that implementation.

I did a bit of a doubletake the first time I read that, but ultimately I think not giving your own implementation language special treatment sends a good message for potential adopters.

⬐ zozbot234

It's also needed because only C provides a standard ABI, so any linking of binary objects that are not being built by that exact same compiler release has to go through that lowest common denominator. Rust even provides 'bindgen' and 'cbindgen' utilities to make this pattern more workable.

⬐ mrec

Oh sure, my doubletake was at them going this route rather than the "obvious" one of having the Rust implementation expose a Rust API and then having a separate C-API wrapper around that.

⬐ shmerl

It would be good for it to support SPIR-V everywhere despite Apple's sabotage of the idea, but wouldn't you still need to use higher level language (HLSL/GLSL) to generate SPIR-V? Writing shaders in SPIR-V assembly directly would be pretty tedious.

⬐ adamnemecek

It supports SPIR-V everywhere I believe. I'm not sure if Apple is trying to sabotage this effort, I actually honestly believe that they just think they have a nice way of doing things and want to tell the world about it.

I think they have made some very good choices in WebGPU as well as WSL.

⬐ shmerl

So WebGPU with SPIR-V will work in Apple's browsers, or you mean they should be ignored as crippled for WebGPU support?

⬐ adamnemecek

The question of browsers is secondary. WebGPU goes way beyond the web. There are WebGPU implementations that you can use say for desktop games. It's a standard say for shaders and GPGPU programming. WebGPU supersedes all of CUDA, Vulkan, DirectX, OpenGL, Metal, OpenCL, WebGL. Maybe not all, but most of it.

For me, the browser is a nice to have, WebGPU is a good standard regardless.

⬐ shmerl

Why would you use WebGPU for desktop games vs Vulkan directly, or a wrapper like gfx-rs? It's a more comfortable level of abstraction? I don't see WebGPU superseding Vulkan really.

⬐ adamnemecek

It's a simpler API. Vulkan takes maybe 3x as many lines of code to express the same thing. Also if you want to run on macOS or Windows, you will use the native platforms. You can also target the web from the same codebase.

⬐ shmerl

gfx-rs does that, or you can use still Vulkan and through the same gfx-rs compat or MoltenVK target MacOS too.

The only outlier is probably OrbisOS with its obscenely locked and NDA'ed GNM.

⬐ adamnemecek

gfx-rs is not an open standard. gfx-rs is a little too hairy, so is rendy.

⬐ pcwalton

wgpu/WebGPU is way less verbose. I don't want to write gfx-rs or Vulkan directly when experimenting with new techniques, unless I absolutely need maximum performance when testing. Only when I want to deploy something to production will I write in those low-level APIs.

⬐ adamnemecek

Do you think there will be much to gain from using Vulkan as opposed to WebGPU?

⬐ pcwalton

Probably highly workload dependent and impossible to answer in a general way.

⬐ shmerl

That sounds reasonable. So you see WebGPU becoming the good general purpose higher level API built on top of good foundation (like Vulkan) that Khronos mentioned was missing in the Vulkan effort?

⬐ pcwalton

I certainly hope so!

⬐ shmerl

Is it feasible to implement it for GNM / PlayStation, for instance through adding that target for gfx-rs? I've heard for example Godot engine can't even target it, due to it being very hostile towards anything open (requiring NDA for any kind of integration).

⬐ pjmlp

Monogame has PS4 support, one just needs to be open minded and not API religious.

http://www.monogame.net/2014/03/23/monogame-for-playstation-...

⬐ shmerl

Did Sony give them permission to avoid the NDA? Otherwise, how did they implement it, when NDA prevents using open source licensing?

⬐ pjmlp

As I mentioned, "one just needs to be open minded and not API religious.".

Bashing about how companies handle 3D APIs will take you nowhere on the games industry, as we discussed multiple times.

⬐ shmerl

You mentioned some flamebait claim, without any substance. If you can't elaborate (like provide a link to the actual source for instance), I'd assume it's a fake, and their PS implementation is not open source and you are simply trolling, like usual.

The whole point of an NDA is to prevent access to the source without authorization. I.e. incompatible with open source by definition.

⬐ pjmlp

Link was provided, anyone without a zealot attitude is welcomed to learn more.

⬐ Jasper_

"When NDA prevents using open-source licensing"

It doesn't. It just means the PlayStation 4 parts are simply not open-source. MonoGame is available under the MS-PL, and MIT-alike. The PlayStation 4 backend is available under non-open-source terms to authorized PlayStation 4 developers.

⬐ adamnemecek

I definitely do. Like you can get to 90% perf using a cross-platform API. And to fine tune, you can probably just contribute some perf improvements to the implementation instead of rewriting it.

⬐ Jasper_

The buffer mapping strategy is still a big perf pitfall, but it could be solved with an extension.

⬐ Jasper_

WebGPU does not supercede Vulkan, Metal, or DirectX, and especially not OpenCL/CUDA. Please at least try using CUDA before claiming WebGPU even approaches anything near its functionality.

WebGPU has tradeoffs and issues like anything else. AAA game engines, like the ones I work on, are still going to continue to have to support console platforms without WebGPU support, and will still have their own platform interfaces around stuff like that. Don't get me wrong, WebGPU is a very nicely designed API, but it is still lowest-common-denominator, and is about 2 years behind schedule.

⬐ giornogiovanna

> So WebGPU with SPIR-V will work in Apple's browsers

Yes, I think the idea is to embed a SPIRV-to-Metal compiler inside the browser.

At least, that's what it looks like https://github.com/gfx-rs/wgpu is doing right now.

⬐ shmerl

So Apple agreed after all? They were resisting it in the past.

⬐ giornogiovanna

Never mind, I have no idea what Apple is doing. It looks like they're inventing yet another shading language.

https://webkit.org/blog/9528/webgpu-and-wsl-in-safari/

⬐ shmerl

That's what I thought. They still want to sabotage SPIR-V usage in the browser.

⬐ pjmlp

Yeah, that is why the only working WebGPU implementation for Chrome, from Google, only works on the Mac and Windows platforms, using Metal and DirectX, your favourite APIs.

⬐ shmerl

In Chrome may be, but that's not Apple's browser. And on iOS that won't work already, due to Apple's anti-competitive ban on browser engines that aren't theirs.

And if anything - those are your favorite APIs. You always flame (like a shill) about how lock-in is good for developers.

⬐ pjmlp

It is quite clear from all our discussions that you have zero experience on how things roll in the games industry.

If you feel good calling everyone, with experience, a shill because we don't buy your Quixotic battle against the man, so be it.

By the way, by law Apple can do whatever they feel like it.

⬐ shmerl

Who "we"? Your bosses who pay you for the shill work of whitewashing lock-in? No one is buying your koolaid of "lock-in is good" and using lock-in thinking its locking limitations are beneficial.

⬐ pjmlp

Those with actual experience in games industry, in whatever way.

IGDA members, attending GDC, going to PAX, local indie games conventions, having been inside AAA studios, knowing names in the industry, meetups at local games design university.

As for the rest, whatever man.

⬐ shmerl

You keep avoiding actual subjects in the discussion while making flamebait posts. That is demagoguery and flaming at best or trolling at worst. Don't waste other people's time.

⬐ dang

Please don't feed flamewars on HN, even when another commenter is wrong and/or you feel provoked. It helps nothing.

https://news.ycombinator.com/newsguidelines.html

⬐ pjmlp

Ok, I will act accordingly.

⬐ dang

You crossed into personal attack repeatedly in this thread, as well as breaking the site guidelines by making insinuations about shilling/astroturfing. We ban users who do these things. Would you please review https://news.ycombinator.com/newsguidelines.html and stick to the spirit of this site when posting here? We'd be grateful.

⬐ shmerl

The person who I was responding to started it, and I view it as a trolling behavior. I'll avoid responding to him to follow the guidelines, but you should focus on the one who started it.

Having an individual block function could be useful, to simply filter our comments by such user.

⬐ dang

It always feels like the other person started it. Maybe their behavior was egregious and I missed it (we don't come close to seeing all the posts here), but even in that case, we need you to stick to the guidelines no matter how badly another commenter behaves.

⬐ giornogiovanna

I'm getting some serious déjà vu here.

Anyway, pjmlp, if you have some time, could you please explain how WSL makes sense in a world where SPIR-V already exists?

Both are intended mainly to be compiler targets, and both will need verifiers for use in WebGPU. The main advantages of SPIR-V are that some tooling already exists (as opposed to none), most of the specification is already done, and it will end up being faster with Vulkan. The only advantage I've seen for WSL is that it's text-based, so you can cut and paste pieces of code together more easily. I don't know how that would even fit in with the idea that WSL is meant to be a compiler target, though.

⬐ pjmlp

WSL also has some tooling, in Safari.

Given that Vulkan is only a viable option on post Android 10 devices, Linux and unsandboxed Win32 apps, being faster with Vulkan is a relative merit.

Now, if SPIR-V is part of the browser and does not require to bundle a JIT compiler, as apparently has been discussed then great.

Then again, maybe some tooling besides shaderc would be welcomed.

⬐ pcwalton

I read the parent comment as against the idea of shipping HLSL/GLSL, not the languages themselves.

⬐ adamnemecek

Yeah, I want whatever->SPIR-V->platform language.

⬐ floatingatoll

Direct link to the talk slides: https://fosdem.org/2020/schedule/event/rust_webgpu/attachmen...

⬐ gb221

I guess shaders are in the same language so it doesn't matter if the rest of the code is Rust.