Chapter 148: GPU Hardware Roadmap

本章讨论 GPU 硬件路线图对图形工程的影响。读完本章后，读者应能把一项硬件发布信息拆成可验证的图形管线能力，判断它会改变哪个 pass、哪类 shader、哪种 buffer 或 texture、哪段同步路径，并据此设计 feature tier、fallback 和测试矩阵。

贯穿材料是一套面向未来三年的实时渲染器：基础路径使用 raster pass 渲染场景，几何阶段可切换 meshlet 管线，阴影和反射可切换 ray tracing，后处理阶段可接入 neural upscaler / denoiser，最终还要支持视频录制、HDR display output 和异步资源上传。这个 frame 的目标是 4K、60 到 120 FPS、稳定 frame pacing。GPU 硬件路线图对它的影响，体现在 shader core、RT core、tensor / AI unit、memory hierarchy、chiplet、power limit、copy engine、display engine 和 API 生态共同形成的约束。

这里的“路线图”不是对某个厂商下一代产品做预测。它是工程判断方式：先把硬件变化映射到管线阶段，再判断 API 是否暴露能力，接着检查驱动、工具、引擎和内容资产是否能跟上，最后用测试矩阵验证视觉结果和性能结果。NVIDIA Blackwell、AMD RDNA 4、DirectX 12 Work Graphs、Vulkan 1.4 等公开资料可以作为观察样本，但结论要回到跨平台渲染器的能力设计。

148.1 GPU 硬件未来架构趋势回顾

GPU 架构的长期方向可以概括为一条主线：可编程 shader core 继续负责通用图形工作，专用单元负责可被硬件固定加速的高价值路径，memory hierarchy 和 power limit 决定这些单元能否持续发挥作用。在贯穿 frame 中，vertex / mesh work、material shading、compute culling、post process 仍然依赖 shader core；ray traversal、matrix inference、video encode、display scanout、copy transfer 则更适合由专用单元承担。

shader core 是图形管线的基础执行资源。它运行 vertex shader、pixel shader、compute shader、mesh shader、work graph node shader，也运行许多后处理和 GPU-driven 任务。未来 shader core 的变化通常体现在 wave 执行效率、寄存器容量、调度能力、cache 访问、低精度数据类型和跨 stage 的数据流。对渲染器来说，shader core 增强的直接意义是让更多工作留在 GPU 上完成，例如 cluster culling、material classification、tile lighting、visibility buffer resolve 和 temporal history filtering。

RT core 或 ray tracing accelerator 的价值在于把 ray traversal 和 triangle / box intersection 从普通 shader ALU 中分离出来。贯穿 frame 的 ray traced shadow pass 需要读取 TLAS / BLAS，发射 shadow ray，得到遮挡结果，再回到 lighting pass。RT 单元增强后，最先受益的是 traversal-heavy workload，例如大量短 shadow ray、反射中的 hit 查询、全局光照中的低 sample count path。工程判断要同时看 ray budget、acceleration structure build / update 成本、denoiser 成本和 memory traffic。只看“RT 性能提升倍数”会漏掉 pipeline 中的其他瓶颈。

AI unit 或 tensor unit 的图形意义逐渐从离线工具转向实时 frame 内路径。neural upscaling、ray denoising、frame generation、neural texture compression、neural material evaluation 都会把 feature buffer、motion vector、depth、normal、roughness、history color 等输入送入模型。这里的关键问题是输入输出 buffer 如何组织、模型运行在哪个 queue、推理延迟是否进入 critical path、低精度格式是否影响质量。NVIDIA RTX 50 系列与 AMD RDNA 4 的公开信息都把 AI 加速放进图形叙事中，这说明未来渲染器需要把 ML inference 当作可选图形 pass 管理。

memory hierarchy 决定数据是否能以足够低的代价到达执行单元。4K frame 中，G-buffer、shadow map、reflection history、acceleration structure、material buffer、texture array、motion vector 和 temporal history 会同时占用显存带宽。更大的 L2 / L3 cache、更高带宽的 GDDR / HBM、更好的压缩、更细粒度的 cache residency，会改变算法取舍。meshlet 和 visibility buffer 偏向压缩几何与延迟材质读取；ray tracing 偏向高随机访问；neural pass 偏向连续张量读取。硬件路线图中任何“带宽提升”都要回到这些访问模式上解释。

