Aros/开发者/OpenGLDev
AROSMesaXXX 是仍然受支持的旧 API，有一个新的 API 以 glAXXX 开头
- Nvidia Gallium 3D
- mesa.library - “旧” 库，发布 GL API，不再按 opener 库基础，现在是按任务 GL 上下文
- glu.library - “新” 库，发布 GLU API，以前此 API 通过 libGLU.a linklib（静态链接）可用
- vega.library - “新” 库，发布 OpenVG API，该 API 使用 Gallium3D 加速，以前不可用
- egl.library - “新” 库，发布 EGL API，以前不可用，这是一个用于上下文创建和控制的“本地” API
Extras:Demos/Mesa 中有两个新示例
- lion - EGL + OpenVG
- eglgears - EGL + OpenGL
请注意，glu、vega 和 egl 的 ABI（LVO）不是最终的，可能还会发生变化 - 将其视为 ALPHA 版本。如果您现在发布使用这些库的任何应用程序，请做好在某个时间点重新编译的准备。这些库将在移植 Mesa 7.10 后变得“稳定”。
- GL 应用程序想要创建 GL 上下文
- mesa.library 调用 gallium.library
- gallium.library 选择驱动程序，在本例中为 softpipe.hidd
- softpipe.hidd 加载，但首先需要加载 gallium.hidd（用于基类）
另一个主题是，与其他主题相同，一个 StormMesa 包装器，它可以调用尚未编写的 AROS 68k 版本的 Mesa.library（或反之亦然）。我认为我们应该做更简单的事情。我们应该将 mesa.library 转换为 StormMesa 兼容 API。仅此而已。我个人认为主要的 AROS mesa.library 应该使用 C 参数传递，这样我们就可以摆脱内部包装函数，从而提高速度。为了在 m68k 上向后兼容，可以提供适当的包装库，然后调用此库。我记得我曾经检查过 SDK。只需重命名库并更改 LVO 以匹配。Mesa 就是 Mesa，函数是相同的。您还可以使用 MorphOS 兼容 API。mesa.library 已经存在，它可以与 Nouveau 或软件 3D 驱动程序一起使用。它只需要扩展以支持更多硬件（这也包括托管环境）。
有一个想法是，不要使用基于 Gallium 的 Linux 托管驱动程序扩展 Mesa，而是为 Linux 托管提供完整的“GL 库”替换，它只包装主机 OpenGL 实现。虽然我对维护多个 OpenGL 实现感到不高兴，因为这会给我的工作带来维护开销，但我确实认识到，从功能角度来看，这比使用使用主机 OpenGL 的 Gallium 驱动程序要好得多。如果有人希望提供 stormmesa 或 tinygl，那么包装器是我现在能想到的唯一方法。虽然所有库都实现了相同的 OpenGL API，但每个库也有特定的上下文/缓冲区处理函数。这些函数是不同的，因为它们不受 OpenGL 标准的约束。这种差异不仅体现在表面上，还体现在设计层面上 - 例如，StormMesa 提供了 3 或 4 个具有公共字段的公共结构，理论上这些字段可以被某些现有软件修改。AROSMesa 只提供 1 个不透明指针，并向客户端隐藏所有实现细节。这些实现细节已经改变了 3 次，这意味着如果字段是公共的，则会破坏应用程序 3 次，或者无法接受 Mesa 的进步。
我个人认为，Linux 的包装器很有意义。虽然我是开源的坚定支持者，但 Nvidia 和 ATI/AMD 的封闭源代码 Linux 驱动程序通常支持更新的卡，并且比开源 Gallium/X 驱动程序性能更好。Linux 的包装器可以使主机 Linux 版本具有比 mesa/Gallium 本机版本更好的性能，并支持更多硬件。如果有人想编写主机包装器，他们需要提供 AROSMesa 函数，这些函数对于创建 AROS 兼容的 GL 上下文是必要的。这些东西在 OpenGL 中没有定义。是的，这就是我看到包装器创建的方式。它还需要实现与 mesa.library 相同的 AROSXXX 函数。我们现在可以使用 ABIV1 事务更改的唯一事情是命名 - 而不是 AROSMesaXXX，我们可以将它们称为 AROSGLXXX 以更通用。这也可以在 Mac 和 Windows 以及（Win）UAE 中完成，为 m68k 模拟程序提供非常好的 3D 性能。
我不会为了 m68k 而重命名它。但是，如果有人实际上承诺从事 Linux 托管包装器的开发，我就会重命名它。那么，拥有可能具有不同实现/打开不同实现的 gl.library 就会有意义。两个“mesa”和“wrapper”库都必须具有同步的 API 和 ABI，并提供兼容的 SDK（头文件 + linklibs）。现在，每次我移植 Mesa 时，我都需要进行相当广泛的回归测试以确保我没有损坏所有东西。使用此包装器，我还必须进行“交叉编译”测试 - 例如，使用“包装器”的 SDK 编译，然后使用“mesa”运行。我认为“包装器”本身的想法很有价值，对于托管环境来说，它会比 Mesa 中当前的 softpipe 好得多。我只是想确保大家明白，这与它相关的重复成本。
那么，我现在会采用最不侵入性的、面向未来的方法。重命名 mesa.library -> gl.library。将所有 AROSMesaXXX 重命名为 AROSGLXXX。如果虚拟 gl.library 在某个时候创建，它将替换“mesa”gl.library。Mesa 将进入后台。但是，API 仍然是 AROSGLXXX，SDK 不会改变。好的，但我确实预见到在编写 gl ABI 参考以用于 ABIV1 时，关于 AROSGLXXX 函数和 SDK 的一些更多讨论。我认为在将 ABI 固定下来之前，让不同的人查看它总是好的。
我个人会将函数调用切换到 C 参数传递，然后调用库 mesa_c.library。此切换将消除对库中存根和包装函数的需求。这是否会让我访问 Mesa 函数中的库？我还必须验证在使用 OpenGL 扩展（从 AROSMesaGetProcAddress 获取的函数指针调用库函数）时不再需要存根。是的，这是由 relbase 修补程序和 genmodule 中的 peropener 支持处理的。您应该能够使用 AROS_GET_LIBBASE 在库的任何位置获取 libbase。共享库的函数指针也由其处理；需要检查它是否处理了 gl.library 的所有极端情况。嗯，peropener 发出了警钟。libbase 不能是 peropener，因为支持库不能与它一起使用。它曾经是 peropener，但我不得不将其更改为单一，以便能够拥有 glu.library。
额外的挑战在于，AROS 从主机角度来看是一个进程，因此一次只能绑定一个 GL 上下文，但是每个在 AROS 下运行的 3D 软件都必须同时绑定自己的 GL 上下文。对于像这样优雅的黑客，我认为“一次只能有一个 3D 窗口”现在是可以接受的。当然，除非您想处理某种合成管理器。这更像是将命令发送到主机的 GL 的问题，而不是合成渲染结果的问题。我可能需要为每个 3D AROS 任务生成一个单独的 Linux 线程。单独的 Linux 线程将有它自己的 Linux GL 上下文，而 AROS 任务将通过队列将命令发送到此线程。但是，这很有可能会降低性能，尤其是在只有一个核心的机器上。
还有一些关于能够在 OpenGL 实现之间切换的讨论。这可以像一两个环境变量一样简单（第二个是支持的 OpenGL 版本）。然后，库 opener 例程只需检查环境变量。
我个人认为，让程序直接与 -lgl（或更合适的名称）链接会更好，然后打开一个虚拟库，例如 api/gl.library。程序必须与 -lGL 链接 - 这就是它的工作方式。
api/gl.library init 函数本身将查看配置并打开 mesa.library 并返回该 libbase。这样，我们可以更改机制的工作方式，而无需重新编译程序。
此机制乍一看是可以接受的，但需要一个概念验证。有些区域，在目前看来，我看到了潜在的问题
- 使用函数指针 - OpenGL 扩展
- ELG.library、GLU.library、OpenVG.library - AROS 3D 支持不仅仅是核心 OpenGL，还包括支持库 - 这些库需要继续工作，无论存在什么 GL.library
- OpenGL ES/ES2 API - 这些是针对“移动目标”的 GL API。它们也由 Mesa 提供，我打算在某个时间点将它们提供给第三方开发者。它们也必须在存在任何 GL.library 的情况下可用。
可能是您的系统上没有加载 gallium.hidd？接下来要检查的是可用内存 - 您需要至少使用 -m 256 运行 AROS 才能使 softpipe 工作（它需要大约 128 MB RAM 才能创建每个 GL 上下文）