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

The Khronos Group announced the availability of technical previews of the new Vulkan open standard API for high-efficiency access to graphics and compute on modern GPUs used in a wide variety of devices. This ground-up design, previously referred to as the Next Generation OpenGL Initiative, provides applications direct control over GPU acceleration for maximized performance and predictability, and uses Khronos’ new SPIR-V™ specification for shading language flexibility. Vulkan initial specifications and implementations are expected later this year and any company may participate in Vulkan’s ongoing development by joining Khronos.

Vulkan is a unified specification that minimizes driver overhead and enables multi-threaded GPU command preparation for optimal graphics and compute performance on diverse mobile, desktop, console and embedded platforms. Vulkan also provides the direct GPU control demanded by sophisticated game engines, middleware and applications with the cross vendor performance and functional portability resulting from simpler, more predictable drivers. The layered design of Vulkan enables multiple IHVs to plug into a common, extensible architecture for code validation, debugging and profiling during development without impacting production performance; this layering flexibility is expected to catalyze strong innovation in cross-vendor GPU tools.

All feedback that is posted to this topic thread will be considered by the working group. We greatly appreciate what you have to say and the time you spent preparing your feedback.

I love the name! Live long and prosper ;-)!

When the API specification will be published?

I hope it’s easy to call from dynamic languages. Bonus points if the bindings could be entirely generated for javascript or python.

With OpenTK committing to this, and the Core and ES variants merging, I cannot wait to see it in action. It certainly looks like a step in the right direction, especially in terms of convergence between platforms and cleaning up the mess of OpenGL’s legacy ballast.

My biggest hopes – and worries – concern tighter, cleaner standards, to reduce the dreaded “write once, debug everywhere” effect. If this also helps the performance of programs that spam draw calls, or other costly CPU-GPU synchronization, that is nice, but nowhere near as important to me as putting pressure on sloppy drivers.

A lack of – or low level of – CPU-side wrapper features is no issue, since libraries can easily fill this gap, in specialized ways for various needs. Taking a step back and leaving more logic to the application sounds like a good choice. As does the use of an intermediate language for shaders. Now, driver and language developers can focus on their respective jobs instead of randomly mixing their responsibilities.

This looks like a very good concept. IMO, it now comes down to reliability, portability, and simplicity. If Vulkan can deliver these and still keep its promises, it will be a game changer.

This is fantastic news, keep up the good work!

For a beginning OpenGL user that wants low-level access to gpu hardware, it’s hard to pick between learning OpenGL’s multiple hundreds of functions and using OpenGL now versus waiting for Vulkan. What makes it even harder is not knowing Khrono’s next step after GDC, will they next speak of Vulkan in a few months time? Or will I get to look at a ‘beta’ specification soon? At least we know that a first spec is expected later this year. It would be great to have more detail than that, even if such details are somewhat uncertain for Khronos. I hope we hear more at GDC.

I just read through the SPIR-V specification. It was clearly written and easy to understand. Encoding is simple:

  • The whole file consists of 32-bit little-endian words, starting with a small fixed size header, then comes instructions.
  • The first word in an instruction describes its length.
  • Instructions seemed easy to decode/encode piecewise. The encodings can be likely populated into a lookup table from an XML or json file.

[QUOTE=oldornew;31014]This is fantastic news, keep up the good work!

For a beginning OpenGL user that wants low-level access to gpu hardware, it’s hard to pick between learning OpenGL’s multiple hundreds of functions and using OpenGL now versus waiting for Vulkan.
[/QUOTE]

Because it is very low level and leaves management of pretty much everything up to the application, Vulkan is not for beginners. Beginners are probably better off using the AZDO subset of OpenGL described by Cass Everitt et al at GDC last year.

[QUOTE=cheery;31015]I just read through the SPIR-V specification. It was clearly written and easy to understand. Encoding is simple:

  • The whole file consists of 32-bit little-endian words, starting with a small fixed size header, then comes instructions.
    [/QUOTE]
    The SPIR-V specification does not describe a file format. It describes a binary form in memory and that form is a stream of words. Endianness only comes in to play if the stream of words has been stored as a stream of bytes, such as in a file. In that case, the magic number should be used to deduce the endianness to apply to convert the byte stream back to a word stream. Endianness of any such storage is outside the scope of the specification.

I disagree. With Vulcan being very low level it should give me a feeling of the hardware behind it. Learning how to use gpu hardware properly with simpler, fewer functions and leaving the management up to the application is bound to be much simpler than learning the obscene amount of OpenGL functions and state, which make it very hard to actually learn something about the underlying gpu. I’m looking for some kind of intuition and with the gpu hardware as hidden as it is, and the OpenGL api as large as it is, it’s hard to get any. It’s all just a huge mess of function after function, all implicitly bound to eachother.

With Vulkan it’ll probably be easier to gain an intuition on how the gpu works, which in turn should give me an even better intuition on the already dead-simple (i’m assuming) Vulkan api and the higher level apis like OpenGL. Gaining an intuitive understanding of current gpu hardware should be better for a beginner than accumulating months and then years of obscure OpenGL facts that truly mean nothing outside of OpenGL. Of course when you get advanced enough there are features in OpenGL that give you some ‘dangerous’ control over the gpu hardware but I’m arguing that that kind of knowledge should be learned first, because it aids in an intuitive understanding of the gpu hardware which is good for both low-level and high-level work.

All that said, I’m still a beginner so this is just my guess. Maybe it’s not fit for all beginners, but it’s how I’d prefer to learn.

Wow! When will the SDK be released? :slight_smile:
Since XBox supports DX only, what about a Vulkan compatibility?

Thanks for correction. Apparently that’s said in 3.1 and I misunderstood the 2.2.1 about literal numbers.