chiplet 会让 GPU 从单一大 die 转向多个功能块或多个计算 chip 的组合。对图形工程来说，chiplet 的可见影响通常不是“应用直接选择某个 chip”，而是跨 die 通信延迟、cache 一致性、显存分区、tile locality 和功耗分布。一个 GPU-driven renderer 如果把可见性、材质分类和 ray query 全部打散到随机内存访问，就可能放大跨分区数据移动。兼容未来 chiplet GPU 的稳定做法是提高数据局部性：meshlet、material table、light list、instance data 和 acceleration structure update 都应按空间或可见性分组。

power limit 是未来 GPU 路线图中最容易被低估的约束。桌面高端 GPU、移动 GPU、主机 APU、XR SoC 和云端 GPU 的功耗边界差异巨大。同一个 neural upscaler 在桌面 GPU 上可能隐藏在 async compute 中，在移动 SoC 上可能压缩主渲染预算，在云端可能受并发密度限制。路线图里的“峰值 TOPS”或“峰值 TFLOPS”只能说明上限，工程判断要看持续频率、显存功耗、display output、video encode、CPU / GPU 共享功耗和散热策略。

用贯穿 frame 做一次趋势映射，可以得到一个稳定顺序：先看 frame 的主要耗时来自 shader、RT、AI、memory、copy、display 还是 CPU submission；再看硬件路线图中哪类单元对应这个瓶颈；接着看 API 和驱动是否暴露能力；最后用 frame capture 验证 bottleneck 是否转移。这个顺序把“未来架构趋势”变成可执行判断，防止把硬件名词堆成结论。

148.2 专用加速单元与异构计算能力

专用加速单元的核心作用是把重复度高、硬件结构稳定、数据路径可预测的工作从通用 shader core 中分离。图形管线中的专用单元包括 RT、AI、video、display、copy engine，也包括能与 graphics queue 并行的 async compute。它们共同服务 frame，但每个单元的输入、输出和同步边界不同。

下面的图把贯穿 frame 中的主要执行单元放到一条 frame 路径中。图的目的不是表达固定实现，而是帮助判断某个硬件能力改变了哪段路径。

RT 单元服务的是 ray query、ray tracing pipeline、inline ray tracing 和 acceleration structure traversal。它的输入通常是 TLAS / BLAS、ray origin / direction、mask、payload 和 shader table；输出是 hit / miss 信息、attribute、instance id 和后续 shading 所需数据。RT 单元越强，renderer 越能把 shadow、reflection、ambient occlusion、GI probe update 放到实时路径中。但 acceleration structure build、compaction、update、memory residency 和 denoising 仍然要消耗 GPU 时间。一个成熟 renderer 会把 ray tracing feature 拆成 tier：hard shadow、soft shadow、reflection、hybrid GI、path tracing preview，各 tier 对 ray count、resolution、denoiser 和 fallback 有不同配置。

AI 单元服务的是 matrix-heavy inference。它的输入来自图形管线生成的 feature buffer，输出通常是 upscaled color、denoised lighting、generated frame、material parameter 或压缩纹理解码结果。AI pass 的工程边界包括模型格式、精度、tensor layout、temporal history、motion vector 质量和 queue 调度。AI 单元强大时，渲染器可以用较低内部渲染分辨率换取高输出分辨率，也可以把 ray tracing 的低 sample 输入恢复成稳定图像。AI 单元受限时，fallback 可以切到传统 TAAU、FSR 类空间 / 时间重建、compute denoiser 或较低质量模式。

video engine 和 display engine 经常被误认为只影响多媒体。它们在现代图形应用中直接决定 capture、streaming、cloud rendering、HDR 输出、VRR、high refresh、multi-monitor 和 XR compositor 的可用性。贯穿 frame 如果要同时渲染、录制和投屏，就要确认 encoder 支持的 codec、bit depth、chroma format、分辨率、并发 session、copy path 和 color conversion。display engine 还决定 HDR metadata、DisplayPort / HDMI 带宽、DSC、刷新率和 latency path。图形引擎的能力表应把 video / display 独立列出，不能把它们塞进“GPU 性能”一个字段。

