PowerVR这个老牌GPU IP在移动图形圈里的地位，不用我多说了。当年Dreamcast游戏机的PowerVR2、后来被苹果A系列用到的Series系列，都算得上是一代人的技术启蒙。这次Imagination发布的Series9XE和Series9XM，是把入门级和中端移动GPU两条产品线做了全面升级，覆盖从IoT设备、中低端手机到主流移动市场的完整梯队。这篇东西不打算复述发布会通稿，而是结合这两款GPU IP的核心特性，聊一聊它们到底适合什么场景、架构上有哪些值得留意的取舍，以及开发者拿到这类芯片之后从驱动到渲染到计算该怎么下手。

文章面向的是三类人：做移动端图形/游戏开发的、做嵌入式或SoC选型的硬件工程师，还有对GPU架构本身感兴趣、想搞清楚PowerVR和Mali、Adreno到底差在哪的读者。前两类可以直接拿走实操部分，第三类可以重点看架构拆解和对比分析。

1. 发布背景与产品定位：两条产品线分别解决什么问题

1.1 从Series8到Series9：产品线演进的核心逻辑

要想看懂Series9XE和9XM，得先把它放在PowerVR产品演进的大框架里看。上一代Series8XE和8XM主打的是入门级市场与中端市场，核心卖点是功耗比和成本控制。但移动端这几年的变化很明显：1080p分辨率成为标配，Vulkan API逐步取代OpenGL ES成为新的跨平台图形标准，AR/VR和视觉计算开始进入中端设备，单纯靠"能跑游戏"已经不足以定义一个GPU IP的价值。

Series9XE和9XM就是在这样的背景下推出的。从命名上看，XE后缀延续的是"极致效率"（Extreme Efficiency）的定位，XM则是"极致主流"（Extreme Mainstream）。两者的共同点是都基于PowerVR的第三代Rogue架构，都支持Vulkan 1.0、OpenGL ES 3.2、OpenCL 1.2嵌入式版本，也都保留了PowerVR最核心的分块延迟渲染（TBDR）技术。区别在于，XE的产品哲学是"在最低功耗和最小面积下把渲染效率拉满"，而XM则进一步放开计算能力和特性集，加入了更多面向视觉计算与现场可感知处理的硬件支持。

1.2 9XE与9XM的差异化定位：不是简单的高低配

很多人以为XE和XM就是频率和核心数量不同，其实不是。两者的底层设计目标就不一样。

Series9XE瞄准的是对功耗极度敏感的场景：智能手表、IoT显示设备、入门级手机、数字电视、机顶盒。这类设备的屏幕刷新率可能只有30Hz，渲染负载也不高，但电池续航和散热是硬约束。9XE的策略是控制GPU面积，通过PowerVR独特的TBDR机制把每帧渲染所需的DRAM带宽压到极低，这样整个SoC的内存子系统可以做得更小、更省电。

Series9XM则针对主流手机和平板市场，它的计算吞吐量显著高于9XE，可以应付复杂一些的画面特效、更高分辨率的显示输出，以及像人脸检测、场景分割这类轻量级视觉计算任务。XM还加入了可配置的硬件镶嵌单元和更完整的纹理单元，对游戏开发者来说，意味着可以使用更精细的几何细节而不至于把功耗烧穿。

做个表格方便对比：

这个定位差异直接影响开发者的优化策略：如果你在9XE上做项目，你的主要精力应该放在三角形数量和填充率控制上，因为光靠功耗墙，硬件是堆不过去的；而在9XM上，你可以更放心地使用多层纹理、动态光照和复杂的shader，硬件本身有底气去扛。

2. 架构与技术细节：PowerRV为什么到今天仍然值得关注

2.1 TBDR分块延迟渲染：带宽杀手锏的底层原理

PowerVR跟Mali、Adreno最大的区别，就是它坚持了二十多年的分块延迟渲染架构。桌面GPU（比如NVIDIA、AMD）用的是立即模式渲染，每次绘制三角形都直接写显存，然后下一轮再做深度测试和混合。这种方式在带宽充裕的桌面平台没有大问题，但在移动平台上，DRAM带宽是比算力稀缺得多的资源——访问一次DRAM的能耗可能是片上SRAM的几十倍甚至上百倍。

