6 ms·

The sample code shows just how absurdly explicit this API is. 200 lines to get a triangle on the screen!

by panic 11y ago

foodmart 11y ago
With great power, comes great responsibility. For those who don't prefer this level of abstraction, just use a higher level zero cost abstraction.
- samstave 11y ago
  This might be a completely ignorant question; How can there not be an drawing app built on top of this so that you can just model/draw and have it translate??
  - 0942v8653 11y ago
    There will be. That's open source's job. Vulkan isn't a complete replacement for OpenGL; it's a GPU API aimed to be built upon.
    - Turbo_hedgehog 11y ago
      The goal is to have a cross-platform low level API that can be easily tested for compliance/conformance, right?
      - azernik 11y ago
        Also one that exposes graphics card mechanics so that higher-level tools can use them more intelligently for optimization purposes. A good analogy is the RISC transition - implementations were made easier and faster, but as a tradeoff assembly was made much more difficult to program in. The idea being that only a small group of tool-makers with specialized knowledge of the underlying mechanics (in that case compiler developers, in this case engine developers) would ever have to deal with them.
  - whatever_dude 11y ago
    There will be. The point of Vulkan wasn't to change the OpenGL API to something else. It was to expose more of what the inner workings of a modern graphics card is, and to remove ambiguity introduced by higher level abstractions used by OpenGL. It is more of a direct translation of what can be done with a graphics driver. This means that developers (engine writers) who want to can now get a lower level access to what the graphics card can do, and do so in a more deterministic fashion. Everyone else will be able to use higher-level abstractions that will undoubtedly appear, and those probably be easier to use than OpenGL itself. Best of all, they'll be open source so anyone can dig in and tweak (or understand) something rather than forever depend on some obscure OpenGL behavior no one really understands. There will be growing pains. The existing engine codebases are heavily based on OpenGL, as are helper libraries. That will need to change. Things won't just be faster overnight. But judging by what I read, in the long run it will be better for everyone involved.
- sdegutis 11y ago
  I don't know, I feel like D3 solidly demonstrated that you can have absolute configurability without sacrificing any conciseness.
  - hodwik 11y ago
    D3 is not concise compared with most simple js graphing libs -- e.g. highcharts.
    - scardine 11y ago
      I agree, but it is not fair to compare D3 and highcharts because they are not in the same league. There are many higher level libraries leveraging on D3 that could be compared to highcharts. There are also many lower level libraries that have the same scope as D3, and compared to most of them D3 is pretty concise - the parent comment has a point.
  - ajross 11y ago
    D3 is not remotely an abstraction API for a hardware compute engine. Vulkan isn't about "configurability", it's about cleanly expressing the specific operations that the hardware can perform, and the specific requirements for talking to it. Those are complicated, inherently. Data graphing, fundamentally, is "simple" in comparison (and to be fair, D3 exploits that beautifully).
  - deleted 11y ago
    [deleted]
- Narishma 11y ago
  The higher level abstractions aren't zero-cost.
  - lmm 11y ago
    No reason they can't be.
bucaran 11y ago
For me, the beauty about Vulkan is in future work and libraries that will be based in it and I bet will start popping up over the next following months, if not sooner.
yason 11y ago
AFAIK, the point of Vulkan is to get to modelling the hardware as possible. It's not even supposed to be a high-level API but allow efficient access to today's GPUs. OpenGL is an abstract state machine and it requires a great deal of effort to convert that state into what today's GPUs are actually capable of efficiently handling. Getting that triangle onto the screen in OpenGL is maybe 20 lines of code but you will have 200,000 lines of code in the OpenGL driver translating the commands into the actual configuration of the hardware unit. And if you want to draw 2 million triangles you will have to work hard to work around the overhead introduced by the OpenGL implementation. Then again, OpenGL can be reimplemented on top of Vulkan for end-developers and more complex game engines will be written against Vulkan directly, and then people will work on those instead of writing direct Vulkan code. Once you get the building blocks right you can build on top of them layers of abstraction that suit what you need. This is in contrast to the current situation where the abstractions are fixed and don't necessarily suit the end-developer nor the driver developer. Today you need to implement your game or graphics engine abstraction (which you will use yourself) in terms of OpenGL (requiring lots of tricks), then the OpenGL driver has to implement OpenGL in terms of the actual hardware (again, requiring a lot of clever trickery to handle and transform the state efficiently) and as a result the pixels will show up on the screen but at the cost of a potentially huge overhead which could be introduced somewhere along the route.
- mpweiher 11y ago
  Yup. The way I understand it is that graphics pipelines today (maybe always) are quite different from the procedural API that OpenGL provides. That mismatch causes all sorts of problems, for example that using the OpenGL APIs "naturally" can be extremely inefficient, whereas trying to access the GPU pipeline naturally is really convoluted and you have to get it just right in non-obvious ways. The structure of the GPU pipeline appears to be sufficiently settled that we can now expose it more directly. That way, talking to the GPU in a way that's natural for the GPU is at least straightforward, even if it's arduous. It seems like you should now be able to build APIs that are both at a higher level and not in conflict with how the hardware actually works.