copy engine 负责资源上传、readback、texture streaming、acceleration structure compaction copy 和跨 queue 数据移动。它能把 CPU 提交与 GPU 资源传输解耦，但正确性依赖 fence、barrier、resource state 和 residency 管理。未来 GPU 的 copy / DMA 能力越强，texture streaming、virtual texture、meshlet streaming 和 remote rendering 越容易做到稳定 frame pacing。工程上要把 upload budget 纳入 frame graph：每帧允许多少 MB 上传、哪些资源允许延迟生效、哪些 pass 读取刚上传资源、哪些 readback 会打断 GPU pipeline。

async compute 是异构执行能力在图形队列中的常见入口。它适合运行与 graphics queue 数据依赖较弱的 compute pass，例如 light culling、particle simulation、post process、denoising、histogram、occlusion resolve。它的收益来自重叠执行，前提是 graphics queue 留有可利用空隙，compute pass 的资源访问不会制造额外同步。对贯穿 frame 来说，ray denoiser 或 upscaler 如果要放进 async compute，就要检查输入 buffer 的 ready time、输出 buffer 的消费时间、UAV barrier、queue ownership 和 profiler 中的 overlap 区间。

专用单元的统一判断顺序是：先确定它接收什么资源，再确定它输出什么资源，接着确定它与 graphics / compute queue 的同步点，最后用工具观察它是否缩短 critical path。这个顺序比“开启某个新特性”更稳定，因为未来硬件会增加新单元，但所有单元都必须通过资源、queue 和同步进入 frame。

148.3 为未来架构做兼容设计

兼容未来 GPU 的核心是把硬件能力设计成可查询、可组合、可降级、可测试的 feature system。渲染器不应把“某代 GPU 名称”写死成渲染路径选择条件；更稳的方式是查询 API capability、driver extension、shader model、resource limit、format support、queue support、memory budget 和厂商推荐路径，再把结果映射到 renderer 自己定义的 capability tier。

feature detection 是第一层。D3D12、Vulkan、Metal、WebGPU 都提供不同形式的能力查询，但字段粒度和命名差异很大。D3D12 关注 feature options、shader model、raytracing tier、mesh shader tier、work graph 支持和 resource binding；Vulkan 通过 feature struct、extension、limits、format properties 暴露能力；Metal 通过 GPU family、feature set、argument buffer、ray tracing、function specialization 和 resource limit 表达能力；WebGPU 则通过 adapter features / limits 给出更保守的跨平台集合。backend abstraction 的职责是把这些差异收敛成引擎内部稳定字段。

能力表可以采用分层结构。下面这个表以贯穿 frame 为例，展示 renderer 内部 tier 如何从硬件能力映射到渲染路径。

能力域	Tier 0	Tier 1	Tier 2	需要验证的证据
几何提交	vertex / index draw	GPU culling + indirect draw	mesh shader / meshlet path	draw call 数量、culling cost、meshlet occupancy
Ray tracing	raster shadow fallback	ray traced hard shadow	reflection / GI hybrid	TLAS / BLAS build time、ray time、denoiser time
Neural pass	TAAU / compute denoiser	vendor upscaler	neural denoiser + upscaler + frame generation	model latency、motion vector 质量、temporal artifact
Memory	static texture set	streaming texture / virtual texture	neural compression / residency feedback	upload budget、cache miss、VRAM pressure
Presentation	SDR 60 FPS	HDR / VRR / high refresh	multi-display / XR compositor / cloud encode	scanout format、encode latency、frame pacing

fallback 设计要保留视觉目标，并允许同一目标由不同算法实现。ray traced reflection 的 fallback 可以是 screen-space reflection、reflection probe、planar reflection 或材质 roughness 降级；neural upscaler 的 fallback 可以是 TAAU、spatial upscaler 或内部渲染分辨率调整；mesh shader 的 fallback 可以是 compute culling + indirect draw 或 CPU culling + indexed draw。这样设计后，新硬件出现时只需要给某个能力域增加 tier，旧硬件仍然走稳定路径。

backend abstraction 要把 API 对象生命周期纳入设计。未来架构常见变化包括新的 shader stage、新的 pipeline state 表达、新的 descriptor / binding 模型、新的 queue 类型、新的 memory heap 和新的 synchronization primitive。抽象层需要封装资源状态、pipeline layout、shader permutation、barrier、descriptor lifetime 和 command recording 规则，函数名封装只是其中一层。一个好的抽象层会让 frame graph 说清“这个 pass 读哪些资源、写哪些资源、需要什么能力、允许哪些 fallback”，backend 再把它翻译到 D3D12 / Vulkan / Metal / WebGPU。

