Vulkan: for beginners?

Vulkan
1

A continuation of the discussion from here.

I think this point was mentioned in the presentation, but I think that’s precisely why beginners will jump toward Vulkan. The current OpenGL atmosphere has way too many unknowns and beginners will be looking for something that offers them a better understanding of what the GPU is doing.

Oh beginners will absolutely jump towards Vulkan. They’ll be attracted by talk about performance, “close to the metal”, and other such things. Vulkan’s new and shiny, while OpenGL is old.

That doesn’t make them right. Nor does it mean that Khronos should support them. Indeed, what Khronos needs to do is widely advertise that Vulkan is not appropriate for beginners. They need to send them to OpenGL or somesuch for a while, until they’re ready for it.

Beginners who have a bad initial experience with a Khronos technology will likely be very upset and not try to use the “old” OpenGL. So Khronos needs to make it clear that Vulkan is not for everyone.

This is not about the “600 lines of code” issue. I’ve written material that attempts to teach beginning graphics programmers based on core OpenGL. So I’ve written ways to teach beginners using “Hello World” programs that are quite verbose. I’m well aware of what you have to do to get a beginner into the right head space.

And that right there is the fundamental problem with Vulkan for beginners.

While I have written learning materials, I’m also the principle curator for the OpenGL Wiki. In that duty, I had to write this information. Now, I’ve done my level best to make that as comprehensible as possible.

But the fact of the matter is this: the people most likely to be effective in comprehending that environment are those who have a firm foundation in multi-threading theory and practical application. And if that defines a particular “beginning graphics programmer”, then that person is clearly an experienced programmer who just hasn’t experienced graphics programming.

That’s a very different audience from random guy on a forum who wants to learn Vulkan.

In OpenGL, that incoherent memory stuff, with it’s oddball barriers and such? That’s opt in; it only applies to certain very advanced features that most OpenGL users can freely avoid. You wouldn’t even be able to use them until you understood the basics of GL.

In Vulkan? That’s every day.

Here’s one of the simplest tasks in graphics: changing the value of a program’s uniform. Let’s be fair and call it a UBO value, so that we can’t cheat on the OpenGL side and call glProgramUniform.

In OpenGL, you map the buffer, set the value, and unmap it. Or you call glBufferSubData. Or whatever. Not using a proper buffer streaming technique may lead to degraded performance, but at least it works.

In Vulkan… you first must make sure the memory isn’t currently being read or due to be read by any outstanding rendering command. And that’s not a Vulkan API call or anything; it’s on you to keep track of that. If you do it wrong, then you hit undefined behavior.

If the memory is currently being read from, then you’re going to have to get a new buffer with new memory and put your value in it, along with all the other values that didn’t change. And if you don’t do it right, then you again achieve undefined behavior.

Uniform setting would be the sort of thing you’d see in the second or third tutorial in OpenGL. It would be pretty trivial, even with UBOs only. But in Vulkan, its an exceedingly complex operation.

Oh, you could just tell them to issue a full CPU/GPU sync after every frame. But then you’re just teaching them to use Vulkan badly. And that’s the last thing we want.

Or to put it another way, OpenGL is to Vulkan as Python is to C++. Sure, C++ is really cool, powerful, and low-level. But unless you actually are Bjarne Stroustrup, you’ll be better off teaching beginning programming students Python first. And even if you are, there’s no evidence that programmers who start off with C++ actually understand what they’re doing better than a programmer who learned Python, then C++.

Furthermore, I don’t believe that Vulkan is that much better for gaining “a better understanding of what the GPU is doing” than OpenGL. And this is again where trying to do it does a disservice to beginners. It gives the impression of knowing what the GPU is doing without the actual knowledge of what it’s really doing.

As an example, Vulkan has this notion of render passes, which represents the concept of rendering to a set of render targets. What does that represent on GPUs?

It depends on the GPU. For a tile-based GPU, it means doing a full render process. For a regular GPU, it means… clearing some caches.

Yet to the Vulkan API, it’s the exact same thing. Someone trying to learn what’s really going on through Vulkan only understands the abstraction, not the hardware. Oh sure, command queues are more explicit, as are GPU devices, state changes, memory allocation, and such (not that OpenGL ever hid any of these save queues and devices). But overall, Vulkan still hides plenty of details about what the hardware is doing.

I doubt you’d be able to tell, for example, that AMD GPUs actually modify your vertex shaders to do vertex attribute field decompression.

1 Like
2

One of the ideas I’ve been kicking around is building a tutorial about how to create a OpenGL driver setup with userspace DLL, “kernel” driver executable and GPU executable all built in software and all communicating and an example app using it all (4 different projects all having to work together!!).

The big goal was to show openGL programming from the other side of the API without needing a existing hardware GPU highlighting the challenges involved with memory consistency and such. The reason it hasn’t happened yet is lack of time and general procrastination.

3

In reply to MissingAFew:

Isn’t everyone a beginner when it comes to Vulkan?

No. Being new to Vulkan doesn’t make you a beginning graphics programmer. I just didn’t want to have to keep typing “beginning graphics programmer” when it was clear what we were talking about.

I consider myself a beginner and I think I work well when Im forced to learn lower level concepts and read through documentation. I don’t think people should just run away from it because the “experts” say to not bother, how else are people supposed to learn?

They will learn when they stop being beginners at graphics programming.

Would you learn rocketry by building a Saturn V? No; you start with something much simpler and work your way up. You don’t learn Calculus without first learning basic Algebra. You could try to teach them both at once, introducing concepts of Algebra when they became relevant to Calculus. But that doesn’t make it a good idea or an effective teaching method.

