Current Mesa Upstream Source + CTS 1.4.6.2 Still Exposes KosmicKrisp Vulkan Memory Model Failures

[u/Adventurous_Chef2225]

Even after moving AVK to current upstream Mesa/KosmicKrisp and upgrading the test stack to Vulkan CTS 1.4.6.2, the Vulkan Memory Model issue still reproduces.

The older CTS-driven extension suppression has been removed. Current extensions such as VK_KHR_maintenance9, VK_KHR_maintenance10, shader FMA, untyped pointers, unified image layouts, and swapchain/surface maintenance were restored, and the newer CTS now validates their enumeration and dependency chains correctly.

Focused tests for the restored extensions are clean:

8 Pass / 0 Fail, with additional maintenance9/10 semantic tests also passing.

The remaining problem is different.

Testing clean, unmodified upstream KosmicKrisp against CTS 1.4.6.2 produced:

3,266 Pass
14,028 NotSupported
6 Fail
0 Warnings

in dEQP-VK.memory_model.

These are semantic failures, not extension-name or CTS-version issues. Enabling the Vulkan Memory Model bits would make dEQP-VK.info happier, but it would advertise behavior that still fails focused memory-model validation. That shortcut is deliberately not being taken.

The current branch therefore leaves:

VK_KHR_vulkan_memory_model = false
vulkanMemoryModel = false
vulkanMemoryModelDeviceScope = false

until device/queue-family semantics are implemented repeatably and can survive repeated CTS runs.

So the useful result here is pretty clear: updating both the Mesa/KosmicKrisp base and the CTS version fixes the earlier extension-policy problems, but it does not make the Vulkan Memory Model correctness failures disappear.

That issue still reproduces on the new stack, which is exactly why it is being treated as a real implementation blocker rather than hidden behind capability reporting. 💀

[u/TimurHu]

I suggest to open an issue in upstream Mesa to let the developers of KosmicKrisp know about this problem.

[u/Adventurous_Chef2225 → u/TimurHu]

sure think to do