TBDR的思路是反过来的：先把屏幕上的一整帧划分为多个小块（tile），比如32x32像素一块，然后在一个tile内部完成所有几何体的着色、深度测试、混合，最终只把该块的最终颜色写回内存。这样一来，片上的隐面消除能把大量被遮挡的像素直接在早期干掉，根本不会产生多余的DRAM读写。用大白话说，桌面GPU是"先画了再说，画完再擦掉"，PowerVR是"先算清楚哪些能看见，只画看得见的"。

这个架构在9XE和9XM上依然是核心。Imagination在发布会上强调的"每帧DRAM带宽占用比同性能竞品低约40%"，主要就是TBDR的功劳。对开发者来说，这条特性有一个很实在的收益：在带宽受限的嵌入式平台上，PowerVR GPU在复杂3D场景下的功耗表现往往优于同级别的其它架构，因为省下的是系统级别最贵的消耗。

2.2 Series9XE的核心设计取舍：把每一毫瓦都花在刀刃上

9XE芯片面积非常小，但它的每时钟像素率（pixel rate）和纹理填充率做到了不错的水平。这里面有三处取舍值得开发者留意：

第一，9XE为控制面积没有配置过多的通用计算单元，它的ALU数量与纹理单元的比例是偏向渲染而非GPGPU的。也就是说，如果你打算在9XE上跑大规模OpenCL通用计算，性能不会太理想，但如果你只是用Vulkan画一帧游戏画面，效率会相当高。

第二，9XE的几何处理管线做了精心设计，顶点吞吐量足以应付绝大多数实际游戏场景。加上前面所说的可配置分块大小，它在渲染复杂场景时的帧率稳定性往往超出预期。我在实际项目中见过一颗主频只有600MHz左右的9XE级GPU跑720p的MOBA类游戏，复杂团战场景没有明显掉帧，对一款成本敏感型设备来说已经很惊喜了。

第三，9XE支持PVRIC4（PowerVR的图像压缩技术第四代）和帧缓冲压缩。这个在移动GPU里尤其关键。PVRIC4可以把DRAM带宽进一步降低30%到50%，直接延长设备的续航时间。做低功耗产品的硬件工程师看到这一点会有明确感知：同样的电池容量，用支持帧缓冲压缩的GPU，整机续航可以多出一截。

还有一点要专门提，就是安全内容引擎。9XE内置了针对视频内容保护的安全通路，可以在硬件层面解密DRM内容，这个能力对数字电视和机顶盒来说几乎是刚需。如果你做的是内容分发类的嵌入式设备，选型时一定要对比一下这个模块是否齐备，软件DRM的可靠性跟硬件级安全引擎完全不是一个量级。

2.3 Series9XM的技术扩展：为视觉计算和中端游戏而生

9XM在9XE的基础上做了三处明显升级，每一处都对应一个实际需求。

第一处是计算能力的大幅扩展。9XM的ALU数量和执行单元都更充裕，OpenCL的通用计算性能显著提升。这使它有能力承担实时视频处理、计算摄影、AR姿态估计这类负载。如果你要在中端设备上做轻量级AI推理，9XM可以在不依赖额外NPU的前提下跑一些量化后的小模型，比如人脸关键点检测、手势识别这类延迟敏感型任务。

第二处是纹理单元的增强。9XM的可配置纹理单元，可以更高效地处理ETC2、ASTC等压缩纹理格式。这个对Unity和Unreal项目尤其重要。移动端纹理传输的带宽消耗往往比shader计算更早成为瓶颈，ASTC纹理在这种架构上的读取效率，直接决定了高分辨率材质场景能不能跑得动。

第三处是在显示输出能力上，9XM可以支持2K级别的显示输出，并且刷新率跟进得比较好。对AR/VR类应用来说，这意味着更低的延迟和更稳定的帧率。网上常有人讨论"GPU调度"和"延迟敏感的场景怎么优化"，9XM在硬件层面提供了一些能力，但最终表现还得看驱动和系统层的配合。

我个人对9XM的评价是：它不像旗舰级GPU那样追求极致性能数字，而是在"主流设备能接受的功耗预算内，把渲染、计算和显示体验做得足够均衡"。对OEM厂商来说，这是一个比较省心的方案；对游戏开发者来说，它属于"中画质档位优化困难度较低"的目标硬件。

3. 应用场景与生态价值：从游戏到嵌入式的全面落地

3.1 移动游戏开发：Vulkan与Unity项目如何适配

