3 ms·

OpenGL is not going away (huge existing code basis etc.), but I'm not sure how much continued development it's going to see. Is there any case where you would

by creshal 11y ago

OpenGL is not going away (huge existing code basis etc.), but I'm not sure how much continued development it's going to see. Is there any case where you would not want to use Vulkan in a new project?

bitmapbrother 11y ago
Sure, it's not going away. Perhaps slowly fading away would be a better description. Any new projects not using Vulkan would be at a serious performance disadvantage in comparison to its competitors. The switch to Vulkan will be swift, at least, in the game development community.
bryanlarsen 11y ago
I think that Vulkan would almost always be the wrong choice for a new project. A higher level abstraction is probably the right choice, whether that would be OpenGL or a third party game engine or CAD kernel or visualization engine etc depends on the project. https://twitter.com/renderpipeline/status/699501481632886786 https://twitter.com/renderpipeline/status/699501481632886786
- creshal 11y ago
  > or a third party game engine All major engines already have announced migrating to Vulkan and/or its platform-specific counterparts (DX12/Metal), so you'd be indirectly using Vulkan anyway.
  - TazeTSchnitzel 11y ago
    Well, when you write in Haskell and compile it to x86-64 machine code, you are indirectly using x86-64 machine code. That doesn't mean a Haskell programmer would like to write x64 asm, they're on quite different levels of abstraction.
w0utert 11y ago
>> Is there any case where you would not want to use Vulkan in a new project? Any project with graphics simple enough that it already easily hits the desired performance on baseline hardware? If you don't need full control or maximum performance, something like OpenGL ES 2 will still be a lot easier to program because it does a lot of things for you that you would have to do yourself when using Vulkan. Also, the installed base of supported hardware/drivers will be much larger for the foreseeable future. I've looked into Metal (Apple's take on an API along the same lines as Vulkan) for my simple 2D game, but for my purpose it does not offer any benefits. The same thing would hold for Vulkan, in case I would want to port to some other platform.
- creshal 11y ago
  > If you don't need full control or maximum performance, something like OpenGL ES 2 will still be a lot easier to program because it does a lot of things for you that you would have to do yourself when using Vulkan. Which is normally done by the game engine. And the big ones are already migrating to Metal et. al. Is the market for self-made game engines still that big? From a consumers perspective, virtually everything is on one of the "big" engines nowadays (when in doubt, Unity).
  - dragonwriter 11y ago
    > Which is normally done by the game engine. Sure, for games. Not all projects using 3d graphics are games, or use game engines.
zanny 11y ago
The better case is to use one of the inevitably many rendering libraries that will be developed for Vulkan that abstract away the implementation details in much the same way OpenGL did before. The problem with OpenGL was that it was the lowest level of access you got to the device - a high level giant API that hides the implementation behind it. Which made it a massive PITA to implement for hardware vendors, and slow to adapt to changes in the GPU landscape. It is very likely we will see an implementation of OpenGL that compiles to Vulkan in the same way we are seeing immediate development of VK -> Metal compilers and will probably see DX12 -> Vulkan as well. You just need an API wrapper and a shader translator that takes their respective shader formats and compiles them to SPIR-V rather than the original targets.

by creshal 11y ago

OpenGL is not going away (huge existing code basis etc.), but I'm not sure how much continued development it's going to see. Is there any case where you would not want to use Vulkan in a new project?

bitmapbrother 11y ago

Sure, it's not going away. Perhaps slowly fading away would be a better description. Any new projects not using Vulkan would be at a serious performance disadvantage in comparison to its competitors. The switch to Vulkan will be swift, at least, in the game development community.

bryanlarsen 11y ago

I think that Vulkan would almost always be the wrong choice for a new project. A higher level abstraction is probably the right choice, whether that would be OpenGL or a third party game engine or CAD kernel or visualization engine etc depends on the project. https://twitter.com/renderpipeline/status/699501481632886786 https://twitter.com/renderpipeline/status/699501481632886786

creshal 11y ago
> or a third party game engine All major engines already have announced migrating to Vulkan and/or its platform-specific counterparts (DX12/Metal), so you'd be indirectly using Vulkan anyway.
- TazeTSchnitzel 11y ago
  Well, when you write in Haskell and compile it to x86-64 machine code, you are indirectly using x86-64 machine code. That doesn't mean a Haskell programmer would like to write x64 asm, they're on quite different levels of abstraction.

w0utert 11y ago

>> Is there any case where you would not want to use Vulkan in a new project? Any project with graphics simple enough that it already easily hits the desired performance on baseline hardware? If you don't need full control or maximum performance, something like OpenGL ES 2 will still be a lot easier to program because it does a lot of things for you that you would have to do yourself when using Vulkan. Also, the installed base of supported hardware/drivers will be much larger for the foreseeable future. I've looked into Metal (Apple's take on an API along the same lines as Vulkan) for my simple 2D game, but for my purpose it does not offer any benefits. The same thing would hold for Vulkan, in case I would want to port to some other platform.

creshal 11y ago
> If you don't need full control or maximum performance, something like OpenGL ES 2 will still be a lot easier to program because it does a lot of things for you that you would have to do yourself when using Vulkan. Which is normally done by the game engine. And the big ones are already migrating to Metal et. al. Is the market for self-made game engines still that big? From a consumers perspective, virtually everything is on one of the "big" engines nowadays (when in doubt, Unity).
- dragonwriter 11y ago
  > Which is normally done by the game engine. Sure, for games. Not all projects using 3d graphics are games, or use game engines.

zanny 11y ago

The better case is to use one of the inevitably many rendering libraries that will be developed for Vulkan that abstract away the implementation details in much the same way OpenGL did before. The problem with OpenGL was that it was the lowest level of access you got to the device - a high level giant API that hides the implementation behind it. Which made it a massive PITA to implement for hardware vendors, and slow to adapt to changes in the GPU landscape. It is very likely we will see an implementation of OpenGL that compiles to Vulkan in the same way we are seeing immediate development of VK -> Metal compilers and will probably see DX12 -> Vulkan as well. You just need an API wrapper and a shader translator that takes their respective shader formats and compiles them to SPIR-V rather than the original targets.