Some background
More than 6 years ago (time flies!) I released the Vulkan Hardware Database and Capability Viewer along with the first public release of Vulkan 1.0. Traffic on the database has been rising steadily and is approaching 1,000,000 hits per month. 2021 more than 3,000 reports have been uploaded to the database, a number that also has been steadily increasing since launch. This makes it my mostly used database (compared to OpenGL and OpenGL ES) and judging by the feedback it seems to be a widely and often used feature among Vulkan developers. Since then I’ve been doing regular updates, added lots of new features (e.g. an updated mechanism) and platforms (e.g. Apple) and integrated valuable feedback from my users.
Some statistics from 2016 until today (numbers for 2022 are obviously not complete):
But one drawback of the database has been that data starts to loose it’s usefulness over time. Lots of the devices present in the database no longer get driver updates and are stuck with old api versions. But all of those devices and their corresponding reports are still factored into coverage numbers and listings. And this makes it hard to get up-to-date relevant numbers for some feature you’re searching for.
Global api level selection
So one of the top requests for the database was a method to mitigate this. Deleting reports for old devices would have been an easy option, but that would also mean information on those devices would no longer be available and people with such devices would probably just reupload it. So I went with a different approach instead and added a global api level selection to the database.
With this new option you can now globally set a minimum api level that is applied to all database queries. To make this easy to use it’s added to the top bar, so you can switch versions no matter what page is currently open. The default setting will display data for all reports in the database, but if you select a minimum api level, all data displayed will be filtered accordingly.
If you e.g. select Vulkan 1.2 as the minimum api level you’ll only get reports, coverage numbers, extensions, format support, etc. for devices that support Vulkan 1.2 (and up). So if you’re not interested in old devices that only support Vulkan 1.1 (or lower) you can now easily exclude that data from the database.
For example here are some extension coverage numbers for all devices (left) and only devices supporting Vulkan 1.3 (and up):
And the same comparison for a feature’s value distribution:
When set, the minimum api version is applied to all listings in the database. So you only get reports with at least that versions, coverage numbers are adjusted and all listings also filter out older reports.
The selection is stored in such a way that once set it’ll be applied to all of the database until you either clean the session or revert back to all versions or a different version. So it’ll even be kept when closing the page and coming back at a later point.
Implementing the api level selection
Even though it may not look like a large effort, adding that feature to the database was actually a large undertaking that took me several months. When I started working on this feature, I wanted it work everywhere.
When I started out, all the SQL statements to fetch data were scattered around. Filters where manually applied in a lot of places, e.g. dynamically adding where clauses to the statements based on request parameters. If you want to add a new feature that’s supposed to work everywhere, that’s obviously not a good starting point.
So my fist step was moving those SQL statements to a central SQL repository. With all statements now managed by a single class, I went on to refactor how the dynamic where clauses would be generated. With that in place I could finally add in the new api version selection filter to all statements used throughout the database. Doing large refactors like this also requires in-depth testing to make sure that I didn’t break accidentally anything.
On the plus side I now have a good base for adding even more global filters, so if you need additional filters aside from the api level, feel free to drop me a line.
I also took this as an opportunity to update a few of the “not so important” listings, like the instance ones, which now also show coverage numbers and have platform selection like all other listings.
Feedback
If you encounter bugs after this update or want to propose feature requests, feel free to submit an issue over at the database’ github repository.