Taichi 贡献指南从源码构建、开发环境搭建到 RFC 流程的完整参与手册【免费下载链接】taichiProductive, portable, and performant GPU programming in Python.项目地址: https://gitcode.com/GitHub_Trending/ta/taichi导读本文基于 Taichi 仓库根目录的 CONTRIBUTING.md系统梳理从零参与 Taichi 开发的完整路径开发者如何从源码构建 TaichiC17 Python3、LLVM 10.0.0 依赖、如何通过 welcome contribution 标签与 RFC 机制找到并推进贡献以及仓库中与贡献流程直接对应的 PR / Issue 模板、开发依赖与构建选项。读完本文你将掌握一套可直接上手、可复现的 Taichi 本地开发环境搭建方案以及一套与社区节奏一致的代码贡献与设计讨论流程。1. 贡献总览与参与前提Taichi 是一个面向 Python 的可移植高性能 GPU 编程语言核心代码以 C17 为主Python 侧负责前端语言与用户 API。仓库的 CONTRIBUTING.md 明确要求所有贡献者遵守行为准则并推荐先阅读官方贡献者指南再着手提交 PR。仓库内为贡献流程准备了完整的模板化基础设施PR 模板.github/pull_request_template.md要求填写关联 Issue 编号、Brief Summary由copilot:summary生成与Walkthrough由copilot:walkthrough生成Issue 模板.github/ISSUE_TEMPLATE/包含 bug_report.md、feature_request.md、document.md、question.md 四类议题页配置.github/ISSUE_TEMPLATE/config.yml允许空白议题并挂出「贡献者指南」与「Taichi 论坛」两个外部联系入口CI 校验仓库维护着 ci/scripts/ 下的若干脚本例如 ci_check_pr_title.py 用于校验 PR 标题格式ci_create_pr_card.py 用于创建 PR 卡片从提交环节就保证 PR 信息规范。1.1 新手切入点welcome contributionCONTRIBUTING.md 指出带有welcome contribution标签的 Issue 是新手的最佳起点可以让贡献者快速了解整个工作流程并融入社区。这类 Issue 通常是经过维护者评估、范围清晰、适合外部开发者接手的问题比自行选题更稳妥。1.2 行为准则所有贡献者都需遵循仓库根目录 CODE_OF_CONDUCT.md 中约定的行为准则。这是社区协作的底线要求任何 PR 与 Issue 讨论都应在此框架内进行。2. 开发者安装从源码构建 TaichiCONTRIBUTING.md 强调Taichi 主要由C17 与 Python3开发开发者应从源码构建而不是直接使用 pip 安装的发布版。构建 Taichi 依赖LLVM 10.0.0官方推荐直接使用预编译的 LLVM 库避免自行编译 LLVM 带来的巨大时间成本。下面结合仓库源码给出当前仓库实际对应的构建配置与可复现步骤。2.1 构建系统的技术栈Taichi 的构建链路在仓库中有清晰的落点顶层入口setup.py 基于scikit-build驱动整个构建将 Python 包构建与 CMake 编译统一起来构建后端声明pyproject.toml 的[build-system]声明了setuptools、wheel、numpy、pybind11、cmake、scikit-build与ninja非 Windows 平台作为构建期依赖CMake 主配置CMakeLists.txt 声明cmake_minimum_required(VERSION 3.17)、CMAKE_CXX_STANDARD 17并在构建时读取 version.txt 生成版本号开发依赖清单requirements_dev.txt 列出了cmake、pybind11、scikit-build、ninja、pre-commit、yapf、isort、pylint、coverage、twine、wheel等工具链。注意从 CMakeLists.txt 的警告信息可以看出官方不推荐直接手动运行cmake而应通过setup.py构建否则可能因缺少版本宏等参数引发问题。2.2 LLVM 10.0.0核心外部依赖LLVM 是 Taichi 编译器的关键支撑Taichi 会把 Python 前端代码编译为 LLVM IR再借助 LLVM 工具链生成各后端的机器码。CONTRIBUTING.md 明确指出Taichi 依赖 LLVM 10.0.0并推荐安装官方预编译的 LLVM 库。在 CMakeLists.txt 中可以看到 LLVM 相关的配置逻辑启用TI_WITH_LLVM时会查找clang可执行文件clang-15到clang-7依次探测并检查其版本仓库中记录的最高已测试版本为 clang 15。这意味着即使 LLVM 主版本固定编译器前端的版本要求也存在一定弹性但LLVM 10.0.0 仍是最稳妥的基线。2.3 本地构建的推荐流程结合仓库文件推荐以下源码构建流程准备 Python 环境Python 3.7 及以上setup.py 的分类器与python_requires3.6,4.0均表明支持 3.73.11 的常见版本建议使用虚拟环境或 conda安装 LLVM 10.0.0 预编译库按平台选择官方提供的对应产物安装开发依赖pip install -r requirements_dev.txt其中包含构建所需的cmake、pybind11、scikit-build、ninja等执行构建在仓库根目录运行python setup.py develop或使用pip install -e .的等价路径setup.py会自动生成 CMake 参数并完成 C 扩展taichi_python的编译。2.4 setup.py 支持的构建环境变量setup.py 文件头注释中记录了以下可用的环境变量对调试构建尤其有用环境变量取值作用DEBUG1/ON以Debug构建类型编译 C 扩展RELWITHDEBINFO1/ON以RelWithDebInfo构建类型编译MINSIZEREL1/ON以MinSizeRel构建类型编译TAICHI_CMAKE_ARGSCMake 参数字符串向 C 扩展传递额外的 CMake 参数此外还有平台相关变量Windows 上TAICHI_USE_MSBUILD1会改用Visual Studio 17 2022生成器否则默认 NinjamacOS 上TAICHI_USE_XCODE1会改用 Xcode 生成器macOS arm64 平台还会自动追加-DCMAKE_OSX_ARCHITECTURESarm64并在构建完成后对动态库执行codesign签名见 setup.py 的sign_development_for_apple_m1函数这是 Apple 对 arm64 本地开发构建的强制要求。并发编译线程数由BUILD_NUM_THREADS控制默认使用机器全部 CPU 核数setup.py。2.5 顶层 CMake 的构建开关CMakeLists.txt 中定义了一组可选的构建特性开关贡献者在构建自定义后端或裁剪功能时可以参考CMake 选项默认值说明TI_WITH_PYTHONON构建 Python 语言绑定Android 或作为子模块集成时关闭TI_WITH_C_APION构建 Taichi 运行时 C API 库TI_WITH_STATIC_C_APIOFF构建静态 C API 库目前仅 macOS 支持TI_BUILD_TESTSOFF构建 C 测试引入 googletestTI_BUILD_EXAMPLESON构建 C 示例TI_BUILD_RHI_EXAMPLESOFF构建 RHI统一设备 API示例USE_LLDOFF使用 lld 链接器USE_MOLDOFF使用 mold 链接器TI_WITH_BACKTRACEOFF使用 backward-cpp 输出 C 崩溃堆栈TI_WITH_LTOOFF启用链接时优化目前影响 Windows MSVCTI_WITH_GRAPHVIZOFF生成目标之间的依赖图同时CMakeLists.txt 会优先探测并使用ccache加速重复编译这正是大型 C 项目开发中提升迭代效率的关键配置。3. 开发环境中的代码规范与质量工具贡献代码前建议先配置好仓库配套的代码质量工具链它们全部记录在 requirements_dev.txt 中yapf isortPython 代码格式化与 import 排序pyproject.toml 中[tool.yapf]基于 pep8 风格并关闭嵌套类/定义前的空行pylintPython 静态检查pre-commit提交前自动执行格式化与检查的钩子工具coverage测试覆盖率统计clang-tidyC 侧检查scripts/run_clang_tidy.py 与 CI 脚本 .github/workflows/scripts/check_clang_tidy.sh 提供了现成的运行方式。C 侧还依赖ccache提升增量编译速度见 CMakeLists.txt并可通过TI_WITH_BACKTRACE在开发期获得更友好的崩溃堆栈。此外仓库的misc/目录维护了一批与贡献流程相关的辅助脚本例如 ci_check_pr_title.py 校验 PR 标题是否符合规范、copyright.py 用于版权头检查、count_tags.py 用于标签统计可在提交前本地自查。4. 测试与 CI贡献的验证关卡Taichi 的测试体系分 Python 与 C 两侧贡献代码时应确保对应测试通过Python 测试位于 tests/python/涵盖语言特性、编译器行为、算子、数据结构与 AOT 等大量用例pyproject.toml的[tool.pytest.ini_options]中配置了 pytest 的告警过滤规则C 测试位于 tests/cpp/按analysis、ir、transforms、program、struct、aot等模块组织通过 tests/cpp/cpptests.yaml 与 cmake/TaichiTests.cmake 接入构建需开启TI_BUILD_TESTSCI 流水线仓库的 GitHub Actions 工作流集中在 .github/workflows/其中 testing.yml 与 pull_request.yml 会在 PR 上自动运行构建与测试贡献者可通过 CI 结果确认改动是否引入回归。测试框架本身也值得关注仓库内 tests/python/test_utils.py 提供了断言与参数化等测试工具函数tests/cpp侧则基于 googletest见 CMakeLists.txt。5. RFC 机制Taichi 的设计讨论与决策流程CONTRIBUTING.md 强调对于更复杂、自包含的功能社区使用RFCRequest for Comments机制进行讨论与组织——这类项目往往因复杂度较高尚未形成具体的设计或实施路线图。RFC 文档同时服务于两个目的为社区提供充分的上下文并吸引潜在的积极贡献者参与设计。5.1 RFC 流程的仓库落地仓库在 docs/rfcs/ 目录维护 RFC 文档体系并定义了完整的流程发起前建议先提 Issue简要描述想法建立跟踪线索复制模板从 docs/rfcs/yyyymmdd-rfc-template.md 复制一份填写所有必填章节提交 PR将 RFC 文件放入 PR 中走常规 PR 评审流程审批通过后若此前未提 Issue此时补开一个跟踪工作实施的 Issue把 Issue URL 填入 RFC 的Relevant Issue字段随后合并 PR 并开始编码未通过时可以迭代修改 RFC 后重新请求评审或直接放弃。该流程在 docs/rfcs/20220410-rfc-process.md 中有完整阐述其中还说明了选择日期作为 RFC ID 的考量对照了 Rust 的递增数字 ID 与 TensorFlow 的日期方案。5.2 仓库中的 RFC 实例仓库内已落地的 RFC 文档包括docs/rfcs/20220410-rfc-process.mdRFC 机制本身的流程定义作者为 Ye Kuang日期 2022-04-10docs/rfcs/20220413-aot-for-all-snode.md面向所有 SNode 的 AOT 支持设计docs/rfcs/yyyymmdd-rfc-template.mdRFC 文档模板。从模板与流程文档看一篇标准 RFC 应包含作者、日期、关联 Issue、TL;DR、Background、Goals、Detailed Design、Alternatives、FAQ 等章节其中Detailed Design 是评审的核心。RFC 的价值不仅在于当下决策更在于沉淀为社区的公开技术文档库帮助后来者理解 Taichi 的架构演进历史——这也是 20220410-rfc-process.md 中「作为公共技术文档」目标的体现。6. 贡献流程速查综合 CONTRIBUTING.md 与仓库基础设施一次完整的贡献通常遵循以下路径在 Issues 中寻找带welcome contribution标签的任务或按模板bug / feature / document / question提交新 Issue 并确认需求对复杂功能先按 RFC 模板 起草 RFC 并经 PR 评审通过在本地按第 2 节流程完成源码构建与开发环境配置C17 Python3 LLVM 10.0.0编写或修改代码运行格式化yapf / isort / clang-tidy与测试Python 侧 pytest、C 侧 googletest按 PR 模板 填写关联 Issue 编号、摘要与改动走查提交 PR 并等待 CI 验证根据评审意见迭代最终合并。这条路径既覆盖了从零搭建开发环境的技术细节也完整保留了社区协作的规范流程是参与 Taichi 开发的可靠起点。7. 参考资料CONTRIBUTING.md本文所依据的官方贡献指南setup.py / pyproject.toml构建配置与构建期依赖CMakeLists.txt顶层 CMake 配置与构建开关requirements_dev.txt开发依赖清单docs/rfcs/20220410-rfc-process.mdRFC 流程定义.github/pull_request_template.md 与 .github/ISSUE_TEMPLATE/PR 与 Issue 模板tests/python/ 与 tests/cpp/测试用例组织.github/workflows/CI 工作流【免费下载链接】taichiProductive, portable, and performant GPU programming in Python.项目地址: https://gitcode.com/GitHub_Trending/ta/taichi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Taichi 贡献指南：从源码构建、开发环境搭建到 RFC 流程的完整参与手册
Taichi 贡献指南从源码构建、开发环境搭建到 RFC 流程的完整参与手册【免费下载链接】taichiProductive, portable, and performant GPU programming in Python.项目地址: https://gitcode.com/GitHub_Trending/ta/taichi导读本文基于 Taichi 仓库根目录的 CONTRIBUTING.md系统梳理从零参与 Taichi 开发的完整路径开发者如何从源码构建 TaichiC17 Python3、LLVM 10.0.0 依赖、如何通过 welcome contribution 标签与 RFC 机制找到并推进贡献以及仓库中与贡献流程直接对应的 PR / Issue 模板、开发依赖与构建选项。读完本文你将掌握一套可直接上手、可复现的 Taichi 本地开发环境搭建方案以及一套与社区节奏一致的代码贡献与设计讨论流程。1. 贡献总览与参与前提Taichi 是一个面向 Python 的可移植高性能 GPU 编程语言核心代码以 C17 为主Python 侧负责前端语言与用户 API。仓库的 CONTRIBUTING.md 明确要求所有贡献者遵守行为准则并推荐先阅读官方贡献者指南再着手提交 PR。仓库内为贡献流程准备了完整的模板化基础设施PR 模板.github/pull_request_template.md要求填写关联 Issue 编号、Brief Summary由copilot:summary生成与Walkthrough由copilot:walkthrough生成Issue 模板.github/ISSUE_TEMPLATE/包含 bug_report.md、feature_request.md、document.md、question.md 四类议题页配置.github/ISSUE_TEMPLATE/config.yml允许空白议题并挂出「贡献者指南」与「Taichi 论坛」两个外部联系入口CI 校验仓库维护着 ci/scripts/ 下的若干脚本例如 ci_check_pr_title.py 用于校验 PR 标题格式ci_create_pr_card.py 用于创建 PR 卡片从提交环节就保证 PR 信息规范。1.1 新手切入点welcome contributionCONTRIBUTING.md 指出带有welcome contribution标签的 Issue 是新手的最佳起点可以让贡献者快速了解整个工作流程并融入社区。这类 Issue 通常是经过维护者评估、范围清晰、适合外部开发者接手的问题比自行选题更稳妥。1.2 行为准则所有贡献者都需遵循仓库根目录 CODE_OF_CONDUCT.md 中约定的行为准则。这是社区协作的底线要求任何 PR 与 Issue 讨论都应在此框架内进行。2. 开发者安装从源码构建 TaichiCONTRIBUTING.md 强调Taichi 主要由C17 与 Python3开发开发者应从源码构建而不是直接使用 pip 安装的发布版。构建 Taichi 依赖LLVM 10.0.0官方推荐直接使用预编译的 LLVM 库避免自行编译 LLVM 带来的巨大时间成本。下面结合仓库源码给出当前仓库实际对应的构建配置与可复现步骤。2.1 构建系统的技术栈Taichi 的构建链路在仓库中有清晰的落点顶层入口setup.py 基于scikit-build驱动整个构建将 Python 包构建与 CMake 编译统一起来构建后端声明pyproject.toml 的[build-system]声明了setuptools、wheel、numpy、pybind11、cmake、scikit-build与ninja非 Windows 平台作为构建期依赖CMake 主配置CMakeLists.txt 声明cmake_minimum_required(VERSION 3.17)、CMAKE_CXX_STANDARD 17并在构建时读取 version.txt 生成版本号开发依赖清单requirements_dev.txt 列出了cmake、pybind11、scikit-build、ninja、pre-commit、yapf、isort、pylint、coverage、twine、wheel等工具链。注意从 CMakeLists.txt 的警告信息可以看出官方不推荐直接手动运行cmake而应通过setup.py构建否则可能因缺少版本宏等参数引发问题。2.2 LLVM 10.0.0核心外部依赖LLVM 是 Taichi 编译器的关键支撑Taichi 会把 Python 前端代码编译为 LLVM IR再借助 LLVM 工具链生成各后端的机器码。CONTRIBUTING.md 明确指出Taichi 依赖 LLVM 10.0.0并推荐安装官方预编译的 LLVM 库。在 CMakeLists.txt 中可以看到 LLVM 相关的配置逻辑启用TI_WITH_LLVM时会查找clang可执行文件clang-15到clang-7依次探测并检查其版本仓库中记录的最高已测试版本为 clang 15。这意味着即使 LLVM 主版本固定编译器前端的版本要求也存在一定弹性但LLVM 10.0.0 仍是最稳妥的基线。2.3 本地构建的推荐流程结合仓库文件推荐以下源码构建流程准备 Python 环境Python 3.7 及以上setup.py 的分类器与python_requires3.6,4.0均表明支持 3.73.11 的常见版本建议使用虚拟环境或 conda安装 LLVM 10.0.0 预编译库按平台选择官方提供的对应产物安装开发依赖pip install -r requirements_dev.txt其中包含构建所需的cmake、pybind11、scikit-build、ninja等执行构建在仓库根目录运行python setup.py develop或使用pip install -e .的等价路径setup.py会自动生成 CMake 参数并完成 C 扩展taichi_python的编译。2.4 setup.py 支持的构建环境变量setup.py 文件头注释中记录了以下可用的环境变量对调试构建尤其有用环境变量取值作用DEBUG1/ON以Debug构建类型编译 C 扩展RELWITHDEBINFO1/ON以RelWithDebInfo构建类型编译MINSIZEREL1/ON以MinSizeRel构建类型编译TAICHI_CMAKE_ARGSCMake 参数字符串向 C 扩展传递额外的 CMake 参数此外还有平台相关变量Windows 上TAICHI_USE_MSBUILD1会改用Visual Studio 17 2022生成器否则默认 NinjamacOS 上TAICHI_USE_XCODE1会改用 Xcode 生成器macOS arm64 平台还会自动追加-DCMAKE_OSX_ARCHITECTURESarm64并在构建完成后对动态库执行codesign签名见 setup.py 的sign_development_for_apple_m1函数这是 Apple 对 arm64 本地开发构建的强制要求。并发编译线程数由BUILD_NUM_THREADS控制默认使用机器全部 CPU 核数setup.py。2.5 顶层 CMake 的构建开关CMakeLists.txt 中定义了一组可选的构建特性开关贡献者在构建自定义后端或裁剪功能时可以参考CMake 选项默认值说明TI_WITH_PYTHONON构建 Python 语言绑定Android 或作为子模块集成时关闭TI_WITH_C_APION构建 Taichi 运行时 C API 库TI_WITH_STATIC_C_APIOFF构建静态 C API 库目前仅 macOS 支持TI_BUILD_TESTSOFF构建 C 测试引入 googletestTI_BUILD_EXAMPLESON构建 C 示例TI_BUILD_RHI_EXAMPLESOFF构建 RHI统一设备 API示例USE_LLDOFF使用 lld 链接器USE_MOLDOFF使用 mold 链接器TI_WITH_BACKTRACEOFF使用 backward-cpp 输出 C 崩溃堆栈TI_WITH_LTOOFF启用链接时优化目前影响 Windows MSVCTI_WITH_GRAPHVIZOFF生成目标之间的依赖图同时CMakeLists.txt 会优先探测并使用ccache加速重复编译这正是大型 C 项目开发中提升迭代效率的关键配置。3. 开发环境中的代码规范与质量工具贡献代码前建议先配置好仓库配套的代码质量工具链它们全部记录在 requirements_dev.txt 中yapf isortPython 代码格式化与 import 排序pyproject.toml 中[tool.yapf]基于 pep8 风格并关闭嵌套类/定义前的空行pylintPython 静态检查pre-commit提交前自动执行格式化与检查的钩子工具coverage测试覆盖率统计clang-tidyC 侧检查scripts/run_clang_tidy.py 与 CI 脚本 .github/workflows/scripts/check_clang_tidy.sh 提供了现成的运行方式。C 侧还依赖ccache提升增量编译速度见 CMakeLists.txt并可通过TI_WITH_BACKTRACE在开发期获得更友好的崩溃堆栈。此外仓库的misc/目录维护了一批与贡献流程相关的辅助脚本例如 ci_check_pr_title.py 校验 PR 标题是否符合规范、copyright.py 用于版权头检查、count_tags.py 用于标签统计可在提交前本地自查。4. 测试与 CI贡献的验证关卡Taichi 的测试体系分 Python 与 C 两侧贡献代码时应确保对应测试通过Python 测试位于 tests/python/涵盖语言特性、编译器行为、算子、数据结构与 AOT 等大量用例pyproject.toml的[tool.pytest.ini_options]中配置了 pytest 的告警过滤规则C 测试位于 tests/cpp/按analysis、ir、transforms、program、struct、aot等模块组织通过 tests/cpp/cpptests.yaml 与 cmake/TaichiTests.cmake 接入构建需开启TI_BUILD_TESTSCI 流水线仓库的 GitHub Actions 工作流集中在 .github/workflows/其中 testing.yml 与 pull_request.yml 会在 PR 上自动运行构建与测试贡献者可通过 CI 结果确认改动是否引入回归。测试框架本身也值得关注仓库内 tests/python/test_utils.py 提供了断言与参数化等测试工具函数tests/cpp侧则基于 googletest见 CMakeLists.txt。5. RFC 机制Taichi 的设计讨论与决策流程CONTRIBUTING.md 强调对于更复杂、自包含的功能社区使用RFCRequest for Comments机制进行讨论与组织——这类项目往往因复杂度较高尚未形成具体的设计或实施路线图。RFC 文档同时服务于两个目的为社区提供充分的上下文并吸引潜在的积极贡献者参与设计。5.1 RFC 流程的仓库落地仓库在 docs/rfcs/ 目录维护 RFC 文档体系并定义了完整的流程发起前建议先提 Issue简要描述想法建立跟踪线索复制模板从 docs/rfcs/yyyymmdd-rfc-template.md 复制一份填写所有必填章节提交 PR将 RFC 文件放入 PR 中走常规 PR 评审流程审批通过后若此前未提 Issue此时补开一个跟踪工作实施的 Issue把 Issue URL 填入 RFC 的Relevant Issue字段随后合并 PR 并开始编码未通过时可以迭代修改 RFC 后重新请求评审或直接放弃。该流程在 docs/rfcs/20220410-rfc-process.md 中有完整阐述其中还说明了选择日期作为 RFC ID 的考量对照了 Rust 的递增数字 ID 与 TensorFlow 的日期方案。5.2 仓库中的 RFC 实例仓库内已落地的 RFC 文档包括docs/rfcs/20220410-rfc-process.mdRFC 机制本身的流程定义作者为 Ye Kuang日期 2022-04-10docs/rfcs/20220413-aot-for-all-snode.md面向所有 SNode 的 AOT 支持设计docs/rfcs/yyyymmdd-rfc-template.mdRFC 文档模板。从模板与流程文档看一篇标准 RFC 应包含作者、日期、关联 Issue、TL;DR、Background、Goals、Detailed Design、Alternatives、FAQ 等章节其中Detailed Design 是评审的核心。RFC 的价值不仅在于当下决策更在于沉淀为社区的公开技术文档库帮助后来者理解 Taichi 的架构演进历史——这也是 20220410-rfc-process.md 中「作为公共技术文档」目标的体现。6. 贡献流程速查综合 CONTRIBUTING.md 与仓库基础设施一次完整的贡献通常遵循以下路径在 Issues 中寻找带welcome contribution标签的任务或按模板bug / feature / document / question提交新 Issue 并确认需求对复杂功能先按 RFC 模板 起草 RFC 并经 PR 评审通过在本地按第 2 节流程完成源码构建与开发环境配置C17 Python3 LLVM 10.0.0编写或修改代码运行格式化yapf / isort / clang-tidy与测试Python 侧 pytest、C 侧 googletest按 PR 模板 填写关联 Issue 编号、摘要与改动走查提交 PR 并等待 CI 验证根据评审意见迭代最终合并。这条路径既覆盖了从零搭建开发环境的技术细节也完整保留了社区协作的规范流程是参与 Taichi 开发的可靠起点。7. 参考资料CONTRIBUTING.md本文所依据的官方贡献指南setup.py / pyproject.toml构建配置与构建期依赖CMakeLists.txt顶层 CMake 配置与构建开关requirements_dev.txt开发依赖清单docs/rfcs/20220410-rfc-process.mdRFC 流程定义.github/pull_request_template.md 与 .github/ISSUE_TEMPLATE/PR 与 Issue 模板tests/python/ 与 tests/cpp/测试用例组织.github/workflows/CI 工作流【免费下载链接】taichiProductive, portable, and performant GPU programming in Python.项目地址: https://gitcode.com/GitHub_Trending/ta/taichi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考