Slang项目中的Vulkan测试失败问题分析与解决

问题背景

在Slang项目的持续集成测试中，发现了一系列与Vulkan相关的测试用例在GCP服务器上失败的情况。最初只观察到少数几个测试失败，如bufferBarrierVulkan和clearTextureTestVulkan，但后来问题扩展到了更多测试用例，包括computeTrivialVulkan、computeSmokeVulkan等。

错误现象分析

测试失败时出现的核心错误信息是：

[Vulkan Loader] ERROR: ICD associated with VkPhysicalDevice does not support GetPhysicalDeviceCooperativeVectorPropertiesNV

这表明Vulkan加载器在尝试调用GetPhysicalDeviceCooperativeVectorPropertiesNV函数时遇到了问题，因为底层硬件或驱动不支持这个NV扩展功能。

问题根源

经过深入分析，发现问题出在Slang-GFX的Vulkan实现中。代码在初始化物理设备时，会尝试查询和设置协作向量(cooperative vector)相关的属性，即使硬件可能不支持这个功能。具体来说，vk-api.cpp文件中有一段代码在initPhysicalDevice函数中直接调用了vkGetPhysicalDeviceCooperativeVectorPropertiesNV，而没有先检查设备是否支持这个扩展。

解决方案

正确的做法应该是：

1. 首先检查设备支持的扩展列表中是否包含VK_NV_COOPERATIVE_VECTOR_EXTENSION_NAME
2. 只有在确认支持该扩展的情况下，才尝试调用相关函数
3. 将相关代码从物理设备初始化阶段移动到设备创建后的阶段

这种修改可以使代码更加健壮，能够优雅地处理不支持该扩展的硬件环境。

影响范围

虽然错误信息直接指向协作向量功能，但实际影响范围更广，导致了许多看似不相关的Vulkan测试失败。这是因为初始化过程中的错误可能导致整个Vulkan上下文创建失败，进而影响所有依赖Vulkan后端的测试用例。

验证与测试

修复后，需要在多种硬件配置上验证：

1. 支持NV协作向量扩展的硬件（如RTX 3090）
2. 不支持该扩展的硬件（如GCP服务器和一些AMD显卡）
3. 不同版本的Vulkan驱动

确保在所有情况下测试都能正常通过，而不会因为缺少某个特定扩展而导致整个测试套件失败。

经验总结

这个问题的解决过程提醒我们：

1. 在调用特定硬件扩展功能前，必须进行充分的可用性检查
2. 错误处理应该更加细致，避免一个功能的失败影响整个系统的初始化
3. 持续集成环境应该包含多种硬件配置的测试，以尽早发现兼容性问题

随着Slang项目向slang-rhi迁移并逐步弃用gfx，这类问题将得到根本解决。但在过渡期间，保持现有实现的稳定性和兼容性仍然非常重要。