The main page of Khronos' beginner's guide to Vulkan has a quote which says "emphatically... NO", but then the first tutorial in the list gives as a prerequisite "some existing experience with 3D computer graphics" and links to a guide (https://paroj.github.io/gltut/) which teaches OpenGL.
* vectors, vertices, points and how they are handled in 3D graphics
* how geometry is built out of the above
* Basic knowledge of how the camera is set up
* Ditto lights
* Basic knowledge of manipulating objects in 3D space
* Knowledge of texture/material systems and how materials are applied to geometry
And, while not specifically 3D graphics, some maths to tie all that together (mostly linear algebra, optionally quaternions).
Besides the math, a couple of days learning to create some simple scenes in Unity - or even better in a pure code environment like Three.js - could give you all the knowledge you need to get started writing shaders.
Of course, you could technically jump straight into writing shaders without any of that, and shaders can be used for a lot more than creating 3D scenes, but presumably the Khronos assumes this kind of knowledge.
There are other options to get started with graphics. Frameworks you can use to start putting your toes in the water: any game engine, a higher-level graphics framework like raylib or bgfx, or a cross-platform graphics layer like WebGPU/wgpu.
I don't want to gatekeep, just being realistic that if you're new to graphics in general, Vulkan might not be the best place to start. You'll get there eventually though.
In Vulkan, you're going to be manually describing to the GPU every last atom of your graphics pipeline. You also need to worry about how it's all laid out in memory through a bunch of descriptor objects that you're building in tandem. Then there's syncing between the GPU and CPU via semaphores etc to transfer data, which can be error prone and hard to debug. This results in very verbose and hard to read code. If you've never touched a graphics api before, I think frustration starts to mount and you'd be more likely to just give up. The upside is you have total control over how the GPU interprets and executes your workload (most likely a triangle as a beginner :P)
Anyway, a lot of this is hidden away in DX11 or OpenGL, you call a few functions here and there and it will do all of these lower level concerns for you. I think once you get used to the jargon and feel of apis like these, you can then start to see how Vulkan or a similar low level api would fill in between the higher level procedures/objects.
Edit: For any graphics api, imo, if you're concerned about building a game you'd probably also not want to touch those apis directly from game code. In DX11 or OpenGL it's not too hard to wrap that up in a bit higher abstraction but in Vulkan you'd almost first want to wrap Vulkan into an api that can be used without writing a ton of manual setup and then use that api to write a higher level, more game appropriate abstraction to call from the game's code. (usually done as part of an engine/framework)
Edit 2: Having said all of this, you could ignore all of the nitty/gritty details and just copy paste the code from the tutorials and make a workable api for yourself to try to understand. Up to you and how you like to learn.
Honestly if platform is not an issue, I'd recommend people start with Metal because it's the easiest of the "modern" graphics APIs. DirectX 12 is probably second and Vulkan is probably among the hardest to start with.
WebGL is also a good way to start though is obviously more limited.
Or start with shader graphs in unreal or unity. You can still learn the shader logic and math without worrying about setting up a render context and learning to "code"
Well, maybe not OpenGL, but almost surely some graphics API which allows you to do graphics without a couple thousand lines of obscure boilerplate.
There are lots of "middleware" systems built on Vulkan that are WAY friendlier than raw Vulkan. They handle things like asset loading, memory management, and scene composition for you. If you want to build something, use those. You'll be vastly happier at the end of the day. Maybe at some point you'll hit a performance bottleneck--fine, but by then you know a lot more about graphics.
If you're doing raw Vulkan, you should have a darn good idea as to your purpose.
If someone says: "I want to use Vulkan." I ask "Why?"
If they say: "Because I want to make a thing that does <X>." then they absolutely should be in a middleware system and not Vulkan. They'll get something on the screen much faster and keep their motivation going.
If they say: "Because I want to learn" I have to try to redirect them to something a lot simpler. Learning is about motivation and Vulkan boilerplate saps your motivation really hard.
It also doesn't help that Vulkan development is basically C++ and Windows and there is no negotiating this as a beginner. Trying to develop Vulkan through a language wrapper or on Linux/OS X adds an unnecessary amount of pain to the process--quadruply so if the wrapper tries to be "idiomatic" in your language of choice.
If they say: "Well, we found a bottleneck using RenderDoc and we..." then I ... HA! I'm kidding. Nobody says this because they KNOW why they need to use Vulkan so they don't even ask me.
The primary problem with Vulkan is that you are mapping REALLY closely to the underlying hardware. If you don't understand what the pieces of your graphics card are and what they are doing and why, Vulkan makes very little overarching sense.
One thing I will warn you about when programming Vulkan, you better be really good in your programming language of choice. There are times when you are writing Vulkan code where you have to add a couple hundred lines of code before you can finally test that you got it right. You have to be very confident in your programming skill that you got all the essential things in your language right so that any bug is really in the way you are using Vulkan. For example, if your understanding of pointers and pointers-to-pointers isn't rock solid, you're gonna have a bad time.
However, if you still wish to persist. Here is a class at Oregon State that does Vulkan: http://web.engr.oregonstate.edu/~mjb/vulkan/
Note that this is considered an upper division/graduate class. That should give you an idea of what you're in for.
Actually Vulkan uses C, not C++ as usual in most Khronos APIs, and only GNU/Linux and Android 10 onwards are the only platforms where Vulkan has any meaningful usage.
On Windows everyone just uses DirectX, OpenGL ICD which are also used by Vulkan drivers aren't even allowed on Windows sandbox driver model, and on Switch, Vulkan might be supported, but so is OpenGL and NVN is actually the one holding the GPU keys.
In what concerns Sony and Apple, Vulkan doesn't even exist.
You are technically correct--Vulkan is a C API. However, all the tutorials you will use are written in C++.
I have never seen a C-only Vulkan tutorial. Link welcomed.
On Windows, everyone is using DirectX 11. That is a very different (and much simpler!) beast than DirectX 12 (which--unsurprisingly--looks very much like Vulkan).
And, as for Apple, I suspect the fact that Valve/Steam is all-in on MoltenVK(Vulkan on top of Metal) for development means that way more gamers are running games with Vulkan on OS X than plain Metal. (DotA 2--for example--is MoltenVK only on OS X, IIRC).
However, most game developers DON'T CARE. They are writing to a game engine that handles all that behind the scenes. As long as the game engine is ported to the appropriate system, the underlying implementation is irrelevant to them.
https://www.amazon.com/Vulkan-Programming-Guide-Official-Lea...
> On Windows, everyone is using DirectX 11
Which is quite different from "It also doesn't help that Vulkan development is basically C++ and Windows".
On Apple, all relevant engines support Metal directly, no need for MoltenVK at all. That is just for the usual FOSS anti-Apple folks that buy Apple hardware and then complain it isn't GNU/Linux.
> However, most game developers DON'T CARE.....
I agree 100% with this statement.
Nope. Leaving aside the fact that the book isn't that great and that I only see snippets and not a compilable codebase, look at the snippets:
"VkResult vkapp::init()"
"std::vector<VkQueueFamilyProperties>"
> It also doesn't help that Vulkan development is basically C++ and Windows
I stand by this statement. If you are doing Vulkan (and not DirectX) the highest probability is that you are on Windows in C++.
> On Apple, all relevant engines support Metal directly
Source 2, at the least, does not as far as I know. Which means that DotA2, CS:GO, Artifact, etc. all only run on iOS via MoltenVK since Apple has dropped OpenGL support.
Source 2 belongs to the "that is just for the usual FOSS anti-Apple folks that buy Apple hardware and then complain it isn't GNU/Linux." given it is from Valve.
Unreal, Unity are the relevant ones.
CS:GO is definitely not Source 2 (yet?), and I'm not sure about Artifact, but it was at least at one point developed using Unity.