5 ms·

Could someone tell me shortly what Vulkan brings over opengl? To me it seems that Vulkan is raising up the barrier to entry to Graphics programming by being eve

Could someone tell me shortly what Vulkan brings over opengl? To me it seems that Vulkan is raising up the barrier to entry to Graphics programming by being even more complex than OpenGL but I hope this feeling will disappear as more code samples come out.

__s 9y ago
Searched ELI5 vulkan https://www.reddit.com/r/explainlikeimfive/comments/4651a7/eli5_whats_the_big_deal_about_vulkan_api/?st=jei3pfpk&sh=b51c0809 https://www.reddit.com/r/explainlikeimfive/comments/4651a7/e... Vulkan offers superior performance potential & avoids concurrency issues in GL. It achieves this by more closely matching its abstraction to GPUs as they are today. It also allows for simpler drivers, which should hopefully make for more consistent results
gpm 9y ago
My first at all substantial graphics program (a ray traced 3d pong game with reflections, refraction, etc) was in Vulkan, not OpenGL. I don't have the most experience in this area, but I probably have a fairly unique viewpoint on this. Vulkan is lowering the barrier for entry to graphics programming. It's doing this by not having hidden state. I don't have to remember what is stored where when I'm programming, I can follow the very fine spec as a pretty much step by step guide and get a working program. Practically every operation is simple, and only really cares about the arguments you pass it not some global state. This is very friendly to someone learning how it works. It is raising the bar for implementing the "get a triangle onto the screen" part of the program, but that's not the hard part and never will be. It's also only raising that bar for crazy people like me who use Vulkan directly. In the future by the time Vulkan really takes over I expect it will lower the bar for that, since there will be nice libraries on top of it which deal with the "allocate everything" step for you (and maybe now, I don't know of any but I haven't searched... AMD has something I think).
- geokon 9y ago
  Have you done anything with OpenCL? Because what a lot of people describe kinda sounds like OpenCL where there isn't really much global state or a predefined pipeline. On a high level you're just sending kernels to be executed on the GPU and you're free to organize things any way you like
  - gpm 9y ago
    I haven't done anything with OpenCL, it's been on my "find an excuse to use this" list for awhile now. I think you might be getting a false impression of Vulkan though. All the vertex shader, fragment shader, submit a buffer filled with geometry primitives, set depth clamping and filter triangles based on winding order, etc pipeline is still there, it's just much more explicit about how you are using it. There is also support for compute shaders that are more what I imagine OpenCL to be like. If you're doing traditional polygon rendering that's going to be slow. Even in my ray tracing project (that does most of the rendering in a compute shader), I imagine using OpenCL would have made it a bit of a pain to display the results realtime to the screen so people can actually play.
    - geokon 9y ago
      Thanks for clearing it up for me. So the pipeline is there but it's stateless... that sounds cool and I guess I really need to try it out. Using OGL a bit it definitely has this weird archaic feeling with all its state. I found it kind of fun and I didn't really shoot myself in the foot with it, but it definitely felt like "this is not how we write software now a days" haha
- pjmlp 9y ago
  > Vulkan is lowering the barrier for entry to graphics programming. It's doing this by not having hidden state. This is OpenGL specific, there isn't an hidden state on other 3D APIs.
  - rys 9y ago
    That's not true. Direct3Ds up to and including 11 are the same way.
    - pjmlp 9y ago
      Not really, COM instances for each 3D concept are created and passed around. There isn't this thing of binding/copying stuff into global state.
      - enqk 9y ago
        What about this (only one example) ID3D11DeviceContext::IASetVertexBuffers https://msdn.microsoft.com/en-us/library/windows/desktop/ff476456(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ff4... It's no different from manipulating the opengl context.. Also google bindless opengl
        mellinoe 9y ago
        It's very different in practice. D3D11 contexts are explicit, real objects that you create, manipulate, and pass around. They can be properly and realistically handled in multi-threaded code. OpenGL contexts are opaque and global, and properly handling them in multiple threads is a nightmare. Multiple OpenGL contexts is also very different in functionality from multiple D3D11 device contexts.
  - sandov 9y ago
    Is there another viable free & open source 3D API that I've not heard about?