My point is not really about “experts” warning off “beginners”. Beginners will do whatever they want, and I can’t reach through the screen and stop them.

My point was about Khronos not spending limited time and resources on beginner-friendly features like input libraries and such. If that’s going to be done, let someone else do it. They should focus on things that “experts” need, like serious debugging tools, cross-compilers, validation layers, etc. Khronos doesn’t have infinite resources, so they should focus those resources where they are needed.

And making Vulkan “beginner friendly” is not where they are needed.

As for how you learn best, I don’t know you. So I have no idea if what you say about how you learn is true or not, so I’ll accept you at your word.

First, if you work best when thrown into the deep end of the pool, then I’m pretty sure you can also figure out how to download an input library or use Win32 or some other library to create your windows and hook them into Vulkan. So Khronos doesn’t need to provide you with a full, cross-platform input and windowing library. You can make it work yourself from various bits, or you can wait the all-of-2-months it’ll take before projects like GLFW and such are updated to support Vulkan.

Second, at the end of the day, you are not everyone.

Most “beginners” learn best from a measured, step-by-step approach. If you work best by being thrown into the deep end, more power to you. But general advice should cater to general audiences.

And the best general advice I can give is that beginning graphics programmers should avoid Vulkan until they stop being beginning graphics programmers. They simply aren’t ready for it.

This is not like the difference between learning old, fixed-function OpenGL and core OpenGL now. The problem there is that FF introduces a number of concepts (texture environments, texture matrices, etc) that do not have direct analogs in core OpenGL. Which means, if you take the time to really learn FF OpenGL, then you’re wasting a lot of time learning things that you don’t need to know. You’re learning an abstraction, but it’s a very poor abstraction compared to what you’ll be learning later on.

By comparison, for every concept in core OpenGL, there is an equivalent concept in Vulkan. Oh yes, Vulkan has (many) more concepts too. But pretty much every graphical construct in core OpenGL is done in a similar fashion under Vulkan. Vertex data comes from buffers. Transform feedback goes into buffers. Uniforms buffers and SSBOs. Textures and samplers as separate objects. Framebuffers with attached images. Program objects and all of the shader stages. And so forth. Core OpenGL even has synchronization primitives and some incoherent memory accesses like Vulkan.

Learning core OpenGL will not in any way hamper your ability to learn Vulkan later. By understanding the graphical concepts of core OpenGL, it allows your eventual transition to Vulkan to focus on the new concepts that Vulkan introduces (explicit synchronization, parallelism, queues, command buffers, descriptor sets, etc). Rather than trying to learn both the graphical constructs and Vulkan’s lower-level style.

Learning core OpenGL lets you focus on learning graphics, without having to deal with the performance issues which is the focus of Vulkan. As they say: premature optimization is the root of all evil. And prematurely learning optimization is no better :wink:

4

If you’re concerned about Vulkan API being too hard, you should send the beginners to use Unity3D or Blender rather than OpenGL.

OpenGL isn’t an easy to use API, and it’s not easy to implement efficient programs in OpenGL. Even simplest tasks expose you to lot of detail you need to understand. And surely Vulkan’s main function is to utilize the graphics hardware, of course it shouldn’t handle input for beginners. That’s why you’ll provide things like GLUT.

You make it sound like Vulkan will be a bad API. “Undefined behavior” and “C++” likeness aren’t neat qualities. Well behaving programs should crash as soon as feasible and lead to the source of an error the programmer did. With an exception that the error checking cannot be feasibly done, the corruption to the state should be easy to isolate. Otherwise programs become harder to diagnose and debug for no good reason. Additionally you shouldn’t be verbose because “it’s professional”. More succinct you can be while doing exactly the things you need to do, the better. Excess leads to pointless errors.

Besides you don’t optimize just by shifting it to Vulkan. Optimization progresses in steps. If Vulkan allows to create an app that is slower than your average OpenGL app, but simpler. In that case it’d be exactly what both beginners and experienced developers need. Need for optimizations should arise before optimizing, and it should be satisfied by benchmarking and then optimizing the code to perform objectively better. Having an “easily” written Vulkan program to optimize is better than having to optimize OpenGL by translating it to Vulkan in that respect.

It’s not similar in any way to “Python” vs. “C++” issues. I get an idea you’re just talking and not representing anything that should be taken seriously. Consider to reason your points better. Otherwise you’re just doing damage to Khronos by smearing the API before it’s even out.

5

I agree that OpenGL is less easy to use than, say, Unity. And there are certainly efficiency snarls (see buffer object streaming, as the simplest example).

But OpenGL is a good order-of-magnitude easier to use than Vulkan. It’s a lot harder to create a broken program in GL. Any breakages that aren’t caught by the API will generally consist of some form of “you put data into GPU memory wrong.”

I’m not sure what you mean by “neat qualities”. But if you think that Vulkan won’t be a minefield of undefined behavior, you might want to re-investigate the purpose of all of these “next-gen” graphics APIs.

Vulkan, like C++, does not exist to coddle you. It’s not going to keep you from shooting yourself in the foot if you don’t know what you’re doing. It will not stop you from writing to a value that the GPU is going to read. You will have to use explicit synchronization mechanisms when poking at data, or you will have to devise strategies around it. It will not check behind your back to see if you’re using the API correctly.

That’s what Vulkan is for: get out of the way of the programmer. And one of those things is the kind of validation that OpenGL always does. Just like C++: Vulkan is a thin(er) abstraction of the underlying stuff. And with great power, comes great responsibility: the programmer must do the right thing; Vulkan’s not going to check your code for you.

