Official Vulkan Feedback: API for High-efficiency Graphics and Compute on GPUs

The name “Vulkan” does not sound professional at all. I was expecting something like DirectGL, or even stick with OpenGL.

Being a GPU low level API rather than a 3D graphics API, I hope it will not send us back to early versions of DirectX Execute Buffers.

What will happen to existing applications using traditional OpenGL? Is it going to be backward compatible? How easy to port to “Vulkan”? How long before we see any working stable drivers?

One more thing, what about the Window/Context Management part? Is it going to be a separate API or part of the specification? Who provides the SDK?

Question about javascript isn’t really about javascript at all. It’s about security. Can an untrusted process on a website be allowed to access Vulkan or OpenCL to display graphics or compute? The answer should be ‘yes’ because it’s good for users. Also desktop isn’t really getting to be different. There are examples of how users can’t even trust the pre-installed software provided by hardware vendors.

Javascript is the GLSL of the web. It’ll be eventually phased out in favor of something generic and better.

I’m pretty sure Microsoft would not be happy with one of those. And while I can’t say I like the name, I did like the name better when it was explained that “Vulkan” is apparently German for “volcano”. As in what happens when “Mantle” erupts :wink:

Well, your hopes are not well-founded, since execute buffers (of some form) are exactly what we’re getting. Just like D3D12 and Apple Metal. Obviously, it’s not going to be exactly D3D 3.0, but the general idea of queuing up a back of work and then submitting it is similar.

Best to get used to it if you intend to do low-level graphics.

I don’t know how you could have missed this, since it’s been stated pretty much everywhere. Vulkan has no relationship to OpenGL whatsoever (besides the fact that they’re both graphics APIs). They are as compatible with each other as OpenGL is to Apple Metal or D3D12.

However, OpenGL development is not going to shut down. That’s why Vulkan is not called OpenGL 5. They still fully intend to release new OpenGL specifications to keep feature parity with Vulkan. Though obviously not performance parity.

BTW, you should watch the post-GDC video presentation or read the Vulkan slides from that presentation.

It depends on your rendering code. But since Vulkan is rather lower-level than OpenGL (particularly with regard to memory), you’ll have to do some work.

Probably not before we see a stable spec. So “later this year”.

All of these questions are answered in the above information.

The question I was answering asked about “WebGL”, which uses JavaScript.

I don’t agree that “yes” is good for users. At least not where Vulkan is concerned.

Vulkan, to me, is too low-level for any code that you consider “untrusted” to start poking at. OpenGL, OpenGL ES, and WebGL will continue to exist alongside Vulkan. So I would much rather that “untrusted” sources use one of them. I think of Vulkan applications as being user-space drivers, and thus they should be trusted about as much.

Granted, I expect that Vulkan will have reasonable robustness support (like not reaching other people’s GPU memory). But protection from GPU resets and the like? I would think that this would get in the way of the performance Vulkan is aiming for.

Sure it is. If I run a graphics application that gets as low-level as Vulkan/D3D12/etc, I expect that such a program could have a negative effect on my GPU.

A website should never be able to reset my GPU. So it needs an API that is specifically designed to forcibly prevent such things. Website-based code should never get as low-level as Vulkan.

I’ll believe JavaScript will be “phased out” when Linus Torvalds “phases out” C in the Linux kernel.

Hi,

I have not seen the video of the presentation (I will very soon), then I apologize now if I talk about components outside the scope of vulkan (suspicions are high on the display management API).

I have 2 main concerns:

  • The vram upload/download/allocation part of the API. Hope vulkan off-load the code paths of vram upload-download to the layer above, usually the 3D engine. Basically, the layer above will need 2 code paths: the one for discret GPUs and the one for integrated GPUs. All that to let the “layer above” (usually the 3D engine) have good timings and a vram budget adapted to its needs in order to get the max performance and best timings and not let a “automated vram manager/garbage collector” ruin it all. When you look at the mess which is the TTM (linux DRM) bug-wise and performance-wise, “automatic” vram management for a low level API is a very bad idea. Worst case scenario: “a layer above” will provide the (v)ram abstraction. That API should be a-synchronous with sorts of call-backs.

  • The displays API. The display management API of the linux DRM is just a joke. They are trying to fix it with an atomic version of it. Hope vulkan did exactly not like the drm.

