Vulkan even made this kind of targeted hack into a first class citizen by letting the application specify the name and version number of itself and its engine during initialization. There's no reason for that besides enabling per-app driver shenanigans.
Vulkan layers being system-wide feels like it's specifically asking for this class of bug. If you're lucky every system-wide layer ships with PDBs... but they probably don't. I've yet to find a bug in a layer, at least, but I've wasted time ruling it out.
System-wide Vulkan layers definitely cause chaos. I remember unit tests for our renderer crashing on some machines and not on other nearly identical ones. The culprit was a Vulkan layer installed by a video capture software. It had a hard limit of 16 Vulkan instances that it could keep track of before overflowing an array and crashing. But our tests would recreate the Vulkan environment from scratch for each test, which is fairly unusual for a Vulkan application, to be fair.
In the end, we added the list of loaded Vulkan layers to the diagnostic log of our software to help customer support spot fishy ones.
I've personally run into stuff like this on Windows but I want to emphasize that the vast majority of developers won't run into these problems. It's basically the equivalent of finding a compiler bug - yes, you might, but usually the problems you hit are not caused by the compiler or OS, as a general thing.
Are OS or compiler problems more common now than they were 10 years ago? Possibly, but I wouldn't be surprised if they're less common, either.
I have run into driver bugs multiple times though, perhaps more often than OS bugs. And that's really frustrating.
If you haven't run into a compiler bug you're not trying hard enough. If you support multiple compilers or your company has their own compiler team/patches it'll definitely happen.
Also happens when some pedantic people decide to turn on -Wall -Wextra -Werror because they think it's safer; now any incorrect warning bug is a fatal compiler bug.
Comes with the general perception of OS vs Software failure responsibility:
- On Windows, this is Window's fault
- On Apple OS, this is the application's fault
- On Linux, this is the user's fault
Of course exception do apply, but as far as I know MacOS I have noticed some instance of application patching by the OS itself (although I haven't dug deeper, I can confirm that the application did have a slight change of behavior even before applying vendor patches, and I doubt it was anything done by the anti-malware protection)
I never understand these drive-by comments. It's not like developing on/for the competition is any easier or less convoluted. The author is debugging a cross-language (both managed and native), cross-architecture video game with a variety of third-party libraries.
Turns out that the Windows graphics stack is complicated (mainly because it needs to support a variety of closed-source programs that never saw maintenance after initial release), so compatibility layers meant to optimise for certain programs (an easy optimisation, frankly) accidentally caught the author's program in the master list, too.
There are people who actually try to implement better APIs. (We can quibble over effectiveness all day long. Sadly, it looks like a losing battle.) This is the only way to find them.
No worries, the same experience can be done with OpenGL or Vulkan, depending on the specific OS flavour and OEM drivers.
Vulkan even made this kind of targeted hack into a first class citizen by letting the application specify the name and version number of itself and its engine during initialization. There's no reason for that besides enabling per-app driver shenanigans.
Vulkan layers being system-wide feels like it's specifically asking for this class of bug. If you're lucky every system-wide layer ships with PDBs... but they probably don't. I've yet to find a bug in a layer, at least, but I've wasted time ruling it out.
System-wide Vulkan layers definitely cause chaos. I remember unit tests for our renderer crashing on some machines and not on other nearly identical ones. The culprit was a Vulkan layer installed by a video capture software. It had a hard limit of 16 Vulkan instances that it could keep track of before overflowing an array and crashing. But our tests would recreate the Vulkan environment from scratch for each test, which is fairly unusual for a Vulkan application, to be fair.
In the end, we added the list of loaded Vulkan layers to the diagnostic log of our software to help customer support spot fishy ones.
I've personally run into stuff like this on Windows but I want to emphasize that the vast majority of developers won't run into these problems. It's basically the equivalent of finding a compiler bug - yes, you might, but usually the problems you hit are not caused by the compiler or OS, as a general thing.
Are OS or compiler problems more common now than they were 10 years ago? Possibly, but I wouldn't be surprised if they're less common, either.
I have run into driver bugs multiple times though, perhaps more often than OS bugs. And that's really frustrating.
If you haven't run into a compiler bug you're not trying hard enough. If you support multiple compilers or your company has their own compiler team/patches it'll definitely happen.
Also happens when some pedantic people decide to turn on -Wall -Wextra -Werror because they think it's safer; now any incorrect warning bug is a fatal compiler bug.
Each operating system has such layers of cruft, they're sometimes just harder to debug.
Comes with the general perception of OS vs Software failure responsibility:
- On Windows, this is Window's fault - On Apple OS, this is the application's fault - On Linux, this is the user's fault
Of course exception do apply, but as far as I know MacOS I have noticed some instance of application patching by the OS itself (although I haven't dug deeper, I can confirm that the application did have a slight change of behavior even before applying vendor patches, and I doubt it was anything done by the anti-malware protection)
I never understand these drive-by comments. It's not like developing on/for the competition is any easier or less convoluted. The author is debugging a cross-language (both managed and native), cross-architecture video game with a variety of third-party libraries.
Turns out that the Windows graphics stack is complicated (mainly because it needs to support a variety of closed-source programs that never saw maintenance after initial release), so compatibility layers meant to optimise for certain programs (an easy optimisation, frankly) accidentally caught the author's program in the master list, too.
There are people who actually try to implement better APIs. (We can quibble over effectiveness all day long. Sadly, it looks like a losing battle.) This is the only way to find them.
EDIT: typo