Remember hearing OpenGL was never for beginners either. You already needed to know quite a lot to just get WebGL render anything else than a blank screen.

It’s new and shiny so it’s attractive for beginners. It may be a good strategy to just provide learning resources to them, even if something else was simpler and sufficient for learning the things at first.

If you’re going to learn Vulkan, it may be good idea to start by learning some maths if you haven’t already. After learning the basics of the API, you’ll quickly face algebra with trigonometry, vectors and matrices.

I would already love to try it out. I hope they’ll be quick with the driver support.

It seems that Vulkan will fit with EGL, since it’s an already available open solution for the platform bridge. But, how will it do so?

The three APIs that have been, until now, accessible from EGL (OpenGL, OpenGL ES and OpenVG), work with per-thread contexts that are managed with eglMakeCurrent, which, as per the linked reference page, “binds a context to the current rendering thread and to draw and read surfaces”. This is not sufficient for Vulkan – at least, if I understood it correctly, there isn’t that “implicit context” in Vulkan.

Perhaps, the following scheme could be adopted:
[ol]
[li]A new EGL method that binds a draw and a read surface to a context (an EGLContext) is added.[/li][li]The relevant Vulkan methods take a context (an EGLContext pointer) as one of their arguments.[/li][/ol]
The first step would be necessary to avoid having to pass many arguments to each Vulkan function (the context and the draw and read surfaces; two or three, in the case that it needed both a draw and a read surface). This model would keep most EGL code valid, while allowing to easily switch contexts and work in parallel. There are some caveats, however; for instance, I do not know how eglBindAPI could be worked-around (it would have to be fixed, I think).

Could anyone please confirm or tell what has been currently proposed in this area? Will there additionally be a new EGL version?

[QUOTE=Sabino;31019]Wow! When will the SDK be released? :slight_smile:
Since XBox supports DX only, what about a Vulkan compatibility?[/QUOTE]

It would be really nice to see GL or Vulkan on XBOX so we won’t have that much overhead in porting applications between platforms.

But i’d be really surprised if microsoft will ever add something that’s not called DirectX :frowning:

Second this. In implementation terms, context initialization has always been an obscure topic for me. It will be interesting to see how Vulkan manages the notion of a context (in case of course such concept still exists in Vulkan land).

Suppose that I’d like to create my own set of Vulkan bindings for Java. What if I wanted to let a Java SWT application talk to a Vulkan device? What steps would be required to create the bridge between my JVM, the OS, and the Vulkan device?

So to reiterate, it would be very interesting to know what are the plans to make Vulkan talk to surrounding display management technologies (e.g. Qt, X11, Java Swing/SWT/JavaFX, GTK, Quartz, etc.).

Awesome stuff. Thanks!

Given how important web-based graphics has become, having WebVulkan (for want of a better term) built in from Day #1 rather than wedged in as an afterthought like WebGL/WebCL seems important and isn’t mentioned anywhere I can see here.

Things that made WebGL incredibly difficult (like defending against denial-of-service attacks using insanely slow shader code and handling external content issues) really need to be built into the core because they are hard-to-impossible to retrofit.

Aside from that…good work! We’ve needed this for the longest time - application & web developers don’t want fragmentation into walled-gardens like DX12 and Apple’s Metal - so let’s push on this one!

Many thanks guys.

– Steve

Thank you for your interest Kalrish. Welcome any further thoughts you have on how we shape this. Overall, we’re bringing the relevant functionality that EGL provides for OpenGL and OpenGL ES within the Vulkan API. This includes a redesign of how presentation to window systems is achieved to meet the needs of current OSes, exposing more explicit swap chain control on platforms that can support it.

Correct. Construction of command buffers across multiple CPU threads is key to the design of Vulkan, and moving away from notion of requiring binding to a particular thread.

With regards to idea of bundling state and surface/image used, this is something that is avoided in order to allow association of memory references with command buffers to occur at submission time. There are multiple benefits to this, including late binding of what target to output to.

There’ll be more details revealed at tomorrow’s GDC sessions, but the direction we’re going is analogous to this, with calls explicitly stating the Vulkan device or queue they are targeting – no implicit ‘current’ device/queue.

Does anyone know if a C++ Shading/Compute Language is in works? Would love to experiment some of my ideas on Android. Graphics and compute indeed belong together. Something renderscript failed at.

This Vulkan API sounds exciting. But for some reason echoes of the past are ringing in my ears… All that boiler plate code to do graphics from scratch…

In all seriousness though, I can’t wait to see the API and the quick reference. I hope it works in the browser.

mov ax, 13h ; mode 13h!
int 10h
mov ax, x
mov bx, y
mov dl, color
call putpixel

putpixel:
mov cx, 0A000h ; 0xA000 segment for graphics
mov es, cx
mov cx, 320 ; ax is the X coordinate
mul cx;
add ax, bx;
mov di, ax
mov [es:di], dl

How long will it be before the slides from the GDC presentation are made available?

Given how important web-based graphics has become, having WebVulkan (for want of a better term) built in from Day #1 rather than wedged in as an afterthought like WebGL/WebCL seems important and isn’t mentioned anywhere I can see here.

Considering how low level Vulkan is supposed to be, I don’t think it is entirely appropriate for it to be exposed to JavaScript. It’s just too low-level for something that isn’t running native on the computer. OpenGL at least keeps its memory management hidden; Vulkan is apparently not supposed to do so.

I have been waited the GLNext, now Vulkan for a long time.
It is exciting!
One thing I really hope for Vulkan is to support Direct Texture Streaming (glTexDirectVIVMap for Vivante, and bc-cat for TI OMAP3 …) or equivalent features by default.
Sharing the memory between the CPU and GPU is very important feature in embedded systems, which can be shared because they are using same physical memory.