I know I’m a bit late, but here is some more info that may be of use to some.
OpenGL/GLSL
OpenGL, is a set of “extensions” (currently 160 as of OpenGL 4.6), which is a subset of features that has to be implemented by each vendor/manufacturer driver.
To be considered compliant with OpenGL 4.0, you have to implement all its extensions. This base serves as the first stepping toward the next step, OpenGL 4.1, which is basically 4.0 with some more extensions, and so on untill the current OpenGL 4.6.
But as everything in OpenGL 4.0 is also in OpenGL 4.6, a driver for 4.6 will run any 4.0 games. But if you used an extension found in the 4.3 spec, your game won’t work on a 4.2 level driver… Well, most of the time, as it may already have implemented the extension you need, but did not implement yet enough of them to reach the 4.3 specs.
To complicate things even further, you have the cut-to-size versions, aka OpenGL ES, which targets embedded devices with a stripped down version of OpenGL.
As an example of this, you can find here the compatibility matrix for the open-source Mesa collection of drivers : https://mesamatrix.net/
DirectX
DirectX, in contrary, is a monolithic spécification. You either support DX11, or you don’t.
Part of it is implemented in the NT kernel (Linux équivalent in Windows) by MS, through its libraries, and the other is implemented by the GPU manufacturer, in their drivers.
DX version are often tied to Windows versions (DX12 with Windows 11), for multiple reasons. It requires the right features available in the NT kernel, the right hardware to be run, and, lets be honest, it is a great sale argument to try to push users to get the latest Windows version. Same goes with hardware manufacturers, it is a great way to make sure your customers upgrade for a GPU that support the latest DX version.
Subsequent versions are not compatible with each other, that’s why, if you play a DX9 game, you have to install the correct driver that (still) supports DX9, and the DX9 libraries.
To convert or not to convert to new API version ?
To convert a game from DX9 to DX10, you have to rewrite part of the underlying engine, which mean putting ressources and money into it.
Most publisher won’t bother, as the return on investment isn’t good enough to motivate such work. The new features won’t be used, and even though it usually give a substantial boost to performance, those games are often old enough to work exceptionally well on the current era hardware anyway.
So, once again, why bother ?
The specific case of DX12 (and Vulkan)
DX12 is to DX11 what Vulkan is to OpenGL. Both are a dramatic philosophical shift in the graphical API world. Previously, graphical APIs where at a higher level in the stack, which reduced their complexity, at the cost of bigger overhead.
Now with those two new beasts, you get a lot lower in the stack, which mean a lot closer to the hardware itself. You loose some of the ease of use in exchange for a lot less overhead, and thus potentially better performances.
But if your game worked on previous APIs, your are out of luck, as the changes are so radical you’d probably have to rewrite the whole engine renderer. It cost a lot, so only very few games goes this way, mostly the very successful ones, and probably mostly to gain experience with those new paradigms before starting to go all DX12/Vulkan for future games.
I know I’m a bit late, but here is some more info that may be of use to some.
OpenGL/GLSL
OpenGL, is a set of “extensions” (currently 160 as of OpenGL 4.6), which is a subset of features that has to be implemented by each vendor/manufacturer driver.
To be considered compliant with OpenGL 4.0, you have to implement all its extensions. This base serves as the first stepping toward the next step, OpenGL 4.1, which is basically 4.0 with some more extensions, and so on untill the current OpenGL 4.6.
But as everything in OpenGL 4.0 is also in OpenGL 4.6, a driver for 4.6 will run any 4.0 games. But if you used an extension found in the 4.3 spec, your game won’t work on a 4.2 level driver… Well, most of the time, as it may already have implemented the extension you need, but did not implement yet enough of them to reach the 4.3 specs.
To complicate things even further, you have the cut-to-size versions, aka OpenGL ES, which targets embedded devices with a stripped down version of OpenGL.
As an example of this, you can find here the compatibility matrix for the open-source Mesa collection of drivers : https://mesamatrix.net/
DirectX
DirectX, in contrary, is a monolithic spécification. You either support DX11, or you don’t.
Part of it is implemented in the NT kernel (Linux équivalent in Windows) by MS, through its libraries, and the other is implemented by the GPU manufacturer, in their drivers.
DX version are often tied to Windows versions (DX12 with Windows 11), for multiple reasons. It requires the right features available in the NT kernel, the right hardware to be run, and, lets be honest, it is a great sale argument to try to push users to get the latest Windows version. Same goes with hardware manufacturers, it is a great way to make sure your customers upgrade for a GPU that support the latest DX version.
Subsequent versions are not compatible with each other, that’s why, if you play a DX9 game, you have to install the correct driver that (still) supports DX9, and the DX9 libraries.
To convert or not to convert to new API version ?
To convert a game from DX9 to DX10, you have to rewrite part of the underlying engine, which mean putting ressources and money into it.
Most publisher won’t bother, as the return on investment isn’t good enough to motivate such work. The new features won’t be used, and even though it usually give a substantial boost to performance, those games are often old enough to work exceptionally well on the current era hardware anyway.
So, once again, why bother ?
The specific case of DX12 (and Vulkan)
DX12 is to DX11 what Vulkan is to OpenGL. Both are a dramatic philosophical shift in the graphical API world. Previously, graphical APIs where at a higher level in the stack, which reduced their complexity, at the cost of bigger overhead.
Now with those two new beasts, you get a lot lower in the stack, which mean a lot closer to the hardware itself. You loose some of the ease of use in exchange for a lot less overhead, and thus potentially better performances.
But if your game worked on previous APIs, your are out of luck, as the changes are so radical you’d probably have to rewrite the whole engine renderer. It cost a lot, so only very few games goes this way, mostly the very successful ones, and probably mostly to gain experience with those new paradigms before starting to go all DX12/Vulkan for future games.