Vulkan计算着色器调用vkCreateComputePipelines耗时过长问题求助

第一步：定位SPIR-V中间码问题 #

• 手动执行SPIR-V优化校验：使用spirv-opt --eliminate-dead-code-aggressive --strip-nondebug 输入.spv -o 输出.spv处理glslc生成的SPIR-V文件，确认死代码是否真的被完全移除，若存在未被清理的冗余全局变量、大数组声明，会导致驱动解析阶段耗时陡增。
• 检查宏定义数值：重点确认ANN_MAX_SIZE、ANN_TOUCHED_BLOCK_COUNT、ANN_OUTPUT_SIZE这类共享内存数组的定义大小，若数值过大（超过4096），N卡专有驱动在做共享内存地址映射、寄存器分配时会触发暴力优化的慢路径，即使着色器整体逻辑简单也会出现超长编译耗时。
• 替换共享内存做对照测试：临时注释掉三个shared数组的声明，将涉及tmp1、tmp2的操作改为线程私有变量，若编译速度恢复正常即可锁定是共享内存相关的驱动优化导致的问题。

第二步：驱动侧编译流程Profiling方法 #

• 开启NVIDIA驱动调试日志：Windows系统在NVIDIA控制面板「管理3D设置-开发者设置」中开启着色器编译日志输出；Linux系统设置环境变量__GL_DEBUG=1 __GL_SHADER_DISK_CACHE=0后运行程序，日志会输出着色器编译各阶段的耗时，可直接定位卡顿节点。
• 禁用驱动优化做对照：创建pipeline时添加VK_PIPELINE_CREATE_DISABLE_OPTIMIZATION_BIT flag，若此时编译速度恢复正常，可100%确认是驱动后端优化流程导致的耗时。
• 排查特化常量问题：你当前使用了local_size_x_id = GROUP_SIZE_CONST_ID的特化常量定义，若创建pipeline时未传入固定的特化常量值，驱动会为兼容动态工作组大小生成多套执行路径，这也是N卡驱动的已知慢路径，可临时将local_size_x改为固定值（如256）测试编译速度。

临时规避方案 #

• 开启驱动着色器磁盘缓存：N卡默认会开启该功能，首次编译完成后后续启动无需重复编译，开发环境可手动指定缓存路径避免频繁失效。
• 若确认是特化常量导致的问题，可将固定工作组大小直接写入着色器代码，不需要使用特化常量。
• 大共享内存数组可拆分为多个小数组，或把不需要跨线程共享的变量迁移到线程私有内存，降低驱动优化的复杂度。

内容的提问来源于stack exchange，提问作者alagris