Vulkan 1.3.245 Brings New NVIDIA Vendor Extension To Help Optimize Ray-Tracing

[Daktyl198]

Extension system actually works well in Vulkan as Vulkan extensions initially are propertiary like extensions that gets promoted to standard for all. Vulkan raytracing initially was Nvidia own extension (thanks to that it appeared fast) and based on it other GPU makers submitted feedback and issues that were resolved before it finally became mainstream extention.

Also other GPU makers are free to implement Nvidia's vulkan extentions, there is 0 blocking here.

Also that extension system is half the reason why projects like DXVK can work at all. It is obvious why such extensions that are meant only to be used in translation layers shouldn't be mainstream for everyone, but thanks to that it is extention they can appear pretty fast as optional dependency that GPU makers are mostly willing to adopt.

Meanwhile less known GPU makers especially mobile/embedded ones probably don't care about many extentions DXVK etc uses.

The problem isn't that Extensions aren't useful, it's that simply by having them you make it extremely annoying for developers trying to use your API. To the people saying "The engine will support it, so game devs won't care", that's a view that doesn't look at history. Unity and Unreal have a long history of supporting OpenGL alongside DX12 to allow for making cross-platform games, but the engine devs get sick and tired of working with OpenGL, leading to sub-par implementations. This, in turn, leads to game devs not building their game using OpenGL/Vulkan because the resulting build is buggier, and slower. This doesn't even touch on the Driver issues that come with maintaining so many extensions. AMD's driver update on Windows a few months ago that resulted in 30% better OpenGL performance shows that it's not easy.

Also, as a counterpoint to "anybody can implement a proprietary extesion", as far as I know there's nothing stopping Linux drivers from implementing the DX12 API into their drivers other than hatred for Microsoft. A few years ago, there was already an effort with Gallium Nine to implement DX9 and it worked great, but was platform specific so Wine hated it. There are several tools like DXVK that essentially "implement" the API, from an application's perspective. If AMD and Intel pushed to allow for DX12 APIs into their mainline drivers, then Nvidia would quickly follow given that their userspace driver is pretty much a clone of their Windows driver.

But god forbid anybody developing Linux software do something useful for the end user, rather than grandstanding their philosophies.

[Quackdoc]

The problem isn't that Extensions aren't useful, it's that simply by having them you make it extremely annoying for developers trying to use your API.

not really, it's a lot more frustrating when there is no extension that does what you need, we are far better off with them then without them, and have fun trying to mandate all of the extensions into core profile, that will end *very* well im sure.

To the people saying "The engine will support it, so game devs won't care", that's a view that doesn't look at history. Unity and Unreal have a long history of supporting OpenGL alongside DX12 to allow for making cross-platform games, but the engine devs get sick and tired of working with OpenGL, leading to sub-par implementations.

I dont think it's accurate or fair to equate this to extensions, opengl is just plain bad for tons of reasons, even core opengl sucks. opengl sucks no matter what you do. vulkan doesn't.

This, in turn, leads to game devs not building their game using OpenGL/Vulkan because the resulting build is buggier, and slower. This doesn't even touch on the Driver issues that come with maintaining so many extensions. AMD's driver update on Windows a few months ago that resulted in 30% better OpenGL performance shows that it's not easy.

Also, as a counterpoint to "anybody can implement a proprietary extesion", as far as I know there's nothing stopping Linux drivers from implementing the DX12 API into their drivers other than hatred for Microsoft. A few years ago, there was already an effort with Gallium Nine to implement DX9 and it worked great, but was platform specific so Wine hated it. There are several tools like DXVK that essentially "implement" the API, from an application's perspective. If AMD and Intel pushed to allow for DX12 APIs into their mainline drivers, then Nvidia would quickly follow given that their userspace driver is pretty much a clone of their Windows driver.

their DX12 implementations presumably have proprietary bits in them, in that case no amount of pushing can solve that, the only reason DX9, and 10 exist in mesa is because of third parties, in the case of DX10, it was vmware devs, G9 was volunteers and not backed by any company,

But god forbid anybody developing Linux software do something useful for the end user, rather than grandstanding their philosophies.

and god forbid someone stop and think why someone who is developing software stops and think's about why it is. without a walled garden approach, you don't get what you want, Linux software devel needs to cater to too many peoples needs.

[piotrj3]

The problem isn't that Extensions aren't useful, it's that simply by having them you make it extremely annoying for developers trying to use your API. To the people saying "The engine will support it, so game devs won't care", that's a view that doesn't look at history. Unity and Unreal have a long history of supporting OpenGL alongside DX12 to allow for making cross-platform games, but the engine devs get sick and tired of working with OpenGL, leading to sub-par implementations. This, in turn, leads to game devs not building their game using OpenGL/Vulkan because the resulting build is buggier, and slower. This doesn't even touch on the Driver issues that come with maintaining so many extensions. AMD's driver update on Windows a few months ago that resulted in 30% better OpenGL performance shows that it's not easy.

Also, as a counterpoint to "anybody can implement a proprietary extesion", as far as I know there's nothing stopping Linux drivers from implementing the DX12 API into their drivers other than hatred for Microsoft. A few years ago, there was already an effort with Gallium Nine to implement DX9 and it worked great, but was platform specific so Wine hated it. There are several tools like DXVK that essentially "implement" the API, from an application's perspective. If AMD and Intel pushed to allow for DX12 APIs into their mainline drivers, then Nvidia would quickly follow given that their userspace driver is pretty much a clone of their Windows driver.

But god forbid anybody developing Linux software do something useful for the end user, rather than grandstanding their philosophies.

1st. You have normal vulkan version system and Vulkan since 1.1 in base has quite good base what is in core and it works good. Vulkan 1.1 is capable of making entire Wayland compositor including managing all memory etc.
2nd. Propertiary extension here means it has public full spec, so it still has very precizly in conformance test defined behaviour. There is nothing preventing AMD implement Nvidia vulkan extension and in fact AMD does implement some of them.
3rd. Vulkan is VERY precize and has conformance tests in depth from start and since it is low-level API with explicit synchronization model, most stuff are very strongly outlined what they do. OpenGL is very imprecise, has bad documentation and is plagued by undefined behaviour (for example, I remember one bug in KDE when some operation was done and state of something after it was unknown, MESA assumed one thing, Nvidia assumed another - such thing is not possible in Vulkan), and OpenGL is very difficult to optimize (forcing full flush after every operation that could require flush is extremly wasteful, so drivers try to optimize certain things leading to sometimes poor quality).

By comparison DX12 has certain propertiary bits that are deep in directx kernel driver and has own scheduler and that part is not just propertiary but it is not even outlined exactly how stuff internally work in docs.

[Quackdoc]

1st. You have normal vulkan version system and Vulkan since 1.1 in base has quite good base what is in core and it works good. Vulkan 1.1 is capable of making entire Wayland compositor including managing all memory etc.

too bad sway needs DRM format modifers, which is an extension not even in 1.3, so no polaris support there for whatever reason