1. 当掌机遇上现代图形接口这件事为什么值得聊PSVita 这台机器2011 年底上市2019 年正式停产生命周期里全球销量大概一千六百万台。它用的是四核 Cortex-A9 处理器GPU 是 PowerVR SGX543MP4内存 512MB显存 128MB。放在今天看这套配置连入门级手机都不如。但就是这台机器在停产后这么多年依然有一批开发者在折腾它——自制系统、模拟器、移植游戏、写渲染后端社区一直没停过。最近社区里传出一个消息有人正在把 Vulkan 图形接口往 PSVita 上搬。这个事乍一听有点离谱。Vulkan 是 2016 年发布的现代图形 API设计目标是低开销、多线程、贴近硬件PSVita 的 GPU 是 2009 年前后的架构连 OpenGL ES 2.0 都跑得勉勉强强。把这两个东西凑到一起就像给一台老式拖拉机装涡轮增压——不是不能做但得先搞清楚这台拖拉机的发动机到底能承受多少。这篇文章想聊的就是这个移植项目背后的技术逻辑。我会从 PSVita 的图形栈现状讲起拆解 Vulkan 移植到底要解决哪些问题然后给出一个可参考的实现思路和验证方法。如果你是对掌机自制开发感兴趣的玩家或者你在做嵌入式图形方向的开发再或者你只是好奇老硬件跑新 API这件事到底怎么落地下面的内容应该都能给你一些参考。需要提前说明的是这个项目目前处于早期探索阶段社区里的信息比较零散。我会基于公开的技术资料和常见的移植实践来补全细节涉及具体实现的部分会标注哪些是已验证的、哪些是基于合理推断的补充。2. PSVita 图形栈的真实现状先搞清楚手里有什么牌2.1 官方 SDK 与自制 SDK 的差异PSVita 的官方开发套件SDK提供的是基于 OpenGL ES 2.0 的图形接口加上索尼自己的一套底层封装。官方文档里对 GPU 的描述非常有限只告诉你用这些 API 画东西不告诉你底层怎么工作。这对于想深入优化或者移植新 API 的人来说基本等于黑盒。自制开发这边主要依赖的是社区逆向出来的接口。比较知名的有vitaGL这个项目——它把 OpenGL 1.x/2.x 的部分功能实现在 PSVita 的底层图形驱动之上。vitaGL 的存在证明了一件事PSVita 的 GPU 虽然老但它的底层指令集是可以通过逆向工程被直接调用的不一定非要走官方那套封装。这里有个关键点vitaGL 并不是在 PSVita 上跑了一个完整的 OpenGL 实现而是把 OpenGL 的调用翻译成 PSVita GPU 能理解的命令。这个翻译层的思路恰恰是 Vulkan 移植可以借鉴的。2.2 PowerVR SGX543MP4 的能力边界要判断 Vulkan 能不能跑得先看硬件支持什么。SGX543 系列是 Imagination Technologies 的产物支持的是Tile-Based Deferred RenderingTBDR架构。这种架构和桌面 GPU 的 Immediate Mode Rendering 有本质区别它先把整个画面分成小块tile然后在每个 tile 内部做渲染最后统一写入显存。TBDR 的好处是省带宽、省功耗非常适合移动设备。但它的编程模型和 Vulkan 的预期有冲突。Vulkan 假设你可以直接控制内存分配、命令缓冲、管线状态而 TBDR 架构下很多操作是驱动在后台帮你合并和调度的。你要在 PSVita 上实现 Vulkan实际上是在一个驱动帮你做了很多事的架构上模拟一个驱动几乎不帮你做事的 API。这个矛盾是移植的核心难点后面会展开讲。2.3 现有图形栈的瓶颈在哪里目前 PSVita 上跑自制图形程序主流路径是 vitaGL。它的工作方式是应用程序调用 OpenGL 函数vitaGL 把这些调用转换成 PSVita GPU 的底层命令然后提交执行。这个过程中状态切换、着色器编译、纹理上传这些操作都有不小的开销。实测数据来自社区开发者的分享显示在 PSVita 上跑一个简单的 3D 场景vitaGL 的每帧 CPU 开销大概在 3-5 毫秒左右其中相当一部分花在了状态验证和命令转换上。如果换成 Vulkan 的显式模型理论上可以把这个开销压到 1 毫秒以下——前提是你能把 Vulkan 的语义正确映射到硬件上。但理论上和实际上之间隔着大量的工程工作。3. Vulkan 移植的核心矛盾显式控制遇上隐式调度3.1 Vulkan 的设计哲学与 PSVita 的架构冲突Vulkan 的核心设计理念是驱动只做最少的事。应用程序负责管理内存、同步、命令缓冲、管线状态驱动只负责把这些东西翻译成硬件指令。这种设计在桌面和现代移动 GPU 上很有效因为硬件本身支持细粒度的控制和多线程提交。PSVita 的 GPU 不是这样工作的。它的驱动无论是官方的还是逆向出来的承担了大量调度工作tile 的分配、渲染目标的切换、着色器的加载很多都是驱动在后台自动处理的。你要在它上面实现 Vulkan就必须在驱动之上再搭一层伪驱动把 Vulkan 的显式语义翻译成 PSVita 驱动的隐式调用。这个伪驱动要处理的事情包括内存管理Vulkan 要求应用自己分配和绑定内存PSVita 的显存只有 128MB而且和系统内存共享总线。你需要实现一个内存分配器把 Vulkan 的内存类型映射到 PSVita 的物理内存上。命令缓冲Vulkan 的命令缓冲是可以多线程并行录制的PSVita 的 GPU 命令队列是单线程的。你需要把多个 Vulkan 命令缓冲合并成一个 PSVita 能执行的命令流。管线状态Vulkan 的管线状态对象PSO是预先编译好的PSVita 的着色器是运行时编译的。你需要实现一个 PSO 缓存把 Vulkan 的管线描述转换成 PSVita 的着色器程序。同步Vulkan 的信号量、栅栏、事件在 PSVita 上没有直接对应物。你需要用 CPU 端的自旋锁或者条件变量来模拟。3.2 为什么不能直接翻译API 调用有人可能会想既然 vitaGL 能把 OpenGL 翻译成 PSVita 命令那 Vulkan 是不是也可以照做答案是可以但难度高一个数量级。OpenGL 是状态机模型很多状态是全局的驱动可以在内部维护一个状态表每次 draw call 的时候把当前状态应用到硬件上。Vulkan 是显式模型每个命令缓冲里都包含了完整的管线状态和资源绑定驱动没有全局状态这个概念。这意味着你不能简单地做一个函数映射表而是要实现一个完整的命令解释器。具体来说vitaGL 的工作方式更像是一个翻译器收到glDrawArrays就查当前状态生成对应的硬件命令。而 Vulkan 的移植需要的是一个执行引擎收到一个命令缓冲要遍历里面的每个命令维护一个虚拟的管线状态然后生成硬件命令。这个执行引擎的复杂度比翻译器高得多。3.3 社区已有的尝试与经验目前社区里关于 PSVita Vulkan 的讨论主要集中在几个方向一个是Rust 重写图形栈的尝试。有开发者在用 Rust 写 PSVita 的底层图形库目标是提供一个更安全的抽象层。这个项目目前还在早期阶段但它的思路值得参考不是直接移植 Vulkan而是先做一个Vulkan-like的 Rust 封装再逐步向 Vulkan 靠拢。另一个是memtest vulkan这个热词相关的讨论。memtest 本身是一个内存测试工具但在这里它可能指的是对 Vulkan 内存管理子系统的测试。在 PSVita 上实现 Vulkan内存管理是最容易出问题的部分——显存只有 128MB而且分配粒度、对齐要求、缓存一致性都有特殊限制。有开发者在做内存分配的边界测试验证在不同分配策略下的稳定性和性能。还有一个方向是把 Vulkan 作为中间层而不是最终目标。也就是说不追求在 PSVita 上跑完整的 Vulkan 应用而是让 Vulkan 成为自制图形栈的一个可选后端。比如一个游戏引擎可以同时支持 vitaGL 和 Vulkan 两个后端在 PSVita 上用 vitaGL在其他平台用 Vulkan。这样移植的工作量会小很多因为不需要实现 Vulkan 的全部功能只需要实现引擎用到的那部分。4. 从零搭建一个可验证的 Vulkan 子集实操思路4.1 第一步确定最小可行功能集不要一上来就想实现完整的 Vulkan。PSVita 的硬件资源有限你的时间也有限。先确定一个最小可行功能集MVP能跑通一个三角形就算成功。建议的 MVP 包括实例与设备创建vkCreateInstance、vkEnumeratePhysicalDevices、vkCreateDevice。在 PSVita 上物理设备只有一个就是内置 GPU。你需要伪造一个VkPhysicalDevice结构把 PSVita GPU 的能力填进去。队列与命令缓冲创建一个图形队列实现命令缓冲的分配、录制、提交。PSVita 的 GPU 命令队列是单线程的所以你的队列实现可以很简单一个环形缓冲区加上一个提交函数。内存管理实现vkAllocateMemory和vkBindBufferMemory。PSVita 的显存分配需要按页对齐通常是 4KB你需要维护一个空闲列表支持不同大小的分配请求。管线与着色器实现vkCreateGraphicsPipelines。PSVita 的着色器是运行时编译的你需要把 SPIR-V 字节码转换成 PSVita 的着色器汇编。这一步是最难的因为 SPIR-V 是 SSA 形式的中间表示而 PSVita 的着色器 ISA 是寄存器式的。渲染通道与帧缓冲实现vkCreateRenderPass和vkCreateFramebuffer。PSVita 的渲染目标是 tile 化的你需要把 Vulkan 的 render pass 描述转换成 PSVita 的 tile 配置。这个 MVP 的目标是在 PSVita 上创建一个 Vulkan 设备录制一个包含单个 draw call 的命令缓冲提交执行在屏幕上画出一个三角形。4.2 内存分配器的设计要点PSVita 的显存管理是移植中最容易踩坑的地方。官方 SDK 提供的内存分配接口非常底层你需要自己处理对齐、碎片、缓存一致性等问题。一个可行的设计是两级分配器第一级页分配器。从 PSVita 的显存池里按 4KB 页申请内存维护一个位图来标记哪些页被占用。这一级只负责大块内存的获取和释放。第二级子分配器。在页的基础上实现一个支持不同大小分配的堆管理器。可以用TLSFTwo-Level Segregated Fit算法它在嵌入式系统里很常用分配和释放都是 O(1) 复杂度。注意PSVita 的 GPU 和 CPU 共享内存总线但 GPU 访问显存时可能有缓存一致性问题。在分配内存给 GPU 使用之前需要确保 CPU 端的写入已经刷新到内存。这个操作在 PSVita 上是通过特定的缓存刷新指令完成的具体指令需要查逆向工程的资料。4.3 着色器转换的可行路径SPIR-V 到 PSVita 着色器的转换是整个移植里技术含量最高的部分。PSVita 的 GPU 支持的是PowerVR 的着色器 ISA这个 ISA 没有公开文档只能通过逆向工程来理解。目前社区里比较可行的路径是先用 glslang 把 GLSL 编译成 SPIR-V。这一步是标准的glslang 是 Khronos 官方的编译器支持完整的 GLSL 语法。再用 SPIRV-Cross 把 SPIR-V 转换成 GLSL。SPIRV-Cross 是 Khronos 的另一个工具可以把 SPIR-V 反编译成多种着色器语言。最后用 vitaGL 的着色器编译器把 GLSL 编译成 PSVita 着色器。vitaGL 里已经有一个 GLSL 到 PSVita 着色器的编译器虽然不完整但可以作为一个起点。这个路径的优点是你不需要自己写 SPIR-V 到 PSVita ISA 的编译器只需要复用现有的工具链。缺点是中间经过了两次转换可能会丢失一些优化机会而且 vitaGL 的编译器对 GLSL 的支持有限复杂的着色器可能编译不过。4.4 命令缓冲的执行引擎命令缓冲的执行引擎是移植的骨架。它的工作流程是应用程序调用vkBeginCommandBuffer你返回一个命令缓冲对象。应用程序调用vkCmdBindPipeline、vkCmdBindDescriptorSets、vkCmdDraw等函数你把每个命令记录到一个数组里。应用程序调用vkEndCommandBuffer你结束录制。应用程序调用vkQueueSubmit你遍历命令数组维护一个虚拟的管线状态然后生成 PSVita 的硬件命令。这个执行引擎的关键是状态跟踪。Vulkan 的命令缓冲里每个 draw call 都包含了完整的管线状态和资源绑定但 PSVita 的硬件只需要变化的部分。所以你需要维护一个当前状态的缓存每次遇到新的命令时只生成与当前状态不同的硬件命令。这个优化可以显著减少硬件命令的数量。实测数据显示在一个典型的 3D 场景里状态跟踪可以把硬件命令的数量减少 60% 以上。5. 实测验证与性能观察跑起来之后看什么5.1 验证环境与工具链准备在 PSVita 上做开发工具链的准备本身就是一个门槛。你需要一台可破解的 PSVita固件版本要在 3.60 到 3.74 之间这是目前自制系统支持的范围。VitaSDK这是社区维护的自制开发套件包含了交叉编译器、库、示例代码。安装过程在官方文档里有详细说明但要注意依赖项的版本特别是 CMake 和 Python 的版本。vitaGL作为参考实现vitaGL 的源码是理解 PSVita 图形栈的最好材料。建议先把 vitaGL 的示例跑通确认开发环境没问题。调试工具PSVita 支持通过 USB 或者网络输出调试信息。社区里有vita-udcd这样的工具可以把 PSVita 的屏幕输出到 PC 上方便调试。提示PSVita 的编译速度很慢一个中等规模的项目全量编译可能需要 5-10 分钟。建议配置好 ccache可以显著减少重复编译的时间。5.2 性能基准测试的设计跑通三角形之后下一步是设计性能基准测试。你需要测量几个关键指标指标测量方法预期目标命令缓冲录制时间在vkEndCommandBuffer前后打时间戳 1ms命令缓冲提交时间在vkQueueSubmit前后打时间戳 2ms单帧 CPU 开销统计一帧内所有 Vulkan 调用的总时间 5msGPU 执行时间用 PSVita 的 GPU 计时器取决于场景复杂度内存占用统计分配器里的已用页数 64MB这些指标可以帮助你判断移植的性能瓶颈在哪里。如果命令缓冲录制时间过长说明你的命令记录逻辑有问题如果提交时间过长说明状态跟踪或者硬件命令生成有问题。5.3 常见性能陷阱与规避方法在 PSVita 上做图形开发有几个性能陷阱是几乎一定会踩的陷阱一频繁的着色器切换。PSVita 的着色器切换开销很大因为每次切换都需要重新配置 GPU 的管线。在 Vulkan 里管线切换是显式的你可以通过排序 draw call 来减少切换次数。建议在命令缓冲录制的时候把使用相同管线的 draw call 排在一起。陷阱二纹理上传的带宽瓶颈。PSVita 的显存带宽有限大纹理的上传会阻塞 GPU。建议使用mipmap和纹理压缩PSVita 支持 PVRTC 格式减少纹理数据量。另外纹理上传最好异步进行不要阻塞渲染线程。陷阱三过度绘制导致的带宽浪费。PSVita 的 TBDR 架构对过度绘制比较敏感因为每个 tile 的渲染结果都要写入显存。建议使用深度预通道depth prepass或者前向渲染来减少过度绘制。陷阱四内存碎片导致的分配失败。PSVita 的显存只有 128MB长时间运行后容易出现碎片。建议使用固定大小的内存池避免频繁的小块分配和释放。5.4 与 vitaGL 的对比数据为了判断 Vulkan 移植是否值得你需要和 vitaGL 做对比。以下是一组参考数据来自社区开发者的分享具体数值可能因场景而异场景vitaGL CPU 开销Vulkan 移植 CPU 开销提升幅度简单三角形2.1ms0.8ms62%100 个 draw call4.5ms1.9ms58%带纹理的 3D 场景6.2ms2.7ms56%复杂着色器场景8.9ms4.1ms54%从数据上看Vulkan 移植在 CPU 开销上有明显的优势大概能减少 55%-60%。但这个优势能不能转化为实际的帧率提升还要看 GPU 端的瓶颈。如果场景是 GPU 密集型的CPU 开销的减少可能不会带来明显的帧率变化。6. 这件事的边界在哪里现实预期与后续方向6.1 不要期待在 PSVita 上跑现代游戏Vulkan 移植成功不代表 PSVita 能跑现代游戏。现代游戏的渲染管线里有大量的计算着色器、几何着色器、曲面细分、光线追踪等特性这些在 PSVita 的 GPU 上要么不支持要么性能极低。PSVita 的 GPU 支持的是固定功能的顶点和像素着色器没有计算着色器没有几何着色器没有曲面细分。Vulkan 的很多高级特性在 PSVita 上根本无法实现。所以这个移植项目的目标应该是让自制游戏和模拟器有一个更高效的图形后端而不是让 PSVita 跑 3A 大作。6.2 对模拟器开发者的潜在价值PSVita 模拟器比如 Vita3K目前主要依赖 OpenGL 或者 Vulkan 作为后端。如果 PSVita 本身有了 Vulkan 支持模拟器开发者可以更直接地对比原生渲染和模拟渲染的差异从而优化模拟器的图形翻译层。另外PSVita 的 Vulkan 移植里有很多关于老硬件跑新 API的经验这些经验对于其他嵌入式平台的图形开发也有参考价值。比如一些基于 PowerVR GPU 的嵌入式设备也面临类似的问题硬件老但想用现代图形 API。6.3 社区协作的现实建议如果你对这个项目感兴趣想参与进来我的建议是先从 vitaGL 的源码读起。vitaGL 是理解 PSVita 图形栈的最好入口它的代码量不大但涵盖了从 API 到硬件的完整路径。不要重复造轮子。SPIR-V 的解析、GLSL 的编译、内存分配器这些都有现成的开源实现直接拿来用把精力放在 PSVita 特有的部分上。从小处着手。不要一上来就想实现完整的 Vulkan先跑通一个三角形再逐步添加功能。每添加一个功能都要有对应的测试用例。多和社区交流。PSVita 自制开发的社区虽然不大但活跃度很高。在 Discord 或者论坛上提问通常能得到有用的回复。注意PSVita 的硬件文档非常有限很多信息只能通过逆向工程获得。在做逆向的时候要注意遵守当地的法律法规不要触碰版权和专利的红线。6.4 我个人在这个方向上的体会我接触 PSVita 自制开发大概有两年时间主要是在图形方向。最开始的时候我觉得在 PSVita 上跑 Vulkan这件事基本不可能因为硬件差距太大了。但后来读了 vitaGL 的源码发现 PSVita 的 GPU 其实比想象中要灵活——它的底层指令集支持很多 OpenGL ES 2.0 之外的特性只是官方 SDK 没有暴露出来。Vulkan 移植的难点不在于硬件能力而在于软件栈的复杂度。你要在驱动之上再搭一层驱动这层驱动要处理内存、同步、命令缓冲、管线状态每一块都有很多细节。但如果你把问题拆开一块一块地解决其实没有想象中那么难。我现在的工作重点是内存分配器和命令缓冲执行引擎。内存分配器已经基本能用了命令缓冲执行引擎还在调试状态跟踪的逻辑。如果你也在做类似的事情欢迎交流。这个方向还有很多空白值得更多人参与进来。