slavik81 9y ago
The OpenGL state machine is a giant set of hidden global data structures that you manipulate through opaque API calls. It's not very friendly, IMO. My hope is that with stable low-level APIs available, we can build new high-level APIs on top. Historically, it's been a slow process to move to a newer graphics API, because you need to wait for all the hardware venders to implement it. Building that high-level API in userland means that basic quality-of-life improvements don't have to wait for hardware vendors to write new drivers.
lucozade 9y ago
Vulkan is much lower level than OpenGL. It gives the user much more control, particularly around memory and thread management, at the expense of the user having to manage those pieces. It has a much higher barrier to entry and will likely stay that way. What will presumably happen is that higher level APIs will emerge that abstract that complexity away.
- Lorkki 9y ago
  Vulkan is actually really close in scope to the vendor-specific APIs that OpenGL drivers use to communicate with the GPU. The intention from the beginning was that you would pick an appropriate higher-level abstraction (unless you're, say, making Unreal Engine and already retooled your OpenGL pipeline for the AZDO extensions). The clear advantage over OpenGL is that those abstractions are debuggable and vendor-independent.
dtech 9y ago
Is OpenGL vs Vulkan really such a big difference for entry? I would think that most programming first experiences with graphics programming are through an engine or wrapper like Unity or SDL.
zaarn 9y ago
Vulkan is largely a successor to OpenGL and it's also a lot lower level. IMO it's primarly targeted at engine developers. The lower level API also allows you to do things that OpenGL simply wouldn't allow, like driving multiple GPUs for one display output using your own abstractions. DirectX12 is much in the same spirit (but not equivalent, they're still a lot different internally). Vulkan will also (probably) bring better crossplatform support from Games since it's equally supported on Windows, Linux, Mac (with a library), Android and the Game Consoles. (There is OpenGL on Android but IIRC it's not quite the same)
- HelloNurse 9y ago
  In this case "lower level" means less messy, not less abstract, and more verbose, not more complex. A lot of Of constraining and not very valuable parts of OpenGL were replaced with do-it-yourself, making the API "retreat" from advanced complex solutions to more general and more portable building blocks.
- WillReplyfFood 9y ago
  Has DirectX still this OO-style going on? I dont want to know what java.jibberish.abstraction.factory they invented to hide these basically embeded system programming- with a thousand seemingly arbitrary <ThisWontWork-duetoMagicNumber Exceeding>Exceptions.
agumonkey 9y ago
from the few that I got: gpu drivers and api lied to each others, it lead to absurdly complex drivers full of bugs and absurdly complex codebase full of paranoid tricks to circle around the weird gpu behavior. Complete waste. Vulkan is a bit like RISC, makes it more "complex" but explicit, so in a way it's simpler.
exDM69 9y ago
OpenGL is a terrible API with 25 years worth of legacy baggage. There are many ways of doing everything and a portable engine needs to support many methods for even the simplest of things because the newest and best methods aren't supported everywhere. Vulkan is a much better designed API with a lot less legacy crap in it. It's lower level and gives more control to the app/engine developer. The bad news is that Vulkan is a bit verbose, but this stops being an issue once you move past "hello world" level apps. OpenGL gets really difficult once you start doing complex things.
- megaman22 9y ago
  The multiplicity of ways to do everything in OpenGL was always a stumbling block for me in the past; it's been a big driver towards leaning in the direction of DirectX, or Monogame or Unity for cross-platform, in the past. There still seems to be a lot of fragmentation from the handful of samples I've looked at so far; is there something like a canonical example of "the right way" to do things?
  - pjmlp 9y ago
    Yeah, first thing you have to do is dynamically collect extensions on program startup. https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Instance https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Instanc...
    - exDM69 9y ago
      That's a bit dishonest way to put it. The situation with extensions has vastly improved w.r.t. OpenGL. In the link you provided, it only needs to enable the appropriate window system extension. It also prints out some info about other extensions but that is not required. It's a huge improvement that extensions need to be explicitly requested at init time. It's massively better than OpenGL, and API extensions can't be completely avoided in a multi-vendor cross-platform API without limiting to lowest common denominator.
      - pjmlp 9y ago
pizza234 9y ago
There was an epic post from an NVidia developer: https://www.gamedev.net/forums/topic/666419-what-are-your-opinions-on-dx12vulkanmantle/?do=findComment&comment=5215019 https://www.gamedev.net/forums/topic/666419-what-are-your-op... In brief: current APIs are a leaky abstraction, and a disproportionate amount of time is spent in debugging the curious "competition" between applications/libraries and drivers, at least, for relatively complex applications.