Or at least, straight Vulkan won’t. The slides spoke of layers built into the loading scheme, and one of those layers was said to be “validation.” And that would (theoretically, since we don’t have actual code) be something that could protect the programmer from themselves. Even so, those layers are opt-in and we don’t know how comprehensive they will be.

I expect that Vulkan’s debugging tools will help alleviate such problems. But that doesn’t mean that those problems won’t exist.

If Vulkan’s “not checking for errors” nature makes it a “bad API” in your book… maybe you should get a different book. But what Vulkan is, the level of abstraction it operates at, is not up for debate. Outside of a validation layer, it will not do any of the things you say are needed for a good API.

You’re basically arguing my case for me. Because that design philosophy is exactly the one taken by… OpenGL. And Python.

Vulkan (sans layers, at any rate), and C++, don’t take that design philosophy. That’s a fact, and it is indisputable. They said exactly this during the presentation: the API has no implicit synchronization and no validation (without asking for it via a layer). It won’t check to see if you’ve created incorrect state. It won’t stop you from crashing or causing a GPU reset.

Welcome to low-level graphics programming.

You speak of Vulkan as though we don’t know what we’re getting. As though its general design was not pinned down or well understood. While the specific details are certainly in flux, we are very well aware of what Vulkan will generally look like. The slides and presentation made that abundantly clear: the API will be analogous to Mantle, D3D12, and Apple Metal.

None of those APIs are simpler than OpenGL apps by any meaningful definition of the word “simpler”. Just in terms of synchronization alone, all of those APIs make rendering much more complex. So why would you think Vulkan would allow you to write an application that is “simpler” than an OpenGL one?

To be fair, Vulkan can make a complex rendering engine less complex. But we’re talking about beginners here. And for them and their applications, Vulkan introduces a lot of concepts and complexity they don’t need and aren’t ready for.

Your conclusion is drawn from a false assumption.

6

I didn’t mean to say that you should become an expert in OpenGL before transitioning over to Vulkan. You don’t need to be an algebra expert to take calculus. I’m saying that your flight to Vulkan should include a lengthy layover in OpenGL.

Once you understand graphics and graphical concepts (shaders, buffers, textures, framebuffers, etc) and have a very solid handle on the theories of rendering and such, you’re ready to move into Vulkan.

Well, after you’ve done some threading :wink:

7

[QUOTE=Alfonse Reinheart;31101]I’m not sure what you mean by “neat qualities”. But if you think that Vulkan won’t be a minefield of undefined behavior, you might want to re-investigate the purpose of all of these “next-gen” graphics APIs.

Vulkan, like C++, does not exist to coddle you. It’s not going to keep you from shooting yourself in the foot if you don’t know what you’re doing. It will not stop you from writing to a value that the GPU is going to read. You will have to use explicit synchronization mechanisms when poking at data, or you will have to devise strategies around it. It will not check behind your back to see if you’re using the API correctly.[/QUOTE]

It’s a C API to where you can feed in a custom allocator. Sure the programmer probably needs to know what he is doing.

It’s also taken by bunch of other systems. It’s one of the mechanisms used in erlang to achieve fault tolerance. In C -case: If you give the API garbage, it either renders garbage or crashes. That’s something that cannot be avoided with C programs. Still you’re not intentionally constructing traps to produce flanging pointers or corrupted memory.

Also the stuff will stay within the process boundaries. It’ll be still unacceptable for an userspace process to cause kernel panics, even if coded by a newbie.

If Vulkan’s “not checking for errors” nature makes it a “bad API” in your book… maybe you should get a different book. But what Vulkan is, the level of abstraction it operates at, is not up for debate. Outside of a validation layer, it will not do any of the things you say are needed for a good API.

I don’t think Vulkan will be the kind of API you describe it will be. It’ll require you to consider things you would have to consider with C anyway. It also doesn’t make it unnecessarily difficult to implement things such as WebVulkan. On the contrary it’ll be simpler than it was with WebGL.

You speak of Vulkan as though we don’t know what we’re getting. As though its general design was not pinned down or well understood. While the specific details are certainly in flux, we are very well aware of what Vulkan will generally look like. The slides and presentation made that abundantly clear: the API will be analogous to Mantle, D3D12, and Apple Metal.

None of those APIs are simpler than OpenGL apps by any meaningful definition of the word “simpler”. Just in terms of synchronization alone, all of those APIs make rendering much more complex. So why would you think Vulkan would allow you to write an application that is “simpler” than an OpenGL one?

I don’t know what we’re exactly getting yet. From the slides I understood that Vulkan actually removes lot more than it introduces. Overall it’d seem that there will be very few API functions. More information is passed up in buffers rather than explicit function calls. This may actually mean more robustness in non-C/C++ -software.

Your conclusion is drawn from a false assumption.

I saw the SPIR-V paper and thought that the designers are quite competent. They’ve taken every measure to not add in unnecessary complexity. And the slides seem quite good too. Before doing any stupid conclusions I need to see more. This far I’m staying optimistic.

8

[QUOTE=Alfonse Reinheart;31102]I didn’t mean to say that you should become an expert in OpenGL before transitioning over to Vulkan. You don’t need to be an algebra expert to take calculus. I’m saying that your flight to Vulkan should include a lengthy layover in OpenGL.

Once you understand graphics and graphical concepts (shaders, buffers, textures, framebuffers, etc) and have a very solid handle on the theories of rendering and such, you’re ready to move into Vulkan.

Well, after you’ve done some threading ;)[/QUOTE]

