undefined
I’ve heard others make the point I’m trying to make like this: if you use this dialect of the technology, would it recognize itself in the mirror?
Meaning, like, does the AZDO dialect of OpenGL look like OpenGL? Does it smell like OpenGL?
For comparison: you can write C++ style code but spell it in Lisp, and you can write Lisp style code but spell it in C++, and both of those are poor uses of programming languages
Right, I think that’s why I had such a strong reaction to this AZDO talk in particular. The techniques they were describing weren’t iterative improvements on top of what you already have. They were describing fundamentally changing how your algorithms are structured. And they described a few different ways to do it, and indicated that you should use whichever is supported by the user’s device at runtime. Which just seems totally untenable to me.
I do think it is interesting, though, that Vulkan is in the same general situation now… the OpenGL registry lists 337 ARB or KHR or EXT extensions across the past 33 years, and the Vulkan registry lists 273 KHR or EXT extensions across the past 9 years.
I don’t think it’s a coincidence; I think it’s actually a result of the work flow that Khronos uses.
I don’t think you are kidding 
️
Review: 5/10 I just can't rate it higher. 11-year-ago me would have rated this way higher, but 2025 me just thinks that this is kind of a clusterfuck
... what if *some* of those are present but not others? Are you expected to totally rewrite your rendering algorithm? How are you supposed to know whether or not most of your potential customers have which extensions? Can you rely on *anything*???
They presented some microbenchmarks where they showed that things go faster if you have these extensions, which is cool, but my head was basically spinning by what the presenters seem to be implicitly asking every developer to do in their engine
4/5
So they talked about, like, if you have persistently mapped buffers, you can just write data into them without making any API calls (provided you synchronize correctly), and if you have bindless textures, you don't have to rebind anything between draw calls, and if you have sparse textures you don't even need multiple textures in the first place and can instead just have a single humongous texture with only part of it mapped to physical memory...
So like that's cool and stuff, but like...
3/5
These were the extensions presented:
- GL_ARB_buffer_storage
- GL_ARB_map_buffer_range
- GL_ARB_draw_indirect
- GL_ARB_multi_draw_indirect
- GL_ARB_indirect_parameters
- GL_ARB_shader_draw_parameters
- GL_ARB_bindless_texture
- GL_ARB_sparse_texture
- GL_ARB_shader_atomic_counters
... and any subset of these may be present on any of your customers' machines. How the hell is any developer supposed to do anything sensible in this situation???
2/5
GDC 2014: "Approaching Zero Driver Overhead in OpenGL (Presented by NVIDIA)" by Cass Everitt, Tim Foley, John McDonald, Graham Sellers of NVIDIA, Intel, NVIDIA, AMD https://gdcvault.com/play/1020791/Approaching-Zero-Driver-Overhead-in
This is the famous AZDO talk!!! This was cool because it was given by all of the major GPU vendors.
I remember watching this back in 2014, and thinking to myself "wow, OpenGL can do so much!!!" but now that I watch it again in 2025, my main reaction now is actually horror at extension hell.
1/5