Some formats are displayed as unsupported

[scygan]

It seems some formats are not marked as supported on the formats page.

For example: https://vulkan.gpuinfo.org/displayreport.php?id=14968#formats on 'Optimal' tab, the format R32G32B32A32_SFLOAT is not marked as supported for any of the the usages.

At the same time, downloaded profile json from this report says:

 "VK_FORMAT_R32G32B32A32_SFLOAT": {
                    "VkFormatProperties": {
                        "linearTilingFeatures": [
                            "VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT",
                            "VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT",
                            "VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT",
                            "VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT",
                            "VK_FORMAT_FEATURE_BLIT_SRC_BIT",
                            "VK_FORMAT_FEATURE_BLIT_DST_BIT",
                            "VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT",
                            "VK_FORMAT_FEATURE_TRANSFER_SRC_BIT",
                            "VK_FORMAT_FEATURE_TRANSFER_DST_BIT"
                        ],
                        "optimalTilingFeatures": [
                            "VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT",
                            "VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT",
                            "VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT",
                            "VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT",
                            "VK_FORMAT_FEATURE_BLIT_SRC_BIT",
                            "VK_FORMAT_FEATURE_BLIT_DST_BIT",
                            "VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT",
                            "VK_FORMAT_FEATURE_TRANSFER_SRC_BIT",
                            "VK_FORMAT_FEATURE_TRANSFER_DST_BIT"
                        ],
                        "bufferFeatures": [
                            "VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT",
                            "VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT",
                            "VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT"
                        ]

According to my own tests from similar device, this format is supported. It is also shown as supported on similar device in desktop gpu caps viewer app.

[SaschaWillems]

Thanks for bringing up this issue. This looks like the uploaded report may have faulty data. Checking the database I get negative values for linear and optimal tiling support, which should not happen.

If you have access to such a device, could you export the json and attach it to this issue?

[MarijnS95]

Seeing the same on https://vulkan.gpuinfo.org/displayreport.php?id=19058 for many "sensible" formats: posting this as a reminder to myself to extract a JSON from that board when close to it again.

[MarijnS95]

@SaschaWillems there seems to be no way to extract a JSON dump from the Android app. Perhaps I can compile the cmdline binary against the Android target to run it from adb shell (or within Termux) or did I miss a button in the UI?

I take it from your comment that the JSON download on the website is generated from the database, and wasn't the raw dump that was uploaded by the device?

[SaschaWillems]

Yes, the download from the front-end is a transformed output to match LunarG's Profile schema.

If you want the raw JSON dump, you can use the following api route to fetch it: https://vulkan.gpuinfo.org/api/v2/getreportjson.php?id=19058

[SaschaWillems]

After taking a closer look at this, it may be a problem with the database indeed. I've been using MySQL's INT datatype for the format support flags, and that can become problematic with certain large values. Something I've run into in the past with other values. I'll change all format columns to use BIGINT instead. But that also means I need to somehow fix broken data.

[MarijnS95]

@SaschaWillems Thanks for checking! The raw JSON dump probably isn't what got uploaded by the client, it already includes negative numbers like -2147365757 unless the client also represents the format wrongly.

It seems you can still fix this, since VkFormatFeatureFlags is defined as VkFlags and not VkFlags64 so you can still reconstruct the original from a two's complement negative value. Strange though that there was a negative sign bit to begin with, since the spec doesn't define 0x80000000 as far as I can tell.

In light of https://stackoverflow.com/questions/75000917/what-does-the-grey-check-mark-mean-on-gpuopens-vulkan-database it is also quite strange that these formats are shown as grey crosses (format not in the list at all).

[MarijnS95]

Looking at https://vulkan.gpuinfo.org/api/v2/getreportjson.php?id=19058, under VK_FORMAT_R32G32B32A32_SFLOAT = 109 for optimalTilingFeatures we see -2147357305, which is 0x8001ed87 in hex. Without the most-significant bit 0x1ed87 is a very sensible st of format feature flags.

Parsing the value in our ash crate shows that we have a few more flags than https://vulkan.gpuinfo.org/api/v3/getprofile.php?id=19058 says:

[examples/src/lib.rs:206] vk::FormatFeatureFlags::from_raw(-2147357305i32 as u32) = SAMPLED_IMAGE | STORAGE_IMAGE | STORAGE_IMAGE_ATOMIC | COLOR_ATTACHMENT | COLOR_ATTACHMENT_BLEND | BLIT_SRC | BLIT_DST | SAMPLED_IMAGE_FILTER_CUBIC_EXT | TRANSFER_SRC | TRANSFER_DST | SAMPLED_IMAGE_FILTER_MINMAX | 10000000000000000000000000000000

Note the addition of SAMPLED_IMAGE_FILTER_CUBIC_EXT and SAMPLED_IMAGE_FILTER_MINMAX, which aren't shown by the UI anyway and probably explain why they were omitted in getprofile?

---

I mentioned two's-complement above, but that makes absolutely no sense as most bits except the lowest bit is getting flipped with regards to the "sensible" value above, so we get all kinds of flags that make no sense, and none of the flags that do:

[examples/src/lib.rs:208] vk::FormatFeatureFlags::from_raw(--2147357305i32 as u32) = SAMPLED_IMAGE | UNIFORM_TEXEL_BUFFER | STORAGE_TEXEL_BUFFER | STORAGE_TEXEL_BUFFER_ATOMIC | VERTEX_BUFFER | DEPTH_STENCIL_ATTACHMENT | SAMPLED_IMAGE_FILTER_LINEAR | VIDEO_DECODE_OUTPUT_KHR | VIDEO_DECODE_DPB_KHR | ACCELERATION_STRUCTURE_VERTEX_BUFFER_KHR | FRAGMENT_DENSITY_MAP_EXT | FRAGMENT_SHADING_RATE_ATTACHMENT_KHR | VIDEO_ENCODE_INPUT_KHR | VIDEO_ENCODE_DPB_KHR | MIDPOINT_CHROMA_SAMPLES | SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER | SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER | SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT | SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE | DISJOINT | COSITED_CHROMA_SAMPLES

In other words, it seems to be just the sign bit that gets flipped, not some kind of overflow.

[MarijnS95]

@SaschaWillems there seems to be no way to extract a JSON dump from the Android app. Perhaps I can compile the cmdline binary against the Android target to run it from adb shell (or within Termux) or did I miss a button in the UI?

https://github.com/KhronosGroup/Vulkan-Tools/pull/766: coincidence? That's nice!

[SaschaWillems]

The export button (for the JSON) is disabled on mobile platforms. For one I wasn't sure about file permissions and it also takes away some space and most users won't need it.

If you can build the app yourself, you can make it visible here: https://github.com/SaschaWillems/VulkanCapsViewer/blob/1cdf4f82bf074f877304b81ccc38e91f3aa359bd/vulkancapsviewer.cpp#L180

[MarijnS95]

Not super interested in recompiling the app, Java and gradle never really work. Including this case:

FAILURE: Build failed with an exception.

* Where:
Build file '/data/AndroidApps/VulkanCapsViewer/android/build.gradle' line: 17

* What went wrong:
A problem occurred evaluating root project 'android'.
> Failed to apply plugin 'com.android.internal.application'.
   > Could not create an instance of type com.android.build.gradle.internal.dsl.BaseAppModuleExtension.
      > Could not create an instance of type com.android.build.gradle.internal.dsl.TestOptions.
         > Could not create an instance of type com.android.build.gradle.internal.dsl.TestOptions$UnitTestOptions.
            > 'void org.gradle.api.internal.DefaultDomainObjectSet.<init>(java.lang.Class)'

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

No idea what that's supposed to mean, afaik gradle automatically picks the right version for itself :upside_down_face:

---

Can you comment on https://github.com/SaschaWillems/vulkan.gpuinfo.org/issues/50#issuecomment-1493097655 and which of the two JSONs has passed through the backend/database, and which of the two is truly raw from the device?

[SaschaWillems]

The one from https://vulkan.gpuinfo.org/api/v2/getreportjson.php?id=19058 is the one exported from the application. I store a raw copy of all submitted jsons from the application in the database in case something goes wrong while storing values to the DB. That way I can always reconstruct from the original JSON.

Haven't had time to look into the differences yet, will try to find some time this weekend.

[MarijnS95]

https://github.com/SaschaWillems/VulkanCapsViewer/blob/c96a71156e9c862b7739fd44d32412c9bde8e6f0/vulkanDeviceInfo.cpp#L886-L888 these uints are definitely cast to int on the JSON serialization side, but that doesn't explain how only the sign-bit gets enabled before this is passed upstream.

EDIT:

The one from https://vulkan.gpuinfo.org/api/v2/getreportjson.php?id=19058 is the one exported from the application.

Ack, then it's definitely the application that is reporting wrong data.

[SaschaWillems]

I've been having similar problems with other large values in the past. It's caused by how Qt stores values to JSON. To work around this I'll probably need to change from using ints to strings.

[teoxoy]

I also got tripped up by the reports containing negative numbers (due to bit 31 being originally set).

Because of the conversions here effectively doing double(int(uint32_t)), if bit 31 was set in the uint32_t, by the time we get to write the double in JSON, it becomes a negative number.

I think why we see bit 31 being set (even if VkFormatFeatureFlagBits has no such bit) is because newer drivers might use a u64 to store all flags in VkFormatFeatureFlagBits2 (since it's a superset of VkFormatFeatureFlagBits) and when asked to return VkFormatProperties via vkGetPhysicalDeviceFormatProperties they will just chop off half of the original u64.

[MarijnS95]

Oh so these are are becoming doubles at some point instead of remaining integers?

I haven't really kept up with this issue, but if we were to fix the reporting code on the app side, can we still reconstruct the valid bits from previously uploaded json dumps (with negative numbers) or should those get a little hint on the website stating that the reported values are likely incorrect?

[teoxoy]

Oh so these are are becoming doubles at some point instead of remaining integers?

Yeah, as far as I found, JSON's number data-type is a double.

VulkanCapsViewer uses https://doc.qt.io/qt-6/qjsonvalue.html#QJsonValue-3 which also states:

Creates a value of type Double, with value v.

I haven't really kept up with this issue, but if we were to fix the reporting code on the app side, can we still reconstruct the valid bits from previously uploaded json dumps (with negative numbers) or should those get a little hint on the website stating that the reported values are likely incorrect?

If the extra int() cast is removed and we just do a double(uint32_t) conversion, we can avoid negative numbers.

The problem with negative numbers in the DB will become an issue when adding support for VkFormatFeatureFlagBits2 (https://github.com/SaschaWillems/VulkanCapsViewer/issues/194).

Since the top half of the bigint is all 1's for those negative numbers (which would erroneously indicate support for the respective format flags).

Another thing that might be a problem is the conversion from uint64_t to and from double (between the DB/JSON/VulkanCapsViewer), idk if it's lossless. It might be easier to write the bitfield as a string and use the BIT type in the DB.

[SaschaWillems]

I'll do what I did with other (u)int64: I'll store them as strings (in the JSON). Also saves me some headaches through the whole process of Vulkan -> Caps Viewer (C++) -> Back-End (PHP) --> Database ( MySQL) --> Back-End (PHP) --> Front-End (Display)

[MarijnS95]

Yeah, as far as I found, JSON's number data-type is a double.

I found similar comments; perhaps it is more clear to use a string?

[SaschaWillems]

Exactly. That's what I was referring to in my comment I above. I made the experience with other values too and moved to strings for those.

I'm already working on fixing all of this (incl. new feature flags) but no ETA yet.

[SaschaWillems]

I have recently deployed a fix to the caps viewer, and the first report for Intel Arc GPUs that came in after that fix are looking good now.

• Old report (report version 3.2) with wrong format support: https://vulkan.gpuinfo.org/displayreport.php?id=29450#formats
• New report (report version 3.3) with correct format support: https://vulkan.gpuinfo.org/displayreport.php?id=29689#formats

I sadly won't be able to fix old reports, but once all devices have newer reports that won't be a problem anymore.