Pannoniae

Great article :D The rabbithole actually goes even deeper because buffering on the read side is almost always good, but reads are often way more latency-sensitive than writes. Which leads to the paradox that increasing the buffer size / prefetching more with mmapping can lead to worse performance due to the added latency. And decreasing the buffer size can have the same effect due to issuing more calls, so in order to squeeze in the optimal throughput/latency ratio on reads you have to tune it per workload.... or just try a few different buffer sizes and see which one works better.

Writes are the opposite, they're usually not RAW (read-after-write), they're "fire and forget", so you don't really care about latency, but you do care a whole a lot about your writes actually arriving... again two competing parameters because the more you batch the writes, the faster they are but the bigger chance of a torn write or data loss. And unlike reads, writes are not idempotent on the application level so ideally you'd want some logic to atomically write a meaningful amount of data so it won't get torn, even if it crashes.

Now in practice just about no one actually does any of this but it's a fun thought :D

it's not like microservices fare better, when you introduce them, you've traded a hard problem for a hard problem and distributed computing...

From the article: "In a note attached to the files, the Department of Peace wrote, "They have our information, so it's only fair that we have theirs.""

small nit, that's not true, since GL4.3 the modern debug message callback is core so you can rely on it. Sure that won't save you on MacOS but if you can target modern OpenGL this isn't a problem in practice

1. monolithic pipelines, pretty much no hardware works like that, the hash-and-cache design makes your design inflexible and adds a ton of overhead

2. WGSL, like come on

3. Hilariously outdated feature set, no mesh shaders, no HWRT, cooperative matrices/tensors, etc.

4. It's security-focused because web untrusted code:tm: so most of the calls are hilariously slow. Yes even the desktop implementations. There's no good webGPU implementation out there

5. it's also not simple to either implement or use. it's basically vulkan's difficulty without any of the advantages....

IMO it's a bit more nuanced than what the author portrays it as. Broadly, software used to be much worse on the micro-level but better on the macro-level i.e. architecture.

Since it was much harder to make stuff, you really had to architect it well or otherwise it would simply fall apart. For example in assembler you need discipline in your calling conventions, layout and so on, otherwise it just corrupted, you needed to follow sensible naming conventions otherwise it degenerated into unreadable label spaghetti and so on.

Nowadays it's the other way around, the micro level is so much better due to libraries, code reuse, LLMs and better languages/tools, you can use highly sophisticated data structures and functions at your fingertips. In exchange, you can afford to skimp on architecture because computers are fast anyway, and the programming languages don't let you make a huge mess. (Most don't have unstructured goto/jumps, can't corrupt memory accidentally, etc.)

However, this has the cost of making larger programs a nightmare to maintain and systems suffering from a "death of thousand cuts" i.e. on the micro level all is well but when you look at the entire system it's a sprawling unreliable mess. This is where rewrites often happen ;)

I mean sure you can do a generic layer and common denominator stuff, basically the kinda stuff webgpu or those rendering abstractions do and that's fair enough, it works well for simpler stuff!

The problem really is that if you do that you'll end up with random weird stalls or perf problems you can't really debug sadly :\

Re GL ye glUniform is usually much faster because you just do a lot less, you're writing a small amount of data directly into constant memory, it doesn't need resource tracking. UBOs / constant buffers come back to the theoretically slow but can-be-made-faster-with-driver-heuristics approach...i.e. if you see a small UBO which is only used as a UBO, you get the same direct constant bank upload

On NV it's quite fast, on AMD it's not really optimised, on intel just use buffersubdata because everything else sucks....

actually yes you could design an alternative API and even implement it....

there's HW references + the linux drivers for AMD (both UMD and KMD), there's refs for NV and their open linux KMD (no UMD though), intel also has HW refs and open drivers for linux

I think it would be possible to put together as long as you don't mind only working for certain hardware, like a prototype you know

I might give it a shot to make a proof-of-concept "high level low level" graphics API ngl if no one else feels like so...

I think there's space for a "two-level" design like have the driver consist of the HW-specific parts, expose things in terms of GPU VAs, explicit sync, explicit memory management, command buffers etc. then have a high-level wrapper over it to provide vaguely GL-ish semantics, and you could intermix the two APIs, obviously you wouldn't be able to get the VA for a high-level object because that'd break the autotracking, if you use low-level you're responsible for syncing, cycling etc.

Sadly it misses many features in C++, it's not really a replacement:(

Any C++ replacement language should support all the features of C++ to be suitable...

You're 100% right...

You can outcode the compiler but ofc that's not a way to go with tens of thousands of instructions and so on. LLMs are just much faster in writing code, just like compilers are much faster at assembling all the functions.

And yes, in a roundabout way, this is Stallman's dream fulfilled to the tip with his printer driver ;)

Many of these people wanted a project to run and gatekeep the people "not worthy enough" to hack on it or to use it. That's changing now, everyone can prompt together a bunch of crap. Fun fact I think I've got like... probably more than ten people into C++ programming simply by helping them prompt AI on how to get started, then they've picked up actual skills along the way. Note, they weren't any kind of programmers before because code is scary, but with a much lower barrier of entry, many more people can do stuff. It's amazing to see.

Rc<RefCell<T>> and Arc<Mutex<T>> says hi

anyway this is especially funny because C++ without compiler-specific pragmas/flags is also a bit mechanistically unsympathetic to the hardware, the whole strict-aliasing saga, you turn it on then you'll suffer with UB and has completely different semantics than hw, you turn it off and you have to manually SSA your code to avoid completely unnecessary loads when accessing fields more than once, the STL is slow, idiomatic C++ often allocates like crazy...

then people saw that and decided that we want more of that, so Rust was born;) (yes I'm being sarcastic here)

I guess the reason C++ fares better traditionally is because even though the actual specification is bonkers, you can mostly coax the compiler into "doing the right thing" as long as you don't mind losing portability and ugly stuff...

or they were lying...

All of those things already got reversed in the past. You just haven't heard of them because they don't really matter without you know, the support, software updates, the ecosystem and so on. What use do you have from one specific version of nvcc or the fw for one specific version of a watch? Your work will be obsolete with the next watch, that's why people haven't bothered so far.

Of course if it's cheaper, someone might, but the real barrier is really the whole first-party support, it's not the technical stuff.

what's wrong with any of these things though, both custom memory allocators and handwritten assembly have their place

do you really care if it's working and it's reliable? (i.e. not an overfit to the current data)