Sorry about posting in wrong thread, will post here. I’ll take your advice for now I guess, it makes sense. If only because there’s better documentation, tutorials, learning tools, etc. for OpenGL. I do know the concepts of those things to an extent from dabbling around here and there, I’m not totally clueless in that regard. But I’m definitely not where I should be either.

9

[QUOTE=cheery;31106]It’s also taken by bunch of other systems. It’s one of the mechanisms used in erlang to achieve fault tolerance. In C -case: If you give the API garbage, it either renders garbage or crashes. That’s something that cannot be avoided with C programs. Still you’re not intentionally constructing traps to produce flanging pointers or corrupted memory.

Also the stuff will stay within the process boundaries. It’ll be still unacceptable for an userspace process to cause kernel panics, even if coded by a newbie.[/quote]

Nobody is suggesting that Vulkan will have an API deliberately designed to screw over the programmer. What we’re saying is that it won’t be a safe API.

That was the point of the Python/C++ comparison. Python is very nice and safe by design. It has garbage collection, and you can’t get at actual pointers. C++ is not safe by design. You can access details, casting pointers and pointer arithmetic is allowed, memory allocation is explicit, etc. C++ is not designed to make programming harder; it makes programming harder as a consequence of giving you lower-level access to things.

The same goes for OpenGL/Vulkan. OpenGL is very nice and safe by design. It has implicit synchronization for most operations, it hides details of hardware memory allocation, and so forth. Vulkan is not safe by design. You must manually synchronize actions, you must explicitly allocate memory of the right size, etc.

In programming, greater power requires greater responsibility.

On what facts do you base this conclusion on? Everything I’ve said about Vulkan (explicit synchronization, explicit memory management, etc) has been confirmed directly by the slides and presentation. These are not difficulties of the API; these aren’t complex functions with lots of parameters or something. These are complex concepts, like concurrency, data races, data visibility and the like.

So what facts do you claim support the idea that any “WebVulkan” would be “simpler” by some measure than “WebGL”?

Removes more… relative to what? To OpenGL?

The number of API functions is basically irrelevant to the complexity of the API. It’s all about what those functions mean and what they do.

This may actually mean more robustness in non-C/C++ -software.

… what does that have to do with usage for beginners? We’re not talking about whether it will have robustness features like process isolation and such. The API can be too complex for beginners while still having process isolation.

10

I’ve managed to crash OpenGL implementations by calling glShaderInfoLog for program objects. And you need to allocate memory with C programs anyway.

In the above sentence, it’s very ambiguous what “power”, “requires” and “responsibility” means in the context.

In the slides you’ve got everything enclosed into a pointer and there’s little or no global state. Those translate to objects in language bindings and provide a clearer view about how everything interacts. “No explicit validation” means that the binding layer gets to implement the validation, that’s fortunate for the reason that the validation in the driver layer doesn’t always work. WebGL already has it’s own validation. By exposing allocation, synchronization and communication specifics to the application, it’s likely easier to deal with those in the bindings.

One metric to consider complexity of the API would be how you can progress in constructing programs.

In OpenGL, the simplest command is to call glClear. You get that in a two-liner. Next easiest thing is to get it draw a triangle without transforms. To get OpenGL API draw a triangle, you have to feed in the data, compile shaders, configure attributes and uniforms, bind it all and issue a draw command. That takes about 200 lines, which includes an utility function to compile shaders. It takes about same amount of code on both WebGL and GL and it remains hard to abstract out because you need to track the state of the OpenGL context.

What does it take to clear the screen or draw a triangle in Vulkan?

Good python bindings and few libraries on the Vulkan can provide much better platform for beginners than what OpenGL ever was. But this is just speculation for now and I need to see a better draft of the API to verify it.

11

And you need to allocate memory with C programs anyway.

… Oh!

When I’m talking about “memory allocation”, I’m not referring to the ability to give Vulkan a set of allocation/deallocation functions. I’m talking about having to explicitly allocate and manage GPU memory directly. In Vulkan, you allocate GPU memory from various available pools, then attach parts of that memory to various buffers and textures.

That’s much more complex than OpenGL’s buffer object and texture object system, which abstracts GPU memory.

In the above sentence, it’s very ambiguous what “power”, “requires” and “responsibility” means in the context.

I thought it was clear. The only word there which is context-specific is “power”; the other two mean what they normally mean. “Power” in this case refers to the low-level access and performance that Vulkan provides.

In order to get that “power”, you are “required” to take on greater “responsibilities” as a programmer. And if you fail to live up to those responsibilities, Vulkan won’t be there to cover your back.

In the slides you’ve got everything enclosed into a pointer and there’s little or no global state. Those translate to objects in language bindings and provide a clearer view about how everything interacts.

OK, I’ll accept that as something that is “simpler” in Vulkan. It’s not much, but it is something.

Granted, OpenGL 4.5 has that, so technically it’s only simpler with regard to the still-remaining non-object context state.

“No explicit validation” means that the binding layer gets to implement the validation, that’s fortunate for the reason that the validation in the driver layer doesn’t always work. WebGL already has it’s own validation.

We’re not talking about what might be “fortunate”. I asked you what made Vulkan “simpler”. And by having no validation in the API, Vulkan becomes much more complex to use, because it won’t tell you why something went wrong. It also won’t stop you from doing bad things to the GPU.

Also, broken drivers don’t count. We’re talking about the API, not its implementation.

By exposing allocation, synchronization and communication specifics to the application, it’s likely easier to deal with those in the bindings.

… no, it isn’t.

