编译器图形学编程语言【免费下载链接】slangMaking it easier to work with shaders项目地址https://gitcode.com/GitHub_Trending/sl/slang点击查看免费下载external/glslang-generated/是 Slang 仓库中一类特殊的目录它不属于任何 git 子模块而是由维护脚本在仓库外生成、随后直接提交进 Slang 源码树的“预生成产物”作用是让普通构建无需现场运行 glslang 自带的代码生成器即可编译 glslang。本文以 external/glslang-generated/README.md 为主体结合仓库内的 external/bump-glslang.sh、external/spirv-tools-generated/README.md 与顶层 CMake 配置完整讲解 glslang 在 Slang 中的定位、依赖关系、build_info.h的生成方法以及手动/脚本化更新 glslang 并创建 Slang 专用 glslang 构建工程的两种路径。读完本文你将能独立完成“升级 glslang 依赖 → 重新生成*-generated文件 → 在 Slang 中构建 glslang 共享库”的完整维护流程。glslang 在 Slang 中的角色GLSL 前端与 SPIR-V 工具链Slang 编译器的后端之一需要将着色器编译到 SPIR-V而这条链路中 glslang 承担的是GLSL 前端解析与 SPIR-V 生成的角色。从源码结构看external/README.md将glslang描述为“GLSL front-end and the SPIRV / SPIRV-Tools-opt / SPIRV-Tools-link libraries”它并不是被静态链接进编译器的而是被包装成Slang 专用共享库后由编译器核心在运行时按名称加载包装层位于 source/slang-glslang/slang-glslang.cpp它导出glslang_CompileRequest等一套独立的 C ABIslang-glslang.version-script中登记导出符号并内置 SPIR-V 校验与反汇编接口glslang_validateSPIRV、glslang_disassembleSPIRV等external/README.md中注明该共享库由source/compiler-core通过loadSharedLibrary在运行时加载而非编译期链接。因此glslang 及其依赖 spirv-tools 的版本选择会直接影响 Slang 输出的 SPIR-V 质量与校验行为这也是为什么仓库对它们的版本有着严格的“捆绑式”管理。glslang-generated 目录的定位预生成、已提交、非子模块external/glslang-generated/目录只包含一个实际文件external/glslang-generated/ └── glslang/ └── build_info.h正如 external/glslang-generated/README.md 所说明的Slang 的external/下并非全是子模块。仓库整体上把第三方依赖分成四类见 external/README.mdgit 子模块18 个如glslang、spirv-tools、spirv-headers、vulkan等通过git submodule update --init --recursive获取直接签入的 vendored 头文件如dxc/、stb/、spirv/等预生成并提交的目录即glslang-generated/与spirv-tools-generated/——它们不是Slang 构建过程的产物而是由维护脚本在仓库外生成后提交进源码树这样普通构建无需现场重新生成由 CMake 在配置期拉取的预编译二进制如 DXC、slang-tint 等。其中 glslang 与 spirv-tools 属于子模块而glslang-generated与spirv-tools-generated属于预生成提交两者的边界正是理解这个目录的关键子模块内容会随git submodule update变化引用上游某个具体提交*-generated目录里的文件是固定提交的其内容必须与当前 glslang / spirv-tools 子模块的版本保持一致否则构建出的库会拿到过期的版本信息或 SPIR-V 指令表。external/README.md特别强调这些*-generated/目录是“编译进 glslang / SPIRV-Tools 构建的提交输入committed inputs而不是构建产物”。REUSE.toml中也将 external/glslang-generated/glslang/build_info.h 单独登记为受许可管理的文件。build_info.h 的内容与作用当前仓库中的 external/glslang-generated/glslang/build_info.h 是标准的 glslang 版本头文件核心内容为#define GLSLANG_VERSION_MAJOR 15 #define GLSLANG_VERSION_MINOR 1 #define GLSLANG_VERSION_PATCH 0 #define GLSLANG_VERSION_FLAVOR 并附带一组版本比较宏GLSLANG_VERSION_GREATER_THAN、GLSLANG_VERSION_GREATER_OR_EQUAL_TO、GLSLANG_VERSION_LESS_THAN、GLSLANG_VERSION_LESS_OR_EQUAL_TO供 glslang 源码在编译期判断自身版本能力。也就是说当前仓库实际捆绑的 glslang 为15.1.0无 flavor 后缀。该文件由 glslang 仓库自带的build_info.py脚本从模板生成Slang 将其产物固定提交于此使构建无需执行该生成步骤。依赖关系spirv-headers 与 spirv-tools 的版本捆绑构建 glslang 依赖于两个子模块原文档明确列出external/spirv-headersSPIR-V 规范头文件与语法 JSON见 external/README.md 中对spirv-headers的用途描述供编译器核心与代码生成使用external/spirv-toolsSPIR-V 校验器 / 优化器 / 链接器作为 glslang 构建路径的一部分被构建。从 .gitmodules 可以看到 glslang 子模块指向KhronosGroup/glslang官方上游Slang 维护的 fork 存放于 shader-slang 组织的同名仓库原文档称之为“slangs current version of glslang”。而external/README.md进一步说明spirv-tools子模块带有slang-skip-pin-check true的特殊设置——Slang 经常把上游尚未合并的修复以 PR 形式先 pin 进来因此跳过了常规的分支可达性检查但 SHA 仍会被验证可从 Khronos 官方地址 fetch 到。spirv-tools-generated/目录external/spirv-tools-generated/README.md与 glslang-generated 是同一思路构建 glslang 需要 spirv-tools 的生成文件core_tables_*.inc、generators.inc、build-version.inc、options-pinned.h等但 Slang 并不想完整编译整个 spirv-tools 工具集于是把生成产物提交进仓库。原文档强调了一个关键纪律glslang 依赖 spirv-tools 并指定了精确版本因此spirv-tools 只能与 glslang 一同更新不能单独升级。这也是下面整个更新流程必须“捆绑操作”的根本原因。更新 glslang手动流程适用于任何平台原文档给出了不依赖脚本的手动更新步骤这是理解整个机制的基础。第一步拉取最新代码在子模块目录中拉取最新版本% git pull origin master⚠️ 开始之前务必确认external/spirv-headers、external/spirv-tools与glslang三者的版本互相兼容。由于 spirv-tools 由 glslang 通过known_good.json指定精确版本后文脚本部分会看到混用新旧版本会导致生成表与头文件不匹配的编译错误。第二步生成 build_info.hbuild_info.h是 glslang 构建必需的版本头文件由 glslang 仓库的 Python 脚本生成。假设当前位于 Slang 仓库根目录执行% cd external/glslang % python build_info.py . -i build_info.h.tmpl -o ../glslang-generated/glslang/build_info.h参数含义参数说明.glslang 仓库根目录脚本据此读取 git 版本信息-i build_info.h.tmpl指定版本头文件的 Jinja 模板文件位于 glslang 仓库根目录-o ../glslang-generated/glslang/build_info.h输出路径直接写进 Slang 的预生成目录该命令会读取 glslang 仓库当前提交的版本信息渲染出我们上文看到的GLSLANG_VERSION_MAJOR/MINOR/PATCH等宏。输出文件必须提交进 Slang 源码树因为正常构建流程不会重新执行该生成步骤。第三步配置 spirv-tools 生成文件glslang 依赖 spirv-tools因此接下来需要更新并生成spirv-tools-generated/下的文件。具体操作完整记录在 external/spirv-tools-generated/README.md在external/spirv-tools下创建构建目录如build.vs确保external/spirv-tools/external下有合适版本的 spirv-headers按需克隆 SPIRV-Headers补齐 spirv-tools 的其余依赖effcee、re2、abseil-cpp用 CMake GUI或命令行配置并生成 spirv-tools 工程源码路径指向external/spirv-tools二进制路径指向构建目录编译该工程——一旦常规 C/C 编译开始所需文件即全部生成删除构建目录中的所有.inc与.h文件再将这些文件拷贝进external/spirv-tools-generated/。更新 glslangLinux 一键脚本 bump-glslang.sh在 Linux 上无需手动执行上述三步直接运行仓库提供的 external/bump-glslang.sh 即可Windows/macOS 上也有对应的手动流程或参考extras/update-spirv-tools.sh的 CI 新鲜度检查脚本见 external/README.md。脚本做了什么从脚本源码可以还原出完整的自动流程拉取与合并 glslang从上游默认 KhronosGroup/glslangfetch 指定 ref 并 merge 进当前分支同步 spirv-tools从 glslang 的known_good.json中读取 spirv-tools 的known good提交fetch 并 checkout同步 spirv-headers同样按known_good.json中 spirv-tools 所引用的版本 checkout补齐 spirv-tools 依赖确保effcee、abseil-cpp、re2三个第三方仓库存在并更新到最新这些是 spirv-tools 编译所需见脚本中git clone ... git pull的逻辑重新生成 glslang-generated执行与手动流程完全一致的命令(cd external/glslang python build_info.py . -i build_info.h.tmpl -o external/glslang-generated/glslang/build_info.h)重新生成 spirv-tools-generated用 CMake 配置 spirv-tools仅构建四个生成目标spirv-tools-build-version、core_tables、enum_string_mapping、extinst_tables避免完整编译耗时然后把生成的.inc/.h拷贝进spirv-tools-generated/提交可选地以“external/glslang: old - new”为提交信息将glslang、spirv-tools、spirv-headers两个子模块指针与两个*-generated目录一并提交。脚本还对运行环境有前置检查require_bin需要jq、git、python、cmake全部在PATH中否则直接退出并且要求external/glslang已是 git 仓库若报错先执行git submodule update --init。脚本参数速查参数作用默认值--do-fetch是否真正从上游拉取并合并 glslang / spirv-tools / spirv-headers 的新提交。不指定时--ref/--release/--upstream均不生效脚本只做本地重新生成不拉取--ref commit合并 glslang 的指定 commit 到当前分支refs/heads/main--release tag等价于--ref refs/tags/tag按上游 release 标签更新—--upstream url指定要合并的 glslang 仓库地址KhronosGroup/glslang--do-commit更新完成后自动提交所有相关目录含子模块指针不提交仅打印建议的 commit 命令-h / --help打印使用说明—不传--do-commit时脚本末尾会打印一条可直接复制的git commit命令模板方便人工审阅后再提交。脚本同时会提醒别忘了把external/glslang与external/spirv-tools的新提交推送到 Slang 自己的 fork因为这两个子模块在 .gitmodules 中记录的 URL 是 KhronosGroup 官方仓库Slang 的 fork 地址见原文档说明。创建并构建 Slang 专用 glslang 工程更新完依赖并生成好*-generated文件后还需要把 glslang 构建成 Slang 专用的共享库。原文档指出在正常操作中premake5.lua不会构建 glslang因为它是一个很慢的过程必须显式在 premake 命令行指定。premake 时代原文档记载的流程Visual Studio% premake vs2015 --build-glslangtruegcc 或 clang使用 clang 时追加-ccclang% premake gmake2 --build-glslangtrue生成工程后按常规方式构建即可——Visual Studio 中直接编译Linux 命令行示例% make configrelease_x64 % make configrelease_x86注意这里--build-glslangtrue是关键开关不指定它premake 生成的工程会跳过 glslang 目标从而避免每次全量构建都等待慢速的 glslang 编译。CMake 时代的对应配置当前仓库需要说明的是当前仓库已从 premake 迁移到 CMake仓库根目录存在 CMakeLists.txt 与CMakePresets.jsonexternal/README.md明确指出依赖的“权威事实来源”是各 CMakeLists 与 .gitmodules。与--build-glslangtrue对应的现代 CMake 选项包括CMake 选项默认值作用SLANG_ENABLE_SLANG_GLSLANGON启用 glslang 依赖与slang-glslang包装目标见 CMakeLists.txt 中的option()声明SLANG_USE_SYSTEM_GLSLANGOFF改为使用系统安装的 glslang此时通过find_package(glslang REQUIRED)查找见 CMakeLists.txtSLANG_OVERRIDE_GLSLANG_PATH—覆盖 glslang 源码路径SLANG_USE_SYSTEM_SPIRV_TOOLSOFF是否使用系统 spirv-toolsglslang 路径内构建时默认使用仓库内子模块SLANG_ENABLE_SPIRV_TOOLS_MIMALLOC平台相关是否让 spirv-tools 使用 Slang 共享的 mimalloc 分配器从 CMakeLists.txt 还可以看到glslang 相关的许可文件glslang/LICENSE.txt、spirv-tools/LICENSE会在满足构建条件时被安装到third-party-notices目录确保二进制再分发符合各依赖的开源许可要求glslang 为 BSD-3-Clause / BSD-2-Clause / MIT / Apache-2.0 混合许可。构建产物运行时加载的 slang-glslang 共享库最终产物是 Slang 专用的 glslang 共享库slang-glslang。其消费方式值得再次强调依据 external/README.md 与 source/slang-glslang/slang-glslang.cpp它由source/compiler-core在运行时按名称加载loadSharedLibrary而非编译期链接进slang-compiler对外暴露的是slang-glslang.cpp中定义的glslang_*C ABI如glslang_CompileRequest、glslang_validateSPIRV、glslang_disassembleSPIRV并通过slang-glslang.version-script控制 ELF/macOS 导出符号。这意味着无论你通过 premake--build-glslangtrue还是 CMakeSLANG_ENABLE_SLANG_GLSLANGON构建只要该共享库存在并能被编译器核心在运行时找到Slang 的 GLSL/SPIR-V 路径即可正常工作。这也是为什么维护者愿意把build_info.h与 spirv-tools 的表文件“预生成提交”进仓库——它把一条本应依赖网络、Python、CMake 与上游子模块状态的生成链压缩成了开箱即用的固定输入显著降低了普通开发者和 CI 的构建复杂度。维护要点速记捆绑更新glslang、spirv-tools、spirv-headers 必须按 glslang 的known_good.json一起更新禁止单独升级 spirv-tools预生成目录是提交输入external/glslang-generated/glslang/build_info.h与external/spirv-tools-generated/*.inc|*.h更新后必须提交进仓库它们不是构建产物脚本优于手动Linux 上用external/bump-glslang.sh先--do-fetch拉新、必要时--ref/--release指定版本、--do-commit自动提交可一键完成“更新 重新生成 提交”手动流程在任何平台均可参考 external/glslang-generated/README.md 与 external/spirv-tools-generated/README.md显式启用 glslang 构建premake 下必须--build-glslangtrueCMake 下对应SLANG_ENABLE_SLANG_GLSLANGON避免每次全量构建都被慢速的 glslang 拖慢版本一致性当前仓库捆绑的 glslang 版本为 15.1.0见 external/glslang-generated/glslang/build_info.h升级时应以该文件的新内容为准核对构建结果。赞分享编译器图形学编程语言【免费下载链接】slangMaking it easier to work with shaders项目地址https://gitcode.com/GitHub_Trending/sl/slang点击查看免费下载相关推荐【亲测免费】 探索GPU编程的新里程KhronosGroup的glslang项目探索GPU编程的新里程KhronosGroup的glslang项目 项目简介 是一个开源项目由Khronos Group维护主要为OpenGL和Vulka编译器图形学上一篇拯救学习记录Hugging Face Agents Course数据导出全攻略下一篇如何永久保存微信聊天记录免费开源工具WeChatMsg让你的数字记忆永不丢失创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考