测试矩阵是兼容设计的落地环节。它至少要覆盖 API backend、GPU vendor、driver branch、OS、显示模式、resolution、quality tier、feature combination 和 fallback path。贯穿 frame 的测试矩阵可以这样组织：基础 raster path 必须覆盖所有平台；meshlet path 覆盖支持 mesh shader 或等价路径的平台；ray traced shadow 覆盖 RT tier；neural upscaler 覆盖支持模型运行的 GPU；video capture 覆盖 encoder；HDR output 覆盖 display engine。每一项都要记录视觉结果、GPU time、VRAM、queue overlap、frame pacing 和 artifact。

兼容未来架构还需要一组“默认保守配置”。新硬件发布初期，驱动和工具支持可能处在快速变化中。引擎可以先把新 feature 放到实验 tier，要求通过自动化画面对比、性能阈值、稳定性测试和用户可配置开关后再进入默认 tier。这样处理能让引擎吸收新硬件能力，同时保持内容生产和发布质量稳定。

148.4 与图形学算法协同的进展

硬件路线图会改变图形算法的形态。mesh shading、work graph、ray tracing、neural rendering 和 GPU-driven pipeline 都说明同一件事：现代图形算法正在从 CPU 组织 draw call、GPU 被动执行，转向 GPU 自己分类、生成、调度和重建 frame。贯穿 frame 中，CPU 仍然负责高层场景提交和资源管理，但更多细粒度决策会移动到 GPU。

mesh shading 把传统 vertex / geometry pipeline 的固定输入模型改成以 meshlet 为单位组织几何。meshlet 是一小组局部三角形和顶点，适合做 cluster culling、LOD selection、compaction 和局部数据缓存。硬件支持 mesh shader 时，GPU 可以在 mesh stage 内生成 primitive；硬件缺少该路径时，引擎可以用 compute shader 做 culling，再用 indirect draw 提交可见 batch。mesh shading 的算法协同点在于数据布局：模型导入阶段要生成 meshlet，runtime 要维护 bounding data、LOD、material id 和 streaming block。

Work Graphs 代表另一种协同方向：让 GPU 上的 producer shader 请求 consumer shader 执行，从而减少 CPU 对细粒度工作扩展的控制。Microsoft 在 D3D12 Work Graphs 中把它描述为 GPU autonomy 的系统，适合 producer-consumer pipeline、动态工作扩展和减少中间 pass 出入显存。对贯穿 frame 来说，材质分类、tile binning、light list 构建、粒子分裂、procedural geometry、visibility-driven shading 都可能从这种模型受益。工程边界是 node 数据大小、递归 / 深度限制、同步模型、工具可见性和 fallback 路径。

ray tracing 与算法协同的重点已经从“能否发射 ray”转向“如何控制 ray budget 并稳定重建结果”。硬件 traversal 提升后，算法会把 ray 用在最有视觉收益的位置：主光源 shadow、roughness 受控的 reflection、probe update、path traced reference、局部 GI 修正。与之配套的是 reservoir sampling、temporal reuse、spatial reuse、denoiser 和 history validation。一个实时 renderer 很少把所有光照都交给完整 path tracing；它会根据材质、距离、运动、噪声和性能预算组合 raster、ray 和 neural pass。

neural rendering 让算法从“手写滤波器”转向“训练得到的重建函数”。它改变的不是最终画面接口，仍然输入 depth、normal、motion vector、color history 等资源并输出 color buffer；它改变的是中间映射方式。工程上要把 neural pass 当作 shader pass 管理：固定输入语义、固定输出 format、记录模型版本、记录训练数据假设、提供 deterministic test scene、监控 ghosting、shimmering、over-sharpening 和 latency。AI 单元强时，neural pass 可以进入默认质量档；AI 单元不足时，传统 temporal reconstruction 仍然要保留。

GPU-driven pipeline 把场景可见性、LOD、draw compaction、material sorting 和部分调度放到 GPU 上。它与未来硬件的协同点是减少 CPU submission pressure，提高细粒度 culling，利用 GPU 上已有的 visibility 数据。但 GPU-driven 也会增加调试难度：draw call 不再直接对应 CPU 侧对象，错误可能来自 append buffer、counter、indirect argument、barrier、resource aliasing 或 shader divergence。引擎要在 GPU-driven 路径中保留 debug buffer、可视化 pass、counter readback 和 deterministic capture 模式。