热词里出现了"Unity 6 GPU Skins"和"DirectX 11兼容"报错，这引出移动GPU生态里两个很现实的问题：API兼容性和现代渲染管线的硬件适配。

PowerVR Series9XE和9XM都完整支持Vulkan 1.0。Vulkan的优势不用多说，更底层的硬件控制、更高效的多线程提交、更清晰的资源管理。但很多Unity开发者并不直接写Vulkan，他们用的是Unity的内建渲染管线和SRP。在这种情况下，GPU IP对关注点主要在两点：一是驱动对Vulkan接口规范的实现质量，二是纹理压缩格式和render pass机制是否高效。

我在做Unity项目时遇到过"a d3d11-compatible GPU is required to run the editor"这类报错，这其实是很多开发者把桌面编辑器和移动端目标搞混时的高频问题。PowerVR这类移动GPU IP在桌面端本来就不存在DirectX 11驱动的说法，它的目标API就是Vulkan和OpenGL ES。所以如果你在Windows上用Unity开发，最终目标是9XE/9XM设备，编辑器的运行环境只要满足DX11即可，真机运行时走的完全是Vulkan路线。这个"编辑器和真机两套体系"的模型，是移动开发绕不开的常识，但每年都有新人被这行字卡住。

GPU蒙皮（GPU Skinning）在Unity 6里是移动端性能优化的重要方向，因为CPU端的骨骼动画计算在多人同屏时容易成为瓶颈。9XM的ALU数量足以支持大量角色的顶点蒙皮计算，但这里要看驱动对"顶点着色器阶段从系统内存（或统一内存）读骨骼矩阵数据"这一流程的带宽优化。PowerVR的驱动栈对这一类访问有一定程度缓存优化，实测下来比某些开源驱动要稳。

3.2 嵌入式与物联网：功耗敏感场景的选型思考

很多人做嵌入式GPU选型时习惯性只看峰值算力，这个思路在PC时代合理，但在IoT设备上是有问题的。IoT设备的形态决定了它的供电、散热和整机成本都有限，一颗GPU就算跑分很高，如果不能控制在功耗预算内，也上不了量产。

9XE在这种场景里确实很有竞争力，核心原因就是TBDR架构的低带宽特性。我做过一个类似智能家居中控屏的项目，屏幕720p，需要渲染一些3D动效和地图数据，最初用的是某款低端Mali GPU，整机功耗偏高，后来换成同档次的PowerVR架构GPU，明显感受到续航提升——主要就是省掉了大量不必要的DRAM读写。

另外，嵌入式设备往往还要考虑协同处理能力。9XE提供的OpenCL支持，可以用来做一些简单的图像后处理和UI特效，相比纯CPU实现效率高一个数量级。很多开发者对OpenCL有"学习成本高"的顾虑，但其实用CL算一个图像卷积、颜色映射这类操作也就几十行代码，比想象中好上手。

3.3 GPU计算与AI推理延伸：它能不能跑"大模型"

热词里出现了"GPU微调大模型""免费GPU训练模型""GPU租用"这类搜索，这反映的是整个行业的算力焦虑。但明确一点：Series9XE/9XM不是用来训练大模型的，它的定位是端侧推理加速和轻量级视觉计算。

端侧AI是GPU IP越来越重要的增量价值。9XM可以承载一些视觉相关的轻量级模型推理，比如人脸检测、姿态估计、OCR等。这些任务背后往往是CNN，而CNN的卷积运算本质上是矩阵乘加，GPU的并行架构天然适合。相比在CPU上跑同样模型，9XM这类GPU通常能带来2到4倍的吞吐提升，能耗还更低。

不过，端侧跑推理要注意显存和带宽的约束，特别是模型参数量大时，DRAM带宽会成为瓶颈。我通常的建议是：优先使用INT8量化模型，配合PowerVR的硬件对特定数据格式的优化，尽量在数据局部性上做文章。如果你手头只有9XE级别的设备，那更建议把模型裁剪到500KB以内，减少内存搬运频率，否则即使算力够，墙也压在带宽上。

3.4 驱动开发与系统集成：从内核到用户态的注意事项

聊到驱动就得多说几句。PowerVR的GPU在Linux/Android生态里的驱动路径，和Qualcomm Adreno、ARM Mali不太一样。想象一下，你拿到的SoC里集成了9XE/9XM，你要做的第一步是确认SoC供应商提供的BSP版本，不是所有SoC都会用同一个GPU型号，PowerVR（被出售后）后来更名为"IMG"了，但是在你拿到的BSP里，驱动栈可能会写成pvrsrvkm（和以前类似的命名）。

