PSA: Just because a Vulkan application works ok on one driver (or version of a driver) and not on another doesn't mean that driver is broken.
This is something I hear all the time: "The Intel driver is broken because X app doesn't work". In my experience debugging these issues, I have see about as many (maybe more?) application bugs than bugs in our driver. Frequently, there are bugs on both sides that have to get fixed before an application will work. How does this happen? Part of the reason is that Vulkan is a new API and things are still maturing, but there's more to it than that.
One of the things about Vulkan that's different from GL is that it requires the application to pass in a lot of redundant or possibly unneeded information. No Vulkan implementation needs 100% of the information the client provides so some of it will get thrown away. If the application is missing some of this information or if it is inconsistent in any way, this can easily cause the application to fail on one driver and work on another without either driver having a bug. The solution to this is a set of validation layers that application developers are supposed to use when developing their application. These layers cross-check the information provided by the application and try to ensure that they provide all of the needed information and that it's consistent. Unfortunately, those layers are somewhat incomplete and application bugs of this type still leak through. The layers are constantly improving, but there are still bits and pieces missing.
There are also driver bugs. Our driver, I'm sure, still has a lot of them. In order to try and improve driver quality and keep the bugs down, the Khronos group has been developing a test suite called the Vulkan CTS. Driver writers are expected to run and pass these tests if they want to ship a driver and call it conformant. Unfortunately, the test suite still has a lot of coverage holes and driver bugs can easily go unnoticed. With GL, the situation is a bit different. There are a multiple test suites out there and also a huge number of applications that are exercising many driver paths that the tests don't. With Vulkan, there are only a few of Vulkan applications that run on Linux so we basically have to rely on the CTS for ensuring that our driver works correctly.
So how do all of these applications run on AMD and NVIDIA out-of-the box? If the driver and validation situation is so bad, how does anything work? Well, first off, it's not that bad, and it's improving every day. But the real answer is, "lost of testing." Most applications (especially games) are primarily developed and tested against AMD and NVIDIA's implementations (and sometimes Quallcom because they support Android) so they naturally work there. Also, all of the driver teams are pulling applications and testing them to try and find bugs in the applications and their drivers and get them fixed as quickly as possible. Some driver teams have more time available for this sort of preemptive debugging than others.
What can you do as an app developer or user? First, if you find bugs, report them. We are dedicated to making our Vulkan driver as good as it can be but we can't fix bugs we don't know about. One of the most frustrating things for me as a driver developer is to see users complaining on internet forums about how our driver is crap because it has some bug and doesn't run their favorite app but they've never bothered to report it. Second, have patience and update regularly. When we come across applications that don't work, we try to get the bugs, whether in our driver or in the application, resolved as quickly as we can. However, it takes time to get the bugs resolved and for driver and application updates to get pushed out.
Finally, please use our driver! The more Vulkan applications that are out there and the more people we have running them on our driver, the better it will be.