In OpenGL ES 2.0 (the basis of WebGL), you don’t deal with synchronization at all. It all happens for you in the driver. Allocation happens, but in a very abstract way; memory is stored within buffers or textures, and once allocated, that memory is locked into that kind of storage. It’s completely invisible, and therefore is as simple as possible.

In Vulkan, this is much more complex on your end because you actually have to deal with it. In WebGL, if you wanted to update a buffer, you call glBufferSubData and you’re done. If that memory happened to still be in use by the GPU at that moment, then OpenGL would issue the necessary instructions to see to it that your changes don’t affect outstanding rendering commands.

In Vulkan, if you update memory that’s currently in use… too bad. You get garbage rendering or whatever. By taking out that synchronization, you increase performance for the user, but the user must adopt greater responsibility by taking on the task of explicitly doing synchonization on such operations. And if the user does it wrong, the API’s not telling them.

Furthermore, it doesn’t matter what language you bind Vulkan to, that doesn’t make it easier to use.

In OpenGL, the simplest command is to call glClear. You get that in a two-liner. Next easiest thing is to get it draw a triangle without transforms. To get OpenGL API draw a triangle, you have to feed in the data, compile shaders, configure attributes and uniforms, bind it all and issue a draw command. That takes about 200 lines, which includes an utility function to compile shaders. It takes about same amount of code on both WebGL and GL and it remains hard to abstract out because you need to track the state of the OpenGL context.

What does it take to clear the screen or draw a triangle in Vulkan?

The presentation goes on record as saying that triangle drawing would take around 600 lines of code. But to me, that’s not nearly as important as the number of concepts the user needs to understand in those “Hello World” lines. That is far more important to beginners, because the more concepts you need to understand up-front, the harder it is for them to learn.

In the “200 lines” (I highly doubt it’s that many) of (desktop) OpenGL, you need to understand: the rendering pipeline, shaders, vertex attributes, vertex array objects, viewport state, and buffer objects.

In the “600 lines” of Vulkan, you need to understand: the rendering pipeline, shaders, vertex attributes, buffers, memory objects (which go into buffers) and GPU memory pools, GPU queues (where you submit your data), GPU command buffers (how you build your rendering command), pipeline state objects (to set the initial default state), render passes and framebuffer images, the Window System Interface and its presentation image (for displaying what you render), and likely some form of synchronization/visibility instructions (once you fill your memory with your vertex data, you must issue a sync/barrier of some kind so the GPU can see it).

Even if that only fit into 100 lines of code, that represents a gigantic wall of complexity that a beginner has to understand.

Or let me put it this way. You said that to clear the screen required only two lines in OpenGL (I’ll call it 3, since you need to swap the framebuffer). This would be the Vulkan general equivalent for the same thing, assuming you already have a graphics command queue and GPU device (which would be part of initialization). And this is just a list of operations; most of these are at least two lines of Vulkan code:


Create pipeline state.
Use WIS to get the window's image.
Create a render pass to render to that image.
Set the image into the render pass.
Create a command buffer.
Put the pipeline state and render pass into the command buffer.
Put a clear command into the command buffer.
Send the command buffer through the GPU graphics command queue.

This may not be quite the correct order of operations (the image-into-render-pass could be part of sending the render pass to the command buffer). And many of the “create” steps are things you could do once and reuse. Also, clear commands could be part of the DMA queue rather than the graphics queue. But that’s still a huge amount of work. And equally importantly, it is a lot of things that a beginner would have to understand.

12

It seems the topic is diverging, so lets get back to the point you try to get across. It’s the thing that angers me, and most of the text doesn’t address it.

We know that all sort of people will charge towards Vulkan, including beginners. Attracted about performance, novelty and closeness to hardware. You propose Khronos should advertise that Vulkan is not appropriate for beginners and direct them to learn OpenGL, or something else instead.

It’s setting really negative tone. Equivalent to slapping with a wet towel. Whoever reads it doesn’t respond by doing as proposed. It’s the worst and most stupid thing Khronos could do.

If someone wants to learn Vulkan, you should provide learning material to that and market it as such. Different approaches may do just as well, and may use OpenGL as a stepping stone. Ultimately the material should get the person started with Vulkan.

But please do not say that something isn’t appropriate for someone, or “not for everyone”. Although it may be true, it’s a wrong thing to say when someone approaches willing to learn. It pisses me that I hear that from someone who boosts himself as person writing learning material.

In any case protocols need documentation and you cannot just sidestep or avoid doing proper specifications. Nobodys time is saved by saving time in writing documentation.

13

Consider this example. Let’s say a beginning GUI programmer comes up to you and says, “I want to learn X11, because it’s all close to the metal and everything!” What should you do?

Should you encourage this behavior, pointing this relatively inexperienced programmer at the byzantine X11 documentation and say, “have at it; good luck!”?

Or do you say that X11 is likely inappropriate to their skill level and suggest that they investigate a more reasonable GUI package like Qt or GNOME?

At the end of the day, I believe that truth is preferable to lies, misinformation, and ignorance. And the truth thus far is that Vulkan is very low-level, and it would be a substantial burden for a beginning graphics programmer to learn without some foundation in modern rendering methodology (as well as concurrent programming).

Because Vulkan is inappropriate for beginners, Khronos should not spend even one programmer-hour trying to encourage them. They don’t need to put up a big, neon sign telling beginners to stay away. But they should focus their time encouraging Vulkan’s actual target audience. Which is not graphics beginners.

Vulkan will succeed or fail based on the support of actual high-performance developers (and IHVs who implement it).