All I hope is that vulkan did not make the same mistakes.

The presentation does state that Vulkan recognizes that devices (ie: GPUs) can have different pools of memory. And these pools can have different (and queryable) characteristics. So you can tell the difference between integrated and discrete cards.

But it didn’t go into any details on exactly how you go about transferring data to/from GPU memory that you allocate. There was a mention of a “DMA” queue (as separate from a “graphics” and “compute” queue), so it’s possible to for a GPU to allow you to issue DMAs via a channel that’s separate from your graphics and compute stuff. Then again, it’s possible for a GPU to not let you do that either (since a particular queue can allow multiple different kinds of commands).

The presentation was not entirely clear on this either, but they did explain the general idea. There will be a Windows System Interface (WSI) component that can provide an Image that represents something visible. You can stick that in a framebuffer and render/blit to it.

The WSI handles things like vsync, fullscreen, and enumerating device displays (ie: monitors) and their capabilities. It also has different codepaths for compositing desktops vs. other kinds. Apparently. I didn’t really understand that part…

WSI components are platform-specific, though it wasn’t clear if they were platform-specific the way WGL and GLX are (ie: completely different APIs), or if the platform-specific implementations are hidden behind a generic, platform-neutral interface.

Well it’s very ambitious transition…good luck to Khronos, and good luck seeing working drivers from major vendors. :smiley:

Generally, I am quite enthousiast about Vulkan, and I really hope to see wide adoption quickly across all major platforms (although I guess we won’t see any Vulkan on iOS or in Windows/Windows Phone app store applications, and of course Xbox One). But I do not like the name. The name seems totally arbitrary. I understand why they would not want to stick with OpenGL, because it is so drastically different, but Vulkan? What is that? Anyway, what’s done is done, we’ll have to live with it (and a lot of people seem to like the name).

Another anoyance to me is, in the API, all structure type names are in full CAPITALS. It kind of feels loud. Is that some D3D-ism creeping in :slight_smile: ? Why not name them, say, like VKThisIsAStructType ? Or whatever, but VK_THIS_IS_A_STRUCT_TYPE (which is the same as constants)? Arguably, the latter is more readable in the sense that “words” are spaced out with an underscore, but if that was the intention, then why keep a camel-back style for function names and not go also for understores?

Finally, in what I have read so far, I saw nothing about how we will be able to update content of resources, most notably buffers and textures. If there is one thing I absolutely like about iOS Metal is that you can access the pointer to a buffer’s storage any time and do as you please with it. Do we have that pointer in VK_GPU_MEMORY? Granted this might not fit in an API covering a wider type of devices, but hopefully we can something better than map/unmap, or else at least have map/unmap with persistence (e.g. from GL_ARB_buffer_storage). Direct access to raw texture storage would be nice as well, but I can understand if, without extensions, we won’t have that.

Kudos: being able to pass in our allocator to the API is very cool!

Actually, I’m much more concerned by the fact that there are structs at all, rather than opaque pointers. Say what you will about OpenGL’s object model (and I could), it is well-designed for extensibility. If an extension wants to add a field to an object, it just adds a new enum and possibly a new function to set that field. The existing Get function will be able to get the data field by using the enum, and everyone is happy.

With structs, it’s very difficult for them to be extended. Vulkan does take the size of the struct, so it’s possible for extensions to require the use of a larger struct with more fields or whatever. But the problem is that two different extensions that add fields to the same struct can’t coexist in the same implementation.

Not to mention that struct layouts are based purely on C’s ABI, which don’t translate well to other languages. Granted, I don’t see a good reason to expose Vulkan to most languages that can’t deal directly with C’s ABI, but it would have been nice to retain that.

Its not arbitrary at all. The new API is based on Mantle, and Vulkan (volcano) is a clear reference to that. It also might be a subtle homage to Leonard Nimoy, but I am not sure about that last bit. If so, then the name was a last-moment decision. As to why they used Vulkan and not Volcano or Vulcan or something like that, I think the first reason has to do with legal issues and the other one with the wish to have a concise, strong sounding name.

