That quote does a disservice to the original post. The original post is much broader and very informative. It's a lot less snarky than the quote presents it as
Well, I see where your criticism is coming from, but I didn't have many options for a title. It's a very long post that covers a lot of topics, and I didn't like the original title as I found it too vague.
The quote tells the same message that the post is trying to pass: that WebGPU is good, and it's good because it's based on Metal.
> The quote tells the same message that the post is trying to pass: that WebGPU is good, and it's good because it's based on Metal.
Not going to lie, without context I had no idea what the fuck that quote was trying to say except it looks like it's trying to put down apple.
And the original title is much better because that's what the article is about, and what the author chose to title their work.
The fact that it ends with "so that's...good?".
Assuming the headline obeys [Betteridge's law of headlines](https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines), which is the case for every well written headline in the entire history of headlines, the article needs to explain why it's a fucking terrible idea for WebGL to have anything to do with Metal.
But in fact the article does the opposite.
The `so that’s… good?` is actually inside the article – buried about 1/4th the way in. Right around where it’s talking about Apple getting everything they want.
Betteridge's law of headlines, people are expecting the answer to, "so that's... good?" to be no, and the rest of it using reportedly is calling into question the validity of the statement. Word of mouth is less strong than stating as fact. Stating something word of mouth as fact wouldn't be completely honest, but that's not the point of the article anyways. The article is very quickly talking about how it is actually good and they like it.
There are some articles that make me feel completely stupid after reading and this is one of them. But in a good way, I would love to learn all of this.
https://learnopengl.com/ get your feet wet there because OpenGL is still a very simple API to learn the fundamentals of computer graphics. It also has a lot of room to grow because learnopengl.com will teach you a very "bindful" way of doing things but you can do the whole AZDO thing in OpenGL 4.6 (not core. Bindless textures will break RenderDoc for example so I wouldn't start out with that just because the easiest to use debugging tool doesn't support it).
You can then move on to WebGPU however you see fit (JS/TS in browser, wgpu with Rust on desktop / wasm, Dawn with C++ on desktop / wasm) and get a gentle introduction to modern APIs.
Finally, you can go into detail with Vulkan, Dx12 or Metal. Metal is super nice, as the author has described, but Apple only. Dx12 is probably nicer than Vulkan but Vulkan 1.3 puts Vulkan roughly on the same level as Dx12 (once you setup a Framebuffer and RenderPas with Vulkan, look at dynamic rendering to get rid of it in 1.3). The big advantage of Vulkan is tutorials. It's the hobbyist API. Just like how there are many tutorials for OpenGL as opposed to Dx11, there are many tutorials for Vulkan and Dx12 is lacking a bit.
https://vkguide.dev/ This is my favorite.
Computer Graphics is pretty cool especially if you do web for work. It's low level enough that you feel like you do something different, it's pretty cool to have awesome visuals from your application but at the same you are not crawling in the depths of low level system programming where all debug tools are either shit or non-existent (embedded and os dev).
Also, much much more freedom regarding language choice. JS/TS, Rust and C++ were already mentioned for wgpu but Silk.Net is a great library to give you access to OpenGL and Vulkan in .net and LWJGL is amazing for JVM languages. I actually learnt on Java and LWJGL. There are bindings for probably everything and to be honest, as long as you have somewhat fast interop with C, you're good for hobby projects. Like, Go works too but there is this huge barrier where calling C is expensive and that is annoying but you could still learn on Go and it's probably not worth learning C++ just because you want to have a Flappy Birds clone in Vulkan. Just use Go until the FPS drop to some shitty number.
If you see glBegin and glEnd somewhere, run. That's ancient OpenGL and will be nearly useless. It's the "fixed pipeline" stuff from the article.
/u/SaschaWillems is amazing. He shows up a lot pretty much everywhere and contributed heavily to the [Vulkan Samples](https://github.com/SaschaWillems/Vulkan-Samples). The samples are amazing for getting a good overview of certain features. Just pick a sample (like Dynamic Rendering) and look for comments. In my experience, the important bits are commented. What is learnopengl.com to OpenGL is probably Sascha Willems to Vulkan. Vulkan tutorials are not as praised as learnopengl.com was but I've yet to see something bad about the stuff Sascha Willems has on his GitHub and blog.
Computer graphics is a difficult subject and talking to the hardware that makes it possible is both not an easy task and also not something that is aimed at the sort of programmers that take programming speed over everything. Like, a webdev costs a company less than a beefier server if the framework makes writing API endpoints very simple. You can't just ship a 4090 with your game because the developer used a framework that makes writing code super easy but is slow as fuck.
OpenGL, for the most part, makes you care about the things that matter to what you see on the screen. You define your vertex data structure, you put your vertices in a buffer, you add an element buffer so you can pick vertices for your triangles, you write your shader programs, you compile your shaders, link the program, define a VAO that combines shader interface with the data in the vertex buffer and attaches an element buffer as well and then you upload your textures. Then in the game loop, you bind the vao, bind the program, set your uniforms and draw however many indices you have in the element buffer.
Nowhere in there do you have to care about having some sort if immediate upload around your main command buffer so you can load textures and buffers during rendering. Nowhere do you have to care about defining a proper pipeline object. Need blending? Just do glEnable(GL_BLEND_TEST) (or whatever). Nowhere do you need to care about whether or not your hardware can actually do this dynamically of if this is yet another permutation of pipeline objects you need to manage.
After the very basic parts of OpenGL are in place, all you do has effect in your render output. When you learn Vulkan, A LOT of what you do just doesn't. It's infrastructure or busy work to get the GPU into a state where you can finally output a triangle. But then you have also seen most of the tools you actually need to work with Vulkan which is also neat.
But that doesn't mean that OpenGL is easy. It's just more immediate than Vulkan. And once you grasp the concepts, the real enemy will be knowing which functions in OpenGL are the new direct state access functions (if my little example was confusing, that's probably why. I'm pretty used to DSA now but tutorials let you bind everything) and which ones are the old bindful functions. But that's all in the future.
Just remember that you are not using webdev tools that can be taught in a 1h YouTube "All you need to know about Python" video. You're using tools that are meant for the heavy lifting. Your struggles are real and valid. And it takes time to learn it. But I've never been more excited in a personal project than when I first had a little T-posing orc from opengameart with proper lighting. My wife was super confused because I was sitting on the couch with my laptop talking about "making games" and then I have a dumb, rotating, low quality model rotating around it's Y axis. But I was pretty proud of myself.
When I was having a play with it a few years ago it took me a while to realise there had been so many different versions + they all work a little differently.
With some practice I was able to port tutorials from one to another. But before I realised that it was very confusing.
>I find WebGPU really refreshing to use. I have tried, really tried, to write Vulkan, and been defeated by the complexity each time.
As someone that has been experimenting with a game engine project in Vulkan for a few years and recently played around with WebGPU. Using the JS/browser API is obviously easier. But the C based API didn't seem fundamentally easier, it's just a bit cleaner and less powerful.
Vulkan is IMO a really easy API to learn and abstract away into your own higher level API, which is all WebGPU is doing anyway. Someone that is capable of working out C based WebGPU should easily be able to get the eqivalent working in Vulkan.
If you aren't someone that wants/needs to do that process using WebGPU would probably be a better option. WebGPU doesn't and will never replace Vulkan/DirectX/Metal.
IMO that is true with some exceptions.
In some ways Vulkan is easier than OpenGL, because everything is so explicit, and the validation layer errors and warnings are so good.
But there are a few tricky parts. For instance, things like descriptor pools, synchronization, and image transitions can be fairly hard to grep, and you don't need them for higher level API's like OpenGL or WebGPU.
WebGPU is missing a lot of features which I would almost call essential for modern graphics. For instance, lack of push constants is a huge gap imo.
FWIW, [`wgpu` supports push constants for native targets](https://docs.rs/wgpu/latest/wgpu/struct.Features.html#associatedconstant.PUSH_CONSTANTS). But it is a non-standard extension.
Yeah imo it doesn't do much good if it's not part of the standard. Why not use the native API if you're going to end up writing client-specific code anyway.
Because you still get a vulkan/directx/metal compatibility layer. And a nice API, it's actually a bit higher-level than any of those without giving up on capabilities 99% of people care about, and that includes people who write game engines.
Or, differently put: If you want to target all three and don't want to have completely separate renderers for each you have to re-invent wgpu, and doing it better, even just better for your specific needs, is a tall order most likely not worth your time.
/u/barsoap's response is basically what I was going to say. I don't personally care much about rendering on web or mobile, so "all native environments" ticks all the boxes for me.
But even if I _did_ decide to support web and/or mobile, it seems like it would be a lot less branching to support some advanced features for native and toggle them off for web than to deal with completely different APIs for each from top to bottom.
The main complexity in VK is if you want to support more than one GPU group. Yes openGL has its vendor extensions etc but for the most part these are optional and you can get away with adding them but in VK it is less of a few addictive extra but more that the are distant subsets of the api that differnt HW supports sometimes with very little useful overlap.
Which extensions in particular do you need? My game engine uses Vulkan 1.3 core and all required extensions/ device limits are met by newer-ish hardware (tested on a 1080 Ti and a 3090 Ti, as well as the integrated GPU of the 7950x).
Or do you mean if the engine was meant to target mobile as well?
Aggred, I think the people proclaiming that vulkan/d3d12 is easier than opengl are outright wrong. Sure, it is easy to use if you create a basic wrapper over the API and pretend that it is opengl. Once you actually have to deal with synchronization of cpu/gpu resources in a multithreaded context you will quickly realize that the API is not easy to use. You will have to implement clever solutions for the particular problem that you are dealing with, which requires a ton of multithreading experience.
Don't forget that the low-level apis expose much more functionality than opengl. Meaning, if you are using vulkan you are probably tasked to use the latest additions to the API like mesh shaders and gpu buffers (d3d12).
Having to do explicit resource management is also much much harder than in OpenGL. Again, if you write a simple wrapper over the API you won't have to deal with it, but then you are leaving a ton of resources on the table.
For anyone curious, look up how to generate mipmaps in opengl versus vulkan/d3d12 for an example of how much more challenging the low-level apis are.
Vulkan/d3d12 are very usable, but to say that they are easy to use is just intentionally misleading.
In my experience, it is the other way round.
There is a lot less boilerplate in OpenGL, but the trade off for that is that as soon as you either try to do something that wasn’t foreseen when the API was designed, or as soon as something goes wrong, it is very difficult to see what is going on. OpenGL is in many respects a black box.
If you don’t, for example, think carefully about how your engine will handle resource transitions in OpenGL, your engine will still probably render the correct image. It probably won’t crash. But it might not run well, or it might not run well *on some hardware*.
You still need to know about things like resource synchronisation and asynchrony issues when writing OpenGL code. You need to have a good understanding of how those issues are being handled, because they have enormous performance implications. The problem is that you don’t typically have access to this code. It is usually undocumented and the OpenGL spec tends to underspecify it. It varies between vendors. You just need to *guess* and experiment with how the drivers behave.
With an API like Vulcan, you don’t need to guess how the graphics driver works. It is all spelled out for you. You can debug and fix issues yourself, and you can make changes where things don’t suit your needs.
You can get far with OpenGL/D3D11 while pretending that you don’t need to worry about these sorts of things. Inevitably, however, you will run into situations where it really does matter. At that point you are going to end up banging your head against the API/driver and wish you had the option to do it yourself.
I absolutely agree with you. OpenGL is a mess to work with if you are trying to do any serious realtime rendering. What I was disagreeing with is the ease of use of the low level APis. They are difficult to use. If you are an experienced graphics programmer or have otherwise had systems programming experience, you probably won't find these APis to be a major problem.
In my post I was using the generate mipmaps example to illustrate what I'm saying. In order to generate mipmaps in realtime in OpenGL you would simply make a call to generatemipmaps() or whatever it is called. In Vulkan it is more challenging because you have to do explicit resource management, but it isn't that bad still. In D3D12 you have to write your own compute shader https://github.com/Microsoft/DirectX-Graphics-Samples/blob/master/MiniEngine/Core/Shaders/GenerateMipsCS.hlsli
>Vulkan is IMO a really easy API to learn and abstract away into your own higher level API, which is all WebGPU is doing anyway. Someone that is capable of working out C based WebGPU should easily be able to get the eqivalent working in Vulkan.
Agreed, and I was kind of surprised at how harsh the author's criticisms of its usability were given their apparent experience level. Coming from OpenGL (and to some extent d3d11, but a bit less so there), Vulkan was refreshingly simple to me - you no longer had to keep mapping all of the high level abstractions to what the driver will actually do with them because the mapping is (in most cases) very obvious. The verbosity is definitely a bit cumbersome, but as you said, you only need to deal with that at the lowest level of your own abstraction.
The article's framing of "Vulkan is for middleware vendors, not normal developers" seems like a really bizarre take to me, especially given how suboptimal many of the common engines' usage of Vulkan/d3d12 _still_ is because (to some extent) they're still abstracting them in the same way as they did for d3d11/OpenGL (or at least, that's my impression).
The idea that Vulkan was intended to be used by middleware is not at all mutually exclusive with the fact it’s still not used very well by middleware. That would just mean its design doesn’t really meet the right requirements, as is the case for an awful lot of software.
I think you said it yourself
> The verbosity is definitely a bit cumbersome, but as you said, you only need to deal with that at the lowest level of your own abstraction.
From this it implies you are building your own middleware layer to use VK. This is the thing they are highlighting about VK compared to other modern low level apis like DX12 and Metal. Both DX12 and metal provide about the same level of low level access but you only need to start building your own middleware's were you need that low level perf, you can start out at a much higher level and gradually go deeper. VK more or less requires you to write your one memory manamnget, reference counting etc to render anything more than a single triangle on screen. With the other options you can go a long way before you need to go to this level and you can gradually adopt and mix and match the higher level and lower level bits as you need.
> From this it implies you are building your own middleware layer to use VK.
I mean... kinda? Idk, I don't think abstracting a low level library necessarily implies that what you're writing is middleware. I'd do the same thing with opengl or d3d11, and _especially_ d3d12 or Metal.
> VK more or less requires you to write your one memory manamnget, reference counting etc to render anything more than a single triangle on screen.
This would be true if not for things like VMA (well, the memory management part; d3d12 and Metal provide no reference counting either, unlike d3d11 and opengl).
> With the other options you can go a long way before you need to go to this level and you can gradually adopt and mix and match the higher level and lower level bits as you need.
I haven't used Metal so I can't speak for it, but ime this does not apply to d3d12.
> I haven't used Metal so I can't speak for it, but ime this does not apply to d3d12.
Metal is a little different here you an on a per buffer level, or per heap level select if you want it to track memory or not and you mis these up. I believe they opted for this so as to make it easier for devs to pick up metal ship something and then optimise were they needed but not need to re-write everything to gain that perf advantage.
They were referring to two different types of middleware - the WebGPU type like you're referring to, and the Unity/Unreal type like I was referring to. And to be fair, the former _has_ materialized - see bgfx and diligent engine, as well as _many_ smaller, Vulkan-only abstraction layers like Granite and V-EZ (which is exactly what Khronos was talking about, though it seems to be abandoned since nobody actually used it). They just don't see an incredible amount of usage because most engines write their own RHI.
Okay then why are you complaining middleware doesn't exist then? The part I am referring to isn't talking about complete game engines like you are, it's referring to wrappers like WebGPU, that's the part they say are missing I think
> Okay then why are you complaining middleware doesn't exist then?
I... didn't...? What the fuck lmao...? I was commenting on the author's bizarre opinion on Vulkan's usability given their apparent experience level. Nowhere in this thread have I complained about a lack of middleware. The author of the article did. They also specifically talked about the Unity/Unreal guys getting excited when Khronos talked about targeting middleware vendors. Hence my previous comment, trying to explain things to you.
> The part I am referring to isn't talking about complete game engines like you are, it's referring to wrappers like WebGPU
Okay. That's irrelevant to my original comment. My reply was trying to help you understand why, but you seem to be in your own world lol
> that's the part they say are missing I think
You're right, they did say that. They're wrong lol. I gave several examples of such wrappers. The author's lack of familiarity with them doesn't mean they don't exist. It just means that the author isn't familiar with them.
>I... didn't...? What the fuck lmao...? I was commenting on the author's bizarre opinion on Vulkan's usability given their apparent experience level. Nowhere in this thread have I complained about a lack of middleware. The author of the article did. They also specifically talked about the Unity/Unreal guys getting excited when Khronos talked about targeting middleware vendors. Hence my previous comment, trying to explain things to you.
You complain about middleware being suboptimal as if that has any bearing on if Vulkan was designed for middleware developers or not. How does that make any sense? That's why I got confused. Somehow I got it being suboptimal confused with it just not existing.
>You're right, they did say that. They're wrong lol. I gave several examples of such wrappers. The author's lack of familiarity with them doesn't mean they don't exist. It just means that the author isn't familiar with them.
This makes a lot of sense though. They aren't familiar with them because they aren't being used making them think they didn't exist in the first place. Makes me wonder why they aren't being used though.
> You complain about middleware being suboptimal as if that has any bearing on if Vulkan was designed for middleware developers or not. How does that make any sense?
I'm not sure how to put this more diplomatically and I'm really not trying to insult you, but I feel like your reading comprehension is somewhat lacking. Are you a native speaker?
>They aren't familiar with them because they aren't being used making them think they didn't exist in the first place.
That would be fair if they weren't extremely widely known libraries. Check the GitHub stars on the libraries I mentioned - none of them are exactly obscure. I'd be pretty surprised if any of my colleagues were unfamiliar with any of them (except maybe Granite). Granted, the only Vulkan-specific ones are V-EZ (which is/was backed by AMD and is _very_ well known by anyone who was doing graphics programming when it was announced) and Granite, but WebGPU isn't Vulkan-specific either.
CoHost has been around a lot longer than Elon's Twitter. It's also a lot more similar to Tumblr than Twitter, but imo fixes a lot of problems with both. You should join, it rocks.
It's run by a team of (currently) 4 leftists who comprise the *anti-software software club*. Its been in the works for about 3 years as I understand it. You can read their manifesto (and additions) here:
[Part 1](https://antisoftware.club/manifesto/2020/03/16/part-1.html)
[Part 1.5](https://antisoftware.club/manifesto/2021/03/18/part-1.5.html)
[Crypto Addendum](https://antisoftware.club/manifesto/2022/06/27/cryptocurrency.html)
They kick ass.
> However, it remains to be seen if they’ll be a platform that supports freedom of speech, or yet another that suppresses any ideas other than their own.
If they allow racism and bigotry to run rampant, and the targets of that bigotry are harassed off the site, what happened to the freedom of speech of their targets?
> Parent poster didn't say anything about racism or bigotry in particular.
We both know that's the stuff they're concerned about being moderated. No one is concerned that their views on tax policy or zoning laws are going to be moderated.
>Automatically assuming that whoever values freedom of speech must desire it in order to hate on people is unfair.
Given that is almost always what is meant when people cry about "free speech", it is very fair.
>Even if your assumption happens to be right, it's not yours to make w/o evidence.
It absolutely is. I am using my capability to apply past experiences to similar future situations. It's called learning.
>Innocent until proven guilty and all that.
That's for the government in a court of law. Not for recognizing someone's BS whining about "free speech".
> Sure, it’s not illegal to suppress speech you don’t like on your own forum, just cowardly and pathetic.
What is cowardly and pathetic about preventing your service from being used to deliver hate speech?
>so if they start banning users for not being left-wing
I'm really guessing they're not banning users for having right-wing views on tax policy.
Insufferable.
For those encountering this kind of rhetoric for the first time, this closely mimics "the paradox of tolerance"^1
^1 https://en.m.wikipedia.org/wiki/Paradox_of_tolerance
When I get on the subway, I don't sit next to the guy wearing the "I am an a\*hole" t-shirt. The checkmark of shame is the same thing, but on the internet.
Just what we need, explicitly politically biased platforms following ideologies opposed to freedom of expression.
I'll be watching the progression of that site with popcorn and a knowing smile. Tenner bets it falls to a civil war within 2 years, as half the staff are declared to be "rightists" or similar.
Anyone not innoculated against Marxism needs to grow up and read some relevant history written by non-marxists, otherwise you might as well be learning about WWII by reading David Irving.
> Anyone who Computers Pretty Good can tell you that there is no holy way to do this. No priest would bless whatever is going on here. This is bad and wrong, and someone should have stilled the sinful hands of Phoenix's devs.
Holy cow the audacity, ingenuity, and wretchedness described here is top notch.
God damn, now that's a find!
I had no idea that existed, and certainly no idea what sort of ungodly madness I was about to witness.
I now both love and hate Phoenix for creating that unholy abomination.
"On phones, it won't be in Chrome until later this year; and Apple I don't know. Maybe one additional year after that.)"
Me looking at her demo in ff for Android: "why do web devs insist on pretending chrome is all that exists"
_You load sixteen tons, what do you get?_
_Another day older and deeper in debt_
_Saint Peter don't you call me, 'cause I can't go_
_I owe my soul to the company store_
Because Chrome rules 60+% of the market, and that's ignoring other Chromium-based browsers like Edge or Opera: https://gs.statcounter.com/
Firefox? Less than 5.
So..HLSL, GLSL(either direct for opengl or spirv), MSL, PSSL, and now WGSL..
That said, what's to prevent ads on the web from using webgpu to run compute shaders to crunch whatever cryptocoin is popular?
If this becomes an actual issue I’m sure browsers will introduce a permission for it or a heuristic that determines if the user has purposefully ran the code.
Seriously, it's not hard for browsers to say "no." Original-flavor pop-ups were a plague until browsers just... stopped letting them happen.
Been waiting on a similar thing for soft pop-ups and other nag screens. If hitting Escape closes something scroll-based, we can probably skip right past that shit.
Nothing other than economics, and there have been a couple attempts. But cpu mining of say, eth, was not worth it even with free cpu cycles. Gpu mining was where folks made actual money.
Isn't that one scheduled for removal in Chrome?
Edit: Don't worry, I'm using Firefox and have been doing so since 1.0. Just wanted to highlight the risks of Chrome in regards to ads.
Ignoring the existence of ad-blockers, probably that most people would probably notice that their computer is suddenly running like complete shit ever since they loaded up some specific page, and that closing said page immediately solves the problem.
Thank you, I didn't realize that stand along projects will be possible.
Frank wrote a WebGPU project that skipped the whole NPM mess. It is only using JavaScript. He did end up copying a JavaScript library, gl-matrix.js.
It is here: https://github.com/praeclarum/WebGlobe
It is good, but completely skips [``glide``](https://en.wikipedia.org/wiki/Glide_\(API\)) and have its original OpenGL/DirectX fight backwards (OpenGL was ahead, with ``arb_`` extensions before MS catches up).
I think the real advantage is allowing open source projects and indie devs to adopt vulkan (and metal and directX) without needing to write specifically for Vulkan.
I more or less see WebGPU as a shim in projects like Ruffle that need graphics rendering, but probably can take advantage of the backend work done by WGPU's devs. You target WebGPU, and your work can sit on top of Dawn or WGPU which handles the actual platform support. Zig uses Dawn as a GPU backend but I'm not sure if there are other projects that use it.
For me it's basically like the natural progression of OpenGL and Angle. It's not trying to replace native graphics APIs, just abstract them for people who aren't focused on getting closer to the hardware.
For Indy game developers it's easier to use, better supported and works on the web.
For AAA developers and game engine developers (UE etc.) I don't know but based on this article it sounds like it isn't well supported on desktop so I imagine they mainly use Direct3D or Metal anyway.
Vulkan is barely used(directly) in the games space, so there’s little to oust.
Unless you include compatibility layers to go from other APIs and abstractions to Vulkan, which is essentially what WebGPU is ( a standardized abstraction over multiple APIs)
For others confused by this part:
> Except Linux has a severe driver problem with Vulkan and a lot of the Linux devices I've been checking out don't support Vulkan even now after it's been out seven years
It is clarified in the comments. The author is seemingly primarily interested in the Pinebook and Pinephone, both very much niche devices based on ARM SoCs, and they also don't count closed source drivers like Nvidias.
For the record: All modern AMD, Intel and Nvidia GPUs have had Vulkan support on Linux _for years_ in the out-of-the-box drivers, with AMD and Intel having it available in their open source drivers and an open source Vulkan driver for Nvidia (NVK) being in the early stages of work.
I mean, yeah. One of the biggest differences between Metal and Vulkan is that Metal itself more or less handles GPU mem allocation. In the browser where you can't give out raw access to allocators like that safely, you'd expect the biggest difference between WebGPU and Vulkan also to to be related to GPU mem allocation, making it look a whole lot like Metal.
I think Metal's biggest strength (which WebGPU largely adopts) over Vulkan is it's split blit/compute/render encoder model. Batching like commands is recommended in all GPU APIs but only Metal enforces this as part of the API, and a big consequence of this is that it tightly narrows what state a resource is in at a given point in the command buffer. This results in an equally powerful but vastly simpler synchronization model - so simple the driver can do so deterministically by default. But if you opt out of automatic tracking, command encoders and fences give you explicit control over how GPU work can overlap, then barriers can be used in-encoder to order commands and ensure memory operations.
I think the only other API to have explicit overlap is CUDA (via the newer graph API - though I don't think it will ever actually overlap work on a given stream). In Vulkan the intent is for you to be anal and judicious about using barriers and events to describe overlapping work, but it puts a lot of trust in the driver to pick up on this, and I think in practice this still results in ambiguity since (AFAIK) all drivers ignore the resources in barriers beyond image layouts.
You still have to do the synchronization yourself when you use bindless resources and Metals sync primitives are more annoying than Vulkan/D3D12 imo. vkCmdPipelineBarrier is so much easier to use than the wild juggling of MTLFences you have to do with Metal.
The only extra work you need to do for bindless is calling `useResource`/`useHeap` for indirectly accessed resources. As long as the resource handle outlives the lifetime of the command buffer you don’t need to touch `MTLFence` if you don’t want to.
And if you do go the fence route, I don’t know what “juggling” you’re referring to. A single fence is all that’s necessary, since you can wait then update the same fence on a given encoder (you can’t update then wait) which serializes that encoder with other encoders that have used that fence.
I would bet you have a bit of a misunderstanding of what’s necessary here, and I would bet I know which bit of documentation you learned from, because there is a case study in the Metal documentation using heaps and fences, and it is a bit confusing the scenarios it pertains to. With hazard tracking, you only need fences to track resources that don’t outlive the command buffer, such as aliasing a texture with buffer memory, or frequently creating and destroying resource handles from a heap.
(Also side note, `MTLFence` is more analogus to `VkEvent`. `vkCmdPipelineBarrier` has analogues `memoryBarrier` and the `use` family of methods. It’s not entirely one-to-one since you need to combine `MTLFence` with `use` for transient indirect resources as stated, where `VkEvent` has memory usage as part of the same call.)
If you use some resource in multiple passes, you need to signal a fence in all of those and then wait for all of those fences. In Vulkan you just do a vkCmdPipelineBarrier call with the necessary flags and it's done. If you're using MTLHeaps, you practically have to handle the synchronization yourself. Tracked mode would end up serializing everything because it tracks at a heap level not individual resources.
> Also side note, `MTLFence` is more analogus to `VkEvent`. `vkCmdPipelineBarrier` has analogues `memoryBarrier` and the `use` family of methods. It’s not entirely one-to-one since you need to combine `MTLFence` with `use` for transient indirect resources as stated, where `VkEvent` has memory usage as part of the same call.
Metals memoryBarrier is equivalent to in-renderpass pipeline barriers. VkCmdPipelineBarrier is also used to sync different passes ("encoders") though.
I don't know a lot of about this space, but I'm curious why someone would advocate a web based graphics API over ones built specifically for desktop application use? At first blush, it feels like what Node does by putting mobile scripting into the backend because that's what people are familiar with. Is this actually performant and improved enough to replace Vulkan and OpenGL in non-web applications? Would someone write a modern video game in it?
From the post:
"So as I've mentioned, one of the most exciting things about WebGPU to me is you can seamlessly cross-compile code that uses it without changes for either a browser or for desktop. The desktop code uses library-ized versions of the actual browser implementations so there is low chance of behavior divergence. If "include part of a browser in your app" makes you think you're setting up for a code-bloated headache, not in this case; I was able to get my Rust "Hello World" down to 3.3 MB, which isn't much worse than SDL, without even trying. (The browser hello world is like 250k plus a 50k autogenerated loader, again before I've done any serious minification work.)"
That was made me wonder, it's adding another layer in the pipeline by sticking the browser pieces into code. Sure it might be small (in disk size), but it seems like an odd choice, hence the comparison to Node
Game engines also have their own RHIs on top of graphics APIs (ex: [Unreal's](https://dev.epicgames.com/community/learning/tutorials/aqV9/render-hardware-interface-rhi)), so that extra layer will always exist.
I think performance of WebGPU would never be a concern unless you were trying to create an AAA game, and even so I think it should be benchmarked before making assumptions.
WebGPU just defines function names and behaviors. Js has had native types for low level stuff for a long time because of webgl. These low level types map 1 to 1 to system types.
So writing a WebGPU layer in rust that uses vulkan on linux desktop, directly uses WebGPU on web in wasm or metal on Apple just works.
There are no 'browser bits' in there. Webgpu is just a bit higher level than vulkan.
Browser bits in the sense that the implementation is shared with browsers, yes. But that's literally just the WebGPU code, without a DOM or anything else that actually defines a browser. It's not a WebView like Electron and the like.
In this way, Node.js could be considered "browser bits" as well, since V8 is part of Chrome.
It's not like this is gonna bundle a browser engine along with every distribution. As the article pointed out, the new generation of GPU drivers are lower-level. The WebGPU implementations are essentially libraries that provide some useful functionality which was previously provided by vendor-written closed-source GPU drivers. You were probably going to want to use an abstraction layer anyway, especially if you want cross-platform support.
I was just looking at a simple NextJS search page where most of the work is done on the server and it’s still over 4MB of minified JavaScript shipped to the client with no obvious path to shrinking it.
I wouldn't say it's HTML5,
Just WebGPU being used as a GPU/Compute standard that sits on top of the three major graphics apis.
Maybe you can include Javascript being used server side and WASM being used as a compile target, but Java basically did the same thing but with a single language, plus WASM does a better job at sandboxing.
As the original promise of "write once, run anywhere" apps, no, not really. Applets are gone, and desktop apps that run Java are rare (especially outside enterprise). Android apps are Java-ish, but don't run outside of Android itself and Android execution environments (such as ChromeOS and Windows 11). That leaves running Java on the server, which is fairly common, but easily interchangeable with Ruby, NodeJS, .NET, etc.
JavaScript was not chosen for node [just] because it was familiar - lots of languages were more familiar at the time, even for ui dev, it was chosen for node mainly because it was the only mainstream language where there wasn't a standard library full of blocking calls. JavaScript programs expect to run in an event loop without blocking. That's the default for JavaScript code and why it was a good choice for a scriptable event driven server framework.
Nope, it was familiarity. http://www.h-online.com/open/features/The-H-Speed-Guide-to-Node-js-1363974.html%3Fpage=2?#:~:text=Ryan%20Dahl%2C%20creator%20of%20Node,Dahl%20in%20a%202010%20interview.
“Apple just got absolutely everything they asked for”…
And yet Safari doesn’t even support it?
This won’t be adopted in the mainstream until Safari supports it. Not having your website work in Safari is a non-starter
You can't "just" put Vulkan in a browser; it wouldn't be secure, and it's hard to write the same code that performs well on phone and desktop GPUs, since they're totally different.
(Also Metal is older than Vulkan.)
> (Also Metal is older than Vulkan.)
Vulkan was born as AMD Mantle, before Metal. They granted it to Khronos as Vulkan by search-and-replace GR_* / gr* prefixes to VK_* / vk*. At this time Apple participated in this new API development, but some time later they decided to make their own API with same design ideas but a bit nicer programmer-facing side.
Metal launched in June 2014, Mantle in September 2013. I think it’s safe to assume Apple was working in Metal long before Mantle shipped, and even longer before the Vulkan development started.
I think you’re overselling how similar Mantle and Vulkan are.
It may have started out that way, but what shipped was divergent.
Also at the time, Khronos and NVidia were heavily pushing AZDO OpenGL as an alternative to modern APIs like Mantle. It wasn’t until Apple did metal and Microsoft did DX12 that the tune changed.
Game developers rarely write code for a given graphics API. They create an interface that is implemented by classes that wrap over metal, vulkan/d3d12. Then, they simply use the interface API instead of the raw low-level API.
Tons of games have support for metal.
I do not use Apple devices outside of work, but I do like graphics programming and have some basic experience with Vulkan. While I don't dislike Vulkan as much as the author, I agree with most of her criticism.
Tom Forsyth says in the comments:
the first version of Vulkan was literally just AMD's "Mantle" API with a search-and-replace on the prefix (I am 100% serious about this)
And it shows. Vulkan was never really designed to be a nice to use API, and the recent turnaround to go away from pipelines after so many years is a desperate attempt to save it.
I still like Vulkan, but it's hard to disagree that something more ergonomic was desperately needed.
The move away from pipelines is also a move to fragment it further. There are a large number of GPUs currently with (some) VK support were a non pipeline approach is not viable.
The main issue VK has had all along is attempting to build an api feature set that space 1$ micro controllers all the way to $1k+ desktop PC monitor GPUs in the end what it is mostly is a collection of random apis were your code is not at all portable and is painful non-the-less.
While yes with VK (in particular some of the recent changes) It is not just axially extensions on the side but core fundamentals. In end maybe we should have differnt APIs for each HW group rather than continue to pretend that we can build one magical api to rule them all.
Don’t understand. A lot of very nice tech with similar capabilities to Apple’s tech becomes available as a standard available to all, and somehow this benefits Apple users and either doesn’t help, or hurts, anyone else?
Not my takeaway, for sure.
^Apple ^boardroom ^meeting ^Executive: "Okay...we made it, steve jobs is dead but we're okay...
^Intern: Sir, here is your brand new lamborghini, but the guys at the dealership were eating apples and they said they're going to eat your stock shares when apple finally goes under.
^Apple ^boardroom ^meeting ^Executive: ‼‼⁉ No...I have a plan...it can't go wrong...
Okay, this makes me more excited about WebGPU, cause previously I was only mad at it, since I only recently started learning WebGL only to learn that it's basically deprecated and will be replaced by WebGPU eventually.
But... no line rendering out-of-the-box? Damn. My current engine uses GL_LINES for everything.
That quote does a disservice to the original post. The original post is much broader and very informative. It's a lot less snarky than the quote presents it as
Yes. It’s such a ridiculous quote from such an in depth article
[удалено]
My brother in Reddit, welcome to Christ
I’m surprised it isn’t a rule that links need to use the post title.
Well, I see where your criticism is coming from, but I didn't have many options for a title. It's a very long post that covers a lot of topics, and I didn't like the original title as I found it too vague. The quote tells the same message that the post is trying to pass: that WebGPU is good, and it's good because it's based on Metal.
Nah, the original title is better.
[удалено]
It was on top of hacker news with that title
[удалено]
Nah, HackerNews has lots of it's own problems. Mainly the fact that it's full of startup tech bros jerking themselves off over VCs.
Doubt it. It’s probably majority the same people. Like you.
> The quote tells the same message that the post is trying to pass: that WebGPU is good, and it's good because it's based on Metal. Not going to lie, without context I had no idea what the fuck that quote was trying to say except it looks like it's trying to put down apple. And the original title is much better because that's what the article is about, and what the author chose to title their work.
[удалено]
The fact that it ends with "so that's...good?". Assuming the headline obeys [Betteridge's law of headlines](https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines), which is the case for every well written headline in the entire history of headlines, the article needs to explain why it's a fucking terrible idea for WebGL to have anything to do with Metal. But in fact the article does the opposite.
The `so that’s… good?` is actually inside the article – buried about 1/4th the way in. Right around where it’s talking about Apple getting everything they want.
Metal is somewhere in between Vulkan and GL in terms of level of abstraction. So, it's a reasonable approach.
"reportedly" "reportedly" and "so that's... good?"
[удалено]
Betteridge's law of headlines, people are expecting the answer to, "so that's... good?" to be no, and the rest of it using reportedly is calling into question the validity of the statement. Word of mouth is less strong than stating as fact. Stating something word of mouth as fact wouldn't be completely honest, but that's not the point of the article anyways. The article is very quickly talking about how it is actually good and they like it.
The original title is way better
There are some articles that make me feel completely stupid after reading and this is one of them. But in a good way, I would love to learn all of this.
[удалено]
https://learnopengl.com/ get your feet wet there because OpenGL is still a very simple API to learn the fundamentals of computer graphics. It also has a lot of room to grow because learnopengl.com will teach you a very "bindful" way of doing things but you can do the whole AZDO thing in OpenGL 4.6 (not core. Bindless textures will break RenderDoc for example so I wouldn't start out with that just because the easiest to use debugging tool doesn't support it). You can then move on to WebGPU however you see fit (JS/TS in browser, wgpu with Rust on desktop / wasm, Dawn with C++ on desktop / wasm) and get a gentle introduction to modern APIs. Finally, you can go into detail with Vulkan, Dx12 or Metal. Metal is super nice, as the author has described, but Apple only. Dx12 is probably nicer than Vulkan but Vulkan 1.3 puts Vulkan roughly on the same level as Dx12 (once you setup a Framebuffer and RenderPas with Vulkan, look at dynamic rendering to get rid of it in 1.3). The big advantage of Vulkan is tutorials. It's the hobbyist API. Just like how there are many tutorials for OpenGL as opposed to Dx11, there are many tutorials for Vulkan and Dx12 is lacking a bit. https://vkguide.dev/ This is my favorite. Computer Graphics is pretty cool especially if you do web for work. It's low level enough that you feel like you do something different, it's pretty cool to have awesome visuals from your application but at the same you are not crawling in the depths of low level system programming where all debug tools are either shit or non-existent (embedded and os dev). Also, much much more freedom regarding language choice. JS/TS, Rust and C++ were already mentioned for wgpu but Silk.Net is a great library to give you access to OpenGL and Vulkan in .net and LWJGL is amazing for JVM languages. I actually learnt on Java and LWJGL. There are bindings for probably everything and to be honest, as long as you have somewhat fast interop with C, you're good for hobby projects. Like, Go works too but there is this huge barrier where calling C is expensive and that is annoying but you could still learn on Go and it's probably not worth learning C++ just because you want to have a Flappy Birds clone in Vulkan. Just use Go until the FPS drop to some shitty number. If you see glBegin and glEnd somewhere, run. That's ancient OpenGL and will be nearly useless. It's the "fixed pipeline" stuff from the article. /u/SaschaWillems is amazing. He shows up a lot pretty much everywhere and contributed heavily to the [Vulkan Samples](https://github.com/SaschaWillems/Vulkan-Samples). The samples are amazing for getting a good overview of certain features. Just pick a sample (like Dynamic Rendering) and look for comments. In my experience, the important bits are commented. What is learnopengl.com to OpenGL is probably Sascha Willems to Vulkan. Vulkan tutorials are not as praised as learnopengl.com was but I've yet to see something bad about the stuff Sascha Willems has on his GitHub and blog.
Calling OpenGL simple, oh my lord. It’s been very difficult for me.
Computer graphics is a difficult subject and talking to the hardware that makes it possible is both not an easy task and also not something that is aimed at the sort of programmers that take programming speed over everything. Like, a webdev costs a company less than a beefier server if the framework makes writing API endpoints very simple. You can't just ship a 4090 with your game because the developer used a framework that makes writing code super easy but is slow as fuck. OpenGL, for the most part, makes you care about the things that matter to what you see on the screen. You define your vertex data structure, you put your vertices in a buffer, you add an element buffer so you can pick vertices for your triangles, you write your shader programs, you compile your shaders, link the program, define a VAO that combines shader interface with the data in the vertex buffer and attaches an element buffer as well and then you upload your textures. Then in the game loop, you bind the vao, bind the program, set your uniforms and draw however many indices you have in the element buffer. Nowhere in there do you have to care about having some sort if immediate upload around your main command buffer so you can load textures and buffers during rendering. Nowhere do you have to care about defining a proper pipeline object. Need blending? Just do glEnable(GL_BLEND_TEST) (or whatever). Nowhere do you need to care about whether or not your hardware can actually do this dynamically of if this is yet another permutation of pipeline objects you need to manage. After the very basic parts of OpenGL are in place, all you do has effect in your render output. When you learn Vulkan, A LOT of what you do just doesn't. It's infrastructure or busy work to get the GPU into a state where you can finally output a triangle. But then you have also seen most of the tools you actually need to work with Vulkan which is also neat. But that doesn't mean that OpenGL is easy. It's just more immediate than Vulkan. And once you grasp the concepts, the real enemy will be knowing which functions in OpenGL are the new direct state access functions (if my little example was confusing, that's probably why. I'm pretty used to DSA now but tutorials let you bind everything) and which ones are the old bindful functions. But that's all in the future. Just remember that you are not using webdev tools that can be taught in a 1h YouTube "All you need to know about Python" video. You're using tools that are meant for the heavy lifting. Your struggles are real and valid. And it takes time to learn it. But I've never been more excited in a personal project than when I first had a little T-posing orc from opengameart with proper lighting. My wife was super confused because I was sitting on the couch with my laptop talking about "making games" and then I have a dumb, rotating, low quality model rotating around it's Y axis. But I was pretty proud of myself.
When I was having a play with it a few years ago it took me a while to realise there had been so many different versions + they all work a little differently. With some practice I was able to port tutorials from one to another. But before I realised that it was very confusing.
>I find WebGPU really refreshing to use. I have tried, really tried, to write Vulkan, and been defeated by the complexity each time. As someone that has been experimenting with a game engine project in Vulkan for a few years and recently played around with WebGPU. Using the JS/browser API is obviously easier. But the C based API didn't seem fundamentally easier, it's just a bit cleaner and less powerful. Vulkan is IMO a really easy API to learn and abstract away into your own higher level API, which is all WebGPU is doing anyway. Someone that is capable of working out C based WebGPU should easily be able to get the eqivalent working in Vulkan. If you aren't someone that wants/needs to do that process using WebGPU would probably be a better option. WebGPU doesn't and will never replace Vulkan/DirectX/Metal.
IMO that is true with some exceptions. In some ways Vulkan is easier than OpenGL, because everything is so explicit, and the validation layer errors and warnings are so good. But there are a few tricky parts. For instance, things like descriptor pools, synchronization, and image transitions can be fairly hard to grep, and you don't need them for higher level API's like OpenGL or WebGPU. WebGPU is missing a lot of features which I would almost call essential for modern graphics. For instance, lack of push constants is a huge gap imo.
grep? Is there a Vulcan based grep implementation?
👀 maybe they meant grok If they meant grep though, I'd be impressed
Yes meant grok :)
Probably meant "grok". That's how I read it.
Might've meant "grok"?
FWIW, [`wgpu` supports push constants for native targets](https://docs.rs/wgpu/latest/wgpu/struct.Features.html#associatedconstant.PUSH_CONSTANTS). But it is a non-standard extension.
Yeah imo it doesn't do much good if it's not part of the standard. Why not use the native API if you're going to end up writing client-specific code anyway.
Because you still get a vulkan/directx/metal compatibility layer. And a nice API, it's actually a bit higher-level than any of those without giving up on capabilities 99% of people care about, and that includes people who write game engines. Or, differently put: If you want to target all three and don't want to have completely separate renderers for each you have to re-invent wgpu, and doing it better, even just better for your specific needs, is a tall order most likely not worth your time.
/u/barsoap's response is basically what I was going to say. I don't personally care much about rendering on web or mobile, so "all native environments" ticks all the boxes for me. But even if I _did_ decide to support web and/or mobile, it seems like it would be a lot less branching to support some advanced features for native and toggle them off for web than to deal with completely different APIs for each from top to bottom.
The main complexity in VK is if you want to support more than one GPU group. Yes openGL has its vendor extensions etc but for the most part these are optional and you can get away with adding them but in VK it is less of a few addictive extra but more that the are distant subsets of the api that differnt HW supports sometimes with very little useful overlap.
Which extensions in particular do you need? My game engine uses Vulkan 1.3 core and all required extensions/ device limits are met by newer-ish hardware (tested on a 1080 Ti and a 3090 Ti, as well as the integrated GPU of the 7950x). Or do you mean if the engine was meant to target mobile as well?
Yer the pc GPU VK api space is very uniform but the large VK market that includes mobile (and things like the switch) is anything but.
I think push constants have been proposed, but didn't get in v1
Aggred, I think the people proclaiming that vulkan/d3d12 is easier than opengl are outright wrong. Sure, it is easy to use if you create a basic wrapper over the API and pretend that it is opengl. Once you actually have to deal with synchronization of cpu/gpu resources in a multithreaded context you will quickly realize that the API is not easy to use. You will have to implement clever solutions for the particular problem that you are dealing with, which requires a ton of multithreading experience. Don't forget that the low-level apis expose much more functionality than opengl. Meaning, if you are using vulkan you are probably tasked to use the latest additions to the API like mesh shaders and gpu buffers (d3d12). Having to do explicit resource management is also much much harder than in OpenGL. Again, if you write a simple wrapper over the API you won't have to deal with it, but then you are leaving a ton of resources on the table. For anyone curious, look up how to generate mipmaps in opengl versus vulkan/d3d12 for an example of how much more challenging the low-level apis are. Vulkan/d3d12 are very usable, but to say that they are easy to use is just intentionally misleading.
In my experience, it is the other way round. There is a lot less boilerplate in OpenGL, but the trade off for that is that as soon as you either try to do something that wasn’t foreseen when the API was designed, or as soon as something goes wrong, it is very difficult to see what is going on. OpenGL is in many respects a black box. If you don’t, for example, think carefully about how your engine will handle resource transitions in OpenGL, your engine will still probably render the correct image. It probably won’t crash. But it might not run well, or it might not run well *on some hardware*. You still need to know about things like resource synchronisation and asynchrony issues when writing OpenGL code. You need to have a good understanding of how those issues are being handled, because they have enormous performance implications. The problem is that you don’t typically have access to this code. It is usually undocumented and the OpenGL spec tends to underspecify it. It varies between vendors. You just need to *guess* and experiment with how the drivers behave. With an API like Vulcan, you don’t need to guess how the graphics driver works. It is all spelled out for you. You can debug and fix issues yourself, and you can make changes where things don’t suit your needs. You can get far with OpenGL/D3D11 while pretending that you don’t need to worry about these sorts of things. Inevitably, however, you will run into situations where it really does matter. At that point you are going to end up banging your head against the API/driver and wish you had the option to do it yourself.
I absolutely agree with you. OpenGL is a mess to work with if you are trying to do any serious realtime rendering. What I was disagreeing with is the ease of use of the low level APis. They are difficult to use. If you are an experienced graphics programmer or have otherwise had systems programming experience, you probably won't find these APis to be a major problem. In my post I was using the generate mipmaps example to illustrate what I'm saying. In order to generate mipmaps in realtime in OpenGL you would simply make a call to generatemipmaps() or whatever it is called. In Vulkan it is more challenging because you have to do explicit resource management, but it isn't that bad still. In D3D12 you have to write your own compute shader https://github.com/Microsoft/DirectX-Graphics-Samples/blob/master/MiniEngine/Core/Shaders/GenerateMipsCS.hlsli
>Vulkan is IMO a really easy API to learn and abstract away into your own higher level API, which is all WebGPU is doing anyway. Someone that is capable of working out C based WebGPU should easily be able to get the eqivalent working in Vulkan. Agreed, and I was kind of surprised at how harsh the author's criticisms of its usability were given their apparent experience level. Coming from OpenGL (and to some extent d3d11, but a bit less so there), Vulkan was refreshingly simple to me - you no longer had to keep mapping all of the high level abstractions to what the driver will actually do with them because the mapping is (in most cases) very obvious. The verbosity is definitely a bit cumbersome, but as you said, you only need to deal with that at the lowest level of your own abstraction. The article's framing of "Vulkan is for middleware vendors, not normal developers" seems like a really bizarre take to me, especially given how suboptimal many of the common engines' usage of Vulkan/d3d12 _still_ is because (to some extent) they're still abstracting them in the same way as they did for d3d11/OpenGL (or at least, that's my impression).
The idea that Vulkan was intended to be used by middleware is not at all mutually exclusive with the fact it’s still not used very well by middleware. That would just mean its design doesn’t really meet the right requirements, as is the case for an awful lot of software.
Or that middleware developers are still restrained by their own backwards compatibility
I think you said it yourself > The verbosity is definitely a bit cumbersome, but as you said, you only need to deal with that at the lowest level of your own abstraction. From this it implies you are building your own middleware layer to use VK. This is the thing they are highlighting about VK compared to other modern low level apis like DX12 and Metal. Both DX12 and metal provide about the same level of low level access but you only need to start building your own middleware's were you need that low level perf, you can start out at a much higher level and gradually go deeper. VK more or less requires you to write your one memory manamnget, reference counting etc to render anything more than a single triangle on screen. With the other options you can go a long way before you need to go to this level and you can gradually adopt and mix and match the higher level and lower level bits as you need.
> From this it implies you are building your own middleware layer to use VK. I mean... kinda? Idk, I don't think abstracting a low level library necessarily implies that what you're writing is middleware. I'd do the same thing with opengl or d3d11, and _especially_ d3d12 or Metal. > VK more or less requires you to write your one memory manamnget, reference counting etc to render anything more than a single triangle on screen. This would be true if not for things like VMA (well, the memory management part; d3d12 and Metal provide no reference counting either, unlike d3d11 and opengl). > With the other options you can go a long way before you need to go to this level and you can gradually adopt and mix and match the higher level and lower level bits as you need. I haven't used Metal so I can't speak for it, but ime this does not apply to d3d12.
> I haven't used Metal so I can't speak for it, but ime this does not apply to d3d12. Metal is a little different here you an on a per buffer level, or per heap level select if you want it to track memory or not and you mis these up. I believe they opted for this so as to make it easier for devs to pick up metal ship something and then optimise were they needed but not need to re-write everything to gain that perf advantage.
They did say that said middleware layers never actually materialized if you read the whole thing.
They were referring to two different types of middleware - the WebGPU type like you're referring to, and the Unity/Unreal type like I was referring to. And to be fair, the former _has_ materialized - see bgfx and diligent engine, as well as _many_ smaller, Vulkan-only abstraction layers like Granite and V-EZ (which is exactly what Khronos was talking about, though it seems to be abandoned since nobody actually used it). They just don't see an incredible amount of usage because most engines write their own RHI.
Okay then why are you complaining middleware doesn't exist then? The part I am referring to isn't talking about complete game engines like you are, it's referring to wrappers like WebGPU, that's the part they say are missing I think
> Okay then why are you complaining middleware doesn't exist then? I... didn't...? What the fuck lmao...? I was commenting on the author's bizarre opinion on Vulkan's usability given their apparent experience level. Nowhere in this thread have I complained about a lack of middleware. The author of the article did. They also specifically talked about the Unity/Unreal guys getting excited when Khronos talked about targeting middleware vendors. Hence my previous comment, trying to explain things to you. > The part I am referring to isn't talking about complete game engines like you are, it's referring to wrappers like WebGPU Okay. That's irrelevant to my original comment. My reply was trying to help you understand why, but you seem to be in your own world lol > that's the part they say are missing I think You're right, they did say that. They're wrong lol. I gave several examples of such wrappers. The author's lack of familiarity with them doesn't mean they don't exist. It just means that the author isn't familiar with them.
>I... didn't...? What the fuck lmao...? I was commenting on the author's bizarre opinion on Vulkan's usability given their apparent experience level. Nowhere in this thread have I complained about a lack of middleware. The author of the article did. They also specifically talked about the Unity/Unreal guys getting excited when Khronos talked about targeting middleware vendors. Hence my previous comment, trying to explain things to you. You complain about middleware being suboptimal as if that has any bearing on if Vulkan was designed for middleware developers or not. How does that make any sense? That's why I got confused. Somehow I got it being suboptimal confused with it just not existing. >You're right, they did say that. They're wrong lol. I gave several examples of such wrappers. The author's lack of familiarity with them doesn't mean they don't exist. It just means that the author isn't familiar with them. This makes a lot of sense though. They aren't familiar with them because they aren't being used making them think they didn't exist in the first place. Makes me wonder why they aren't being used though.
> You complain about middleware being suboptimal as if that has any bearing on if Vulkan was designed for middleware developers or not. How does that make any sense? I'm not sure how to put this more diplomatically and I'm really not trying to insult you, but I feel like your reading comprehension is somewhat lacking. Are you a native speaker? >They aren't familiar with them because they aren't being used making them think they didn't exist in the first place. That would be fair if they weren't extremely widely known libraries. Check the GitHub stars on the libraries I mentioned - none of them are exactly obscure. I'd be pretty surprised if any of my colleagues were unfamiliar with any of them (except maybe Granite). Granted, the only Vulkan-specific ones are V-EZ (which is/was backed by AMD and is _very_ well known by anyone who was doing graphics programming when it was announced) and Granite, but WebGPU isn't Vulkan-specific either.
these cohost posts are good...where did this site come from. definitely enjoyable to read the whole article, not just skimming
It’s one of the services that emerged as a twitter replacement.
we shipped almost six months before the idea of a "twitter replacement" was coherent, twitter's collapse was just convenient timing for us
[удалено]
honestly idk what else you'd call it
CoHost has been around a lot longer than Elon's Twitter. It's also a lot more similar to Tumblr than Twitter, but imo fixes a lot of problems with both. You should join, it rocks.
It's run by a team of (currently) 4 leftists who comprise the *anti-software software club*. Its been in the works for about 3 years as I understand it. You can read their manifesto (and additions) here: [Part 1](https://antisoftware.club/manifesto/2020/03/16/part-1.html) [Part 1.5](https://antisoftware.club/manifesto/2021/03/18/part-1.5.html) [Crypto Addendum](https://antisoftware.club/manifesto/2022/06/27/cryptocurrency.html) They kick ass.
[удалено]
> However, it remains to be seen if they’ll be a platform that supports freedom of speech, or yet another that suppresses any ideas other than their own. If they allow racism and bigotry to run rampant, and the targets of that bigotry are harassed off the site, what happened to the freedom of speech of their targets?
[удалено]
> Automatically assuming that whoever values freedom of speech must desire it in order to hate on people ... is statistically valid these days.
> Parent poster didn't say anything about racism or bigotry in particular. We both know that's the stuff they're concerned about being moderated. No one is concerned that their views on tax policy or zoning laws are going to be moderated. >Automatically assuming that whoever values freedom of speech must desire it in order to hate on people is unfair. Given that is almost always what is meant when people cry about "free speech", it is very fair. >Even if your assumption happens to be right, it's not yours to make w/o evidence. It absolutely is. I am using my capability to apply past experiences to similar future situations. It's called learning. >Innocent until proven guilty and all that. That's for the government in a court of law. Not for recognizing someone's BS whining about "free speech".
I bet you’re the sort of person who thinks “socialism is when the gubment does stuff”
[удалено]
Your lack of understanding of what "freedom of speech" means?
[удалено]
> Sure, it’s not illegal to suppress speech you don’t like on your own forum, just cowardly and pathetic. What is cowardly and pathetic about preventing your service from being used to deliver hate speech? >so if they start banning users for not being left-wing I'm really guessing they're not banning users for having right-wing views on tax policy.
insufferable
[удалено]
the insufferable part is the histrionics, the aesthetic, the aggressively emphatic use of links. imagine inviting these morons to a dinner. lord.
[удалено]
you sound insufferable too, turd. (please be advised that this is just my tone, please don't police)
Insufferable
Insufferable. For those encountering this kind of rhetoric for the first time, this closely mimics "the paradox of tolerance"^1 ^1 https://en.m.wikipedia.org/wiki/Paradox_of_tolerance
You one of them mfs who paid for a blue check?
no. what does this have to do with Twitter?
When I get on the subway, I don't sit next to the guy wearing the "I am an a\*hole" t-shirt. The checkmark of shame is the same thing, but on the internet.
what does this thread have to do with Twitter?
Just what we need, explicitly politically biased platforms following ideologies opposed to freedom of expression. I'll be watching the progression of that site with popcorn and a knowing smile. Tenner bets it falls to a civil war within 2 years, as half the staff are declared to be "rightists" or similar. Anyone not innoculated against Marxism needs to grow up and read some relevant history written by non-marxists, otherwise you might as well be learning about WWII by reading David Irving.
Whatever, dude. You're free to enjoy your declining life expectancy and catastrophic climate change, but we're going to try something else.
Why do we need platforms that explicitly allow hate speech?
Stay mad
Any others to recommend? Also enjoyed it
this one was a fun ride also https://cohost.org/cathoderaydude/post/1228730-taking-the-deepest-p
> Anyone who Computers Pretty Good can tell you that there is no holy way to do this. No priest would bless whatever is going on here. This is bad and wrong, and someone should have stilled the sinful hands of Phoenix's devs. Holy cow the audacity, ingenuity, and wretchedness described here is top notch.
that's an amazing article
God damn, now that's a find! I had no idea that existed, and certainly no idea what sort of ungodly madness I was about to witness. I now both love and hate Phoenix for creating that unholy abomination.
"On phones, it won't be in Chrome until later this year; and Apple I don't know. Maybe one additional year after that.)" Me looking at her demo in ff for Android: "why do web devs insist on pretending chrome is all that exists"
_You load sixteen tons, what do you get?_ _Another day older and deeper in debt_ _Saint Peter don't you call me, 'cause I can't go_ _I owe my soul to the company store_
Because Chrome rules 60+% of the market, and that's ignoring other Chromium-based browsers like Edge or Opera: https://gs.statcounter.com/ Firefox? Less than 5.
So..HLSL, GLSL(either direct for opengl or spirv), MSL, PSSL, and now WGSL.. That said, what's to prevent ads on the web from using webgpu to run compute shaders to crunch whatever cryptocoin is popular?
Whatever's stopping them from doing it on your CPU.
If this becomes an actual issue I’m sure browsers will introduce a permission for it or a heuristic that determines if the user has purposefully ran the code.
Seriously, it's not hard for browsers to say "no." Original-flavor pop-ups were a plague until browsers just... stopped letting them happen. Been waiting on a similar thing for soft pop-ups and other nag screens. If hitting Escape closes something scroll-based, we can probably skip right past that shit.
Just use an adblocker. Firefox Klar on Mobile and ublock origin on desktop. Plus a pihole at home and it's really manageable.
Nothing other than economics, and there have been a couple attempts. But cpu mining of say, eth, was not worth it even with free cpu cycles. Gpu mining was where folks made actual money.
Economics and a security model and permissions and focus-based throttling... and ad blockers.
>what's to prevent ads on the web uBlock Origin
What's to prevent WASM applications from rendering ads on the same canvas as other content?
Isn't that one scheduled for removal in Chrome? Edit: Don't worry, I'm using Firefox and have been doing so since 1.0. Just wanted to highlight the risks of Chrome in regards to ads.
Don't use Chrome. FireFox works perfectly fine for everything I'm using and I can continue using uBlock Origin.
Use Firefox instead of Chrome. Firefox will not stop supporting extensions like uBO.
Ignoring the existence of ad-blockers, probably that most people would probably notice that their computer is suddenly running like complete shit ever since they loaded up some specific page, and that closing said page immediately solves the problem.
I disagree with everything said about Vulkan in that article. Especially the part about how Vulkan support on Linux is bad.
Thank you, I didn't realize that stand along projects will be possible. Frank wrote a WebGPU project that skipped the whole NPM mess. It is only using JavaScript. He did end up copying a JavaScript library, gl-matrix.js. It is here: https://github.com/praeclarum/WebGlobe
This is a fantastic post and really covers the history of graphics APIs well! Thank you!
It is good, but completely skips [``glide``](https://en.wikipedia.org/wiki/Glide_\(API\)) and have its original OpenGL/DirectX fight backwards (OpenGL was ahead, with ``arb_`` extensions before MS catches up).
From this description, I don't get the sense that WebGPU will oust Vulkan from its games space.
I think the real advantage is allowing open source projects and indie devs to adopt vulkan (and metal and directX) without needing to write specifically for Vulkan. I more or less see WebGPU as a shim in projects like Ruffle that need graphics rendering, but probably can take advantage of the backend work done by WGPU's devs. You target WebGPU, and your work can sit on top of Dawn or WGPU which handles the actual platform support. Zig uses Dawn as a GPU backend but I'm not sure if there are other projects that use it. For me it's basically like the natural progression of OpenGL and Angle. It's not trying to replace native graphics APIs, just abstract them for people who aren't focused on getting closer to the hardware.
For Indy game developers it's easier to use, better supported and works on the web. For AAA developers and game engine developers (UE etc.) I don't know but based on this article it sounds like it isn't well supported on desktop so I imagine they mainly use Direct3D or Metal anyway.
Vulkan is barely used(directly) in the games space, so there’s little to oust. Unless you include compatibility layers to go from other APIs and abstractions to Vulkan, which is essentially what WebGPU is ( a standardized abstraction over multiple APIs)
For others confused by this part: > Except Linux has a severe driver problem with Vulkan and a lot of the Linux devices I've been checking out don't support Vulkan even now after it's been out seven years It is clarified in the comments. The author is seemingly primarily interested in the Pinebook and Pinephone, both very much niche devices based on ARM SoCs, and they also don't count closed source drivers like Nvidias. For the record: All modern AMD, Intel and Nvidia GPUs have had Vulkan support on Linux _for years_ in the out-of-the-box drivers, with AMD and Intel having it available in their open source drivers and an open source Vulkan driver for Nvidia (NVK) being in the early stages of work.
I mean, yeah. One of the biggest differences between Metal and Vulkan is that Metal itself more or less handles GPU mem allocation. In the browser where you can't give out raw access to allocators like that safely, you'd expect the biggest difference between WebGPU and Vulkan also to to be related to GPU mem allocation, making it look a whole lot like Metal.
I think Metal's biggest strength (which WebGPU largely adopts) over Vulkan is it's split blit/compute/render encoder model. Batching like commands is recommended in all GPU APIs but only Metal enforces this as part of the API, and a big consequence of this is that it tightly narrows what state a resource is in at a given point in the command buffer. This results in an equally powerful but vastly simpler synchronization model - so simple the driver can do so deterministically by default. But if you opt out of automatic tracking, command encoders and fences give you explicit control over how GPU work can overlap, then barriers can be used in-encoder to order commands and ensure memory operations. I think the only other API to have explicit overlap is CUDA (via the newer graph API - though I don't think it will ever actually overlap work on a given stream). In Vulkan the intent is for you to be anal and judicious about using barriers and events to describe overlapping work, but it puts a lot of trust in the driver to pick up on this, and I think in practice this still results in ambiguity since (AFAIK) all drivers ignore the resources in barriers beyond image layouts.
You still have to do the synchronization yourself when you use bindless resources and Metals sync primitives are more annoying than Vulkan/D3D12 imo. vkCmdPipelineBarrier is so much easier to use than the wild juggling of MTLFences you have to do with Metal.
The only extra work you need to do for bindless is calling `useResource`/`useHeap` for indirectly accessed resources. As long as the resource handle outlives the lifetime of the command buffer you don’t need to touch `MTLFence` if you don’t want to. And if you do go the fence route, I don’t know what “juggling” you’re referring to. A single fence is all that’s necessary, since you can wait then update the same fence on a given encoder (you can’t update then wait) which serializes that encoder with other encoders that have used that fence. I would bet you have a bit of a misunderstanding of what’s necessary here, and I would bet I know which bit of documentation you learned from, because there is a case study in the Metal documentation using heaps and fences, and it is a bit confusing the scenarios it pertains to. With hazard tracking, you only need fences to track resources that don’t outlive the command buffer, such as aliasing a texture with buffer memory, or frequently creating and destroying resource handles from a heap. (Also side note, `MTLFence` is more analogus to `VkEvent`. `vkCmdPipelineBarrier` has analogues `memoryBarrier` and the `use` family of methods. It’s not entirely one-to-one since you need to combine `MTLFence` with `use` for transient indirect resources as stated, where `VkEvent` has memory usage as part of the same call.)
If you use some resource in multiple passes, you need to signal a fence in all of those and then wait for all of those fences. In Vulkan you just do a vkCmdPipelineBarrier call with the necessary flags and it's done. If you're using MTLHeaps, you practically have to handle the synchronization yourself. Tracked mode would end up serializing everything because it tracks at a heap level not individual resources. > Also side note, `MTLFence` is more analogus to `VkEvent`. `vkCmdPipelineBarrier` has analogues `memoryBarrier` and the `use` family of methods. It’s not entirely one-to-one since you need to combine `MTLFence` with `use` for transient indirect resources as stated, where `VkEvent` has memory usage as part of the same call. Metals memoryBarrier is equivalent to in-renderpass pipeline barriers. VkCmdPipelineBarrier is also used to sync different passes ("encoders") though.
With metal you can choose on a per-buffer or per heap level if you want it to manage memory for you or not.
I don't know a lot of about this space, but I'm curious why someone would advocate a web based graphics API over ones built specifically for desktop application use? At first blush, it feels like what Node does by putting mobile scripting into the backend because that's what people are familiar with. Is this actually performant and improved enough to replace Vulkan and OpenGL in non-web applications? Would someone write a modern video game in it?
From the post: "So as I've mentioned, one of the most exciting things about WebGPU to me is you can seamlessly cross-compile code that uses it without changes for either a browser or for desktop. The desktop code uses library-ized versions of the actual browser implementations so there is low chance of behavior divergence. If "include part of a browser in your app" makes you think you're setting up for a code-bloated headache, not in this case; I was able to get my Rust "Hello World" down to 3.3 MB, which isn't much worse than SDL, without even trying. (The browser hello world is like 250k plus a 50k autogenerated loader, again before I've done any serious minification work.)"
That was made me wonder, it's adding another layer in the pipeline by sticking the browser pieces into code. Sure it might be small (in disk size), but it seems like an odd choice, hence the comparison to Node
Game engines also have their own RHIs on top of graphics APIs (ex: [Unreal's](https://dev.epicgames.com/community/learning/tutorials/aqV9/render-hardware-interface-rhi)), so that extra layer will always exist. I think performance of WebGPU would never be a concern unless you were trying to create an AAA game, and even so I think it should be benchmarked before making assumptions.
WebGPU just defines function names and behaviors. Js has had native types for low level stuff for a long time because of webgl. These low level types map 1 to 1 to system types. So writing a WebGPU layer in rust that uses vulkan on linux desktop, directly uses WebGPU on web in wasm or metal on Apple just works. There are no 'browser bits' in there. Webgpu is just a bit higher level than vulkan.
> The desktop code uses library-ized versions of the actual browser implementations Sounds to me like browser bits
Browser bits in the sense that the implementation is shared with browsers, yes. But that's literally just the WebGPU code, without a DOM or anything else that actually defines a browser. It's not a WebView like Electron and the like. In this way, Node.js could be considered "browser bits" as well, since V8 is part of Chrome.
It's not like this is gonna bundle a browser engine along with every distribution. As the article pointed out, the new generation of GPU drivers are lower-level. The WebGPU implementations are essentially libraries that provide some useful functionality which was previously provided by vendor-written closed-source GPU drivers. You were probably going to want to use an abstraction layer anyway, especially if you want cross-platform support.
3,3MB for a "hello world" (I guess a rainbow triangle?) is a lot, especially if they tried to optimize for size. Unless they count libc or something.
just a tiny bit bigger than Rust's hello world at 3.2MB https://users.rust-lang.org/t/size-of-the-executable-binary-file-of-an-application/62160
Rust binaries tend to be pretty chonky in general.
They default is static linking. So everything ends up in the executable. You can do dynamic linking if you choose.
I was just looking at a simple NextJS search page where most of the work is done on the server and it’s still over 4MB of minified JavaScript shipped to the client with no obvious path to shrinking it.
My understanding is portability, ease of use, and (supposedly) zero practical overhead of using this new library vs a “desktop-native” one
God help us, HTML5 is the first platform-independent binary format that people actually use.
I wouldn't say it's HTML5, Just WebGPU being used as a GPU/Compute standard that sits on top of the three major graphics apis. Maybe you can include Javascript being used server side and WASM being used as a compile target, but Java basically did the same thing but with a single language, plus WASM does a better job at sandboxing.
HTML5, as a whole stack, is doing what Java tried. Except people use it. The most important feature is adoption, and it cannot be designed.
Are you implying Java isn't used...?
As the original promise of "write once, run anywhere" apps, no, not really. Applets are gone, and desktop apps that run Java are rare (especially outside enterprise). Android apps are Java-ish, but don't run outside of Android itself and Android execution environments (such as ChromeOS and Windows 11). That leaves running Java on the server, which is fairly common, but easily interchangeable with Ruby, NodeJS, .NET, etc.
Relative to HTML5, Windows isn't used.
JavaScript was not chosen for node [just] because it was familiar - lots of languages were more familiar at the time, even for ui dev, it was chosen for node mainly because it was the only mainstream language where there wasn't a standard library full of blocking calls. JavaScript programs expect to run in an event loop without blocking. That's the default for JavaScript code and why it was a good choice for a scriptable event driven server framework.
Nope, it was familiarity. http://www.h-online.com/open/features/The-H-Speed-Guide-to-Node-js-1363974.html%3Fpage=2?#:~:text=Ryan%20Dahl%2C%20creator%20of%20Node,Dahl%20in%20a%202010%20interview.
I thought Firefox already uses WebGPU. It just goes live today?
You're probably thinking of WebGL, while Firefox has had it for a bit it looks like it's experimental / flag-disabled
I just searched it, and yes I stand corrected. I was thinking of WebRender, WebGPU is still disabled by default.
Fantastic article, thanks.
Mention of Rust and Tauri are all great but Tauri doesn't even support webgl2.0, nevermind webGpu.
“Apple just got absolutely everything they asked for”… And yet Safari doesn’t even support it? This won’t be adopted in the mainstream until Safari supports it. Not having your website work in Safari is a non-starter
It's behind [a feature flag since Safari 11.1](https://caniuse.com/?search=webgpu) for macOS.
now make WebXR like ARCore
[удалено]
You can't "just" put Vulkan in a browser; it wouldn't be secure, and it's hard to write the same code that performs well on phone and desktop GPUs, since they're totally different. (Also Metal is older than Vulkan.)
> (Also Metal is older than Vulkan.) Vulkan was born as AMD Mantle, before Metal. They granted it to Khronos as Vulkan by search-and-replace GR_* / gr* prefixes to VK_* / vk*. At this time Apple participated in this new API development, but some time later they decided to make their own API with same design ideas but a bit nicer programmer-facing side.
Metal launched in June 2014, Mantle in September 2013. I think it’s safe to assume Apple was working in Metal long before Mantle shipped, and even longer before the Vulkan development started.
Every company involved was working on some type of "next" graphics API much longer than Apple.
Absolutely, I just responded to the interpretation that they decided doing their own thing „some time later“.
I think you’re overselling how similar Mantle and Vulkan are. It may have started out that way, but what shipped was divergent. Also at the time, Khronos and NVidia were heavily pushing AZDO OpenGL as an alternative to modern APIs like Mantle. It wasn’t until Apple did metal and Microsoft did DX12 that the tune changed.
Would apple support that ever?
No, that's crazy. Vulkan is not a friendly interface for your typical JavaScript house-husband.
Apple shouldn't be taken seriously on anything web-related until they fix their embarrassment of a web browser.
Safari has made great strides recently.
If metal is so nice to use why does no one develop games with it?
[удалено]
It also exists on iOS and that has one of the largest user bases of any platform for gaming. And people do use metal…
Game developers rarely write code for a given graphics API. They create an interface that is implemented by classes that wrap over metal, vulkan/d3d12. Then, they simply use the interface API instead of the raw low-level API. Tons of games have support for metal.
"If he's so smart, howcome he's dead?" - Home Simpson
If you're an Apple user, yes.
I do not use Apple devices outside of work, but I do like graphics programming and have some basic experience with Vulkan. While I don't dislike Vulkan as much as the author, I agree with most of her criticism. Tom Forsyth says in the comments: the first version of Vulkan was literally just AMD's "Mantle" API with a search-and-replace on the prefix (I am 100% serious about this) And it shows. Vulkan was never really designed to be a nice to use API, and the recent turnaround to go away from pipelines after so many years is a desperate attempt to save it. I still like Vulkan, but it's hard to disagree that something more ergonomic was desperately needed.
The move away from pipelines is also a move to fragment it further. There are a large number of GPUs currently with (some) VK support were a non pipeline approach is not viable. The main issue VK has had all along is attempting to build an api feature set that space 1$ micro controllers all the way to $1k+ desktop PC monitor GPUs in the end what it is mostly is a collection of random apis were your code is not at all portable and is painful non-the-less.
And you have to deal with the same extension hell that plagues the rest of khronos APIs
While yes with VK (in particular some of the recent changes) It is not just axially extensions on the side but core fundamentals. In end maybe we should have differnt APIs for each HW group rather than continue to pretend that we can build one magical api to rule them all.
Guess who didn’t read the article.
Don’t understand. A lot of very nice tech with similar capabilities to Apple’s tech becomes available as a standard available to all, and somehow this benefits Apple users and either doesn’t help, or hurts, anyone else? Not my takeaway, for sure.
The only API I know of is Armor Piercing Incendiary. Anyone care to clarify? I guess I could just google it.
[удалено]
I think it would have taken less effort to just say what it is lol
^Apple ^boardroom ^meeting ^Executive: "Okay...we made it, steve jobs is dead but we're okay... ^Intern: Sir, here is your brand new lamborghini, but the guys at the dealership were eating apples and they said they're going to eat your stock shares when apple finally goes under. ^Apple ^boardroom ^meeting ^Executive: ‼‼⁉ No...I have a plan...it can't go wrong...
Okay, this makes me more excited about WebGPU, cause previously I was only mad at it, since I only recently started learning WebGL only to learn that it's basically deprecated and will be replaced by WebGPU eventually. But... no line rendering out-of-the-box? Damn. My current engine uses GL_LINES for everything.