If this creates a negative atmosphere for beginners… so be it. That’s much better than encouraging a generation of cargo cult-style Vulkan developers who have no real clue what they’re doing. At the very least, if you tell beginners up front that this new-fangled thing isn’t for them, some of them will listen and find other more appropriate material.

In any case protocols need documentation and you cannot just sidestep or avoid doing proper specifications. Nobodys time is saved by saving time in writing documentation.

If a beginner in graphics programmer, who’s not an experienced programmer in general, could read and understand the Vulkan spec (or the OpenGL one, for that matter), I would be very impressed.

Specifications are not proper documentation. Specifications are primarily meant for the benefit of those implementing the system, not those using it. That’s not to say that users can’t get anything out of it. But it’s much harder.

This is why OpenGL has reference documentation which is separate from the OpenGL specification.

Vulkan certainly will have a specification. And they’ll probably have appropriate API documentation too. But I hope you don’t think that this will be in any way sufficient for a beginner to learn the API.

Even ignoring the inherent difficulty in learning from reference docs, StackOverflow is pretty strong evidence that there are plenty of beginners who don’t read documentation.

14

Khronos is likely concentrating on getting the drafts out now. It’s all right if they just present the stuff and concentrate on professional needs. Obviously it’s not their job to pamper people around.

There will be tons of websites popping up, providing tutorials of various quality related to Vulkan. There’s no control over what those sites will present though. I guess some of them will take your approach and turn people away, either intentionally or not.

Placing beginners and professionals too far apart from each other may in fact cause clueless. If you’ve ever searched anything around about Excel VBA or Unity3D ‘beginner stuff’, you’d be surprised how bad answers you find there.

You’re worried that there will be a new generation of clueless Vulkan developers? Why to prevent this “clueless bunch” from forming up? How does dropping beginner documentation will prevent the formation?

15

If explained clearly I find Vulkan’s system simpler than the current OpenGL model. I don’t really see why a beginner would have an issue following such steps compared to the old ways. Once they learn that they need synchronization and where and when they’re basically fine. The WSI steps, and probably the render passes and framebuffer, are something you do once for a project anyway. Actually most of the memory stuff will have very standard methods to do things also. The key to most of this is proper documentation and examples that clearly states what’s required with no ambiguity.

Say the community tells a user to check out OpenGL 4.5 before Vulkan. They’ll see the complexity and numerous old tutorials for previous versions of OpenGL and GLSL version differences and get frustrated. (Writing a modern OpenGL application is not as straightforward as some would believe). They’d see the new Vulkan API and find clear examples and techniques and make the switch anyway. I think it’s possible that your experience with OpenGL through the years is clouding how complex the API is for a beginner who isn’t viewing it with the same filters. To you Vulkan looks more complex because it changes the way things are done from OpenGL. To a beginner Vulkan is the way things are done. There’s no previous method. You set up a buffer one way. You set up the pipeline and descriptor sets. They’re clear. They aren’t worrying “how do I convert my VAO to Vulkan” or anything like that. Their fresh slate tied with tutorials give them a much simpler view of the GPU.

[QUOTE=cheery;31120]
We know that all sort of people will charge towards Vulkan, including beginners. Attracted about performance, novelty and closeness to hardware. You propose Khronos should advertise that Vulkan is not appropriate for beginners and direct them to learn OpenGL, or something else instead.

It’s setting really negative tone. Equivalent to slapping with a wet towel. Whoever reads it doesn’t respond by doing as proposed. It’s the worst and most stupid thing Khronos could do.

If someone wants to learn Vulkan, you should provide learning material to that and market it as such. Different approaches may do just as well, and may use OpenGL as a stepping stone. Ultimately the material should get the person started with Vulkan.

But please do not say that something isn’t appropriate for someone, or “not for everyone”. Although it may be true, it’s a wrong thing to say when someone approaches willing to learn. It pisses me that I hear that from someone who boosts himself as person writing learning material.

In any case protocols need documentation and you cannot just sidestep or avoid doing proper specifications. Nobodys time is saved by saving time in writing documentation.[/QUOTE]
Very well said. It’s my hope the documentation will be written from a fresh slate so that a beginner can follow it with no issues. The same goes for the wiki. I fear someone will mess it up though and try to obfuscate things with comparisons to OpenGL when there should be a clear cut between the APIs.

16

Since it was in another thread, I think it is important to note something. This discussion was originally spawned from someone wanting Khronos to devote time into developing an official, cross-platform equivalent to GLFW, complete with input processing and so forth.

So clearly, some people do think it’s their job to “pamper people around.”

Because I don’t believe that it’s feasible. Or helpful.

First, I think we need to answer the question, “what kind of ‘beginner documentation’?” There are basically three kinds of things that people call “documentation”, yet they’re all very different:

  • Reference documentation. These are basically man pages. Reference documentation is only really useful for people who already know something. This is great if you already know what to look for, or need to see what the valid parameters to a function are.

But if you’re trying to understand concepts, it is terrible. That’s why newbies usually don’t read reference docs. Without a solid beginning and good presentation of information, they can’t figure out where to really start or get going.

Learning from reference documentation is not very effective. Sure, some people can do it, and if the concepts behind a system are simple enough, the person can pick them up. But there’s a reason that intro programming books are not just a series of API calls and syntax.

  • Topic Based Documentation (TBD). Here, you don’t document the APIs or objects or the like. Not specifically, at any rate. Documentation is per-topic. You document the concepts around a system.

This is better to learn from than reference documentation. But it has some of the same problems. In order to avoid repetition, if multiple concepts interact, you often have to read multiple pages to fully understand things. From an OpenGL perspective, it’s all well and good to talk about Textures as a topic. But to use a texture also requires dealing with the concepts of Shaders, GLSL sampler types, and [Sampler Objects](Sampler - OpenGL Wiki Object).

