在我看来，获得与主线 Linux 兼容的 Arm 平台可能还需要几年的时间，因为这项工作通常由第三方完成，而且芯片供应商又有自己的 Linux 树。这就会导致一种局面，即只有当硬件平台过时或即将要过时的时候，主线Linux提供的软件才会准备就绪。我就在思考如果能够在硬件准备好之前就开始对软件进行开发就好了。这似乎是一个疯狂的想法，但其实 Collabora 团队就正在做这样的事， Collabora 向Panfrost开源 GPU 驱动程序添加对 Arm“Valhall”GPU（Mali-G57、Mali-G78）的支持正是在做这样的工作。
Collabora 团队取得的结果似乎也还不错，由于过去六个月的工作，他们在收到实际硬件后，只用了几天时间，就使用由他们的 Mesa 驱动程序准备的数据结构和由他们的 Valhall 编译器编译的着色器成功地通过了测试。那么他们究竟是如何实现这一壮举的呢？
要了解这一壮举之前，我们必须要先回到几个月前。去年 7 月，Collabora 宣布他们使用了三星Galaxy S21 智能手机对 Mali-G78 GPU 的 Valhall 指令集进行了逆向工程。等等，你们可能会很疑惑刚刚我不是说他们可以在没有 Mali-G78 硬件的情况下开发吗？是的，但当时他们无法在设备上安装主线 Linux 和他们的 GPU 驱动程序，因为它还没有被主线Linux支持。所以，他们只是用该硬件来对指令进行逆向工程，并通过修改编译的着色器和 GPU 数据结构来进行一些测试，这样就能试验每一项是否通过。其实，如果有 Mali G78 文档，就可以避免这一步骤了。
据我所知，Collabora 公司的图形软件工程师 Alyssa Rosenzweig 一直在继续她的软件开发工作。在 2021 年 11 月的时候，她编写了一个 Valhall 编译器，并进行了足够的逆向工程用来编写驱动程序，但她仍然没有用 Linux 硬件来测试代码。为此，她给从指令打包到优化的所有内容编写了单元测试，并在开发过程中设法仅使用运行 Linux 的开发机器解决了一些错误。
下一步就是在用户空间中使用drm-shim库和伪造的 GEM 内核驱动程序，他们主要用于 Mesa 项目中使用的 CI（持续集成）。drm-shim 驱动程序使系统认为它具有实际的 GPU，但除了接收来自用户空间图形驱动程序的系统调用外，其他的它什么都不用做。这不是模拟器，不能用来测试功能，但它可以帮助发现程序流程中的缺陷。在修复了一个错误（该错误是：页面大小为 16K，而不是 4K）后， Alyssa Rosenzweig 就能够在运行 Linux 的 Apple M1 上运行大量的测试了，包括使用 Valhall 编译器每秒编译数千个着色器，运行 Khronos 的 OpenGL ES 一致性测试用于识别任何问题的套件等等。
Collabora 公司还尝试识别了 Valhall 和 Bifrost 等早期 Arm Mali GPU 之间的差异，重用大部分的Panfrost 驱动程序代码，并且更改的也只他们检测到差异的部分代码。例如，Valhall 指令集与旧的 Bifrost 指令集非常相似，因此他们就将 Valhall 编译器作为附加后端嵌入到现有的 Bifrost 编译器中。对此，Alyssa解释说：
共享编译器传递的指令选择和寄存器分配等在 Valhall 上都是“正常工作”的，即使它们是为 Bifrost 开发和调试的。
2022 年 1 月，Collabora 终于收到了带有联发科 MT8192 (Kompanio 820) 片上系统（带有 Mali-G57 MC5 GPU）和串行电缆的 Chromebook，他们在修复USB问题后成功在板上运行了主线 Linux ，不过其显示器还没有正常工作。GPU 在 MT8192 中被自动禁用显然是由于芯片的bug，但可以在禁用“加速器一致性端口”（ACP）后再启用。正如上所述，由于他们前期做了大量的准备工作，他们只花了几天时间就成功通过了对实际硬件的数百次测试。Collabora 公司现在预计 Panfrost 是能“及时地为最终用户”支持 Valhall GPU 的。你们也可以在 Collabora 的博客上阅读其相关的内容。
文章翻译者：Taylor Lee，瑞科慧联（RAK）高级嵌入式开发工程师，有丰富的物联网和开源软硬件经验，熟悉行业主流软硬件框架，对行业发展动向有着敏锐的感知力和捕捉能力。