1. 项目概述为什么AMD要“另起炉灶”最近在图形计算和开源软件社区里一个话题引起了不小的讨论AMD正在开发一种新的方法用以获取Blender用于GPU加速的标准代码。乍一听这似乎是个纯粹的技术新闻但如果你了解Blender的生态、GPU渲染的格局以及AMD在专业计算领域的长期策略就会明白这背后是一场关于标准、性能和生态话语权的“暗战”。Blender作为全球最知名的开源3D创作套件其Cycles渲染引擎的GPU加速能力直接决定了艺术家和工作室的工作效率。长期以来NVIDIA的CUDA技术凭借其先发优势和成熟的生态几乎是Blender GPU渲染的代名词。OptiX作为NVIDIA的专用光线追踪API更是将这种优势在高端渲染领域发挥到了极致。而AMD尽管其Radeon显卡在硬件规格上不乏亮点但在Blender这类专业应用中的体验却常常因为软件生态的“水土不服”而大打折扣。这种差距并非完全源于硬件算力更多是软件栈和标准支持层面的问题。因此AMD开发新方法去获取Blender的GPU加速标准代码其核心目标非常明确打破CUDA/OptiX在关键开源应用中的事实垄断为自家的GPU特别是CDNA架构的计算卡和RDNA架构的游戏卡铺平一条性能得以完全释放的软件通路。这不仅仅是为了让Blender跑得更快更是一个信号——AMD正试图从底层标准入手重塑高性能计算和内容创作领域的游戏规则。对于开发者、工作室和所有依赖GPU加速的用户来说多一个高性能、开放的选择总归是件好事。2. 核心需求解析AMD面临的“软件墙”是什么要理解AMD为什么需要“新方法”我们得先看看现有的“旧方法”存在哪些瓶颈。在Blender中实现GPU加速渲染尤其是光线追踪这类计算密集型任务主要依赖几条技术路径而每一条对AMD来说都像是一堵需要翻越的“墙”。2.1 现有技术路径的局限第一堵墙是CUDA路径。这是最成熟、优化最深入的路径。Blender的Cycles引擎内置了CUDA后端能够直接调用NVIDIA GPU的流处理器进行光线追踪计算。然而CUDA是NVIDIA的私有技术完全锁定在其硬件上。AMD的GPU根本无法运行CUDA代码。虽然有过像HIPHeterogeneous-Compute Interface for Portability这样的转换工具试图将CUDA代码自动移植到AMD平台但在Blender这样庞大且不断更新的代码库中保持移植代码的性能和功能同步是一个巨大的工程挑战往往导致AMD用户只能使用性能打折扣或功能滞后的版本。第二堵墙是OpenCL路径。这是理论上跨厂商的开放标准。Blender也确实曾长期维护一个OpenCL后端。但问题在于OpenCL在光线追踪这类新兴工作负载上的生态发展缓慢各家厂商的驱动支持和优化水平参差不齐。更关键的是Khronos Group后来推出了更具现代性的Vulkan API并将光线追踪等高级功能纳入其Vulkan Ray Tracing扩展中这导致OpenCL的维护优先级在开源社区中逐渐下降。Blender官方在近年已宣布弃用OpenCL后端这意味着这条“开放”之路实际上已经走不通了。第三堵墙是HIP原生开发。这是AMD力推的移植方案。HIP的语法与CUDA高度相似旨在让开发者能相对轻松地将CUDA代码迁移到AMD平台。理想很丰满但现实是让Blender这样的开源项目将其庞大而复杂的CUDA内核代码库完全重写或移植到HIP需要投入巨大的社区开发资源。这不仅仅是一个技术移植问题更是一个社区协作和持续维护的承诺问题。进展缓慢且充满不确定性。2.2 AMD的真实诉求因此AMD的“新方法”必须解决以下几个核心诉求性能对标新方法实现的性能必须能够与CUDA/OptiX在同等硬件档次下的表现相竞争至少不能有明显代差。这是赢得用户信任的底线。开发与维护效率不能要求Blender开发团队为AMD单独维护一套完全独立的内核代码。理想情况是能有一套机制让同一份“标准”的渲染内核代码可以高效地编译到不同厂商的硬件上运行。拥抱开放标准方法最好基于行业开放标准这样更容易获得开源社区和广大开发者的认同与支持避免陷入另一个“私有技术”的窠臼。未来可扩展性不仅要支持当前的光线追踪还要能顺畅地扩展到未来的硬件特性如更复杂的光线追踪管线、AI降噪等。3. 技术方案探秘“新方法”可能是什么基于以上诉求我们可以推测AMD的“新方法”不太可能是又一个全新的、封闭的API。更大的可能性是它基于或深度整合了现有的、有潜力的开放标准。目前来看最有可能的技术基石是Vulkan及其Vulkan Ray Tracing (VKR)扩展并结合高级的编译器技术。3.1 Vulkan Ray Tracing开放的基石Vulkan是一个低开销、跨平台的图形与计算API。它的Ray Tracing扩展首次在API层面为不同厂商的GPU提供了统一的光线追踪加速功能抽象。这与NVIDIA OptiX这种在驱动层和应用层之间提供完整SDK的方案不同VKR更底层但也更灵活和开放。为什么是Vulkan跨厂商支持AMDRDNA2及以上、NVIDIA图灵及以上、IntelArc的现代GPU都支持Vulkan Ray Tracing。这为“一次编写多处运行”提供了硬件基础。开源生态友好Vulkan本身是Khronos的开放标准其开源驱动如AMD的AMDVLK、RADV和工具链如Vulkan SDK拥有活跃的社区。这与Blender的开源精神契合。与Blender架构的潜在契合点Blender的渲染引擎核心是计算密集型的与图形管线耦合度相对较低。Vulkan强大的计算能力和显式控制特性非常适合用来构建一个高效、可定制的渲染后端。3.2 关键猜想从“标准代码”到“GPU代码”的桥梁仅仅有Vulkan API还不够。Blender Cycles的渲染内核是高度优化的、手写的CUDA代码或为CUDA设计的抽象内核描述。如何将这些“标准代码”转换成高效的Vulkan Ray Tracing管线或计算着色器是最大的技术挑战。这里就需要引入编译器技术的魔法。我推测AMD的“新方法”可能包含一个高级着色器语言编译链。这个链条的工作流程可能是这样的定义中间表示IR首先需要一种与硬件无关的、用于描述光线追踪内核的“标准代码”格式或中间表示。这可能是一种领域特定语言DSL或者是对现有内核代码如基于CUDA语法或特定抽象层的一种规范化描述。实现编译器后端AMD需要开发一个强大的编译器后端将这个“标准代码”的IR针对AMD GPU的硬件架构特别是RDNA2/CDNA的Ray Accelerators光线加速器进行深度优化最终生成高效的Vulkan SPIR-V字节码用于计算着色器和光线追踪着色器。运行时集成在Blender中这个编译器工具链会被集成到构建系统或运行时中。当用户选择AMD GPU渲染时Blender会调用这个工具链将内核的“标准代码”即时JIT编译或预编译为适用于当前AMD显卡的Vulkan着色器并通过Vulkan API提交执行。[Blender Cycles 标准内核代码/DSL] -- [AMD 编译器前端 (解析/优化)] -- [与硬件无关的中间表示 (IR)] -- [AMD 编译器后端 (针对RDNA2/CDNA架构优化)] -- [Vulkan SPIR-V 字节码] -- [Vulkan Runtime (驱动)] -- [AMD GPU 执行]这种方法的好处是巨大的对Blender社区友好理论上Blender核心团队只需要维护一套“标准”的内核代码描述。AMD以及其他厂商负责提供将自己IR编译到各自平台的编译器后端。这大大降低了主代码库的维护负担。性能潜力大编译器可以进行针对特定GPU架构的激进优化比如充分利用AMD GPU的无限缓存Infinity Cache、光线加速器的遍历顺序等从而挖掘最大硬件潜能。符合开放趋势基于Vulkan和开放的编译器技术如LLVM容易吸引更多开发者参与形成生态。注意这只是一个基于技术趋势的合理推测。AMD官方可能将其称为“AMD Render Backend”或类似的名称其具体实现细节如是否基于LLVM、IR的具体形式尚未公开。但核心思想一定是建立一套开放的、基于编译技术的桥梁将渲染内核的抽象描述与自家GPU的硬件优势高效连接起来。4. 实操推演如果我是Blender开发者如何接入假设AMD提供了这样一套工具链我们暂且称之为“AMD Cycles Compiler Backend for Vulkan”简称ACCBV那么作为Blender集成者需要做哪些工作呢这里我根据开源项目集成新后端的常见流程做一个技术推演。4.1 环境准备与代码审视首先需要在开发环境中搭建完整的工具链。获取AMD工具链从AMD官方获取ACCBV的SDK其中应包含编译器可执行文件或库、头文件、链接库、以及详细的API文档和示例代码。分析Blender Cycles代码结构重点研究intern/cycles目录。需要找到设备抽象层device/目录下的device.h,device_*.cpp等。这里定义了Device基类所有后端CUDA、HIP、Metal等都从此派生。内核调用入口Cycles是如何组织并调用其渲染内核kernel的。这些内核目前很可能是以.cuCUDA文件或某种内联形式存在。构建系统CMakeLists.txt文件看新后端如何被编译选项控制、如何链接。4.2 创建新的设备后端接下来在cycles/device/目录下创建新文件例如device_vulkan_amd.h和device_vulkan_amd.cpp实现一个从Device派生的新类比如DeviceVulkanAMD。这个类的核心职责包括初始化与销毁在device_init()中创建Vulkan实例Instance、设备Device、命令池等。关键是要成功检测并启用VK_KHR_ray_tracing_pipeline等必要扩展。内存管理实现mem_alloc(),mem_copy_to(),mem_copy_from(),mem_free()等函数将Cycles的内存请求映射到Vulkan的设备内存VkDeviceMemory和缓冲区VkBuffer操作。这里要特别注意内存类型的选择设备本地、主机可见等以优化性能。内核编译与管线管理这是最核心的部分。需要实现一个load_kernels()或类似函数。在这个函数中遍历Cycles需要的内核列表如path_traceshader_evaluate等。对于每个内核不是去加载预编译的二进制包像CUDA那样而是找到对应的“标准代码”源文件可能是.cl.rtc或一种新的DSL文件。调用ACCBV工具链的API将这些源文件编译成Vulkan SPIR-V模块。使用Vulkan API根据SPIR-V模块创建着色器模块VkShaderModule进而创建光线追踪管线VkRayTracingPipelineKHR或计算管线VkComputePipeline并创建和管理对应的管线布局VkPipelineLayout和描述符集布局VkDescriptorSetLayout。4.3 实现内核启动与参数传递在Device类中会有类似task_run()的函数来启动内核执行。在DeviceVulkanAMD中需要实现它资源绑定根据要执行的内核找到对应的Vulkan管线。然后将Cycles传递过来的参数如渲染缓冲区、场景数据缓冲区、随机数种子等通过vkUpdateDescriptorSets更新到对应的描述符集VkDescriptorSet中。描述符集是Vulkan中着色器访问外部资源缓冲区、图片等的桥梁。命令录制与提交申请一个Vulkan命令缓冲区VkCommandBuffer。开始命令录制。绑定管线vkCmdBindPipeline(cmdBuf, VK_PIPELINE_BIND_POINT_RAY_TRACING_KHR, pipeline)。绑定描述符集vkCmdBindDescriptorSets(...)。分发光线追踪工作使用vkCmdTraceRaysKHR命令并计算正确的派发大小基于渲染图块的分辨率。如果是纯计算内核则使用vkCmdDispatch。结束录制并提交命令缓冲区到队列。同步需要插入适当的屏障VkMemoryBarrier/VkBufferMemoryBarrier以确保内存操作顺序正确并使用栅栏VkFence或信号量VkSemaphore等待任务完成。4.4 集成到构建系统与测试最后需要修改CMake构建脚本添加一个选项例如WITH_CYCLES_DEVICE_VULKAN_AMD。当此选项开启时编译device_vulkan_amd.cpp并链接ACCBV的库和Vulkan SDK的库。在设备枚举代码中通常在device.cpp的device_create函数里将DeviceVulkanAMD添加到可用设备列表中。完成编码后就是漫长的测试和调试阶段。需要准备各种复杂的Blender场景从简单的立方体到包含大量毛发、体积雾、焦散效果的复杂场景对比新后端与CPU、CUDA后端在渲染结果正确性和速度性能上的差异。实操心得在集成这类低级API后端时调试工具至关重要。Vulkan有强大的调试工具链如RenderDoc、Vulkan ConfiguratorLunarG SDK自带。务必学会使用它们来捕获帧、检查管线状态、验证描述符绑定是否正确、查看着色器反汇编。初期90%的问题都会出在资源绑定和同步上。5. 潜在挑战与应对策略这条路听起来很美好但AMD和社区开发者在实际操作中必然会遇到重重挑战。5.1 性能调优的深水区即便代码能跑通达到与CUDA/OptiX媲美的性能才是终极目标。这涉及多个层面的调优着色器编译开销JIT编译在每次启动Blender或切换场景时都可能带来延迟。需要设计高效的缓存机制将编译好的SPIR-V或甚至管线对象序列化到磁盘下次直接加载。内存访问模式AMD GPU如RDNA2与NVIDIA GPU如Ampere的内存架构不同。编译器后端必须生成能够充分利用AMD无限缓存和高速GDDR/GDDR6内存带宽的代码。这可能需要对内核中的数据结构访问模式进行针对性优化。光线遍历效率Vulkan Ray Tracing提供了底层加速结构BLAS/TLAS的构建和遍历接口。如何设置加速结构的构建参数如三角形排序、空间分割策略以最适合AMD光线加速器的工作方式需要大量的实验和数据分析。异步计算与多引擎利用现代GPU有多个计算引擎。如何利用Vulkan的异步计算队列让光线追踪、AI降噪如果也用Vulkan实现、后期处理等任务重叠执行是榨干GPU性能的关键。5.2 与Blender社区协作的复杂性技术问题之外社区协作是另一大挑战。“标准代码”的定义权谁来决定这套中间表示IR或DSL的语法和语义是AMD主导还是由Blender基金会牵头联合各硬件厂商共同制定这需要一个公平开放的治理模式。上游合并的阻力向Blender主分支提交一个全新的、复杂的大型后端代码审查将极其严格。社区会担心增加维护复杂度、引入新依赖、破坏现有功能。AMD需要派出顶尖的工程师不仅代码质量要高还要积极参与社区讨论解答疑虑甚至帮助维护相关代码。功能对等与测试负担新后端必须实现Cycles所有现有功能包括复杂的着色器节点、体积散射、自适应细分等。任何功能的缺失或行为差异都会导致用户场景渲染出错。建立覆盖全面的自动化测试套件并与CI/CD集成是保证长期稳定的前提。5.3 生态建设的长期性即使技术成功集成生态建设也非一日之功。用户接受度艺术家和工作室习惯于CUDA的稳定和速度。新后端在初期难免有bug和性能波动。如何建立用户信任鼓励他们尝试并反馈问题需要时间和成功的案例。驱动稳定性Vulkan驱动尤其是涉及较新的光线追踪扩展其稳定性和性能在不同驱动版本间可能有波动。AMD需要确保其GPU驱动团队与这个项目紧密合作。扩展到其他应用Blender只是一个起点。AMD的最终目标是让这套基于开放标准的方法能被其他渲染器如LuxCoreRender、模拟软件等采纳。这需要证明其技术方案的普适性和优越性。6. 影响与展望如果成功意味着什么如果AMD的这项努力最终成功并被Blender官方接纳为一个稳定、高性能的后端其影响将是深远的。对用户而言最直接的好处是真正的选择自由。在构建或升级工作站时可以基于价格、功耗、显存容量等因素在AMD和NVIDIA的显卡之间进行权衡而无需过分担心在Blender中的性能被“锁死”。激烈的竞争也会倒逼双方提供更好的硬件和驱动。对开发者而言一个基于开放标准Vulkan、模块化编译器后端的渲染架构降低了为不同硬件优化代码的难度。他们可以更专注于渲染算法本身而不是为每种GPU重写底层代码。这有助于创新和实验。对开源生态而言这将是一个巨大的胜利。它证明了一个重要的开源项目可以摆脱对单一厂商私有技术的深度依赖通过开放、协作的方式构建起健康、多元的硬件支持生态。这为其他开源项目如机器学习框架、科学计算软件提供了宝贵的范例。对AMD自身而言这不仅是攻破了一个重要的“软件堡垒”更是其“软件先行”战略的一次关键实践。通过主导或深度参与关键开源项目的基础设施建设AMD能够更早地将硬件特性融入软件生态从而在未来的产品竞争中占据更有利的位置。当然这条路注定漫长且充满挑战。它考验的不仅是AMD的工程技术能力还有其与开源社区协作的智慧、以及长期投入的决心。但无论如何看到有巨头愿意投入资源去推动开源生态的开放与多元化总是一件值得鼓励和期待的事情。作为从业者我会持续关注这个项目的进展并期待有一天能在自己的AMD显卡上毫无妥协地享受Blender带来的创作自由。