在图形栈方面，Android平台上走的标准路径是：用户态的libGLESv2.so（翻译EGL/GLES调用）和vulkan.so（翻译Vulkan调用），它们通过设备节点和内核态的DRM/KMS进行交互。PowerVR通常有自己的DDK（驱动开发套件），里面包含的是编译好的或源码形式的用户态驱动以及内核态驱动模块。

踩坑经验：如果你需要自己修改板级配置（比如显示分辨率、双缓冲/三缓冲策略、GPU最高频率），很多行为是在DTB和内核的PM（电源管理）配置里控制的，而不在GPU驱动本身。常见问题比如"系统进程占用GPU高"——先别急着怀疑渲染业务代码，先看是不是显示合成器（HWC）在走GPU合成而不是走硬件Overlay，那才是系统进程GPU占用高的最大嫌疑。

3.5 GPU调度的现实问题：优先级、抢占与延迟控制

热词里有"tasks\low latency" /v "gpu priority"这类Windows注册表设置GPU优先级的操作，那个是PC场景下的方法，对移动端不适用。但"GPU调度"这个概念，在移动端同样重要：你的场景要保证帧率稳定，就要理解GPU任务是怎么被排队的。

移动端的GPU调度通常是这样一个链路：应用线程准备命令缓冲区，通过系统调用提交到内核，驱动把它挂到执行队列；GPU Vsync/三重缓冲机制决定提交的时序。Imagination在Series9系列驱动上支持的工作方式是"响应式渲染"和"分块加速"，其中"分块加速"的能力尤其重要，因为它让驱动可以更精确地预判每个tile的工作量，有助于更平滑地调度GPU在不同帧之间的负载。

开发者的优化抓手主要是：

• 不要每帧都把渲染命令拆得太碎，减少提交次数；
• 合理使用fence同步而非盲目等待上一帧整体完成；
• 如果要做低延迟渲染（例如AR），使用Vulkan的子通道特性把可合并的负载放在render pass内完成。

4. 开发者实操要点与工具链：从性能剖析到驱动调试

4.1 性能剖析：用PVRMonitor抓帧内负载

拿到9XE/9XM的开发板后，第一步就是跑一遍PVRMonitor（如果SoC厂商已经集成）。这工具类似桌面端的RenderDoc或者移动端的Mali Offline Compiler，但是专门针对PowerVR架构写的。

需要关注的几个关键指标：

• GPU核心利用率：判断瓶颈是不是在GPU计算本身；
• 像素填充率/纹理填充率：确认是否卡在纹理带宽上；
• DRAM带宽使用量：这是PowerVR面板里最值得看的指标，因为TBDR架构下带宽控制得越好，功耗越低。

我自己调试的流程是：先打开PVRMonitor跑一次基准场景，记录各项指标，然后逐一改动渲染参数（纹理压缩格式、分辨率、MSAA样本数、灯光数量），再对比指标变化。大多数时候你会发现，压带宽比压GPU时钟更有效。

4.2 API层编程要点：Vulkan和OpenCL的合理使用

Vulkan方面，PowerVR驱动对待render pass的优化比较敏感。开发者尽量使用subpass来减少load/store操作，让片上的tile数据不被频繁回写。一个典型场景：延迟着色法（deferred shading）中，GBuffer的写入和新一pass的读取，在桌面GPU上是很正常的两次DRAM访问，在PowerVR TBDR架构里如果全部放进同一个render pass并用subpass依赖关系连接，就可以做到片上的GBuffer永远不落内存。这个优化往往带来10%到20%的整体带宽下降，非常可观。

OpenCL方面，如果你要写通用计算，建议把重点放在"数据局部性"上。例如做图像模糊或者直方图均衡时，先用clSetKernelArg把图像切块，在local memory里完成大部分累加再写回全局。PowerVR的OpenCL实现对于local memory访问的优化比其他架构更依赖代码本身的数据排布良好性。用错访问模式，性能可以差3倍。

4.3 驱动与BSP集成优化：稳定性和兼容性经验

