Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone with no article paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

Vulkan API 1.0.42 released, new NVIDIA beta drivers released to go with it

By - | Views: 11,118
Vulkan 1.0.42 seems like a much bigger release than usual, NVIDIA have also release their 375.27.12 beta Vulkan driver to fit in the new extensions from this Vulkan release.

I can't find the actual Vulkan 1.0.42 changelog to list all the new extensions, but NVIDIA do actually have a changelog on their newest driver which is a good indicator of what's new.
Update: Seems the actual Vulkan API changelog is buried at the bottom of this file.

The new NVIDIA driver now supports these extensions:
QuoteBeta support for the following new extensions:

Descriptor Set Extensions
VK_KHR_push_descriptor, VK_KHR_descriptor_update_template

Cross process interop extensions:
VK_KHX_external_memory, VK_KHX_external_memory_capabilities, VK_KHX_external_memory_fd, VK_KHX_external_memory_win32, VK_KHX_external_semaphore, VK_KHX_external_semaphore_capabilities, VK_KHX_external_semaphore_fd, VK_KHX_external_semaphore_win32, VK_KHX_win32_keyed_mutex

Multi-GPU extensions:
VK_KHX_device_group, VK_KHX_device_group_creation

Multiview and VR related extensions:
VK_KHX_multiview, VK_NVX_multiview_per_view_attributes (Pascal), VK_NV_viewport_swizzle (Maxwell), VK_NV_viewport_array2 (Maxwell), VK_NV_geometry_shader_passthrough (Maxwell), VK_NV_clip_space_w_scaling (Pascal)

Other extensions:
VK_NV_sample_mask_override_coverage (Maxwell), VK_EXT_discard_rectangles

Also bug fixes to improve compatibility with shaders generated from HLSL


This is likely what the Mesa developers had been waiting on, which is why initially SteamVR had their own 'radv' driver for people to use on their github page.

We know Khronos will be at GDC, so it's likely some of the Vulkan talks will mention these new extensions for VR use. The Vulkan API changelog does specifically say this:
Quotevendor Vulkan extensions for release at GDC

So GDC could be fun.

You can find the new NVIDIA Vulkan driver here. Article taken from GamingOnLinux.com.
Tags: NVIDIA, Vulkan
10 Likes , Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
9 comments

gehneo 27 Feb, 2017
I'm already updating my AUR packages for the new drivers for Arch Linux devs. I'm submitting them after testing with SteamVR :D


Last edited by gehneo on 27 February 2017 at 1:01 pm UTC
Alm888 27 Feb, 2017
VK_KHX_external_memory_win32

VK_KHX_external_semaphore_win32

What?.. And this was somehow standardized by Khronos?! So, now we have OS-specific functions as part of the standard or what? I'm confused, seriously confused!
FireBurn 27 Feb, 2017
VK_KHX_external_memory_win32 is the windows equivalent of VK_KHX_external_memory_fd, it must have been significantly different to warrant a separate extension. Probably goes for semaphore's, windows will be the only non-posix OS Vulkan runs on.

I believe David Airlied has already implemented a few of these extensions (which were put in the Valve binary radv driver) which should be upstreamed now the spec has been published
kellerkindt 27 Feb, 2017
View PC info
  • Supporter Plus
Quoting: Alm888VK_KHX_external_memory_win32

VK_KHX_external_semaphore_win32

What?.. And this was somehow standardized by Khronos?! So, now we have OS-specific functions as part of the standard or what? I'm confused, seriously confused!

The extension - and therefore the optional support including bahvaior definitions - has been standardized. Before using those, one needs to check whether the extension is supported since its not core Vulkan.
Alm888 27 Feb, 2017
Quoting: kellerkindt
Quoting: Alm888VK_KHX_external_memory_win32

VK_KHX_external_semaphore_win32

What?.. And this was somehow standardized by Khronos?! So, now we have OS-specific functions as part of the standard or what? I'm confused, seriously confused!

The extension - and therefore the optional support including bahvaior definitions - has been standardized. Before using those, one needs to check whether the extension is supported since its not core Vulkan.

???

Then why do I see "VK_KHX_external_memory_win32" here? Does it not stand for Khronos? In case of OpenGL additional extensions were labeled "GL_EXT_someting", not "GL_ARB_someting".
tuubi 27 Feb, 2017
View PC info
  • Supporter Plus
Quoting: Alm888What?.. And this was somehow standardized by Khronos?! So, now we have OS-specific functions as part of the standard or what? I'm confused, seriously confused!
The platforms are different, and Vulkan is an explicit API. Khronos provides API extensions for developers to handle these differences instead of abstracting them away. Makes sense to me.
Ehvis 27 Feb, 2017
View PC info
  • Supporter Plus
Maybe Alm88 missed the "_fd" versions for non-Windows operating systems.
Alm888 27 Feb, 2017
Quoting: EhvisMaybe Alm88 missed the "_fd" versions for non-Windows operating systems.

No, I did not miss them. I just imagined the situation of a developer writing a game for Windows and using VK_KHX_external_memory_win32 everywhere in the code. And then, when the time to port on Linux comes (s)he needs to replace all those occurrences with VK_KHX_external_memory_fd counterparts! Or to use #IFDEF / #ELIF directives everywhere. And that's provided that "win32" and "fd" versions are equivalent for the code and not require some vastly different usage.
Ehvis 27 Feb, 2017
View PC info
  • Supporter Plus
Quoting: Alm888Or to use #IFDEF / #ELIF directives everywhere. And that's provided that "win32" and "fd" versions are equivalent for the code and not require some vastly different usage.

That's probably the whole point. They needed to do that anyway because the systems have different approaches to these system functions. Khronos could either put two different approaches in the same extension or separate them. Since a system can only really implement one approach, separating them in different extensions is better way to do it.
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.
Livestreams & Videos
Community Livestreams
Latest Forum Posts