__s 9y ago

Searched ELI5 vulkan https://www.reddit.com/r/explainlikeimfive/comments/4651a7/eli5_whats_the_big_deal_about_vulkan_api/?st=jei3pfpk&sh=b51c0809 https://www.reddit.com/r/explainlikeimfive/comments/4651a7/e... Vulkan offers superior performance potential & avoids concurrency issues in GL. It achieves this by more closely matching its abstraction to GPUs as they are today. It also allows for simpler drivers, which should hopefully make for more consistent results

gpm 9y ago

My first at all substantial graphics program (a ray traced 3d pong game with reflections, refraction, etc) was in Vulkan, not OpenGL. I don't have the most experience in this area, but I probably have a fairly unique viewpoint on this. Vulkan is lowering the barrier for entry to graphics programming. It's doing this by not having hidden state. I don't have to remember what is stored where when I'm programming, I can follow the very fine spec as a pretty much step by step guide and get a working program. Practically every operation is simple, and only really cares about the arguments you pass it not some global state. This is very friendly to someone learning how it works. It is raising the bar for implementing the "get a triangle onto the screen" part of the program, but that's not the hard part and never will be. It's also only raising that bar for crazy people like me who use Vulkan directly. In the future by the time Vulkan really takes over I expect it will lower the bar for that, since there will be nice libraries on top of it which deal with the "allocate everything" step for you (and maybe now, I don't know of any but I haven't searched... AMD has something I think).

geokon 9y ago
Have you done anything with OpenCL? Because what a lot of people describe kinda sounds like OpenCL where there isn't really much global state or a predefined pipeline. On a high level you're just sending kernels to be executed on the GPU and you're free to organize things any way you like
- gpm 9y ago
  I haven't done anything with OpenCL, it's been on my "find an excuse to use this" list for awhile now. I think you might be getting a false impression of Vulkan though. All the vertex shader, fragment shader, submit a buffer filled with geometry primitives, set depth clamping and filter triangles based on winding order, etc pipeline is still there, it's just much more explicit about how you are using it. There is also support for compute shaders that are more what I imagine OpenCL to be like. If you're doing traditional polygon rendering that's going to be slow. Even in my ray tracing project (that does most of the rendering in a compute shader), I imagine using OpenCL would have made it a bit of a pain to display the results realtime to the screen so people can actually play.
  - geokon 9y ago
    Thanks for clearing it up for me. So the pipeline is there but it's stateless... that sounds cool and I guess I really need to try it out. Using OGL a bit it definitely has this weird archaic feeling with all its state. I found it kind of fun and I didn't really shoot myself in the foot with it, but it definitely felt like "this is not how we write software now a days" haha
pjmlp 9y ago
> Vulkan is lowering the barrier for entry to graphics programming. It's doing this by not having hidden state. This is OpenGL specific, there isn't an hidden state on other 3D APIs.
- rys 9y ago
  That's not true. Direct3Ds up to and including 11 are the same way.
  - pjmlp 9y ago
    Not really, COM instances for each 3D concept are created and passed around. There isn't this thing of binding/copying stuff into global state.
    - enqk 9y ago
      What about this (only one example) ID3D11DeviceContext::IASetVertexBuffers https://msdn.microsoft.com/en-us/library/windows/desktop/ff476456(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ff4... It's no different from manipulating the opengl context.. Also google bindless opengl
      - mellinoe 9y ago
        It's very different in practice. D3D11 contexts are explicit, real objects that you create, manipulate, and pass around. They can be properly and realistically handled in multi-threaded code. OpenGL contexts are opaque and global, and properly handling them in multiple threads is a nightmare. Multiple OpenGL contexts is also very different in functionality from multiple D3D11 device contexts.
- sandov 9y ago
  Is there another viable free & open source 3D API that I've not heard about?

slavik81 9y ago

The OpenGL state machine is a giant set of hidden global data structures that you manipulate through opaque API calls. It's not very friendly, IMO. My hope is that with stable low-level APIs available, we can build new high-level APIs on top. Historically, it's been a slow process to move to a newer graphics API, because you need to wait for all the hardware venders to implement it. Building that high-level API in userland means that basic quality-of-life improvements don't have to wait for hardware vendors to write new drivers.