I would hope that the descriptor structs are key-value pairs as used by WGL_ARB_pixel_format etc. This is a quite flexible format and can be processed rather quickly in the driver.

the trademark request was filed before Mr. Nimoy died. So coincidental.

It’s possible that they’re doing it that way, and it would be quite extensible. However, I don’t think the API works that way. Consider this code:

VK_GRAPHICS_PIPELINE_CREATE_INFO info = { ... }; 
VK_PIPELINE pipeline; 
 
vkCreateGraphicsPipeline(device, &info, &pipeline);

If [var]info[/var] is an array (and therefore presumably [var]VK_GRAPHICS_PIPELINE_CREATE_INFO[/var] is a macro for [var]uint32_t[/var]), then [var]vkCreateGraphicsPipeline[/var] has a major flaw. Namely, it’s incredibly vulnerable to buffer overrun attacks.

If they’re going to go this way, then the functions really need to take an explicit size.

I’m very excited about the simplicity of SPIR-V and I really hope to see different compilers that compile different languages into SPIR-V; imagine compilers that compile code from C, Javascript, and even HLSL into SPIR-V. It will make Vulkan really flexible in terms of programming and code portability. Also, I’m really curious about the debugging tools that will be available for Vulkan. Right now, debugging OpenGL with glGetError is not really helpful; I’d certainly love to see something like Direct3D’s Debug Layer implemented into Vulkan. That would be really amazing, specially for noobs and hobbyist (or noob hobbyists, like myself).

I’m excited that you’ll be able to debug your shaders by stepping through them as opposed to the current trial and error method with limited logging.

I do hope that Vulkan doesn’t do the stupid Windows variable length structures a la:


struct some_struct {
   int size; /* sizeof this struct */
   float some_field1;
   float some_field2;
   float some_field3;
   float some_field4;
};

struct my_struct {
  some_struct initial_data;
   /* Extra crap goes here */
};

my_struct data = {
  .size = sizeof (my_Struct),
   /* etc. */
};

N.B: My C is not up to date, so there are likely errors, but you should see my point.

In other words a struct where you have to embed into a new struct where you add extra fields. This is a really stupid way of doing things and makes defining bindings to other languages an absolute nightmare and all because you lot can’t be bothered to define a sane API. Please do not do this.

Luke.

Why would it be? Its not returning any data, only reading it.

But on the second glance, I agree with you that the API examples don’t look like key-value lists but rather as plain C structs. Here, I fully agree with yours and Lucretia’s reservations about extensibility. I would strongly prefer Longs Peak style of initialising such structures. Sure, it is more overhead than just setting/reading a struct, but I doubt that the few extra indirect dispatches will make any difference.

A question about the relationship between memory, buffers, and textures in Vulkan.

The slides state that memory allocation is something that happens outside of textures and buffers. You then assign specific memory to a buffer/texture.

This seems to suggest that multiple buffers/textures can be assigned to the same memory. Even more, it suggests that you could do memory casting by assigning two textures to the same memory, so long as the two formats and texture sizes result in the same size of data.

So if I had an application that needed lots of textures of a certain size, even if those textures have different image formats, it would be possible for me to “cast” one memory allocation into another format (and overwrite it with data appropriate to the new format). So memory that was used for an RGBA8 image could be repurposed for an RGBA8UI image.

Even more, would it be possible to allocate a large arena of memory up-front, and then dole bits of it out to different textures/buffers as needed, so I don’t have to go through reallocation at runtime? I didn’t see anything in the functions that bind memory objects to buffers/textures that took a size+byte offset, but that could have been in the “_INFO” object somewhere.

There was a function to compute the size of an allocation for a particular texture, presumably taking into account its format, size, etc. How necessary is that? Is there some guarantee such that I can know, off-line, exactly how many bytes will be needed for a texture of a given size/format, regardless of hardware?

>Vulkan initial specifications and implementations are expected later this year and any company may participate in Vulkan’s ongoing development by joining Khronos.

So… is there a way a student can get this API? (Me) :wink:

There is a way! By waiting for the spec!

The DMA queue sounds very useful for streaming map purposes.