5 ms·

NOT a successor. It's a very different beast. It's frequently described as a "low-level" API, but "explicit API" is more correct. It gives you control (and resp

NOT a successor. It's a very different beast. It's frequently described as a "low-level" API, but "explicit API" is more correct. It gives you control (and responsibility) for things that happen behind your back in OpenGL, e.g. semantics of sharing of resources between the CPU and the GPU, explicit separate access to many GPUs, explicit separation of command buffer building and submission etc. It will live side-by-side with OpenGL for the foreseeable future. It's just targeting the same general area (graphics using GPUs) and is standardized by the same folks (Khronos).

norea-armozel 11y ago
I'm glad you clarify this because I thought it was meant not to replace OpenGL but to make it easier for certain developers to optimize and override GL behavior as needed.
- veli_joza 11y ago
  Vulkan is indeed intended as a replacement, but in following decade OpenGL will still have to be supported so that legacy applications can still run. New game engines and other graphically intensive applications will probably target both OpenGL and Vulkan, at least until Vulkan is supported on most of hardware available.
- shmerl 11y ago
  > I thought it was meant not to replace OpenGL but to make it easier for certain developers to optimize and override GL behavior as needed. It is intended to replace OpenGL eventually. It matches modern hardware and unlike OpenGL allows using parallelism without shared state.
ekianjo 11y ago
Well it may not be a successor, but since Khronos' resources are limited you can bet there will be more updates coming to Vulkan than the OpenGL standard.
mtgx 11y ago
Maybe not a direct successor (as in OpenGL will now be deprecated), but still a defacto successor if all game engines adopt it. The bulk of the low-level work will be done by game engines, and developers won't have to worry too much about it. So developers will get the best of both words: easy to use and higher performance.
nothis 11y ago
That's a big "NOT", though, for such subtle semantics and IMO more confusing than helpful. It's by the same people, for the same thing. It's set to replace OpenGL in the long term, no? I'd say that the only reason not to call it a successor would be if OpenGL offered features that Vulkan can't provide which I don't think is the case.
- msbarnett 11y ago
  > It's set to replace OpenGL in the long term, no? No. Not at all. That's why it's not a successor. If you're a huge games company writing an engine, sure, it's a better fit for you than OpenGL. If you're almost any other visualization use-case, it's too low level and you'll want to remain with the higher level OpenGL API. It's an alternative, not a replacement. At most OpenGL might come to be a friendly API implemented on top of Vulkan, as opposed to beside.
  - wlesieutre 11y ago
    Historically there's been a big divide between what the game engine vendors vs the CAD vendors want out of the OpenGL standard, so this split is a good thing for both. The existing OpenGL systems stick around without dragging game performance down with them. EDIT: Some historical discussion in this reddit thread https://www.reddit.com/r/vulkan/comments/3hkdek/opengl_support_into_the_future/ https://www.reddit.com/r/vulkan/comments/3hkdek/opengl_suppo...
  - nothis 11y ago
    Why isn't it a subset of OpenGL, then? Maybe that's what's confusing? It sounds like the most typical usage would be to implement things in OpenGL and then do a few hardcore optimization tasks in Vulkan. Why not add that access to OpenGL and put a "use at your own risk" disclaimer in front of it? Or are they so incompatible you have to write your entire graphics code in either but never both?
    - msbarnett 11y ago
      > It sounds like the most typical usage would be to implement things in OpenGL and then do a few hardcore optimization tasks in Vulkan. No. You can't really mix the two. The semantics are wildly incompatible. Roughly: the OpenGL API models an ideal graphical state machine and does an enormous amount of work to retain state and paper over the fact that a modern GPU works nothing like the ideal state machine. Vulkan does literally the opposite. Stateless calls that let you control low-level GPU resources, and nothing more. You can't really make a bunch of Vulkan calls and then an OpenGL call that will blow away all your buffers, generate shader code dynamically without telling you, and do a billion other things "magically", and make it all work. The two fundamentally different approaches are in opposition. They're implemented by different drivers, as well. The Vulkan driver is intentionally very thin, stateless, and consequently multithreading-friendly. The OpenGL driver is enormous (including everything up to and including a GLSL compiler), stateful, and consequently very hard to use from more than one rendering thread. This is a big source of performance issues, since it means draw calls are inherently limited to a single thread, which is a big limiter for games. You can't have the two different models, from two different drivers, talking to the same hardware at the same time. It would be pointless even if you could -- you use Vulkan so you can thread draw calls. OpenGL destroys that. I think this answers your first question, too: > Why isn't it a subset of OpenGL, then? Maybe that's what's confusing? You lose the thin & multithread-able advantages of Vulkan if you keep OpenGLs higher level stateful semantics around. It's been tried, many times, in different OpenGL versions, over the years, to create a low-level performant subset. The conclusion has always been the same -- retaining compatibility with higher level calls hampers what you can do in your new low-level calls (need to constantly sync state and expect that at any time a call could have been made that changed any number of internal state variables == lots of checks and lots of locks). Your draw call ceiling is always low and CPU bound because the locks kill threadability
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.
Brakenshire 11y ago
Is the idea people will build higher level API's on top of Vulkan which will rival OpenGL? Or is it more likely to stay as something for engine builders, and as a fall-back for the points where OpenGL performance isn't sufficient?
- dietrichepp 11y ago
  There is not one idea behind Vulkan, but many. It's not just a question about performance. Vulkan should make it easier to write libraries and middleware, for example. Vulkan will make it easier to use multiple threads. Vulkan will make it easier to write shaders, because you don't have to rely on the driver's compiler as much. I think we'll have to wait and see how people actually use it. I know from answering Stack Overflow questions that a lot of people are still using glVertex().
- Ericson2314 11y ago
  To make a networking analogy, Vulkan/SPIR-V is an ideal thin waist with drivers and hardware below, and engines and games above.
- mintplant 11y ago
  Personally, I would love to see a reimplementation of OpenGL on top of Vulkan that behaves more consistently and with uniform feature support vs. what current drivers offer system-by-system.
shmerl 11y ago
> NOT a successor. Why not? It is a successor, except it's not an iterative development but rather an effort to make things from scratch (which is good in this case). > It will live side-by-side with OpenGL for the foreseeable future. Sure, because OpenGL is still needed for supporting legacy applications and anything that won't be rewritten to Vulkan.
dang 11y ago
We took "OpenGL Successor" out of the title. That language doesn't appear on the page. Submitters: the HN guidelines ask you to use the original title except when it is misleading or linkbait. Please don't add editorial interpretation—it's against the spirit of the site and often turns the discussion into a nitpicky debate about what you did to the title. In this case, the post has no obvious single title, but the subtitle "Vulkan Is Here" works fine.
- nostrademons 11y ago
  FWIW, I looked at the (current) title, read the page, and thought "Oh, right, this is the OpenGL successor, finally released. Why is that not in the title? It's important context for other readers." The Wikipedia article on OpenGL lists Vulkan as the successor, and the former name for the Vulkan project was "Next Generation OpenGL Initiative" (glNext). https://en.wikipedia.org/wiki/OpenGL#Successor https://en.wikipedia.org/wiki/OpenGL#Successor
  - dmix 11y ago
    "OpenGL successor" was the headline everywhere when it was announced last year [1][2]. Personally, I see nothing wrong with including it in the title, even if it's not 100% intended to be the successor, it helps provide context to people unfamiliar with the software/industry. Almost all pitch deck guides recommend using similar analogies and it's probably the only reason this is #1 on HN. [1] "Khronos announces openGL successor Vulkan" http://www.infoworld.com/article/2892236/khronos-announces-opengl-successor-vulkan.html http://www.infoworld.com/article/2892236/khronos-announces-o... [2] "The successor to OpenGL has a name: Vulkan" http://www.gamasutra.com/view/news/237907/The_successor_to_OpenGL_has_a_name_Vulkan.php http://www.gamasutra.com/view/news/237907/The_successor_to_O...
  - slavik81 11y ago
    There are reasons why they named it Vulkan rather than OpenGL 5. Though, as far as I can tell, the reasons were mostly political. It reminds me of Nintendo releasing the Nintendo DS and calling it their 'third pillar', standing alongside their home console and Gameboy lines. They made it quite clear that despite its similar market position, the Nintendo DS was not the next Gameboy and it was not replacing the Gameboy line. Of course, the DS was incredibly successful and they never made any new Gameboy-branded handhelds ever again. (Though they did do a few updates to the existing model.) The Nintendo DS was a Gameboy that they didn't want to call a Gameboy, and so when it succeeded the brand simply changed and things continued on as usual. I suspect that we may see the same with Vulkan. When anyone can design an OpenGL-like abstraction as a library on top of Vulkan, the desire to make big updates to OpenGL will fade.
bitwize 11y ago
It absolutely is a successor. What the dev space sees is "old and busted" (OpenGL) vs. "new hotness" (Vulkan), especialky when the devs have such a boner for performance as game and 3D graphics developers do. Since most devs don't actually touch the graphics API but simply use whatever engine or framework was handed to them, and since the major ones have committed to supporting Vulkan, OpenGL is bound to be phased out over the coming years, existing mainly to support legacy apps.
- bryanlarsen 11y ago
  Those "legacy apps" are things like SolidWorks, AutoCAD, 3DSMax, et cetera. Those are multi-billion dollar markets that aren't ever going to switch away from OpenGL. I predict that in 10 years or so Vulkan gets replaced by some new hotness but OpenGL will still be around.
  - bitwize 11y ago
    Autodesk went all in on Microsoft platforms some years ago. AutoCAD and 3DSMax are Direct3D-only on Windows. Their software on Mac and iOS devices uses OpenGL for now, but I think Autodesk will likely switch the back end out for Metal, given Apple's sterling reputation for OpenGL support. /s Point being that OpenGL exists mainly to support old CAD apps. Actively maintained current apps will switch to Vulkan, or whatever API provides the best benefit on the target platform.

norea-armozel 11y ago

I'm glad you clarify this because I thought it was meant not to replace OpenGL but to make it easier for certain developers to optimize and override GL behavior as needed.

veli_joza 11y ago
Vulkan is indeed intended as a replacement, but in following decade OpenGL will still have to be supported so that legacy applications can still run. New game engines and other graphically intensive applications will probably target both OpenGL and Vulkan, at least until Vulkan is supported on most of hardware available.
shmerl 11y ago
> I thought it was meant not to replace OpenGL but to make it easier for certain developers to optimize and override GL behavior as needed. It is intended to replace OpenGL eventually. It matches modern hardware and unlike OpenGL allows using parallelism without shared state.

ekianjo 11y ago

Well it may not be a successor, but since Khronos' resources are limited you can bet there will be more updates coming to Vulkan than the OpenGL standard.

mtgx 11y ago

Maybe not a direct successor (as in OpenGL will now be deprecated), but still a defacto successor if all game engines adopt it. The bulk of the low-level work will be done by game engines, and developers won't have to worry too much about it. So developers will get the best of both words: easy to use and higher performance.

nothis 11y ago

That's a big "NOT", though, for such subtle semantics and IMO more confusing than helpful. It's by the same people, for the same thing. It's set to replace OpenGL in the long term, no? I'd say that the only reason not to call it a successor would be if OpenGL offered features that Vulkan can't provide which I don't think is the case.

msbarnett 11y ago
> It's set to replace OpenGL in the long term, no? No. Not at all. That's why it's not a successor. If you're a huge games company writing an engine, sure, it's a better fit for you than OpenGL. If you're almost any other visualization use-case, it's too low level and you'll want to remain with the higher level OpenGL API. It's an alternative, not a replacement. At most OpenGL might come to be a friendly API implemented on top of Vulkan, as opposed to beside.
- wlesieutre 11y ago
  Historically there's been a big divide between what the game engine vendors vs the CAD vendors want out of the OpenGL standard, so this split is a good thing for both. The existing OpenGL systems stick around without dragging game performance down with them. EDIT: Some historical discussion in this reddit thread https://www.reddit.com/r/vulkan/comments/3hkdek/opengl_support_into_the_future/ https://www.reddit.com/r/vulkan/comments/3hkdek/opengl_suppo...
- nothis 11y ago
  Why isn't it a subset of OpenGL, then? Maybe that's what's confusing? It sounds like the most typical usage would be to implement things in OpenGL and then do a few hardcore optimization tasks in Vulkan. Why not add that access to OpenGL and put a "use at your own risk" disclaimer in front of it? Or are they so incompatible you have to write your entire graphics code in either but never both?
  - msbarnett 11y ago
    > It sounds like the most typical usage would be to implement things in OpenGL and then do a few hardcore optimization tasks in Vulkan. No. You can't really mix the two. The semantics are wildly incompatible. Roughly: the OpenGL API models an ideal graphical state machine and does an enormous amount of work to retain state and paper over the fact that a modern GPU works nothing like the ideal state machine. Vulkan does literally the opposite. Stateless calls that let you control low-level GPU resources, and nothing more. You can't really make a bunch of Vulkan calls and then an OpenGL call that will blow away all your buffers, generate shader code dynamically without telling you, and do a billion other things "magically", and make it all work. The two fundamentally different approaches are in opposition. They're implemented by different drivers, as well. The Vulkan driver is intentionally very thin, stateless, and consequently multithreading-friendly. The OpenGL driver is enormous (including everything up to and including a GLSL compiler), stateful, and consequently very hard to use from more than one rendering thread. This is a big source of performance issues, since it means draw calls are inherently limited to a single thread, which is a big limiter for games. You can't have the two different models, from two different drivers, talking to the same hardware at the same time. It would be pointless even if you could -- you use Vulkan so you can thread draw calls. OpenGL destroys that. I think this answers your first question, too: > Why isn't it a subset of OpenGL, then? Maybe that's what's confusing? You lose the thin & multithread-able advantages of Vulkan if you keep OpenGLs higher level stateful semantics around. It's been tried, many times, in different OpenGL versions, over the years, to create a low-level performant subset. The conclusion has always been the same -- retaining compatibility with higher level calls hampers what you can do in your new low-level calls (need to constantly sync state and expect that at any time a call could have been made that changed any number of internal state variables == lots of checks and lots of locks). Your draw call ceiling is always low and CPU bound because the locks kill threadability

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.

Brakenshire 11y ago

Is the idea people will build higher level API's on top of Vulkan which will rival OpenGL? Or is it more likely to stay as something for engine builders, and as a fall-back for the points where OpenGL performance isn't sufficient?

dietrichepp 11y ago
There is not one idea behind Vulkan, but many. It's not just a question about performance. Vulkan should make it easier to write libraries and middleware, for example. Vulkan will make it easier to use multiple threads. Vulkan will make it easier to write shaders, because you don't have to rely on the driver's compiler as much. I think we'll have to wait and see how people actually use it. I know from answering Stack Overflow questions that a lot of people are still using glVertex().
Ericson2314 11y ago
To make a networking analogy, Vulkan/SPIR-V is an ideal thin waist with drivers and hardware below, and engines and games above.
mintplant 11y ago
Personally, I would love to see a reimplementation of OpenGL on top of Vulkan that behaves more consistently and with uniform feature support vs. what current drivers offer system-by-system.

shmerl 11y ago

> NOT a successor. Why not? It is a successor, except it's not an iterative development but rather an effort to make things from scratch (which is good in this case). > It will live side-by-side with OpenGL for the foreseeable future. Sure, because OpenGL is still needed for supporting legacy applications and anything that won't be rewritten to Vulkan.

dang 11y ago

We took "OpenGL Successor" out of the title. That language doesn't appear on the page. Submitters: the HN guidelines ask you to use the original title except when it is misleading or linkbait. Please don't add editorial interpretation—it's against the spirit of the site and often turns the discussion into a nitpicky debate about what you did to the title. In this case, the post has no obvious single title, but the subtitle "Vulkan Is Here" works fine.

nostrademons 11y ago
FWIW, I looked at the (current) title, read the page, and thought "Oh, right, this is the OpenGL successor, finally released. Why is that not in the title? It's important context for other readers." The Wikipedia article on OpenGL lists Vulkan as the successor, and the former name for the Vulkan project was "Next Generation OpenGL Initiative" (glNext). https://en.wikipedia.org/wiki/OpenGL#Successor https://en.wikipedia.org/wiki/OpenGL#Successor
- dmix 11y ago
  "OpenGL successor" was the headline everywhere when it was announced last year [1][2]. Personally, I see nothing wrong with including it in the title, even if it's not 100% intended to be the successor, it helps provide context to people unfamiliar with the software/industry. Almost all pitch deck guides recommend using similar analogies and it's probably the only reason this is #1 on HN. [1] "Khronos announces openGL successor Vulkan" http://www.infoworld.com/article/2892236/khronos-announces-opengl-successor-vulkan.html http://www.infoworld.com/article/2892236/khronos-announces-o... [2] "The successor to OpenGL has a name: Vulkan" http://www.gamasutra.com/view/news/237907/The_successor_to_OpenGL_has_a_name_Vulkan.php http://www.gamasutra.com/view/news/237907/The_successor_to_O...
- slavik81 11y ago
  There are reasons why they named it Vulkan rather than OpenGL 5. Though, as far as I can tell, the reasons were mostly political. It reminds me of Nintendo releasing the Nintendo DS and calling it their 'third pillar', standing alongside their home console and Gameboy lines. They made it quite clear that despite its similar market position, the Nintendo DS was not the next Gameboy and it was not replacing the Gameboy line. Of course, the DS was incredibly successful and they never made any new Gameboy-branded handhelds ever again. (Though they did do a few updates to the existing model.) The Nintendo DS was a Gameboy that they didn't want to call a Gameboy, and so when it succeeded the brand simply changed and things continued on as usual. I suspect that we may see the same with Vulkan. When anyone can design an OpenGL-like abstraction as a library on top of Vulkan, the desire to make big updates to OpenGL will fade.

bitwize 11y ago

It absolutely is a successor. What the dev space sees is "old and busted" (OpenGL) vs. "new hotness" (Vulkan), especialky when the devs have such a boner for performance as game and 3D graphics developers do. Since most devs don't actually touch the graphics API but simply use whatever engine or framework was handed to them, and since the major ones have committed to supporting Vulkan, OpenGL is bound to be phased out over the coming years, existing mainly to support legacy apps.

bryanlarsen 11y ago
Those "legacy apps" are things like SolidWorks, AutoCAD, 3DSMax, et cetera. Those are multi-billion dollar markets that aren't ever going to switch away from OpenGL. I predict that in 10 years or so Vulkan gets replaced by some new hotness but OpenGL will still be around.
- bitwize 11y ago
  Autodesk went all in on Microsoft platforms some years ago. AutoCAD and 3DSMax are Direct3D-only on Windows. Their software on Mac and iOS devices uses OpenGL for now, but I think Autodesk will likely switch the back end out for Metal, given Apple's sterling reputation for OpenGL support. /s Point being that OpenGL exists mainly to support old CAD apps. Actively maintained current apps will switch to Vulkan, or whatever API provides the best benefit on the target platform.