4 ms·

It's cool seeing the tech develop to run D3D/OpenGL on Vulkan/DX12/Metal, moving a lot of code out of drivers and in to libraries. But in the long term apps sho

It's cool seeing the tech develop to run D3D/OpenGL on Vulkan/DX12/Metal, moving a lot of code out of drivers and in to libraries. But in the long term apps should all end up using Vulkan/DX12/Metal themselves directly (or modern derivatives) - so there won't be many uses for the old legacy D3D/OpenGL stacks left, so these libraries will probably fall out of use too. So, nice for the short/medium term, but probably no longer relevant in the long term.

devwastaken 6y ago
I don't believe opengl is going anywhere. It's still heavily embedded in modern gaming everywhere. If anything a translation layer from opengl to vulkan would be the direction.
Tuna-Fish 6y ago
> But in the long term apps should all end up using Vulkan/DX12/Metal themselves directly In terms of "a typical 3d app writes directly to the API", they really shouldn't. The fundamental shift between DX12/Vk and the earlier APIs is that the old graphics APIs were fundamentally about graphics, in the sense that they described a specific way to draw graphics, and then in conjunction with hardware translated that into something that ran well. Originally, there were many very different ways this was done. Over time the hardware implementations all converged towards a common form, and game developers found themselves not really coding against the old APIs as designed, but twisting it's use into something that translated into what they wanted on the actual hardware. (That they knew and understood because of the consoles that just let the devs target the same or very similar hardware directly without a translation layer on top of it.) DX12/Vk then approaches the API design from a completely different perspective: They are designed to provide an efficient interface to the functionality that is available in hardware. Much of this is graphics-specific, simply because the hardware is meant to run graphics, but in a very real way the API isn't about the graphics, it's about the hardware. Vk doesn't have the kind of simple graphics pipeline that OpenGL devs are used to, because it's outside the context of the API. You, the developer, are supposed to make your own pipeline, out of the pieces of hardware-supported operations that the API exposes. Which brings this back to my point: The typical game dev has no interest or need to learn DX12/Vk, because they fundamentally do not provide what the devs need or want. Instead, game devs should largely build their work on top of an actual graphics pipeline. Right now, most devs get that pipeline out of the large 3rd-party game engines (UE, Unity), but if you are not using those, OpenGL or DX11 is not a bad choice, and a lot of studios still do that, and probably will for a very long time yet. Hopefully over time someone will design a good separate graphics pipeline that runs on DX12/Vk, that is designed purely to be a good abstraction for graphics, and will do that well enough that it will replace most use of the old APIs. However, this will take a very long time, simply because of the human factors. (I already know DX11/OGL, why would I learn something new?) But even when it does, D3D/OpenGL will not be replaced by DX12/Vk, they will be replaced by a new translation layer that sits on top of it and is an analogue of these translation layers being built now.
- MaxBarraclough 6y ago
  To add to this: we've already seen high-budget games with worse performance on Direct3D 12 than on Direct3D 11. Making good use of the new APIs is no small task.
- AshleysBrain 6y ago
  The last part is what I was referring to by "modern derivatives". OpenGL is widely regarded to have a poor API. If you want a higher level API, wouldn't you want a new modern layer with a nicer API instead? How long will technologies like OpenGL last just because people have already learnt them? Surely eventually we will switch over to better alternatives?
  - pjmlp 6y ago
    That has been covered by middleware for years, which is another reason why most professional studios don't care about 3D API portability as much as FOSS crowd thinks.
flohofwoe 6y ago
Keeping older D3D and GL versions alive via emulation layers on top of modern APIs totally makes sense also for the future. Only few applications and games actually benefit from the new APIs, but the new APIs require a lot more work and detailed knowledge of what's going on under the hood (with the exception of Metal vs GL of course, Metal is a lot nicer to work with than GL; but if you compare D3D11 to Vulkan or D3D12, then D3D11 definitely is the more "ergonomic" API - at least for rendering traditional triangle geometry).
feanaro 6y ago
Apart from other excellent answers, there will also always be a need to run legacy software. Surely we don't want to lose the ability to play old games, for instance?

devwastaken 6y ago

I don't believe opengl is going anywhere. It's still heavily embedded in modern gaming everywhere. If anything a translation layer from opengl to vulkan would be the direction.

Tuna-Fish 6y ago

> But in the long term apps should all end up using Vulkan/DX12/Metal themselves directly In terms of "a typical 3d app writes directly to the API", they really shouldn't. The fundamental shift between DX12/Vk and the earlier APIs is that the old graphics APIs were fundamentally about graphics, in the sense that they described a specific way to draw graphics, and then in conjunction with hardware translated that into something that ran well. Originally, there were many very different ways this was done. Over time the hardware implementations all converged towards a common form, and game developers found themselves not really coding against the old APIs as designed, but twisting it's use into something that translated into what they wanted on the actual hardware. (That they knew and understood because of the consoles that just let the devs target the same or very similar hardware directly without a translation layer on top of it.) DX12/Vk then approaches the API design from a completely different perspective: They are designed to provide an efficient interface to the functionality that is available in hardware. Much of this is graphics-specific, simply because the hardware is meant to run graphics, but in a very real way the API isn't about the graphics, it's about the hardware. Vk doesn't have the kind of simple graphics pipeline that OpenGL devs are used to, because it's outside the context of the API. You, the developer, are supposed to make your own pipeline, out of the pieces of hardware-supported operations that the API exposes. Which brings this back to my point: The typical game dev has no interest or need to learn DX12/Vk, because they fundamentally do not provide what the devs need or want. Instead, game devs should largely build their work on top of an actual graphics pipeline. Right now, most devs get that pipeline out of the large 3rd-party game engines (UE, Unity), but if you are not using those, OpenGL or DX11 is not a bad choice, and a lot of studios still do that, and probably will for a very long time yet. Hopefully over time someone will design a good separate graphics pipeline that runs on DX12/Vk, that is designed purely to be a good abstraction for graphics, and will do that well enough that it will replace most use of the old APIs. However, this will take a very long time, simply because of the human factors. (I already know DX11/OGL, why would I learn something new?) But even when it does, D3D/OpenGL will not be replaced by DX12/Vk, they will be replaced by a new translation layer that sits on top of it and is an analogue of these translation layers being built now.

MaxBarraclough 6y ago
To add to this: we've already seen high-budget games with worse performance on Direct3D 12 than on Direct3D 11. Making good use of the new APIs is no small task.
AshleysBrain 6y ago
The last part is what I was referring to by "modern derivatives". OpenGL is widely regarded to have a poor API. If you want a higher level API, wouldn't you want a new modern layer with a nicer API instead? How long will technologies like OpenGL last just because people have already learnt them? Surely eventually we will switch over to better alternatives?
- pjmlp 6y ago
  That has been covered by middleware for years, which is another reason why most professional studios don't care about 3D API portability as much as FOSS crowd thinks.

flohofwoe 6y ago

Keeping older D3D and GL versions alive via emulation layers on top of modern APIs totally makes sense also for the future. Only few applications and games actually benefit from the new APIs, but the new APIs require a lot more work and detailed knowledge of what's going on under the hood (with the exception of Metal vs GL of course, Metal is a lot nicer to work with than GL; but if you compare D3D11 to Vulkan or D3D12, then D3D11 definitely is the more "ergonomic" API - at least for rendering traditional triangle geometry).

feanaro 6y ago

Apart from other excellent answers, there will also always be a need to run legacy software. Surely we don't want to lose the ability to play old games, for instance?