Pannoniae
The only even slightly tricky part is like "don't mess unicode up", rest is straightforward. Sure it can be complicated with logging sinks, configurability, when to flush, monitoring and so on but in many cases you just don't need all that. You just build it whenever you do need it.
magnet:?xt=urn:btih:0d366035664fdf51cfbe9f733953ba325776e667&dn=EleutherAI_ThePile_v1&tr=https%3A%2F%2Facademictorrents.com%2Fannounce.php&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce
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
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....
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 ;)
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....
Look at a GDC talk (https://d29g4g2dyqv443.cloudfront.net/sites/default/files/ak...), efficient dx11 is also "reinvent a diy memory allocator" level except that you don't have much control.
btw you can run dx11 on other platforms because dxvk exists, but while d3d9vk is a solid idea (high-level API, lowering to vulkan often makes it much faster than the crummy MS d3d9 runtime + DDI combo), d3d11vk is just often a wash or even a regression. I've had to debug dxvk-only perf problems a bit too many times...
anyway, point is, it's not really an easy-to-use or intuitive API
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.
Any C++ replacement language should support all the features of C++ to be suitable...
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.
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...
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.
do you really care if it's working and it's reliable? (i.e. not an overfit to the current data)
but it's simply impossible to make a device which can keep a secret in presence of an attacker with physical access. It might be very hard but it's literally impossible, even embedded hardware keys can be extracted
There's the "inline editing" paradigm - independent sessions, describe each micro-change individually. This is good for quick responses but requires you to re-describe the context every time. There's also the "use an agent as a fancy code editor" stuff - just list out all the functions and the changes you want to make in them. This is a better workflow IMO but the trap is that it doesn't feel "productive" compared to one-shotting it, irrespective of the actual quality.
So people gravitate towards one-shot agentic prompts without a human in the loop.
i.e. have few, generic rules, and have their boundaries be constrained by implementation. The important part is consistency. There is a boundary, it's just unstated. If you're enforcing stuff arbitrarily, this won't work, but if you're mostly consistent this can make things smooth by eliminating the space for rules lawyering, drama and schemes by getting everyone in the community to "sign up" to the status quo.
When you're new you don't know where you're at so you join, observe and listen. After some time, you're familiar with the norms so you can engage with them, advocate for changes, etc.
Of course, the alternative is codified rules for everything, but the moral hazard there is that the more rules you add, the more they're likely to be contradictory, leading to the possibility of arbitrary enforcement nonetheless despite the pretence that the rules are specific and clear so the enforcement isn't arbitrary at all.
With that many elements you'd be better off storing the elements as a tuple or a struct, but people often reach for a generic array container regardless.
Traditionally you've opened to a PR only to get closed for a style/procedural issue or get ghosted. You often didn't fork because maintenance is a hassle. Less so with LLMs, you know?
Nowadays you can just implement your change and vibe-fork it...
Completely missing the part they didn't ask for permission to mod the base game either..... and that Thaumcraft (the original mod) had assets consisting mostly of random images copied off google images. Yes you can't make that up. "You can't steal what I've rightfully stolen!"
But it's much easier and makes the game faster to just not bother, compile the windows version and let people play under Proton/Crossover :)
5.5 is even better. It's so glorious. I've got some modern game. I don't have the source. I'm curious how it works. After a day and a half it's already 5% bytematched ;)