编译器图像处理编程语言高性能计算【免费下载链接】Halidea language for fast, portable>项目地址https://gitcode.com/gh_mirrors/ha/Halide点击查看免费下载导读本文基于 dependencies/README.md 展开系统讲解 Halide 仓库中dependencies目录的定位它不参与 Halide 对外 API而是为构建流程捆绑vendor了两套 GPU 后端必需的 Khronos 标准头文件——SPIR-V v1.6 ANSI-C 头文件与 Vulkan v1.3.296 SDK 头文件。读完本文你将理解这两个目录的目录结构、与上游版本树的一一对应关系、update-spirv.sh/update-vulkan.sh两个脚本的完整工作原理以及这些头文件在 Halide 的 CMake、Makefile 与源码中如何被真实消费包括src/SpirvIR.h、src/runtime/vulkan.cpp等核心文件从而掌握 Halide 构建 GPU 后端时依赖项从获取到使用的完整链路。一、dependencies目录的定位构建期依赖而非 API 面原文档开篇即给出明确界定This folder contains vendored dependencies for building Halide. They do not form part of the API surface.本文件夹包含用于构建 Halide 的捆绑依赖它们不构成 API 面的一部分。这句话的含义可以拆解为三点用途限定这些头文件只服务于 Halide 的构建编译 Halide 编译器本体及其运行时而不是 Halide 语言对外暴露的编程接口来源固定它们是从 Khronos 官方仓库SPIRV-Headers、Vulkan-Headers固定版本分支同步进来的快照不是 Halide 自研代码非 API 承诺Halide 不承诺这些头文件的稳定性或向后兼容升级依赖时它们可以整体替换。从仓库证据看这一点在.clang-format-ignore中也有呼应——该文件第 19、20 行明确把./dependencies/spirv与./dependencies/vulkan加入格式化忽略名单说明这些第三方头文件不遵循 Halide 自身的代码风格规范属于外部引入、原样保存的内容。二、SPIR-V 目录官方 v1.6 ANSI-C 头文件快照2.1 版本来源与目录结构原文档说明spirv/目录包含官方发布的 SPIR-V v1.6 ANSI-C 头文件取自 KhronosGroup/SPIRV-Headers 仓库的sdk-1.3.231分支。目录结构完全复刻官方版本的 install tree安装树附带上游LICENSE仅剔除 Halide 用不到的文件。对照仓库实际结构dependencies/spirvdependencies/spirv/ ├── LICENSE # 上游 Khronos 许可声明 ├── include/ │ └── spirv/ │ └── unified1/ │ ├── GLSL.std.450.h # GLSL 扩展指令集common intrinsics │ └── spirv.h # SPIR-V v1.6 核心头文件 └── share/ └── cmake/ └── SPIRV-Headers/ ├── SPIRV-HeadersConfig.cmake ├── SPIRV-HeadersConfigVersion.cmake └── SPIRV-HeadersTargets.cmake可见 Halide 只需要unified1下的两个头文件spirv.h 与 GLSL.std.450.h其余如各语言绑定、core/extinst下的其他生成文件均被裁剪这正是文档所说minus files that Halide doesnt need的落地形态。2.2 Halide 编译器如何消费 SPIR-V 头文件这两个头文件并非摆设而是 Halide 的SPIR-V IR 生成模块src/SpirvIR.cpp/src/SpirvIR.h直接依赖的编译期头文件。src/SpirvIR.h 顶部有明确的 include 与注释#include spirv/unified1/GLSL.std.450.h // GLSL extended instructions for common intrinsics #include spirv/unified1/spirv.h // Use v1.6 headers but only use the minimal viable format version (for maximum compatibility)代码注释还透露了关键设计意图虽然使用的是 v1.6 头文件但 Halide 只采用最小可用的 SPIR-V 格式版本以换取最大兼容性即生成的 SPIR-V 二进制尽量兼容更多版本的消费方。在 src/SpirvIR.cpp 中可以看到对 GLSL 扩展指令集的导入调用return import_instruction_set(GLSL.std.450);该指令集编号与常量正是由GLSL.std.450.h提供二者在此建立编译级联系。在构建侧src/CMakeLists.txt 使用 CMake 的find_package在本地 vendored 目录中定位该包并链接find_package(SPIRV-Headers 1.5.5 REQUIRED HINTS ${Halide_SOURCE_DIR}/dependencies/spirv) ... target_link_libraries(Halide PRIVATE $BUILD_LOCAL_INTERFACE:SPIRV-Headers::SPIRV-Headers) target_compile_definitions(Halide PRIVATE WITH_SPIRV)HINTS指定优先从仓库内dependencies/spirv查找WITH_SPIRV宏则在编译期开启 SPIR-V 后端代码路径。测试侧同样依赖它test/correctness/CMakeLists.txt第 705-712 行的correctness_spirv_ir测试目标同样find_package(SPIRV-Headers 1.5.5 ...)并链接SPIRV-Headers::SPIRV-Headers、定义WITH_SPIRV用于校验 Halide 生成的 SPIR-V IR 的正确性。此外顶层 Makefile 也提供了对应的 make 构建路径SPIRV_CXX_FLAGS$(if $(WITH_SPIRV), -DWITH_SPIRV -isystem $(ROOT_DIR)/dependencies/spirv/include, )即通过-isystem将 vendored 头文件目录加入系统 include 路径供编译 SPIR-V 相关源文件使用。三、Vulkan 目录官方 v1.3.296 SDK 头文件快照3.1 版本来源与目录结构原文档说明vulkan/目录包含官方发布的 Vulkan v1.3.296 SDK 头文件取自 KhronosGroup/Vulkan-Headers 仓库的vulkan-sdk-v1.3.296分支同样目录结构与官方安装树一致 附带上游LICENSE.md 裁掉不需要的文件。对照仓库实际结构dependencies/vulkandependencies/vulkan/ ├── LICENSE.md # 上游 Khronos 许可声明 ├── include/ │ ├── vk_video/ # Vulkan 视频编解码扩展头文件 │ │ ├── vulkan_video_codec_av1std.h │ │ ├── vulkan_video_codec_av1std_decode.h │ │ ├── vulkan_video_codec_h264std.h │ │ ├── vulkan_video_codec_h264std_decode.h │ │ ├── vulkan_video_codec_h264std_encode.h │ │ ├── vulkan_video_codec_h265std.h │ │ ├── vulkan_video_codec_h265std_decode.h │ │ ├── vulkan_video_codec_h265std_encode.h │ │ └── vulkan_video_codecs_common.h │ └── vulkan/ │ ├── vk_icd.h # Installable Client Driver 接口 │ ├── vk_layer.h # 验证层接口 │ ├── vk_platform.h # 平台宏与类型基础 │ ├── vulkan.h # 汇总入口包含 vk_platform.h vulkan_core.h │ ├── vulkan_core.h # 核心 API 声明 │ ├── vulkan_beta.h │ └── vulkan_平台.h # android / ios / macos / metal / fuchsia / │ # wayland / win32 / xcb / xlib / directfb / ggp / screen / vi / xlib_xrandr └── share/ └── cmake/ └── VulkanHeaders/ ├── VulkanHeadersConfig.cmake └── VulkanHeadersConfigVersion.cmake头文件之间还存在明确的包含依赖链从 dependencies/vulkan/include/vulkan/vulkan.h 可见#include vk_platform.h #include vulkan_core.h即vulkan.h是面向应用的汇总入口底层由平台定义头与核心 API 头组成vk_layer.h内部也#include vulkan_core.h见 vk_layer.h。3.2 Halide 运行时如何消费 Vulkan 头文件Vulkan 头文件服务于 Halide 的Vulkan GPU 运行时。仓库中对应实现为 src/runtime/vulkan.cpp该文件通过#include HalideRuntimeVulkan.h声明运行时 API并在runtime_api.cpp中注册halide_vulkan_acquire_context、halide_vulkan_release_context、halide_vulkan_initialize_kernels、halide_vulkan_run等设备接口见 src/runtime/runtime_api.cpp这些接口的类型签名全部依赖 vendored 的VkInstance、VkDevice、VkQueue等 Vulkan 类型定义。构建侧src/runtime/CMakeLists.txt 通过find_package(VulkanHeaders 1.3.296 REQUIRED HINTS ...)定位版本精确到1.3.296的头文件包并取出其 include 目录参与运行时编译顶层 Makefile 同样提供VULKAN_CXX_FLAGS$(if $(WITH_VULKAN), -DWITH_VULKAN -isystem $(ROOT_DIR)/dependencies/vulkan/include, )当WITH_VULKAN开启时头文件目录以-isystem方式进入编译命令行。四、一键更新脚本从上游仓库到 vendored 快照的自动化流水线原文档指出update-spirv.sh与update-vulkan.sh会自动获取上游仓库、构建并抽取所需文件且都接收一个参数要 clone 的分支名。4.1 update-spirv.sh 逐行拆解脚本本体见 dependencies/update-spirv.sh核心流程如下#!/bin/bash set -eo pipefail # 任一命令失败即中止 cd -- $(dirname -- $0) || exit 1 # 切换到脚本所在目录即 dependencies/ GIT_BRANCH$1 # 唯一参数要 clone 的上游分支 if [ -z $GIT_BRANCH ]; then echo error: usage: $0 git-branch echo remark: the current git-branch is sdk-1.3.231 exit 1 fi mkdir -p spirv # 目标目录 cleanup() { rm -rf SPIRV-Headers; } # 收尾清理临时 clone trap cleanup SIGINT SIGTERM EXIT # 中断/退出时自动清理 git clone https://github.com/KhronosGroup/SPIRV-Headers.git --branch $GIT_BRANCH cmake -S SPIRV-Headers -B SPIRV-Headers/build \ -DCMAKE_BUILD_TYPERelease -DCMAKE_INSTALL_PREFIX$PWD/SPIRV-Headers/_local cmake --build SPIRV-Headers/build --target install # 拷贝许可声明 cp SPIRV-Headers/LICENSE spirv/ # 拷贝用到的头文件仅 unified1 下的两个 mkdir -p spirv/include/spirv/unified1/ cp SPIRV-Headers/_local/include/spirv/unified1/GLSL.std.450.h spirv/include/spirv/unified1/ cp SPIRV-Headers/_local/include/spirv/unified1/spirv.h spirv/include/spirv/unified1/ # 拷贝 CMake 配置 mkdir -p spirv/share/ cp -R SPIRV-Headers/_local/share/cmake spirv/share/ git add -f spirv/ # 强制将产物纳入 Halide 仓库版本管理 echo Updated SPIRV-Headers to branch $GIT_BRANCH!流程要点归纳步骤行为目的参数校验必须传入分支名无参数时打印用法与当前分支提示sdk-1.3.231并退出安全清理trap ... SIGINT SIGTERM EXIT无论成功失败都删除临时 clone不留构建垃圾源码获取git clone --branch branch按指定分支拉取上游 SPIRV-Headers标准构建cmake -S/-B --target install复用上游官方 CMake 构建体系产出 install tree内容裁剪只拷GLSL.std.450.hspirv.h只保留 Halide 真正需要的两个头文件元数据跟随拷 LICENSE 与 share/cmake许可声明与SPIRV-HeadersConfig*.cmake一并入库保证find_package可用版本入库git add -f spirv/强制提交生成的快照使头文件随 Halide 源码同步分发4.2 update-vulkan.sh 逐行拆解脚本本体见 dependencies/update-vulkan.sh流程与 SPIR-V 版同构#!/bin/bash set -eo pipefail cd -- $(dirname -- $0) || exit 1 GIT_BRANCH$1 if [ -z $GIT_BRANCH ]; then echo error: usage: $0 git-branch echo remark: the current git-branch is vulkan-sdk-1.3.296 exit 1 fi mkdir -p vulkan cleanup() { rm -rf Vulkan-Headers; } trap cleanup SIGINT SIGTERM EXIT git clone https://github.com/KhronosGroup/Vulkan-Headers.git --branch $GIT_BRANCH cmake -S Vulkan-Headers -B Vulkan-Headers/build \ -DCMAKE_BUILD_TYPERelease -DCMAKE_INSTALL_PREFIX$PWD/Vulkan-Headers/_local cmake --build Vulkan-Headers/build --target install # 拷贝许可声明 cp Vulkan-Headers/LICENSE.md vulkan/ # 拷贝需要的头文件仅 ANSI-C 核心接口 mkdir -p vulkan/include/vulkan cp Vulkan-Headers/_local/include/vulkan/*.h vulkan/include/vulkan/ mkdir -p vulkan/include/vk_video cp Vulkan-Headers/_local/include/vk_video/*.h vulkan/include/vk_video/ # 拷贝 CMake 配置 mkdir -p vulkan/share/ cp -R Vulkan-Headers/_local/share/cmake vulkan/share/ git add -f vulkan/ echo Updated Vulkan-Headers to branch $GIT_BRANCH!与 SPIR-V 脚本的关键差异在于裁剪策略Vulkan 头文件数量多、覆盖面广脚本按目录批量拷贝include/vulkan/*.h与include/vk_video/*.h两组 ANSI-C 头文件脚本注释明确写着 only the ANSI-C core interfaces!把 C 绑定、官方示例等其他内容留在上游。这样既满足 Halide 运行时对VkInstance/VkDevice等核心类型与视频扩展类型的需要又不至于把整个上游仓库塞进 Halide。4.3 两个脚本的共性设计单一参数git-branch即要 vendor 的上游分支两个脚本的报错提示都直接给出当前所用分支sdk-1.3.231/vulkan-sdk-1.3.296方便维护者照着填构建即抽取都不手工复制上游源文件而是先跑官方 CMakeinstall目标生成标准 install tree再从中拷贝保证抽取结构与官方分发形态一致许可与 CMake 元数据随行LICENSE/LICENSE.md与share/cmake目录一并入库既满足开源合规又让find_package(SPIRV-Headers ...)、find_package(VulkanHeaders ...)在本仓库内直接可用强制入库git add -f确保这些生成产物成为 Halide 仓库的正式内容构建时无需网络即可拿到头文件。五、从更新脚本到构建系统依赖消费链路一览把脚本产出与构建消费放在一起看整条链路非常清晰update-*.sh拉取上游 → CMake install → 裁剪拷贝 → git add -f │ 产出 ▼ dependencies/spirv/ ──find_package(SPIRV-Headers 1.5.5)──▶ src/CMakeLists.txt dependencies/vulkan/ ──find_package(VulkanHeaders 1.3.296)──▶ src/runtime/CMakeLists.txt │ ▼ 使用 src/SpirvIR.h#include spirv/unified1/spirv.h / GLSL.std.450.h src/SpirvIR.cppimport_instruction_set(GLSL.std.450) src/runtime/vulkan.cpp runtime_api.cppVulkan 设备接口 │ ▼ 验证 test/correctness/CMakeLists.txtcorrectness_spirv_ir 测试目标关键证据位置汇总环节仓库证据头文件快照dependencies/spirv/include/spirv/unified1、dependencies/vulkan/include/vulkanSPIR-V 消费src/SpirvIR.h、src/SpirvIR.cppVulkan 消费src/runtime/vulkan.cpp、src/runtime/runtime_api.cppCMake 集成src/CMakeLists.txt、src/runtime/CMakeLists.txtMake 集成Makefile测试联动test/correctness/CMakeLists.txt格式化豁免.clang-format-ignore许可声明LICENSE.txt六、维护与实操建议基于以上分析对 Halide 依赖目录的日常维护可以归纳出几条实操准则升级依赖时不要手动改头文件内容应执行对应脚本并传新分支名例如./dependencies/update-spirv.sh new-branch如升级到新的 sdk 分支./dependencies/update-vulkan.sh new-branch如升级到新的 vulkan-sdk 分支。 脚本执行后会自动更新头文件、许可声明与 CMake 配置文件并完成git add -f。同步修改版本约束脚本更新到新分支后记得同步核对 src/CMakeLists.txt 中的find_package(SPIRV-Headers 1.5.5 ...)与 src/runtime/CMakeLists.txt 中的find_package(VulkanHeaders 1.3.296 ...)版本要求是否匹配新快照否则find_package的版本校验可能失败。理解裁剪边界spirv/只保留两个 ANSI-C 头文件vulkan/只保留include/vulkan/*.h与include/vk_video/*.h两组 C 头文件若 Halide 未来需要更多扩展头需同步调整脚本的拷贝清单。构建前提使用 CMake 或 make 构建 Halide 并启用 SPIR-V / Vulkan 后端时无需联网下载头文件——vendored 快照已随仓库分发HINTS与-isystem会直接指向仓库内目录版本信息以当前仓库实际内容为准SPIR-V v1.6 / Vulkan v1.3.296。赞分享编译器图像处理编程语言高性能计算【免费下载链接】Halidea language for fast, portable>项目地址https://gitcode.com/gh_mirrors/ha/Halide点击查看免费下载相关推荐uv脚本管理功能详解单文件脚本的依赖管理与执行uv脚本管理功能详解单文件脚本的依赖管理与执行 引言解决单文件脚本的依赖管理痛点 你是否曾经历过以下场景编写了一个简短的Python脚本却因依赖管理问题包管理器开发工具CLI头文件管理终极指南CMake-Examples中的包含目录与依赖解析技术头文件管理终极指南CMake Examples中的包含目录与依赖解析技术 在C/C项目开发中头文件管理是确保代码可维护性和编译效率的关键环节。CMake示例工程教程构建工具Gradle 版本目录更新插件自动化管理依赖版本的利器Gradle 版本目录更新插件自动化管理依赖版本的利器 项目介绍 在软件开发过程中管理各种依赖库和插件的版本是一项繁琐的工作。为此我们引荐一个名为 ve开发工具上一篇如何在生产环境中高效部署Kimi-K2-Thinking-MXFP4-AttnFP85个关键实践指南下一篇gh_mirrors/caf/caffe2模型序列化与加载底层实现详解创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考