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 上下文）