I think it would be much nicer, although unrealistic at the moment given the number of combinations of GPU vendors and variety of hardware, to directly target the underneath GPU ISA machine code.
Since I can write a simple compiler to target x64 machine code, it should be possible to write one to target my GPU.
Though, I'm certain that vendor lock is probably more profitable for them.
My thoughts on this, as a person who has recently coming around to working in this space is that up to now the convenience and "simplicity" of working in CUDA as it is has been a giant moat for NVIDIA. Having a whole toolchain with a C++ dialect and a giant extant pile of code out there that looked familiar to people meant they've "won" the AI wars.
And in that context NVIDIA had every motivation to keep their SDK somewhat abstracted higher up the chain and fully under their control and then be free to innovate in the lower bits. And this served them well as well as their customers.
My sense is that now with agent driven development this is basically evaporating. Agents are capable of at least prototyping/writing kernels for any hardware and ISA. e.g. OpenAI built their own custom hardware and ISA for it and then set agents loose on it writing kernels and claims great success. At least they're claiming this. And from my own experiences as a n00b entering this space, I can believe it.
TLDR I don't think vendor lock on the software side is going to work out for them as a strategy.
But luckily for them they continue to have really good hardware and good access to semiconductor fabrication. But just look at HotChips 2026 a couple weeks ago and look at the huge variety of new inference hardware coming down the pipe which looks completely unlike NVIDIA/CUDA.
I'm a software engineer with around two years of professional experience using Java, Python, Javascript and SQL (Postgres, Oracle)
Outside of work, I focus on systems programming and language implementation. I'm currently building a compiler in C from scratch, and I'm particularly interested in compilers, interpreters, runtimes, developer tools and low-level software in general.
I'm open to systems software, compiler or back-end roles, and I'm also interested in startup environments.
I'm a software engineer with around two years of professional experience using Java, Python, Javascript and SQL (Postgres, Oracle)
Outside of work, I focus on systems programming and language implementation. I'm currently building a compiler in C from scratch, and I'm particularly interested in compilers, interpreters, runtimes, developer tools and low-level software in general.
I'm open to systems software, compiler or back-end roles, and I'm also interested in startup environments.
I kind of don't see the benefit, as it's still going to use only the window, input and platform integrations features, while SDL3 has a whole software renderer built-in and much more.
This fixed a lot of bugs related to input. If you scroll down to the bottom of the page you can see all the bug fixes from this snapshot, there are a lot related to input.
You can compile in only the used stuff with various build flags, not sure if they did that though. I've done that before to make a pared down SDL that only does audio playback.
SDL2 and SDL3 both have hardware accelerated 2D renderers, appropriately called SDL_Renderer. You can tell SDL to upload pixel buffers to GPU textures and tell SDL to draw those textures on the screen with various transformations and color effects.
SDL3 added a way to tell SDL to render vertex-based geometry as well: https://wiki.libsdl.org/SDL3/SDL_RenderGeometry. Those vertexes can have 3D positions, so that counts as a 3D renderer I guess. Though of course the GPU is doing the heavy lifting; SDL is just exposing a little bit more of the GPU's functionality. It's quite useful for some 2D applications as well. I remember reading about how it could enable more efficient drawing of 2D plots or cleaner ImGUI integration, though I don't remember details.
If you want to get pedantic the hardware rasterizer in your GPU doesn't rasterize "3D triangles" either. Any notion of '3D' comes from how you project your vertices when transforming them through your coordinate spaces. Though the perspective divide needed to make perspective projection work is baked in, but otherwise NDC is a 2D space. Z only exists for the depth buffer/depth test and perspective correct interpolation. The "shape" of the triangle on screen isn't affected by it.
As long as you can draw 2D triangles there's nothing stopping you from drawing a "3D" scene with a software transform pipeline. Depth sorting gets fun without a z-buffer though.
I'm a software engineer with around two years of professional experience using Java, SQL and JavaScript.
Outside of work, I focus on systems programming and language implementation. I'm currently building a compiler in C from scratch, and I'm particularly interested in compilers, interpreters, runtimes, developer tools and low-level software in general.
I'm open to systems software, compiler or backend roles, and I'm also especially interested in startup environments.
Compatibility with PUC Lua versions after 5.1 is especially hard, given that more or less arbitrary syntactic and semantic but also C API changes have been introduced in every version since then.
That is mostly the reason why LuaJIT is stuck with a mix of 5.1 and toggled 5.2 features.
Since I can write a simple compiler to target x64 machine code, it should be possible to write one to target my GPU.
Though, I'm certain that vendor lock is probably more profitable for them.
reply