I'm noob so I want to ask. Will this change something for existing games?

Rambo:

I'm noob so I want to ask. Will this change something for existing games?

That depends. If the only thing you do is update Vulkan and drivers, then no, you're probably not going to see any difference. If the games are updated to utilize the new features, then yes, you might see a difference. I could've sworn Vulkan 1.0 was already capable of simultaneous processing on mismatched GPUs, but, maybe 1.1 has the potential to allow users to toggle this even on unsupported software, much like how you could force Crossfire or SLI to run on unsupported software. Obviously that doesn't mean your games will be optimized to run on, for example, an Intel IGP with a GTX 1080 (I'm sure you'd get horrible microstuttering, or should I say, macrostuttering), but it's interesting to think about such potential features. Anyway, my point is if something like this were to be done, that could in theory apply to existing games, since this is handled at the OS and driver level.

Rambo:

I'm noob so I want to ask. Will this change something for existing games?

https://vulkan.lunarg.com/doc/sdk/1.1.70.0/windows/release_notes.html The installed runtime or loader program has a few bug fixes in addition to support for the new 1.1 features but for games I don't think any current released title will see a update to the new SDK, emulators might in time as AMD and NVIDIA get stable drivers out that support it though and of course upcoming Vulkan games and game engines such as Unity, Unreal and Cry engine. 🙂

Fixed Vulkan-LoaderAndValidationLayers Github Issues: #2410 vkGetSwapchainImagesKHR called more than once, returns another handle (ID)s bug #2403 Presence of ICD json causes loader errors when loading layers loader question #2379 vulkaninfo doesn't give anything useful when DISPLAY is not set #2360 Validate descriptor set flags for vkCmdPushDescriptorSetKHR incomplete #2289 Missing validation: Transitioning an image before binding memory to it is illegal incomplete #2213 VL reports too early when recording secondary command buffer bug #1600 SC layer: GS output to FS input not taken into account (refs VS instead)

AMDs 18.2.3 drivers got re-released with it added 🙂

From my experience with Vulkan, I can without a doubt say that by playing a game that supports the Vulkan api this will allow you to stretch old hardware alot longer than what any DX can ever do. I still don't know why developers don't use this api more often? Maybe it's a lack of knowledge of how to use it or maybe Microsoft is paying royalties to use the DX api??? No one will truly know, but man go and play a game that supports the Vulkan api then you will kno what I mean. I have seen improvements of 30% + in certain games. However I have not seen actual image quality comparisons between DX and Vulkan on a like for like basis. But I do know one thing and that is if you run a game with the Vilkan api then every last drop of your performance is sucked out of your pc to make the game run as smooth as possible. Really I will advise anyone that haven't tried a game with the Vulkan api yet to install something like Doom and test it a bit. It amazes me every time to see what better optimized code does to actual performance. Those peeps at Khronos deserve a lot more respect than what they currently get.

@RooiKreef I'm quite sure that DirectX is popular because it is very well documented and supported by Microsoft and other users. What Khronos is doing now is trying to emulate the same way of partnership with companies and support for developers that Microsoft did long ago, or so I assume they did. I'm happy that this is happening and owners of AMD's GCN-cards are probably too. The possible gains for those cards are immense compared to DX11. I still wonder why DX12 is still so slowly adopted, since to my understanding, it offers very similiar features to Vulkan in the end.

GamerNerves:

I still wonder why DX12 is still so slowly adopted, since to my understanding, it offers very similiar features to Vulkan in the end.

I guess because it's locked to Win10 probably? Vulkan is not locked to a single platform actually, or is it? I'd rather see Vulkan on the rise than dx12, but that's just my opinion.

fantaskarsef:

I guess because it's locked to Win10 probably? Vulkan is not locked to a single platform actually, or is it? I'd rather see Vulkan on the rise than dx12, but that's just my opinion.

Yes, that is a very likely reason. In a case of emergency though, Microsoft can just update Windows 7 to support DX12.

GamerNerves:

Yes, that is a very likely reason. In a case of emergency though, Microsoft can just update Windows 7 to support DX12.

While I guess you might be right, I'd like to see that emergency 😀

I wish developers wern't lazy and implented vulkan in all their games. But making a half assed console port is easier money i guess.

Some Linux ports also gets Vulkan now over OGL though the Windows versions usually remains on DirectX, and sometimes with the DRM still in place too heh. Mad Max for example though in it's favor it's really well optimized for both AMD and NVIDIA.

GamerNerves:

@RooiKreef I'm quite sure that DirectX is popular because it is very well documented and supported by Microsoft and other users. What Khronos is doing now is trying to emulate the same way of partnership with companies and support for developers that Microsoft did long ago, or so I assume they did. I'm happy that this is happening and owners of AMD's GCN-cards are probably too. The possible gains for those cards are immense compared to DX11. I still wonder why DX12 is still so slowly adopted, since to my understanding, it offers very similiar features to Vulkan in the end.

Absolutely correct on why DX (d3d) is the hands-down developer-preferred API--it's tools, and then it's more tools and lots of developer support from Microsoft for d3d. Nobody does that better, imo. The old OpenGL ARB group was contentious--IHVs and devs in constant disagreement (picking "sides", etc.) and wanting to develop custom extensions the other guy(s) didn't have, etc.--ARB progressed with the speed of a glacier in those days, accordingly. ARB/OpenGL predictably went the way of extinct birds, and then out of the ashes Kronos & Vulkan are born. Don't forget that Vulkan is as slowly adopted as DX12 currently. But neither is actually "slow" when it comes to widespread adoption. People have short memories when it comes to how long DX9.0c (shipped in 2002--the "c" version) remained current, and how *long* it took game developers to fully support everything it had to offer and to ship games that *required* DX9.0c (instead of merely "supported it" with a couple of features optional to the game engine, etc.) Somewhere in the neighborhood of 10-15 years, IIRC, for DX9 to hit its maximum stride--DX9.0c games were still shipping in 2015/16, and may still be shipping, I'm sure. DX11 is only now beginning to accrue significant developer interest. DX12 is a brand new API which developers have to learn how to build their game engines around--that's going to take awhile. (For instance, DX12 allows devs to directly implement multi-gpu support in their d3d12 game engines--doing away with the current situation of xFire/SLI not supported in in games through the API--but only through custom GPU driver support bolted on by the GPU IHVs--which is entirely why some games don't support it at all while other games support it poorly, etc.) Couple more years, at least, I would guess, before we begin seeing "DX12-required" game engines. But it's not unusual--game devs prefer to ship to the widest possible gaming audience, of course, which right now is neither Vulkan nor DX12, imo. Patience is advised...;)