Khronos' Vulkan Webinar Video Now Online

[phoronix]

Phoronix: Khronos' Vulkan Webinar Video Now Online

For those still craving to learn more about Vulkan 1.0 with this week's exciting launch and our lengthy overview of it, The Khronos Group's Vulkan webinar from yesterday is now available for viewing...

http://www.phoronix.com/scan.php?page=news_item&px=Watch-The-Vulkan-Webinar

[emblemparade]

The biggest 4 take-aways for me:

1) After AMD donated Mantle to Khronos, Khronos made it much better and cross-platform, and AMD is very happy with the result. Khronos is very happy with AMD's donation, because there is no way there would be where they are right now without Mantle as a starting point.

2) The Vulkan conformance test suite is developed in an open-source model. This is extremely important: in the OpenGL world, we know of several cases where drivers differed in behavior across different vendors, even though they passed the tests. This was a major pain point for developers. Now, if someone sees that the tests aren't good enough, they can submit a fix to ensure that the difference is caught. But, as someone asked in the Q&A, this does complicate the notion of what "conformance" means. We'd probably have to qualify driver conformance with a specific date in which it passed the conformance suite.

3) I didn't realize how lean Vulkan is: even the validation and debug layers are things you plug in later via an SDK. The drivers as used by average users are extremely thin, and have unprecedentedly minimal overhead. (Of course, drivers also don't have to include a compiler for shaders, and none of that antique direct drawing model nonsense.)

4) WebGL is here to stay, and it doesn't make much sense to create a "Vulkan-like" API for web browsers. Even now, WebGL is actually backed by DirectX on most browsers on Windows, so in the future it can definitely be that WebGL will be backed by Vulkan. But nobody sees an advantage in making the API more Vulkan-like for now.

[shmerl]

@emblemparade:

1) that was pretty known from the start. Without Mantle, Vulkan never could have gotten where it is right now. What people realize less is that the same thing can be said about DX12 and Metal. They all used Mantle as a source really. Which is simply annoying since they could work with Vulkan instead, but that's MS and Apple, what else could we expect from them.

4) That was a strange part. The only reason given for possibly not making WebVulkan is that Apple doesn't support Vulkan. Shame on Apple again.

[uid313]

Is Vulkan available as a binding for Rust, Python, Ruby, Go, C#, Lua, JavaScript, Julia or anything?

[justmy2cents]

@emblemparade:

1) that was pretty known from the start. Without Mantle, Vulkan never could have gotten where it is right now. What people realize less is that the same thing can be said about DX12 and Metal. They all used Mantle as a source really. Which is simply annoying since they could work with Vulkan instead, but that's MS and Apple, what else could we expect from them.

4) That was a strange part. The only reason given for possibly not making WebVulkan is that Apple doesn't support Vulkan. Shame on Apple again.

4. WebVulkan really does not make sense since with web you want to stream as little commands that do as much as possible and Vulkan is complete opposite. remember that with web your bottleneck will not be cpu, memory or threading. it will be network transfer and latency. what would work is writing high level API like that takes advantage of Vulkan and then use it for web iteration

[blackout23]

Is Vulkan available as a binding for Rust, Python, Ruby, Go, C#, Lua, JavaScript, Julia or anything?

I only came across Haskell bindings:

https://hackage.haskell.org/package/Vulkan

[liamdawe]

Minor thing: It's not 2 hours, it's 1hr 21 minutes