Improving filtering

Eight years after launching the Vulkan database to the public, it’s approaching 30,000 uploaded reports from more than 3,300 different devices across Windows, Linux, Android, MacOS and iOS. With that much data available, good filtering capabilities are crucial.

One part where the filtering capabilities of the database were severely lacking have been device coverage based listings. Device coverage is a percentage value that states how many distinct devices (not reports) support a given feature. So if a certain device launched without support for a given extension that was added in a newer driver version, that device will count towards this device coverage. So basically it’s the percentage of devices supporting a given extension, feature, property, etc. at the current date.

Here is an example: On the global extension coverage listing page one can check what devices support a given extension like this:

This will list all devices that support this extension, including the first driver version that added support for it. E.g. the extension VK_KHR_video_encode_h265 was added for NVIDIA’s RTX 4070 with driver version 538.9 on Windows.

Clicking on a device then would redirect to a list with reports for that device:

(This actually shows three pages worth of reports)

Looking at that list you might notice that this does include all driver versions for that device, and not just the ones that support the extension. To pick a report with support for the selected extension you’d have to manually skim through the report list to pick the right one(s), making this a kinda pointless feature. Due to how drivers work for certain vendors, sorting by version wouldn’t work anyway, as a newer developer driver version might actually not support that extension at all.

And this was the case for a lot of the report listings behind coverage links. Why this was happening becomes evident looking at the caption of the screenshot above. It only contains the name of the selected device, but no info on what extension it should look for. That was a limitation of the database back-end affecting all coverage based listings. This includes extension, features, properties and many more. It was caused by the fact that only one filter could be applied to such listing simultaneously (in this case the device name).

But realizing how important this feature is to the database users I went on and added support for multiple filters to all the routes and views in the back-end. Due to how the database works and the fact that there’s some legacy code this wasn’t trivial, esp. as I didn’t want to accidentally break other parts of the database. I don’t do time tracking for my hobby projects, but I’d estimate that it took me around one or two full weeks of work to get this added in all places, making this one of the largest changes to the database I didn’t in recent years. A positive side-effect: I also refactored a lot of code, simplified it a bit and also added lots of new filtering possibilities that haven’t been possible before.

So if you now follow a device coverage link, you’ll get a listing filtered by multiple arguments. E.g. device name and extension (and operating system, though that was already possible):

Extensions

Profiles

Extension properties

Format feature flag support

As expected, this now starts with the first driver version that supports this extension and only lists reports that actually support the extension, making this view far more usable than before.

Filtering is done via URL parameters, meaning you can even pass along URLs for views filtered like that. E.g. :

Fixing bugs

One feature of the device coverage listings is the “first known driver” version column. This column displays the first driver version for that device where the selected extension, feature, property, etc. was added. While adding in all the new filters I noticed that some of those seemed wrong.

In this listing the privateData feature is reported as being first supported in driver version 466.11 for the Geforce GTX 980. That’s actually impossible though, as that’s a Vulkan 1.2 driver and privateData is a Vulkan 1.3 feature:

And indeed, the statement for this device coverage view was partially wrong. Instead of looking for actual reports it only checked for device names. After fixing it (by using the proper SQL in clause) that view now reports the correct first known driver version:

Improving database performance

One drawback of the databases getting more and more popular is server load. Some users noticed that certain pages (esp. the extension listings) often were either slow or timed out completely. To fix this I improved some of the SQL statments, added some indices and upgraded servers. Some months ago I started logging execution times, and judging by that data the upgrades indeed improved performance by a lot. So hopefully you’ll see the database deliver results faster in general. I’ll be writing about this in a future post.

Feedback

If you have any feedback on this new feature, or find a bug, feel free to open an issue at the github repository for the database.

I hope that these changes and additions make the database an even more useful tool for all you Vulkan developers out there 😊

vulkan