M1 上符合规范的 OpenGL 4.6

总体反应

• 许多读者喜欢这篇文章，但觉得深入的 GPU/驱动细节不太容易跟上。
• 还有几位对这项工程投入和这一系列博客的教育价值表示强烈赞赏。

移植到 macOS / 使用 Metal

• 有人询问是否也能在 macOS 上获得类似的 OpenGL 4.6 支持。
• 提到的障碍包括：
  • Apple 缺乏稳定的公开内核 API，并限制第三方内核驱动。
  • 需要从用户态对接 Apple 的 GPU 命令提交机制，并与 macOS 的合成系统集成。
• 也有人认为，在 macOS 上，GL-on-Metal 层比完整自定义驱动更合理，但质疑为什么要为一个“遗留” API 投入如此多。
• 反方观点是：很多软件仍然依赖 OpenGL；有人认为 Apple 在正确支持它方面有一种道义责任。

Apple Silicon 上的 Asahi Linux

• 这个新的符合规范的 OpenGL 栈被视为一个重大里程碑；有人甚至称 Apple Silicon 现在是“最好的 Linux 硬件”。
• 也有人提出不同意见：
  • 就某些特定工作负载而言，macOS/Metal 仍然提供更好的性能，比如 Blender。
  • Asahi 还没有完全补齐功能：麦克风、一些省电功能和硬件视频解码仍不完整，不过相关工作仍在进行。
  • 作为日常主力系统是否合适也存在争议：有人说“还没准备好”，也有人表示自己已经成功全职使用。

技术路线与性能

• 主要成就是：在原生大致只映射到 OpenGL ES 3.1 的硬件上，实现了 OpenGL 4.6 的符合规范性。
• 缺失的功能（几何着色器、曲面细分、transform feedback 等）通过计算着色器和着色器技巧来模拟。
• 评论者将这与 Zink（OpenGL 跑在 Vulkan 之上）进行比较，并好奇这种“用功能实现功能”的技巧有多强的可复用性。
• 相较 Metal 的性能影响被承认是“视情况而定”，从讨论串里也无法完全看清，不过有人指出即便是“硬件”特性，很多也都是用微代码实现的，因此性能可能很接近。

OpenGL 与 Vulkan/Metal 以及 API 设计

• 争论点在于为什么先做 OpenGL，而不是 Vulkan：
  • 支持 OpenGL 的观点：这是一条从早期工作自然延伸的增量路径，对桌面/合成器立刻有用，而且开发者本身就有 GL 驱动经验。
  • 支持 Vulkan 的观点：Vulkan 是现代目标，而且已经有 GL 层，但这些层在底层仍然需要同样的功能工作。
• OpenGL 与 Vulkan 的易用性：
  • 许多人认为 OpenGL 对初学者和小型/独立项目容易得多；Vulkan 的样板代码和显式同步让人望而生畏。
  • 也有人认为很多 Vulkan 的“痛点”只是一次性的初始化工作，可以用库封装；对有经验的图形程序员来说，Vulkan 更受青睐。
  • 还有人觉得在 Apple 平台上，Metal 比这两者都更简洁、更容易用。

历史与生态

• 讨论到 Quake 和相关游戏如何推动 OpenGL 超越 CAD，进入主流 PC 游戏领域，同时也被 Direct3D 的崛起所制衡。
• 观点不一：
  • 有人认为 Direct3D 的 API 演进、工具和与 GPU 厂商的协作最终在 PC 上“赢了”。
  • 也有人强调微软过去试图边缘化 OpenGL，并指出 Direct3D 依赖 Windows/Xbox 锁定，使其不可能成为真正的跨平台标准。

OpenGL 的未来与跨平台图形

• 普遍共识是 OpenGL 实际上已经停滞：4.6 是最后一个版本，在 Apple 平台上已被弃用，而且在驱动中越来越多地被 Vulkan/Direct3D 分层实现。
• 尽管如此，很多人仍然认为 OpenGL 是：
  • 如今直接编写时最实用的跨平台 API。
  • 对许多非 AAA 场景已经足够且更简单，即使它不是前沿性能的最佳选择。
• 一些人预计，更高层、类似 OpenGL 的 API（例如建立在 Vulkan 之上或通过 wgpu、Zink 之类项目）对可访问性仍然会很重要。