- PopsiclePete 11y ago
  Ok so is Vulkan basically assembly code targeting GPU's? If so, my only question is - why the heck did it take so long for it to get here?
gcb0 11y ago
openGL was a good idea. But drivers were buggy as hell and every vendor was adding their own extensions like crazy. Vulkan is the F-that solution. They removed most unifying abstractions, made the API turn the video card into a general computer and let the engine developers do the hardware compatibility layer instead of the developers, since they were doing that work indirectly on top of the drivers bugs anyway. and wow, it is really exactly 200 lines.
skoczymroczny 11y ago
Well, in OpenGL it would take you at least 100 lines of code. Don't forget that glBegin and fixed function pipeline is deprecated nowadays. Sure, with that you can draw a triangle in 10 lines. For modern OpenGL you have to create vertex and fragment shaders, send uniforms, create vertex buffers, upload vertex data, set up vertex attributes, and only then can you render. Vulkan is just the next step of that. Also, a lot of Vulkan code is something you will wrap once, and unless you need the absolute best performance and finetuning you can just stash it in some utility method. Creating an image takes 40 lines of code? Put it into a create_default_image() method and it's only one line of code from now on.
exDM69 11y ago
200 lines for a triangle is roughly comparable to what it takes on D3D or Metal. This is the level of control that graphics and engine programmers require to make things run efficiently.
- mrec 11y ago
  That's D3D12, presumably.
sgift 11y ago
This only tells me that it is not the right API for putting one triangle on a screen. Sounds okay? APIs (or programming languages or frameworks or ...) which are build for "big things" often have a certain amount of boiler plate required that looks absurd when you use them for something extremely small, but doesn't matter for something bigger.
andresmanz 11y ago
Oooh, yes. It couldn't get any better, right? The amount of control you have here is just perfect. If you don't like that, just wait a few days. I'm sure there will be tons of libraries that let you do that with a few lines of code.
sklogic 11y ago
Next thing you'll complain about would be on how absurdly explicit the x86 ISA is. So many instructions just to get "Hello, world" printed.

The sample code shows just how absurdly explicit this API is. 200 lines to get a triangle on the screen!

by panic 11y ago

The sample code shows just how absurdly explicit this API is. 200 lines to get a triangle on the screen!

With great power, comes great responsibility. For those who don't prefer this level of abstraction, just use a higher level zero cost abstraction.

samstave 11y ago
This might be a completely ignorant question; How can there not be an drawing app built on top of this so that you can just model/draw and have it translate??
- 0942v8653 11y ago
  There will be. That's open source's job. Vulkan isn't a complete replacement for OpenGL; it's a GPU API aimed to be built upon.
  - Turbo_hedgehog 11y ago
    The goal is to have a cross-platform low level API that can be easily tested for compliance/conformance, right?
    - azernik 11y ago
      Also one that exposes graphics card mechanics so that higher-level tools can use them more intelligently for optimization purposes. A good analogy is the RISC transition - implementations were made easier and faster, but as a tradeoff assembly was made much more difficult to program in. The idea being that only a small group of tool-makers with specialized knowledge of the underlying mechanics (in that case compiler developers, in this case engine developers) would ever have to deal with them.
- whatever_dude 11y ago
  There will be. The point of Vulkan wasn't to change the OpenGL API to something else. It was to expose more of what the inner workings of a modern graphics card is, and to remove ambiguity introduced by higher level abstractions used by OpenGL. It is more of a direct translation of what can be done with a graphics driver. This means that developers (engine writers) who want to can now get a lower level access to what the graphics card can do, and do so in a more deterministic fashion. Everyone else will be able to use higher-level abstractions that will undoubtedly appear, and those probably be easier to use than OpenGL itself. Best of all, they'll be open source so anyone can dig in and tweak (or understand) something rather than forever depend on some obscure OpenGL behavior no one really understands. There will be growing pains. The existing engine codebases are heavily based on OpenGL, as are helper libraries. That will need to change. Things won't just be faster overnight. But judging by what I read, in the long run it will be better for everyone involved.
sdegutis 11y ago
I don't know, I feel like D3 solidly demonstrated that you can have absolute configurability without sacrificing any conciseness.
- hodwik 11y ago
  D3 is not concise compared with most simple js graphing libs -- e.g. highcharts.
  - scardine 11y ago
    I agree, but it is not fair to compare D3 and highcharts because they are not in the same league. There are many higher level libraries leveraging on D3 that could be compared to highcharts. There are also many lower level libraries that have the same scope as D3, and compared to most of them D3 is pretty concise - the parent comment has a point.