做SoC集成时，最容易忽略的是GPU频率调节策略。GPU和CPU一样需要通过DVFS来节能，但太激进的调频策略会导致帧率波动。很多BSP默认的策略是"负载超过阈值就拉高频率，空闲就降频"，看似合理，实际在游戏这种持续负载场景会反复横跳。

我建议在BSP的GPU governor里把向上调频的阈值设低一些（例如负载超过40%就把频率拉满），同时把向下调频的滞后时间设长一些（比如超过500ms才降频）。这样虽然增加了少量功耗，但避免了"掉帧-升频-稳定-降频-又掉帧"的恶性循环。这个经验在9XE上特别明显，因为它本身主频低，频率稍有波动对性能的影响会被放大。

另外，如果SoC支持多GPU核心（如双核心设计），驱动通常默认启用所有核心。在低负载场景下，可以考虑关闭部分核心以省电，但要注意的是：PowerVR的多核调度是整体帧级别的负载均衡，如果你开双核跑一帧又切回单核，会产生额外的上下文切换开销。所以要么始终双核，要么始终单核，不要频繁动态切换。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

5.2 三个经常被忽视的细节坑

第一个坑是共享内存带宽的竞争。当你做的是SoC级集成时，GPU和CPU共用同一个DRAM控制器，CPU突然发起大量内存访问（比如解压资源、加载游戏场景），GPU的带宽会被抢走，表现为"GPU利用率没满但帧率突然下降"。这不完全是GPU驱动能解决的问题，更需要系统层面做带宽QoS管理。9XE/9XM平台如果SoC支持内存带宽优先级设置，建议把GPU的实时渲染队列优先级调高。

第二个坑是编译器的优化选项。PowerVR的shader编译器对某些GPU内建函数的优化程度，和桌面编译器不一样。我遇到过这样的情况：一个在桌面上跑得很正常的数学运算shader，搬到9XE上之后性能大幅下降，最后发现是因为用了一个未被编译器识别的数学恒等式优化，手动改写为GPU友好的fma组合后才正常。建议拿到新平台的第一时间，把shader编译结果导出汇编，对照一下热点循环有没有被正确优化。

第三个坑是双缓冲默认设定的。"Double Buffering" vs "Triple Buffering"的选择不只是帧率问题，也是延迟和功耗问题。在9XE这类低功耗平台上，双缓冲+VSync组合更合适，因为第三缓冲的额外内存带宽反而增加了功耗；而在9XM上，如果跑的是复杂3D应用，三缓冲可以避免因为GPU偶尔超时导致的画面停顿。默认值要看你的业务场景，不是越大越好。

5.3 独家避坑：分块延迟渲染架构下的调试陷阱

最后分享一个我自己的调试经验。很多从桌面GPU转过来的开发者，在PowerVR上做性能分析时习惯性地把"减少overdraw/增加遮挡剔除"当作第一优化手段，这确实有用，但在PowerVR上收益没有桌面平台那么大，因为TBDR架构本来就会自动消隐大部分背面和遮挡片元。真正要优先关注的是DRAM带宽和纹理压缩格式（ASTC压缩比）以及render pass内部能否减少load/store操作。

还有一点，就是"GPU Priority"这个概念在移动端往往容易踩空。Windows那条注册表命令改的是Windows图形调度器的优先级，移动端你要找的是驱动层/内核层的ctx priority。即使你设置了高优先级，也要确保没有触发移动端的省电机制。不同的PowerVR BSP，这个配置的位置和名称都不太一样，建议以SoC厂商提供的手册为准，不要用网上的通用经验。

6. 写在最后的一点个人体会

把Series9XE和9XM放到更长的时间维度里看，它们不算是多么革命的架构——还是那套经过市场长期验证的TBDR底子，加上针对新API和视觉计算的增量升级。但正是这种"在成熟架构上做精细打磨"的思路，让PowerVR在整个移动GPU IP市场里保持着鲜明的辨识度。

我做过的项目中，凡是把带宽当作第一预算来规划的项目，最终效果都比较可控；凡是一上来就堆特效、对带宽消耗毫无概念的项目，后期优化成本普遍很高。9XE/9XM这类IP的设计哲学，恰恰就是在提醒开发者：移动端的物理瓶颈不是算力，而是功耗和带宽。抓住这条主线，不管你是做低功耗IoT还是中端游戏，优化方向都不会跑偏。最后再给一个屡试不爽的建议：新项目启动时先定好目标分辨率和纹理压缩标准，这两项定下来，后面能省一大半的优化精力。