开源的 Panfrost Mali GPU 驱动程序现在支持新的 Valhall 架构，在 Mali-G57 GPU 上完全符合 OpenGL ES 3.1 标准。最终的 Mesa 补丁今天将投入使用，所需的内核补丁也已排队等待合并到上游。
马利-G57系列集成在搭载MT8192和MT8195系统级芯片的新款MediaTek Chromebook上。Collaborans的AngeloGioacchino Del Regno和Nícolas F. R. A. Prado正在领导这些设备的集成工作。使用Mesa 22.2和适当的内核，这些笔记本电脑上的Linux操作系统将能够直接启用图形加速。
瓦拉哈尔基于较老的比弗罗斯特架构，我们去年已经实现了对其的兼容性，因此驱动程序更改是硬件更改的直接功能。瓦拉哈尔拥有精简的指令集架构，这是我们之前已经逆向工程并文档化的。因此，我们需要一个瓦拉哈尔编译器。由于比弗罗斯特和瓦拉哈尔指令集密切相关，我们可以重用编译器传递，如指令选择和寄存器分配，同时替换其他传递，如调度。
除了新的指令集之外，Valhall的固定功能被调整以提高Vulkan性能。考虑变换反馈，这是一个用于将顶点着色器输出捕获到应用程序缓冲区的已弃用功能。变换反馈有限，在硬件中实现代价高昂，已被计算着色器取代，但为了与旧应用兼容而保留。
在之前的Mali GPU中，顶点着色器将它们的输出存储到由驱动程序提供的缓冲区中，而片元着色器从该缓冲区读取输入。表面上，我们可能通过简单地提供应用程序缓冲区来实现“变换反馈”。但设计上存在其他问题。当不使用变换反馈时分配缓冲区，驱动程序必须确定大小，这在索引渲染中代价高昂，而在间接渲染中则不可能。在最坏的情况下，驱动程序必须分配大量内存，并希望这足够。
Valhall解决了这个问题。现在硬件为顶点输出分配了一个临时缓冲区，而不是驱动程序，从而减少了开销。不幸的是，这种新的设计破坏了我们的“免费”变换反馈实现。
如何在没有硬件支持的情况下实现变换反馈？使用计算着色器。多亏了Marek Olšák和Collaboran Faith Ekstrand的核心代码，驱动程序可以将变换反馈替换为显式存储到变换反馈缓冲区。这种方法比我们以前的技巧效率低，因为我们可能需要存储相同的数据两次。硬件设计师做出了一项权衡：优先考虑使用索引和间接绘制现代应用程序的性能，而不是使用变换反馈的旧应用程序。这可能是一个正确的决定。然而，变换反馈在OpenGL ES 3.0中是强制性的，因此我们需要支持它——即使牺牲性能——仅为了Zink。
另一个遗留特性也有类似的模式：触发顶点选择。
在片段着色器中，有两种方式可以访问顶点着色器的输出。通常，三角形每个顶点的输出会被平滑插值，以在每个像素处形成一个单一的值。然而，也可以使用平面着色（flatshading）：每个三角形的输出由单个“触发”顶点提供。
是哪个顶点？这取决于三角形中顶点的顺序。OpenGL使用最后一个顶点，而Vulkan使用第一个顶点。我们应该能够只指定一次API，因为在一个应用程序中这不应该发生变化。
不幸的是，OpenGL和Vulkan扩展允许更改触发顶点以模拟其他API。实际上，桌面OpenGL允许在每次绘制时更改触发顶点。在较老的马利（Mali）GPU上，驱动程序会在每次绘制时重新指定触发顶点。
但是Valhall不针对桌面OpenGL，因此Valhall驱动程序只能在每个渲染过程中指定一个触发顶点。我们的桌面OpenGL驱动程序必须在每个触发顶点更改时拆分渲染过程。这可以工作，但很慢。这个改动是在简化硬件与为旧应用性能之间进行权衡。
这没关系。工艺节点改进意味着新硬件通常比旧硬件更快，但软件是为现代硬件编写的，因此旧软件在新硬件上仍然很快。无论移除多少旧OpenGL的冗余来优化新应用，旧游戏都会保持流畅。
未来是Vulkan - Valhall拥抱了它。
1. Valhall保留了由软件分配的旧路径，但由于实例化时引入了额外的填充，因此不能用于变换反馈。旧路径是为2D工作负载设计的，而不是3D渲染。
