Vulkan-Tutorial.com, while not affiliated with The Khronos Group, is a good read to understand how the Vulkan API is structured. It is set up like the tutorials I followed when learning WebGL, which seems to make it quite approachable. I mean, we are still talking about the Vulkan API, which was in no way designed to be easy or simple, but introduction-level material is still good for developers of all skill level, unless they're looking for specific advice.
To emphasize what I mean by “approachable”, the tutorial even includes screenshots of Visual Studio 2015 at some points, to help Windows users set up their build environment. Like… step-by-step screenshots. This explanation is also accompanied by Linux instructions, although those use Ubuntu terminal commands.
>was in no way designed to be
>was in no way designed to be easy and simple
Excuse me my french, Scott, but…you friggin’ WHAT? Vulkan was developed from the DAY-ONE with an absolute setmind to NEVER EVER be like OpenGL when it came down to it’s documentation and overall approachability for newbies. Literally EVERYONE out there knows what a completely nightmarish hell is the so-called “documentation” for OpenGL, when they began working on Vulkan – Khronos vowed to never ever do such mistakes ever again. Easiness of documentation and difficulty of learning-wise, Vulkan is NOTHING like what friggin’ OpenGL was for all these years. OpenGL is super-convoluted and a total pain in the ass, while Vulkan’s pretty easily understandable and open as all hell. As long as a man can code on a level above “dummy”, he can get decent results from Vulkan (even if not the best), while OpenGL REQUIRES of you to be an effing Mitnick (or Carmack, lol) to obtain ANY decent results AT ALL. They are nothing alike sheer difficulty-wise, that is my point. Vulkan is NOT that hard as you make it seem to be in that article of yours.
Vulkan, like DX12, is a
Vulkan, like DX12, is a low-level API. It’s very purpose is to move more of the actual implementation of the graphical pipeline into the hands of the engine developer, rather than the GPU vendors’ driver developers.
Unlike OpenGL and DirectX, which abstract a lot of the underlying work away, Vulkan and DX12 expose it. That means that if you actually want to get something running well (rather than the bare minimum “OMG I can display a textured poly in a buffer!”) you have whole new skillsets to learn in terms of memory management, pipeline wrangling, etc. And those skills aren’t universal, but architecture-specific (i.e. a tweak that boosts one architecture will impede another).
They are not, and never were intended to be, easier to develop for. Making them easy to develop for would defeat the point of a low-level API in the first place. Low level APIs are not magically +1 faster, they achieve better performance through requiring a lot more work.
You wrote absolute nonsense,
You wrote absolute nonsense, because almost everything you’ve said there heavily contradicts both Khronos and also AMD’s stand and take on the whole thing (be that Mantle or Vulkan). Don’t bring your DefectX-crap into this argument, because the entire approach to handling that platform is utterly different (latest iterations are way worse than even the OpenGL). It’s true that DefectX 12 is a low-level API (thanks, Captain O), but it’s way more closed (and outright blackboxed) than Mantle/Vulkan ever was. Also – OpenGPU initiative is out there for a reason.
No, he did is 100% correct in
No, he did is 100% correct in what he said, However you are right that DX12 is nothing more than an effort from Microsoft to lock down game engines, for them the person who only can use their pre-built tools is called “developer”, and the same applies to Apple cult.
Anyway, The real programmers are those who want less layers between them and the hardware they are writing to.
Correction: He is … *
Correction: He is … *
It has nothing to do with
It has nothing to do with DirectX. I distinctly remember hearing The Khronos Group recommend OpenGL AZDO over Vulkan for novice programmers, but I can't find the source.
I have heard in one-on-one calls with Khronos Group that they are hoping for frameworks (ex: Qt) to abstract Vulkan. They mentioned how people said that WebGL was too complicated for web developers, but it was added anyway and it is being used, just mostly through Three.js and other frameworks. They expect the same for Vulkan, and that it would be the key to mass adoption.
Vulkan is still pretty new,
Vulkan is still pretty new, so all the automated code designers and SDK plug-ins to make programming easier are still under development, but there are thousands involved across the PC/laptop market and the Mobile market(Much larger than the PC/Laptop market) working on getting all the programming aids added to QT/VS/Other SDKs, including the gaming engine SDKs. Programming Noobs Need to get up to speed with not only Programming concepts but also OS API concepts, and Graphics API concepts, in addition to any API concepts use by any modern OSs. With Any OS/API there are abstraction layers to deal with, and its APIs/abstraction layers all the way down to the metal in computer world, it has always been thus!
This instruction manual helps
This instruction manual helps ->Programmers<- to get their own coding template/s started to help them to get up to speed using the available Windows and Linux SDKs and the Vulkan API. If you are not a programmer that has experience with coding, Graphics programming included, for APIs using SDKs then you will have a larger learning curve. So once the programmer can get the proper libraries loaded and linked to by header files and what ever libraries compiled(When Needed)and linked to with header files then that programmer can create a Template under the respective SDK(Windows/Linux) to generate the necessary code and header files for all their Vulkan based projects without having to do it all from scratch every time. For any programmer not used to any of the Windows/Linux SDKs well that programmer must be pretty much a ghost from a time when COBOL was new, because SDKs have been around for Ages to help automate the massive task of learning to program for any API, graphics or otherwise. IF you are not fully used to C type programming, and some OO programming also, then things are going to be harder, and much harder if you have no SDK experience. APIs, any APIs, usually comprise hundreds of thousands of lines of code, if not millions! And who in their right mind does not want to use a proper SDK with some form of automated code designers, and symbol listing tools with auto-complete functionality that can list the thousands of Methods/Functions that are included in the thousands of Objects/Structures with Object/Structure hierarchies that make up most of the APIs of any type and functionality. If you do not have much experience with the Windows/Linux OS APIs, then you need to get up to speed with that also because every Windows or Linux application runs under their respective OS APIs including the Graphics APIs whose call stacks eventually reach into their respective OS’s APIs to get any thing done on any computer. Vulkan requires more code but that code is able to be accessed by the programmer and tweaked/optimized way more than the older Graphics APIs allowed, and the Device drivers that are used with Vulkan are much simpler with access much closer to the GPUs’ metal than with the previous graphics APIs! So everybody and his dog will be able to optimize their code, and also take part in Optimizing the Vulkan API, because Vulkan is the only fully open and cross OS/devices platform API with that close to the GPU metal ability. Vulkan is also a Compute API, in addition to the Graphics functionality so plenty of games designers will be moving more compute onto the GPU and off of the CPU to make games more responsive with the lowest latency.
I mainly code in Delphi. You
I mainly code in Delphi. You people amuse me.