- ajross 11y ago
  D3 is not remotely an abstraction API for a hardware compute engine. Vulkan isn't about "configurability", it's about cleanly expressing the specific operations that the hardware can perform, and the specific requirements for talking to it. Those are complicated, inherently. Data graphing, fundamentally, is "simple" in comparison (and to be fair, D3 exploits that beautifully).
- deleted 11y ago
  [deleted]
Narishma 11y ago
The higher level abstractions aren't zero-cost.
- lmm 11y ago
  No reason they can't be.

bucaran 11y ago

For me, the beauty about Vulkan is in future work and libraries that will be based in it and I bet will start popping up over the next following months, if not sooner.

yason 11y ago

AFAIK, the point of Vulkan is to get to modelling the hardware as possible. It's not even supposed to be a high-level API but allow efficient access to today's GPUs. OpenGL is an abstract state machine and it requires a great deal of effort to convert that state into what today's GPUs are actually capable of efficiently handling. Getting that triangle onto the screen in OpenGL is maybe 20 lines of code but you will have 200,000 lines of code in the OpenGL driver translating the commands into the actual configuration of the hardware unit. And if you want to draw 2 million triangles you will have to work hard to work around the overhead introduced by the OpenGL implementation. Then again, OpenGL can be reimplemented on top of Vulkan for end-developers and more complex game engines will be written against Vulkan directly, and then people will work on those instead of writing direct Vulkan code. Once you get the building blocks right you can build on top of them layers of abstraction that suit what you need. This is in contrast to the current situation where the abstractions are fixed and don't necessarily suit the end-developer nor the driver developer. Today you need to implement your game or graphics engine abstraction (which you will use yourself) in terms of OpenGL (requiring lots of tricks), then the OpenGL driver has to implement OpenGL in terms of the actual hardware (again, requiring a lot of clever trickery to handle and transform the state efficiently) and as a result the pixels will show up on the screen but at the cost of a potentially huge overhead which could be introduced somewhere along the route.

mpweiher 11y ago
Yup. The way I understand it is that graphics pipelines today (maybe always) are quite different from the procedural API that OpenGL provides. That mismatch causes all sorts of problems, for example that using the OpenGL APIs "naturally" can be extremely inefficient, whereas trying to access the GPU pipeline naturally is really convoluted and you have to get it just right in non-obvious ways. The structure of the GPU pipeline appears to be sufficiently settled that we can now expose it more directly. That way, talking to the GPU in a way that's natural for the GPU is at least straightforward, even if it's arduous. It seems like you should now be able to build APIs that are both at a higher level and not in conflict with how the hardware actually works.
PopsiclePete 11y ago
Ok so is Vulkan basically assembly code targeting GPU's? If so, my only question is - why the heck did it take so long for it to get here?

gcb0 11y ago

openGL was a good idea. But drivers were buggy as hell and every vendor was adding their own extensions like crazy. Vulkan is the F-that solution. They removed most unifying abstractions, made the API turn the video card into a general computer and let the engine developers do the hardware compatibility layer instead of the developers, since they were doing that work indirectly on top of the drivers bugs anyway. and wow, it is really exactly 200 lines.

skoczymroczny 11y ago

Well, in OpenGL it would take you at least 100 lines of code. Don't forget that glBegin and fixed function pipeline is deprecated nowadays. Sure, with that you can draw a triangle in 10 lines. For modern OpenGL you have to create vertex and fragment shaders, send uniforms, create vertex buffers, upload vertex data, set up vertex attributes, and only then can you render. Vulkan is just the next step of that. Also, a lot of Vulkan code is something you will wrap once, and unless you need the absolute best performance and finetuning you can just stash it in some utility method. Creating an image takes 40 lines of code? Put it into a create_default_image() method and it's only one line of code from now on.

exDM69 11y ago

200 lines for a triangle is roughly comparable to what it takes on D3D or Metal. This is the level of control that graphics and engine programmers require to make things run efficiently.

mrec 11y ago
That's D3D12, presumably.

sgift 11y ago

This only tells me that it is not the right API for putting one triangle on a screen. Sounds okay? APIs (or programming languages or frameworks or ...) which are build for "big things" often have a certain amount of boiler plate required that looks absurd when you use them for something extremely small, but doesn't matter for something bigger.

andresmanz 11y ago

Oooh, yes. It couldn't get any better, right? The amount of control you have here is just perfect. If you don't like that, just wait a few days. I'm sure there will be tons of libraries that let you do that with a few lines of code.

sklogic 11y ago

Next thing you'll complain about would be on how absurdly explicit the x86 ISA is. So many instructions just to get "Hello, world" printed.