`maxMemoryAllocationSize` does not display the full range of `VkDeviceSize`

[Cyphall]

The type of the property maxMemoryAllocationSize is VkDeviceSize (aka uint64_t) but the listing on the website clamps at 9223372036854775807 (= (2^63)-1).

With the latest Nvidia driver advertising (2^64)-1 for this property, this causes different values to be reported between the Vulkan Caps Viewer and the website:

[SaschaWillems]

Can you post a link to a report?

[Cyphall]

Sure, the report in the screenshots is https://vulkan.gpuinfo.org/displayreport.php?id=46674

[SaschaWillems]

Can you export a report to JSON and attach it?

The database already contains the wrong value (9223372036854775807), so this might be happening either when exporting to JSON or while reading that JSON into the database.

[Cyphall]

Here is the report: report.json
It contains the right value (18446744073709552000).

[SaschaWillems]

Should be fixed. I had to change the database column to long varchar (text), as there is no integer type in MariaDB that can store values as large as these.

[Cyphall]

Thanks!

[Cyphall]

I see that BIGINT can be tagged with UNSIGNED, in which case the range is 0 to 18446744073709551615 instead of -9223372036854775808 to 9223372036854775807 (reference: https://mariadb.com/docs/server/reference/data-types/numeric-data-types/bigint)

This should work in our case, no?

[SaschaWillems]

No, unsigned bigint is too small.

Your report has:
18446744073709552000

unsinged bigint is
18446744073709551615

I already have to use text column types for other values, and PHP pretty much doesn't care anyway.

[Cyphall]

Oh wait, there is a bug in the Vulkan Caps Viewer export then, the json indeed contains 18446744073709552000 but the UI shows 18446744073709551615 (see screenshot).

18446744073709551615 is the expected value ((2^64)-1)

18446744073709552000 is actually above the range of an uint64_t/VkDeviceSize

[SaschaWillems]

Okay, then I'll have to investigate further. This might be an issue with the JSON library of Qt.

[Cyphall]

It seems the original uint64_t value is converted to double during export.

static_cast<double>(18446744073709551615ull) gives 1.8446744073709552E+19, which in plain decimal is 18446744073709552000.

[Cyphall]

Indeed, it seems all numbers are stored as double in QJsonValue: https://doc.qt.io/qt-6/qjsonvalue.html#Type-enum

EDIT: They actually support 64-bit values but warn that values >= 2^63 will lose precision: https://doc.qt.io/qt-6/qjsonvalue.html#loss-of-information-and-other-types

From looking at their source code, values above (2^63)-1 are stored as double:
https://github.com/qt/qtbase/blob/7499237a6c948a973f43c25c03458a2bd11f35c7/src/corelib/serialization/qjsoncbor.cpp#L725-L733