lucozade 9y ago

Vulkan is much lower level than OpenGL. It gives the user much more control, particularly around memory and thread management, at the expense of the user having to manage those pieces. It has a much higher barrier to entry and will likely stay that way. What will presumably happen is that higher level APIs will emerge that abstract that complexity away.

Lorkki 9y ago
Vulkan is actually really close in scope to the vendor-specific APIs that OpenGL drivers use to communicate with the GPU. The intention from the beginning was that you would pick an appropriate higher-level abstraction (unless you're, say, making Unreal Engine and already retooled your OpenGL pipeline for the AZDO extensions). The clear advantage over OpenGL is that those abstractions are debuggable and vendor-independent.

dtech 9y ago

Is OpenGL vs Vulkan really such a big difference for entry? I would think that most programming first experiences with graphics programming are through an engine or wrapper like Unity or SDL.

zaarn 9y ago

Vulkan is largely a successor to OpenGL and it's also a lot lower level. IMO it's primarly targeted at engine developers. The lower level API also allows you to do things that OpenGL simply wouldn't allow, like driving multiple GPUs for one display output using your own abstractions. DirectX12 is much in the same spirit (but not equivalent, they're still a lot different internally). Vulkan will also (probably) bring better crossplatform support from Games since it's equally supported on Windows, Linux, Mac (with a library), Android and the Game Consoles. (There is OpenGL on Android but IIRC it's not quite the same)

HelloNurse 9y ago
In this case "lower level" means less messy, not less abstract, and more verbose, not more complex. A lot of Of constraining and not very valuable parts of OpenGL were replaced with do-it-yourself, making the API "retreat" from advanced complex solutions to more general and more portable building blocks.
WillReplyfFood 9y ago
Has DirectX still this OO-style going on? I dont want to know what java.jibberish.abstraction.factory they invented to hide these basically embeded system programming- with a thousand seemingly arbitrary <ThisWontWork-duetoMagicNumber Exceeding>Exceptions.

agumonkey 9y ago

from the few that I got: gpu drivers and api lied to each others, it lead to absurdly complex drivers full of bugs and absurdly complex codebase full of paranoid tricks to circle around the weird gpu behavior. Complete waste. Vulkan is a bit like RISC, makes it more "complex" but explicit, so in a way it's simpler.

exDM69 9y ago

OpenGL is a terrible API with 25 years worth of legacy baggage. There are many ways of doing everything and a portable engine needs to support many methods for even the simplest of things because the newest and best methods aren't supported everywhere. Vulkan is a much better designed API with a lot less legacy crap in it. It's lower level and gives more control to the app/engine developer. The bad news is that Vulkan is a bit verbose, but this stops being an issue once you move past "hello world" level apps. OpenGL gets really difficult once you start doing complex things.

megaman22 9y ago
The multiplicity of ways to do everything in OpenGL was always a stumbling block for me in the past; it's been a big driver towards leaning in the direction of DirectX, or Monogame or Unity for cross-platform, in the past. There still seems to be a lot of fragmentation from the handful of samples I've looked at so far; is there something like a canonical example of "the right way" to do things?
- pjmlp 9y ago
  Yeah, first thing you have to do is dynamically collect extensions on program startup. https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Instance https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Instanc...
  - exDM69 9y ago
    That's a bit dishonest way to put it. The situation with extensions has vastly improved w.r.t. OpenGL. In the link you provided, it only needs to enable the appropriate window system extension. It also prints out some info about other extensions but that is not required. It's a huge improvement that extensions need to be explicitly requested at init time. It's massively better than OpenGL, and API extensions can't be completely avoided in a multi-vendor cross-platform API without limiting to lowest common denominator.
    - pjmlp 9y ago

pizza234 9y ago

There was an epic post from an NVidia developer: https://www.gamedev.net/forums/topic/666419-what-are-your-opinions-on-dx12vulkanmantle/?do=findComment&comment=5215019 https://www.gamedev.net/forums/topic/666419-what-are-your-op... In brief: current APIs are a leaky abstraction, and a disproportionate amount of time is spent in debugging the curious "competition" between applications/libraries and drivers, at least, for relatively complex applications.