While this organization of information is much more searchable, it still retains the difficulty of not really having a starting point. Since all concepts tend to interact in (from a beginner perspective) arbitrary ways, it’s hard to find a good jumping-on point for learning.

  • Serial Documentation, from sets of tutorials to full-on books. This is full-on hand-holding. You’re taking a user step-by-step through learning in depth about something. These have the advantage of being able to effectively order information, presenting each new concept with an example of its use, as well as reinforcing older concepts by seeing them reused. Furthermore, the simpler concepts can be presented first, with new concepts building on the foundations of older ones.

Searching in such documentation is pretty difficult. And such documentation is not necessarily meant to be comprehensive (and I’ve always felt that’s a detriment. One of the Superbible’s flaws is that it tries to present all of OpenGL eventually). But as a tool for teaching a beginner who is willing to learn, it can work well.

And this is where we steer things back into Vulkan for beginners. Obviously, some form of Serial Documentation would be in order.

Now look at that last link. See the Introduction section? It contains precisely zero code. It exists for the purpose of getting the reader into the headspace necessary to consume core OpenGL. The first tutorial is nothing more than a detailed listing of what was explained in the intro, with regard to the rendering pipeline. Shaders were initially defined quite abstractly; here, you see how to write and build them. And so forth.

That stuff is there because swallowing core OpenGL is hard. For someone who knows virtually nothing about graphics, it is difficult. Core OpenGL requires eating a lot of concepts, all up front and all at once. Oh, you could try to lie and hide stuff. The Superbible turns to its “gltools” library to obfuscate and simplify core OpenGL. But of course, that only leads to people learning “gltools,” not OpenGL.

The more concepts you need to show the person at once, the harder it is to digest that.

In the introduction, there is also a section on vector math. The reason being obvious: vector math is very important in graphics, so an understanding of it is crucial to understanding graphics. Vectors are a concept you need to do graphics.

In order to write a Vulkanization of that tutorial, one would have to add a really big introduction section. This would basically be all about threading, synchronization, data visibility, data races, cache behavior, and such things.

Because without that foundation, you will have no idea why it is that the first tutorial will tell you to stick a memory barrier after your memory upload operation. Oh sure, you could learn it by the “just do it” method. But I don’t see that as learning; that’s cargo cult programming: do it because that guy said to. It doesn’t promote understanding. And it will lead to dangerous behavior later on, when you start doing it needlessly, or you forget to do it and something doesn’t work for reasons you can’t understand or diagnose.

So now, before you can even start showing code to the beginner, you have to present them with 3 full chapters worth of material. A crash course on vector math, rendering pipelines, API structure, and then a massive chapter on threading in all its agony.

How many beginners would keep reading after that? Not a whole lot. They’ll either skip ahead or go somewhere else.

Also, consider this. Threading and all of its issues are very useful concepts, and ones that beginners would not be expected to know. However, they are not graphical concepts; they’re computational concepts. You don’t need them to understand how graphics works, to understand how rendering techniques work.

You only need them to efficiently tell a particular rendering architecture how to render with it.

So if the goal of your teaching material is to learn graphics, to learn graphical techniques (transformations, lighting equations, textures as lookup tables, HDR, deferred rendering, etc), Vulkan is not helpful. Vulkan’s additional concepts are a hindrance to that goal; they’re needless noise, arbitrary hoops you have to jump through to make your code work.

If your goal is to teach a beginning graphics programmer how to use the Vulkan API, what exactly are you teaching them? What good is it for them to learn, for example, that you can render to a floating-point texture if they have absolutely no idea why they should? Without a firm foundation in lighting and HDR, let alone colorspace issues, the beginner is simply learning a seemingly meaningless fact: I can render to floating-point textures in Vulkan like this.

And thus, even if you manage to teach them how to use Vulkan, they still don’t really know why they should. Without the understanding of graphics, they’re just throwing textured triangles or whatever on the screen.

So what are you trying to teach people: how to use an API, or how to do graphics? And which is more important: the ephemeral knowledge of the minutiae of how an API works, or the foundational knowledge that will be useful for any rendering system?

If you’re picking an API to teach someone something in, then you pick the API that doesn’t hinder the learning process.

And Vulkan hinders the process of learning graphics and graphical techniques for beginners.

17

And then promptly fails their “save vs. threading” roll and runs into subtle problems with synchronization that they have no idea how to detect, diagnose, or cope with.

Multi-processing and synchronization is one of the most complicated things that programmers have to deal with in modern programming. And you expect me to believe that beginners will just pick it up because they read somewhere in the docs, “when you use a piece of memory in a rendering command, make a note of it. Don’t delete or modify that memory until any commands that might try to use it have finished.”

Does that genuinely sound like something beginners can handle? Consistently?

That’s a great strawman, one that I’m sure plays right into your opinion of me and anyone who dares to claim that Vulkan is more complex than OpenGL. Of course, like any strawman, it has no actual bearing on the argument at hand.

I never said anything about how you “convert my VAO to Vulkan” or converting from any OpenGL API calls to any Vulkan API calls. My argument focused on concepts that the APIs have, regardless of the specific way they are accessed.

And Vulkan has a lot more concepts on display than OpenGL. That’s pretty much indisputable; I even gave a list for the example you quoted, yet you made no attempt to say that some of those aren’t real concepts.

Therefore, you have made up this accusation out of whole cloth. You’re putting words in my mouth and reacting to a position I do not hold. Stop it!