这些算法的共同趋势是把 frame 组织成数据流。CPU 提供 scene metadata 和资源边界，GPU 在 frame 内执行分类、生成、追踪、推理、重建和输出。硬件路线图的价值因此不在于某个单元名称，而在于它让哪段数据流更短、哪段同步更少、哪类中间数据更靠近 cache、哪种视觉结果能在预算内稳定出现。

148.5 生态系统与平台支持演化

硬件能力只有进入 API、驱动、工具、引擎和内容制作链后，才会变成可交付的图形能力。生态系统演化的节奏通常慢于硬件发布：厂商先发布硬件和示例，API 增加 feature 或 extension，驱动开放支持，工具能 capture / profile，主流引擎接入，内容团队建立资产规范，最后用户在游戏、DCC、XR 或云端应用中看到稳定效果。

API 是硬件能力进入工程的第一道边界。DirectX 通过 Agility SDK、Shader Model、DXR、Mesh Shader、Work Graphs 等机制把 Windows 图形能力向应用暴露；Vulkan 通过 core version、extension 和 feature chain 暴露跨厂商能力；Metal 通过 Apple 平台的 GPU family 和 framework 集成暴露能力；WebGPU 提供更保守的跨平台抽象。一个跨平台 renderer 要把 API 支持视为能力证据之一，但还要结合驱动版本、工具支持和实际性能。

驱动决定 feature 是否稳定、性能是否可预期、同步语义是否可靠。未来硬件早期常见问题包括 shader compiler bug、pipeline cache 行为变化、extension 支持不完整、capture 工具无法解析新对象、某些格式组合性能异常。工程上应为新 feature 设置 driver allowlist / denylist、收集 crash signature、记录 shader hash、保存 pipeline cache 版本，并在运行时允许回退到保守路径。

工具决定开发者能否定位问题。RenderDoc、PIX、Nsight、Radeon GPU Profiler、Xcode GPU tools 等工具分别回答 draw state、resource binding、shader cost、queue overlap、cache / bandwidth、RT acceleration structure、counter、stall 等问题。新硬件单元出现后，如果工具无法显示对应事件，调试会退回黑盒猜测。引擎应提供自有 telemetry：每个 pass 的 GPU time、输入输出资源大小、queue、barrier、分辨率、feature tier、模型版本、ray count 和 memory budget 都要可记录。

引擎决定硬件能力是否能被内容团队使用。Unreal、Unity、自研引擎和 DCC renderer 对硬件能力的封装方式不同。内容团队不应直接面对“第几代 RT core”或“某个 tensor 格式”，他们需要面对可制作的质量档：阴影半径、反射距离、GI 更新频率、材质模型、贴图压缩、LOD 策略、后处理质量、输出分辨率和平台目标。引擎要把硬件 feature 转译成 artist-friendly 预算，同时在 build pipeline 中生成所需 meshlet、BVH-friendly geometry、motion vector、feature buffer 和 model asset。

平台支持还包括主机、移动、XR、云端和浏览器。主机平台强调固定硬件下的长期优化；移动和 XR 强调功耗、热预算、低延迟和 foveated rendering；云端强调 encoder、网络、并发密度和区域部署；浏览器强调安全沙箱、保守 feature set 和跨设备一致性。未来 GPU 路线图对这些平台的影响并不相同。同一项 neural upscaling，在主机上可能成为默认输出路径，在移动端可能只用于高质量模式，在云端可能受 encoder latency 限制，在浏览器中可能暂时缺少 API 暴露。

评价生态成熟度可以使用五个问题：API 是否能查询并创建对象；驱动是否在目标设备上稳定；工具是否能 capture 和 profile；引擎是否能提供 fallback、资产规范和质量档；内容是否能在目标平台上通过自动化测试。五个问题都得到证据后，硬件路线图中的能力才进入正式产品路径。缺少其中任何一环，都应把该能力放入实验路径或可选路径。

