From scratch OpenGL and shaders with raw Xlib
hereket.com
hereket.com
(The only thing on the top of my head that absolutely requires Xlib is some niche Vulkan stuff; e.g. VK_EXT_acquire_xlib_display unfortunately has no XCB analogue.)
Xlib certainly is quirky, in particular around error handling, though.
> Calls that don't require a response from the X server are queued in a buffer to be sent as a batch of requests to the server. Those that require a response flush all the buffered requests and then block until the response is received. [1]
X11, the protocol is a distributed systems protocol, built on asynchronous message passing, that outputs to the screen as a side effect. Xlib hides the nature of the underlying protocol, and makes it very hard to pipeline things that should be pipelined for maximum performance. Xcb separates out sending a request and waiting for a response, so if you absolutely need the response before you continue, you can do that, but you can also request many things and then wait when you need them.
Of course, you should just skip GLX nowadays and use EGL instead, which I'm pretty sure does work with XCB.
- A 500-line (non-OpenGL-compatible) software rasterizer: https://github.com/ssloy/tinyrenderer/wiki.
- A “hello Wayland” app written in C without libwayland or anything else: https://gaultier.github.io/blog/wayland_from_scratch.html.
- A “hello X11” app written in x86-64 assembly(!) without libX11, libxcb, or anything else: https://gaultier.github.io/blog/x11_x64.html.
IIRC OpenGL is implemented at the driver level.
I’m sure you could find a, potentially dated, walkthrough of mesa’s code if you looked hard enough.
From that starting point there's a natural progression to tackling raw Vulkan, D3D12 or Metal if you outgrow what the WebGPU libraries are capable of. If you start from OpenGL instead then you have to unlearn all the nonsensical abstractions it teaches you.
If you have sufficiently low level API that works similarly, then the benefit of two low level APIs is relatively direct translations are possible.
Also, OpenGL never really quite made it into game consoles, only in some ways not fully compatible, so if they are a target, one already needs to handle multiple APIs anyway.
At worst you'd end up having to use an OpenGL middleware thing in the middle of you and the lower abstraction level API. Like yes, OpenGL is crufty. It's also just not good in many ways, but in many ways it's simple. The lessons learnt from it also informed Khronos on the design of Vulkan, so even for that, it's nice to be able to see just where some of the design decisions come from.
Also, not everyone develops for Apple and so their deprecation is less compelling than, say, Khronos officially stopping development on the API ;)
> Also, not everyone develops for Apple and so their deprecation is less compelling than, say, Khronos officially stopping development on the API ;)
Have they not stopped? The last major update to OpenGL was six years ago, around the time Vulkan went public. I recall there initially being talk of OpenGL continuing to be developed alongside Vulkan but that just hasn't happened.
While this is true, for somebody who is starting from scratch there is a lot to learn before getting to the level at which thinking in terms of PSO is important, and it can be easier to get there via OpenGL, which btw still teaches you a decent chunk of GPU-friendly patterns (assuming of course we are talking about "modern" OpenGL and not display lists and such...). Also, with a good command of OpenGL, one can start trying to understand and re-implement rendering techniques spanning from deferred/forward+/clustered lighting, the various shadowing techniques and even HW raytracing eg. via the GLSL_NV_ray_tracingextension, which is - in my opinion - the more important side of learning GPU-accelerated rendering.
Well sure, but as the other commenter pointed out, there's a lot of stuff you'd have to learn about how GPUs and 3D rendering with them actually works, before ever getting to concepts such as PSOs. Like think just the kind of thinking that you'd have to go through just to get a handle on things such as how shaders work, how to pack the data so that it can be efficiently used from the shader, uploading textures and so on. And for these kinds of things, OpenGL is as good a learning platform as any.
> Have they not stopped? The last major update to OpenGL was six years ago, around the time Vulkan went public. I recall there initially being talk of OpenGL continuing to be developed alongside Vulkan but that just hasn't happened.
That's what I'm saying tho. Khronos has stopped OpenGL development, which is a way more prescient and compelling reason to not use the API (aside from if you're targeting more "legacy" hardware that doesn't support Vulkan, like you might if you're developing a Wayland compositor, for example, where you might still like some 3D hardware acceleration to complement hardware planes), than the idea that because Apple doesn't support it, it shouldn't be used.
OpenGL was, after all, always a 2nd-class citizen on Apple. Even back in the OpenGL 3 days, Apple got stuck in OGL 2 for whatever reason.
Oh, and at least with Mesa's Zink[0], you can absolutely use OpenGL even if your hardware natively only support Vulkan. That's not a problem.
This is definitely true, but newer OpenGL gives you indirect rendering and bindless textures which is about as good as you can get even in Vulkan in terms of driver overhead.
Regardless, much like picking a programming language to learn, it doesn’t really matter what you start with. Most concepts transfer over and any graphics programmer will know more than one graphics API anyways.
It’s funny you mention PSOs because there is now an extension to not use them in Vulkan (VK_EXT_shader_object) because it turns out it’s not how the hardware works [1].
[1]: https://github.com/KhronosGroup/Vulkan-Docs/blob/main/propos...
Is not OpenGL a good starting point if you want to transition to Metal or Vulkan later on?
If not, should I seek out the "new flavor" to learn graphics?
If you bring extensions to WebGPU for native into the picture, then it is no better than the spaghetti way of dealing with extensions in OpenGL and Vulkan.
Besides, if you pick one native API (say, Vulkan), then you're still going to go through translation layers on the platforms it isn't native to, so wgpu isn't any different. Or you can write multiple backends for different platforms, which multiplies the amount of work you have to do. Either way, saying that wgpu gives you "no added benefit" is silly.
Not the WebGPU or WebGL per se, but teaching engineers not familiar with Javascript or web development, local servers, CORS, etc.. adds a whole new level of difficulty.
I don't think there is any good replacement for OpenGL as of now (2024). I hoped there would be higher-level Vulkan wrappers coming out to bridge the gap but even AMD's attempt (V-EZ) got abandoned fairly soon.
Maybe webgpu will win because Apple Google and Microsoft will have to have good support for it but today it's not even available in all browsers yet. When it is released it will be missing features the other middleware solutions have and we'll have to wait for WebGPU Next to be available.