Vulkan 1.2.145 Released With VK_EXT_extended_dynamic_state

[phoronix]

Phoronix: Vulkan 1.2.145 Released With VK_EXT_extended_dynamic_state

There have been a few Vulkan spec updates without any new extensions introduced but this weekend's Vulkan 1.2.145 revision does bring new functionality...

http://www.phoronix.com/scan.php?page=news_item&px=Vulkan-1.2.145-Released

[Cr0ydon]

Can someone explain me in simplified terms how it can be, that one of the biggest selling points of Vulkan is simpler implementations and therefore better drivers, but now they continue to add extensions constantly?

From my understanding, extensions are optional and applications can use them conditional, but this still adds tons of complexity in the long run, doesn't it?

[oysstu]

Can someone explain me in simplified terms how it can be, that one of the biggest selling points of Vulkan is simpler implementations and therefore better drivers, but now they continue to add extensions constantly?

From my understanding, extensions are optional and applications can use them conditional, but this still adds tons of complexity in the long run, doesn't it?

I agree with your sentiment, but it's also supposed to be a low level language that exposes the necessary constructs to do very precise control of the hardware. I suspect many of these extensions are mostly useful for developers building new APIs or engines on top of Vulkan, and not for general graphics programming. I do sincerely hope that Khronos manages to keep the API lean however, and not cause too much fragmentation across the Vulkan ecosystem

[JMB9]

I am not a programmer using OpenGL or Vulkan, but from my understanding:

OpenGL is for highest abstraction so you can get easy to same visuals on all platforms.
[OpenGL is a 3D graphics library started in 1989 (as direct descendant of SGI's IRIS GL) and supported by IBM, DEC and SGI.]

Vulkan is for most efficient use of HW (less energy/more FPS) so we have to use a lot more functions to tailor it to the real needs and still making full use of the underlying HW.
[Vulkan is derived from Mantle API developed by AMD in 2013 - and now all graphics HW companies contribute to Vulkan and standardize the needed functionality.]

So I expect Vulkan to be much harder to use but yielding much better results. And energy efficiency is the future.
And as Vulkan is more efficient it makes sense to build OpenGL via Vulkan (e.g. Zink, GLOVE - and also D3D oder Vulkan like DXVK, VKD3D or VK9), the other way around would be fruitless (technically - except for corner cases).

If this is not correct, someone else may give a better impression of the reasoning behind both standards ... it's just for the start.

[Nocifer]

Can someone explain me in simplified terms how it can be, that one of the biggest selling points of Vulkan is simpler implementations and therefore better drivers, but now they continue to add extensions constantly?

From my understanding, extensions are optional and applications can use them conditional, but this still adds tons of complexity in the long run, doesn't it?

In a perfect world where everyone uses Vulkan and the GPU drivers are fully Vulkan spec-compliant, you'd use the core spec without extensions and call it a day.

In our less-than-perfect world, where games are still mostly being developed in Direct3D and Linux gaming mostly exists as the result of Wine translating the games' original Direct3D calls into equivalent Vulkan calls, we need to make sure that Vulkan does indeed have those equivalent calls at hand. But Vulkan does not, because Vulkan is its own API, not some cheap knock-off API clone of Direct3D, and it does things in it own Correct™ way. But that Correct™ way, great though it may be, is largely (and in some cases fundamentally) incompatible with Direct3D.

So on the one hand, if we wish for Wine to be able to translate Direct3D adequately (i.e., without a significant loss of performance compared to the original Direct3D implementation), we need to make Vulkan's API compatible with Direct3D; but on the other hand, we do not want to change our carefully constructed, Correct™ API just so we can accommodate the legacy garbage that is Direct3D, because our long-term goal is to achieve the perfect world described above - and that perfect world won't be nowhere near as perfect if in the meanwhile Vulkan has devolved itself into a Direct3D clone.

The solution? Keep the core API pure and simple, ready and able to be utilized on its own to achieve gaming greatness, and provide a separate layer for all that other stuff that can be ditched in the blink of an eye when the time comes (i.e. if and when most game devs and GPU vendors adopt Vulkan as their primary target API). Hence, extensions. Think of it as our own EEE against Microsoft :P

[smitty3268]

Can someone explain me in simplified terms how it can be, that one of the biggest selling points of Vulkan is simpler implementations and therefore better drivers, but now they continue to add extensions constantly?

Simpler implementation doesn't mean simple implementation. Vulkan is still complex, and as it becomes more used developers start to understand it's strengths and weaknesses better, leading to attempts to fix some of the weak points.

The other two types of extensions tend to be DX11 compatibility extensions, and experimental vendor extensions adding functionality specific to their hardware.

[krOoze]

Can someone explain me in simplified terms how it can be, that one of the biggest selling points of Vulkan is simpler implementations and therefore better drivers, but now they continue to add extensions constantly?

I hope this answers your question:

https://youtu.be/HM8vYJQtHpA?t=366

It is as simple as possible, while meeting all the technical checkboxes. E.g. extensibility.

[starshipeleven]

Can someone explain me in simplified terms how it can be, that one of the biggest selling points of Vulkan is simpler implementations and therefore better drivers, but now they continue to add extensions constantly?

Vulkan is NOT simpler, Vulkan is less abstraction so you have more control over what is going on. It is more complex than OpenGL because of that.

But people in the graphics development actually wanted this, so those that actually NEED to have best performance possible can optimize as they have more control than with OpenGL, while everyone else (the ones that were fine with OpenGL) can just use a third party framework or a whole third party game engine that does that for them.

From my understanding, extensions are optional and applications can use them conditional, but this still adds tons of complexity in the long run, doesn't it?

all extensions are optional until they are not. The good ones become part of the next revision of the spec. So if you target Vulkan revision X you know what is there and what is not.

Again, this allows the spec to grow as hardware and software requirements change, and it's also how OpenGL worked.

[krOoze]

^ For now Khronos wants to keep free path to version upgrade, so it is a no-brainer for driver makers to bump the version. Notable difference from 1.0 to 1.2 is timeline semaphores and imageless framebuffer, rest is still optional via caps.