search

SaschaWillems / vulkan.gpuinfo.org

Front-End and Back-End for the Vulkan Hardware Database
https://vulkan.gpuinfo.org
GNU Affero General Public License v3.0
23 stars 4 forks source link

Instead of VkPhysicalDeviceDescriptorBufferPropertiesEXT in the report, its misreporting as VkPhysicalDeviceDescriptorBufferDensityMapPropertiesEXT #76

Closed devshgraphicsprogramming closed 10 months ago

devshgraphicsprogramming commented 10 months ago

The whole of the issue has been described here (first wrongly accused the python script): https://github.com/KhronosGroup/Vulkan-Profiles/issues/484

You might want to run the report through the profile validator before making its profile JSON downloadable.

Because it fails against the .json schema not only because of the name typo but also because some of the members are strings and not integers

SaschaWillems commented 10 months ago

Can you provide links to the reports?

I probably "just" need to update the profiles in the back-end but would need something to check against.

And just to confirm: It's about profiles downloaded from the database? Cause the caps viewer itself can't export profile jsons.

devshgraphicsprogramming commented 10 months ago

Any profile for any report with API version >1.3.250

SaschaWillems commented 10 months ago

Took me quite a while to figure this out, but this is caused by how the internal mapping structure is generated from vk.xml. While not wrong per se. the vk.xml entry for VK_EXT_descriptor_buffer also has multiple properties structures which leads to problems with interpretation on my side. Sadly the xml doesn't have a way to find out if that struct is actually "the" feature/property struct for a given extension.

That means I'll have to manually fix my mapping and make sure this gets patched in the automated spec to mapping generation :(

Will try to push out an update sometime this weekend.

SaschaWillems commented 10 months ago

You might want to run the report through the profile validator before making its profile JSON downloadable.

That's sadly not that easy for different reasons.

Profile generation is already one of the most complex parts of the back-end and adding schema validation would add even more complexity. And what would be the result if that would fail? Telling the user that the profile couldn't be generated?

The cause for this issue is a very specific one and tied to how a single extension is exposed in the spec. I don't think this will happen a lot of times.

SaschaWillems commented 10 months ago

Please test again, the generated profiles should now validate clean against the schema files.

Fixing this wasn't trivial and I took the opportunity to rewrite some important parts of the profile generation code and the way struct and type mappings are generated from the spec. Aside from fixing problems with invalid files this should make it easier for me to update to newer profile schema versions and should make generation more future proof.

SaschaWillems commented 10 months ago

Closing this for now. If the issue persists, please open a new issue.