Support me on Patreon to keep GamingOnLinux (and me) alive. Funding me on Patreon allows us to have no adverts, no paywalls, no timed articles. Just good content for you to keep up with Linux gaming. Alternatively, you can support me on Paypal.

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

Posted by , 27 February 2017 at 12:40 pm UTC / 6911 views
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.
10 Likes, Who?
gehneo 27 February 2017 at 1:01 pm UTC
I'm already updating my AUR packages for the new drivers for Arch Linux devs. I'm submitting them after testing with SteamVR


Last edited by gehneo at 27 February 2017 at 1:01 pm UTC
Alm888 27 February 2017 at 1:13 pm UTC
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 February 2017 at 1:33 pm UTC
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 February 2017 at 1:33 pm UTC
View PC info
  • Supporter
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 February 2017 at 1:44 pm UTC
kellerkindt
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 February 2017 at 1:45 pm UTC
View PC info
  • Supporter
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 February 2017 at 1:50 pm UTC
View PC info
  • Supporter
Maybe Alm88 missed the "_fd" versions for non-Windows operating systems.
Alm888 27 February 2017 at 2:14 pm UTC
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 February 2017 at 2:20 pm UTC
View PC info
  • Supporter
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.
Corralx 27 February 2017 at 7:51 pm UTC
Alm888
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.

I'll quote from my reddit answer so it's easier:

"Because the point of these extensions is cross the boundaries of the API itself and do inter-process communication, so this necessarily needs some ad-hoc, per-platform work. Vulkan already did that with the swapchain extension (which is fundamental if you want to show an image on screen) which is per-platform. It's necessary to give the developer all the options and flexibility it needs."

If you need to communicate with the outside world, some specific per platform work is required, and in Vulkan this is explicit too.
Even if the memory and semaphore extensions were multiplatform, you would still need to wrap the code that communicate with the outside world in platform specific code, while losing control and flexibility.

See the Win32/XCB/Xlib/Wayland variant of the surface extension as an example: https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/html/vkspec.html#VK_KHR_win32_surface


Last edited by Corralx at 27 February 2017 at 7:51 pm UTC
While you're here, please consider supporting GamingOnLinux on Patreon. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. We also accept Paypal donations! If you already are, thank you!

Due to spam you need to Register and Login to comment.


Or login with...

Livestreams & Videos
Popular this week
View by Category
Contact
Latest Forum Posts
Facebook