回到贯穿 frame，GPU Hardware Roadmap 最终转化为一张工程地图：shader core 决定通用 pass 的基础吞吐，RT 单元决定 ray budget，AI 单元决定 neural reconstruction 是否进入 critical path，memory hierarchy 决定数据布局，copy / video / display engine 决定 streaming 和输出，API / driver / tool / engine / content 共同决定交付时机。读者面对未来 GPU 发布时，应先完成这张映射，再决定引擎是否接入新能力。

最小自检任务

假设你正在维护一个跨平台实时渲染器，目标 frame 包含 meshlet 几何、ray traced shadow、neural upscaler、HDR 输出和视频录制。现在出现一代新 GPU：官方资料强调更强 RT 单元、更高 AI TOPS、更大 cache、新 display engine 和改进的 copy engine。请设计一份最小兼容方案，说明你会如何把这些硬件信息映射到 feature tier、fallback、测试矩阵和工具证据。

答案要点

先把硬件信息拆到管线阶段。更强 RT 单元对应 ray traced shadow / reflection 的 ray budget 和 acceleration structure 路径；更高 AI TOPS 对应 neural upscaler / denoiser 的模型延迟和输入输出 buffer；更大 cache 对应 meshlet、material buffer、texture streaming、ray tracing acceleration structure 的局部性；display engine 对应 HDR、VRR、高刷新和 scanout format；copy engine 对应 texture / meshlet streaming、readback、capture 和资源上传。

接着设计 renderer 内部 capability tier。基础 tier 使用 raster shadow、传统 TAAU、vertex / index draw、SDR 或普通 HDR 输出；中间 tier 开启 meshlet culling、ray traced hard shadow、传统 compute denoiser、HDR / VRR；高 tier 开启更高 ray budget、neural upscaler、neural denoiser、视频录制并行和更高刷新输出。每个 tier 都要由 API capability、driver version、format support、queue support、memory budget 和自动化测试共同决定。

然后安排 fallback。ray traced shadow 的 fallback 可以回到 shadow map 或 hybrid shadow；neural upscaler 的 fallback 可以回到 TAAU 或空间 / 时间重建；meshlet 几何的 fallback 可以回到 compute culling + indirect draw 或 CPU culling；HDR / video 的 fallback 可以降低格式、刷新率、录制分辨率或关闭并发录制。fallback 的目标是保持 frame 可交付，并让质量下降可控。

最后建立测试矩阵和工具证据。矩阵覆盖 API backend、GPU vendor、driver、OS、resolution、quality tier、HDR / SDR、录制开关、ray tracing 开关、neural pass 开关。工具证据包括每个 pass 的 GPU time、queue overlap、barrier、TLAS / BLAS build time、ray dispatch time、model latency、VRAM、upload budget、encoder latency、present timing 和画面对比。只有当高 tier 的视觉结果和 frame pacing 都稳定时，新硬件能力才进入默认路径。

本章知识点总结

• 路线图读法：GPU 硬件路线图应先映射到 frame、pass、资源、queue 和同步点，再进入工程决策。
• Shader core：shader core 继续承担通用图形工作，mesh、compute、material、post process 和 GPU-driven 任务都依赖它。
• RT 单元：RT 单元主要缩短 ray traversal 和 intersection 路径，但最终收益还受 acceleration structure、denoiser 和 memory traffic 约束。
• AI 单元：AI 单元让 neural upscaling、denoising、frame generation 和 neural material 进入实时 frame，但模型延迟和输入质量决定可用性。
• Memory 层级：cache、带宽、压缩和 residency 会直接影响 meshlet、ray tracing、texture streaming 和 temporal history 的成本。
• 功耗边界：峰值算力只代表上限，持续频率、热预算、显存功耗和平台功耗共同决定真实 frame budget。
• 专用单元：video、display、copy engine 和 async compute 需要通过资源状态、queue 和 fence 接入 frame graph。
• 能力分层：feature detection 应转译成 renderer 内部 capability tier，使新旧硬件都能走明确路径。
• Fallback 设计：fallback 应保持视觉目标和交付稳定性，同一目标可以由不同算法实现。
• 测试矩阵：兼容未来架构必须覆盖 API、GPU、driver、OS、quality tier、feature combination 和输出模式。
• 算法协同：mesh shading、work graph、ray tracing、neural rendering 和 GPU-driven pipeline 都在把更多细粒度决策移动到 GPU。
• 生态成熟：硬件能力进入产品路径需要 API、驱动、工具、引擎和内容制作链同时给出证据。