7 ms·

Vulkan 1.1 Released

112 points by z3phyr 9y ago

antoineMoPa 9y ago
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.
- 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.
tracyma 9y ago
YCbCr texture support is great. Not sure future Android will make SurfaceTexture compatible with Vulkan. https://stackoverflow.com/questions/43507536/how-to-connect-android-mediacodec-surface-to-vulkan/43550804 https://stackoverflow.com/questions/43507536/how-to-connect-...
- pjmlp 9y ago
  Vulkan support on Android is pretty thin outside Samsung and Google flagship phones, not even big enough to be worthy being listed on Android Dashboards.
loeg 9y ago
Notably, radv is 1.1 conformant on launch day: https://airlied.blogspot.com/2018/03/radv-vulkan-11-coformant-on-launch-day.html https://airlied.blogspot.com/2018/03/radv-vulkan-11-coforman...
- vetinari 9y ago
  RADV (Mesa-developed driver for AMD), ANV (Intel), AMDVLK (AMD-developed driver) and Nvidia are all 1.1 conformant on launch day.
hit8run 9y ago
It’s kind of sad that Apple and the Khronos Group diverted here. Apple pushes Metal and has thus far not shown any interest in supporting Vulkan. It would be nice for the industry to have a stable well maintained common denominator for all platforms.
- pjmlp 9y ago
  FOSS people like to single out Apple, when the reality is Apple, Nintendo (Switch main API is NVN), Sony and Microsoft (Vulkan is desktop only). And game devs don't care because they already have their own middleware.
  - loup-vaillant 9y ago
    I hear there's an automatic translator for Dx12 as well, not just Metal. This should cover the Microsoft consoles, shouldn't it?
  - vetinari 9y ago
    FOSS people like to single out Apple, because it is the only company that ships desktop and mobile OSes that ignore Vulkan. You won't find much FOSS software on Nintendo, Playstation or Xbox, and for the respective middlewares porting to their respective 3d apis is cost of business.
    - pjmlp 9y ago
      Microsoft ships also desktop and mobile OSes that ignore Vulkan. Vulkan works only on desktop thanks to the same ICD model as OpenGL, which isn't currently supported on UWP.
      - vetinari 9y ago
        Microsoft doesn't make the GPU drivers and the vendors are free to support any API they want, at least under Win32. Frankly, nobody cares about UWP and nobody cares about Microsoft mobile OSes. Their usage is lower than deskto BSD.
golergka 9y ago
It's kind of sad to see graphics APIs finally become significantly better while everybody except for a couple of AAA studios uses third party engines.
- pjmlp 9y ago
  It is not a couple of AAA, it is the majority of games industry, the guys that actually attend GDC and publish console games.
- sandov 9y ago
  Still really good news for people who want to understand and experiment with graphics on a fundamental level, I guess.
- craftyguy 9y ago
  Those third party engines have to use something. I don't think anyone expects all game developers to write their own engines using the vulkan API..

112 points by z3phyr 9y ago

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.
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.

tracyma 9y ago

YCbCr texture support is great. Not sure future Android will make SurfaceTexture compatible with Vulkan. https://stackoverflow.com/questions/43507536/how-to-connect-android-mediacodec-surface-to-vulkan/43550804 https://stackoverflow.com/questions/43507536/how-to-connect-...

pjmlp 9y ago
Vulkan support on Android is pretty thin outside Samsung and Google flagship phones, not even big enough to be worthy being listed on Android Dashboards.

loeg 9y ago

Notably, radv is 1.1 conformant on launch day: https://airlied.blogspot.com/2018/03/radv-vulkan-11-coformant-on-launch-day.html https://airlied.blogspot.com/2018/03/radv-vulkan-11-coforman...

vetinari 9y ago
RADV (Mesa-developed driver for AMD), ANV (Intel), AMDVLK (AMD-developed driver) and Nvidia are all 1.1 conformant on launch day.

hit8run 9y ago

It’s kind of sad that Apple and the Khronos Group diverted here. Apple pushes Metal and has thus far not shown any interest in supporting Vulkan. It would be nice for the industry to have a stable well maintained common denominator for all platforms.

pjmlp 9y ago
FOSS people like to single out Apple, when the reality is Apple, Nintendo (Switch main API is NVN), Sony and Microsoft (Vulkan is desktop only). And game devs don't care because they already have their own middleware.
- loup-vaillant 9y ago
  I hear there's an automatic translator for Dx12 as well, not just Metal. This should cover the Microsoft consoles, shouldn't it?
- vetinari 9y ago
  FOSS people like to single out Apple, because it is the only company that ships desktop and mobile OSes that ignore Vulkan. You won't find much FOSS software on Nintendo, Playstation or Xbox, and for the respective middlewares porting to their respective 3d apis is cost of business.
  - pjmlp 9y ago
    Microsoft ships also desktop and mobile OSes that ignore Vulkan. Vulkan works only on desktop thanks to the same ICD model as OpenGL, which isn't currently supported on UWP.
    - vetinari 9y ago
      Microsoft doesn't make the GPU drivers and the vendors are free to support any API they want, at least under Win32. Frankly, nobody cares about UWP and nobody cares about Microsoft mobile OSes. Their usage is lower than deskto BSD.

golergka 9y ago

It's kind of sad to see graphics APIs finally become significantly better while everybody except for a couple of AAA studios uses third party engines.

pjmlp 9y ago
It is not a couple of AAA, it is the majority of games industry, the guys that actually attend GDC and publish console games.
sandov 9y ago
Still really good news for people who want to understand and experiment with graphics on a fundamental level, I guess.
craftyguy 9y ago
Those third party engines have to use something. I don't think anyone expects all game developers to write their own engines using the vulkan API..