That’s pretty much impossible, since a “beginner” would have to understand threading, synchronization, visibility, and similar notions to “follow it with no issues”.

Um… what wiki? Unless Khronos creates one, I highly doubt there will be a wiki for Vulkan.

18

Hi all,

I cannot see the point in making the discussed distinction between beginner and ‘experienced graphics programmer’ . People are different and come with respective backgrounds. I learned graphics programming when I was a mathematician. I had to delve into assembler to do it right at that time. I buyed some expensive manual for a state of the art graphics card (ET 4000, ~120$) to get the last opcodes, register information, whatever.
On the other hand, all this graphics transformation stuff, vector math etc., were rather basic information to me. And thats only me, there are zillion people coming from completely different angles.

I have been writing software for a living for 20 years now (most of the time C++) and even there all my knowledge comes from some very individual approach. I am a strong proponent of the opinion, that programming is first and foremost a self-taught profession. For this, all you need is information. You are the one responsible to weed it out. But it has to be there. So, let the people decide what is hard and what is easy to them. But give them the means to make some educated decision.

Regarding tools - I don’t think this will happen. Look at the current state of shader debuggers for example. Ok, at least I have Nsight now. But these things will never come from what organisation ever, it doesn’t matter (or rather as a detriment) how big the consortium/supporter list is. There is no standard compiler for C++ and no standard debugger. And the same is true for the Khronos area. Let them do the documentation right, this is enough. The rest will follow. If this standard takes root at all, of course.

BTW: Why do I have to allow facebook.net in order to post here?

19

But you don’t even need to show threading to the beginner, I am 100% certain that you will be able to build a vulkan app with just the single thread like you kinda need to in openGL.

You will still need to discuss memory transfer and barriers but that can be contained to just the asynchronous IO concepts. If they understand that while IO is busy (between the writeAsync call and the checkfinished returns true) changing the contents of the buffer passed in writeAsync will cause undefined results, then they will be able to understand that those are the barriers of the async-API.

Then you will be able to explain that the entire command buffer will be executed asynchronously and the barriers will prevent advancing of the queue until user code calls vkBarrier(barrierObject); to ensure the buffer is fully populated by usercode and that the fence after the DMA will let user code test if the result is done and then use the buffer for something else. (I am making assumptions about what barriers and fences are here)

You can introduce the reentrant behavior of each API call/object in an advanced section at the end of the tutorial.

20

[QUOTE=Alfonse Reinheart;31126]Since it was in another thread, I think it is important to note something. This discussion was originally spawned from someone wanting Khronos to devote time into developing an official, cross-platform equivalent to GLFW, complete with input processing and so forth.

So clearly, some people do think it’s their job to “pamper people around.”[/QUOTE]

Given large population, you can always find at least one person who doesn’t get it right.

I asked two questions:

  • Why to prevent clueless Vulkan developers from forming?
  • How does dropping beginner documentation will prevent clueless developers?

[QUOTE=Alfonse Reinheart;31126]Vulkan hinders the process of learning graphics and graphical techniques for beginners.

If you’re picking an API to teach someone something in, then you pick the API that doesn’t hinder the learning process.[/QUOTE]

I take it this is the reason why you think it induces clueless. OpenGL still introduces plenty enough of concepts to hinder learning process, if it’s just about amount of concepts.

Now you’re spitting at someone who took the same conclusions as you. Equally if you teach someone OpenGL instead of Vulkan then they end up learning OpenGL, not Vulkan. Also you likely see behind the motivation of gltools, someone thought teaching things in OpenGL hindered learning.

I have an excellent book about Vectors and Matrices in my shelf. I haven’t gotten anyone to read it although it’d be invaluable to about anyone standing with two legs. I know why they aren’t reading the book. It’s because they don’t think they need it and won’t find an use for the contents.

Most of them won’t just believe me if I say that it’s crucial to understanding graphics. They need to experience the need themselves.

[QUOTE=Alfonse Reinheart;31126]So now, before you can even start showing code to the beginner, you have to present them with 3 full chapters worth of material. A crash course on vector math, rendering pipelines, API structure, and then a massive chapter on threading in all its agony.

How many beginners would keep reading after that? Not a whole lot. They’ll either skip ahead or go somewhere else.[/QUOTE]

I did read differential geometry too. The need arose when I tried to understand Raph Levien’s Spiro splines. Now I consider it should be mandatory reading for graphics programmers, s/graphics//. I suppose that’s also something you wouldn’t supposedly read without having motivation for it.

[QUOTE=Alfonse Reinheart;31126]Oh sure, you could learn it by the “just do it” method. But I don’t see that as learning; that’s cargo cult programming: do it because that guy said to. It doesn’t promote understanding. And it will lead to dangerous behavior later on, when you start doing it needlessly, or you forget to do it and something doesn’t work for reasons you can’t understand or diagnose.

So if the goal of your teaching material is to learn graphics, to learn graphical techniques (transformations, lighting equations, textures as lookup tables, HDR, deferred rendering, etc), Vulkan is not helpful. Vulkan’s additional concepts are a hindrance to that goal; they’re needless noise, arbitrary hoops you have to jump through to make your code work.[/QUOTE]

I’m sure there’s nothing needless in the Vulkan. They strike for zero overhead. Everything that was useless has been tossed over the shoulder.

I think you just need to understand motivations of people looking up to learn Vulkan. Find them out and provide fast paths to filling those motivations. Also answer all the questions they present. These are the things you need to do. Having or not having Vulkan doesn’t change the problem that the graphics programmers have to understand the concepts eventually.