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:
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:
So GDC could be fun.
You can find the new NVIDIA Vulkan driver here. Article taken from GamingOnLinux.com.
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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
9 comments
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
Last edited by gehneo on 27 February 2017 at 1:01 pm UTC
1 Likes, Who?
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!
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!
0 Likes
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
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
0 Likes
kellerkindt Feb 27, 2017
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.
0 Likes
Quoting: kellerkindtQuoting: 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".
0 Likes
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.
1 Likes, Who?
Maybe Alm88 missed the "_fd" versions for non-Windows operating systems.
0 Likes
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.
1 Likes, Who?
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.
2 Likes, Who?
Patreon
PayPal
See more from me