Vulkan in 30 minutes(renderdoc.org)
renderdoc.org
Vulkan in 30 minutes
https://renderdoc.org/vulkan-in-30-minutes.html
5 comments
The sample code shows just how absurdly explicit this API is. 200 lines to get a triangle on the screen!
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.
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.
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.
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.
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?
It's more like C than like assembly.
Different GPUs have different machine codes, Vulkan is abstracting away the differences, but tries (like C) to be simple abstraction close to the real thing.
Different GPUs have different machine codes, Vulkan is abstracting away the differences, but tries (like C) to be simple abstraction close to the real thing.
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.
With great power, comes great responsibility.
For those who don't prefer this level of abstraction, just use a higher level zero cost abstraction.
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??
How can there not be an drawing app built on top of this so that you can just model/draw and have it translate??
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.
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.
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.
Vulkan isn't a complete replacement for OpenGL; it's a GPU API aimed to be built upon.
The goal is to have a cross-platform low level API that can be easily tested for compliance/conformance, right?
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.
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.
I don't know, I feel like D3 solidly demonstrated that you can have absolute configurability without sacrificing any conciseness.
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).
D3 is not concise compared with most simple js graphing libs -- e.g. highcharts.
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.
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.
[deleted]
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.
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.
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.
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.
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.
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.
It's Vulkan, with a K.
[deleted]
[deleted]