FragmentShader

We know MacOS is Unix. We know Linux server runs most of the internet. We know Android is Linux. Thanks for your input.

We were obviously talking about the classic Linux Desktop distros, and based on the whole conversation you should know that. If ChromeOS and Android were categorized as Linux distros, then nobody would hate/love Linux Desktop per se.

> This isn't 2010 any more.

I've used Linux Desktop for 2 years in 2018 for IT studies, it was mandatory. We were like 20 students and there was a new Linux-related complaint, timewaste and workaround every day. Nobody got their degree and thought "Y'know what? i'm gonna use linux at home!"

I still use Linux for servers nowadays, though.

> If you're doing any dev work at all native linux will cause way less headaches than WSL/mingw or whatever.

I use visual studio and I don't dev for linux, so I don't have this problem.

> Even the old folks in my family are all using linux these days because everything they do is in a browser and it's easier for them than windows.

If all you do is use a web browser, you might as well just use a chromebook.

> That and microsoft constantly changing things out from under you and reverting settings

My settings are never touched, but I agree they sometimes change stuff in a way that bothers me. Like, removing file explorer functionality in W11 and remaking it months later. But they usually make up for it by adding other cool features. Such as native (but slow) unzipping, file explorer tabs, power toys and so on.

i'd rather have MS taking 8GB away from my 1TB disk than having Linux taking away at least 6 hours of my life per week cause something broke or cause I have to hoop through the entire internet to install or configure some shit that could've been a single click in windows.

> but when you create your own engine you are _fiercely_ aware of _everything_ it can and can't do

The problem is that if you start gamedev by making engines, then you aren't aware of what you need to do.

To give an example, if you make font rendering and looks blurry/pixelated, what now? Oh, and a simple 2D game takes 8 seconds to load, wonder why?

Meanwhile, if you have ever made a Unity game, chances are you already know the keywords "SDF" and "Texture compression", because you tore down an already big engine for optimizing your game and accidentally learned about what features a game needs.

> The webgpu and webgl apis are pretty different so im not sure you can call it “technically the same code”.

Isn't Bevy using WGPU under the hood, and then they just compile with it both WebGL and WebGPU? That should be the same code Bevy-wise, and any overhead or difference should be caused by either the WGPU "compiler" or the browser's WebGPU.

> I think a better comparison would be more representative of a real game scene, because modern graphics APIs is meant to optimize typical rendering loops and might even add more overhead to trivial test cases like bunnymark.

I know, but that's the unique instance where I could find the same project compiled for both WebGL and WebGPU.

> Either way your graphics driver should be receiving roughly the same commands as you would when you use Vulkan or DX12 natively or WebGL, so there might be something else going

Yep, I know. I benchmarked my program with Nsight and calls are indeed native as you'd expect. I forced the Directx12 backend because the Vulkan and OpenGL ones are WAYYYY worse, they struggle even with 1000 triangles.

> That said though, they're already comparable which seems great considering how little performance optimization WebGPU has received relative to WebGL (at the browser level).

I agree. But the whole internet is marketing WebGPU as the faster thing right now, not in the future once it's optimized. The same happened with Vulkan but in reality it's a shitshow on mobile. :(

> There is some extra API call (draw, upload, pipeline switch, etc.) overhead because your browser execute graphics commands in a separate rendering process, so this might have a noticeable performance effect for large draw call counts. Batching would help a lot with that whether you're using WebGL or WebGPU.

Aha. That's kinda my point, though. It's "Slow" because it has more overhead, therefore, by default, I get less performance with more usage than I would with WebGL. Except this overhead seems to be in the native webgpu as well, not only in browsers. That's why I consider it way slower than, say, ANGLE, or a full game engine.

So, the problem after all is that by using WebGPU, I'm forced to optimize it to a point where I get less quality, more complexity and more GPU usage than if I were to use something else, due to the overhead itself. And chances are that the overhead is caused by the API itself being slow for some reason. In the future, that may change. But at the moment I ain't using it.

Yeah, you're right. Sorry about that one.

> WebGPU is super slow on GPU and all the official benchmarks only care about CPU performance.

omg I thought I was the only one that found that. I tried webgpu (On a native context) and it was slowwwww. Only 10k non-overlapping triangles can bring my RTX GPU to its knees. It's not the shader because it was only a color. It's not the overlapping (And I tried a depth prepass as well). It's not the draw calls. The API is slow, straight up.

In fact, you can try to open a WebGPU demo in your browser and check the GPU usage in the Task Manager. Close it, open a random webgl Unity game and you'll see how much a single WebGPU triangle takes compared to a full-fledged game.

On my computer, the average Unity game with shadows, shaders 'n stuff takes 5% GPU and a simple WebGPU demo takes 7%.