Xorg 嶄新的硬體加速與效能提昇機制(续)

Xorg 嶄新的硬體加速與效能提昇機制(续) 作者: Jim Huang (黃敬群 / "jserv") 日期: 2009-06-29 本文是根据 jserv 于 2006 年 12 月 27 日在 ircconf.debian.org.tw 上的讲座整理而来的，本文延續上一次「Xorg 嶄新的硬體加速與效能提昇機制」的內容，继续讲解 X window 崭新的硬件加速与性能提升机制。

简介 本議程延續上一次「Xorg 嶄新的硬體加速與效能提昇機制」的內容，本次 Debian@Taiwan IRC Conference 大綱如下： 3D Rendering 與 DRI 探索 3D Rendering 模型 既有硬體加速機制 迎向新紀元：Xgl 與 AIGLX 實做層面的效能提昇 上一篇文章“Xorg 嶄新的硬體加速與效能提昇機制”已經提及必要的 2D Rendering 的技術細節，這裡將進一步邁入 3D Rendering 與 DRI 的新紀元。 演讲者：Jim Huang (黃敬群 / "jserv")。 演讲时间：2006-12-27 3D Rendering 與 DRI 2004 年開始，X Window System 面臨了史無前例的巨大變革，其中 3D Graphics 可說是帶動這一系列技術方案的推手。從 Sun Microsystems 的 Looking Glass 計畫整合 Java3D 與 Compositing GL X server 開始，XGL 在 2005 年首次展現於 X Developer Conference，隨後於 2006 年正式釋出 XGL 與 compiz 等創新技術，更引發 AIGLX 與 Beryl 等種種突破。就 3D Desktop 來說，也達到實用的境界， 試看 Beryl 提供種種美妙的視覺機制，完全不輸給 MacOS X 或 Microsoft Vista 的特效： http://www.beryl-project.org/ http://www.beryl-project.org/features.php 既然我們身處於這個技術巨變的時代，倘若只能依據國外的 HOW-TO 文件，一知 半解的安裝與設定軟體，而未能感受到這些技術背後的美妙與震撼，豈不是太可 惜了嗎？ 所以，今天我們先來探索 3D Rendering 模型。 需要注意的是，在這些目眩的特效背後，其技術細節也是多如牛毛，為了避免有 「見樹不見林」的遺憾，再看一次在 X Window System 中 3D Rendering 的架 構圖： OpenGL 並無限制於特定的 Window System 上，在 X Winow System 的 API 實 現則是 GLX，OpenGL rendering 時可挑選合適的visual format / attribute， 將OpenGL context 對應於特定 X11 Drawable。 在兩年前的 IRCConf「FreeDesktop.org 與 X.org 嶄新發展概況(續集)」 http://ircconf.debian.org.tw/log/2004-12-30.html 曾提及「一旦導入 X11/OpenGL 後，情勢就有很大的轉變」，這也是今日要探討的重心。 當時以 X Protocol 的角度切入，搭配的圖示為： 這也就是所謂的 "Control Flow"，在這錯綜複雜的架構中，3D Rendering 事實上是相對單純的。 重心在於 Indirect/Direct rendering，觀念列表如下： Indirect rendering program (2D): | Direct rendering program (2D): X Protocol Encode -> Protocol Decode -> | X Protocol Encode -> DIX -> EXA/XAA -> DDX Driver -> | Protocol Decode -> DIX -> Graphics Hardware | EXA/XAA -> DDX Driver -> | Graphics Hardware | Indirect rendering program (3D): | Direct rendering program (3D): X Protocol Decode -> GLX -> | Direct rendering (3D data) -> Mesa (including SW rasterizer) -> | 3D data -> Graphics Hardware DDX Driver -> Graphics Hardware | 由上可見，在 2D Rendering 的部份，變化不大，因為還是受限於傳統 client-server 架構的約束，但我們也在七月份的議程提到 XRender extension 與 EXA 在這方面的突破，不過呢，3D Rendering 的變化就相當大，上表右下方 的 control flow 即是最理想的情況，而 X.org 一系列的技術變化也可說是往 這個方向努力，並維持既有的相容性。 從實做的角度，我們來看看 Mesa 的硬體加速能力。 3Dfx 提出 Linux 上首次的硬體加速繪圖機制，透過 Mesa (GL 實做) + Glide (直接存取 3Dfx 硬體) 的方式來實現，但有 single-context 與僅能於 fullscreen 運作的缺點。隨後，Utah 大學在 XFree86 3.3.6 的基礎之上，提 出 GLX protocol，實做出非常受限的 direct rendering。而在 XFree86 4.x 提出的 DRI，才是目前我們採用的技術基礎。 為了加強與會朋友的印象，先行解釋相關的術語。 運作於 kernel mode 的部份有：DMA (Direct Memory Access)、AGP memory，以及 MMIO (Memory-mapped I/O) 2D XFree86 driver 則指傳統的 2D X Window System 3D DRI driver 提供 3D 硬體的支援 libGL.so：處理 GLX protocol 的細節，並載入 DRI driver DRI extension：處理 3D 繪圖所需資源管理與通訊 GLX extension：server-side GLX protocol handling / rendering [特別注意到以上三項，非常令人混淆。簡單來說，這是一個分工合作的設計] libGL：這是 API (Application Programming Interface) 層面的部份，也是決定 OpenGL 應用程式在執行時期的行為。 就目前的設計來說，分成： from Mesa：虛擬的 GLX 實做，可用於任何 X server 實做； from XFree86/DRI：真實的 GLX 實做，GLX protocol encoder； from specific Vendor (像是 nVIDIA)：真正的 GLX，不走 DRI 也不走 Mesa，直接存取硬體。 GLX extension 也稱為 libglx，在 X server 中透過 GLX protoco l 對應用程 式提供 OpenGL context 服務，保留給硬體廠商實做或 Xorg 自行處理。NVIDIA closed source driver 即處理此動作，直接對應到硬體加速呼叫。 補充一下，glxinfo 會顯示 GLX protocol version OpenGL version DRI version 對一般的應用程式來，我們只看 OpenGL version， 不過在 3D Desktop 中，這三者的版本都很重要，會牽涉到其執行時期的行為。 名词解释 我們解釋些名詞。 Direct OpenGL Context Direct Rendered 的 context libGL 可直接與控制硬體的3D driver溝通，而不必透過 GLX extension Indirect OpenGL Context 必須透過 GLX extension Accelerated Rendering 將 CPU-bound (Mesa) 的 3D 複雜運算移轉到 GPU/Hardware DRI (Direct Rendering Infrastructure) - OpenGL Context 的軟體集合 libGL (透過Mesa ==> swraster) libglx (透過Mesa) 一系列 3D 驅動程式的集合 DRM (Direct Rendering Manager) 本質是kernel module (menuconfig 裡面 character device -> drm) 管理對硬體的操控要求 nVidia的Linux driver設計不透過DRM (！) 附帶一提，nVIDIA 不走 DRI/DRM 除了其技術上的優勢外還有授權考量， 因為 X Window System / DRI is licensed under MIT X License， 但 Linux Kernel Module shall be licensed under GNU GPLv2。 有興趣的朋友可參考： http://blog.linux.org.tw/~jserv/archives/001247.html # 簡報：自由軟體 授權分析。 XGL/AIGLX 相关的 GL 项目 既然提到 3D Rendering，我們快速探討與 XGL/AIGLX 相關的 GL 項目，不過這 裡完全不會提到 OpenGL programming，而是針對實做層面。 OpenGL 既然是開放規格，允許不同廠商與團體實做 API，而官方則以 Conformance Testing 來驗證並確保相容性，其中 OpenGL ARB (Architectural Review Board) 就是相當有代表性的協調單位，以下簡稱 ARB，透過協調與合作 的方式，ARB Conformance Test 可界定標準 OpenGL 規範與建議實做的部份， 當然，各家廠商也可提出自己的專屬實做部份。這裡再提到一項重要的規範： Linux/OpenGL Base Standard (oglbase)，類似 LSB 的概念，但涵蓋 ABI 與 OpenGL Runtime。 OpenGL extension 是相當重要的項目，雖然只是「建議性」，但為了瞬息萬變、 永遠無法妥協的視覺需求，高階應用需透過這些 Extensions 來實現，換言之， extension 是在OpenGL 中實現新功能的方式，舉例來說： GL_ARB_multitexture GL_ARB_texture_env_add GL_ARB_multisample GL_ARB_texture_compression GLX_ARB_get_proc_address GL_EXT_blend_color GL_EXT_blend_subtract GLX_EXT_texture_from_pixmap Xgl 在 OpenGL 需要的 Extensions，列舉如下 (部份)： GL_EXT_framebuffer_object OpenGL/Mesa Off-screen Rendering Framebuffer Object (FBO) back buffer / pbuffers (for pixmaps) GLX_SGIX_pbuffers GLX_EXT_texture_from_pixmap binding redirected top-level windows to texture objects. XGL/compiz 為了圖形處理的加速，可以透過 GLX 更快的路徑，直接操作硬體，會透過 FBO (FrameBuffer Object) 與 pBuffer 來實現，不過在現實考量，則得考慮到 ATI、Intel，或者 nVIDIA 等硬體上不同的 extension 表現。 在 XGL 搭配 compiz (以 OpenGL 實做的 Window Manager 的 Composite Manager) 運作的情況，其架構圖可簡化為如下： 我們可以看到 X server 底層的 DDX (Device-Dependent X) 透過 glitz/OpenGL 直接驅動硬體的 3D 加速處理，這也是我們一直提到 "X-on-GL" 的表現。 而深入來看則是： 我們需要留意的是，XGL/AIGLX 是 "X-on-GL" 的架構，至於真正與使用者互動的部份，是 GL application，也就是 compiz 或者分支而出的 Beryl。由上圖可以發現，compiz/Beryl 本身也是貨真價實的 OpenGL 程式，但綁定許多不同層面的軟體元件。 compiz/beryl 同時也是 window manager 與 composite manager，但不同於傳統的 window manager (如 IceWM) 或 composite manager (如 xcompmgr)，除了透過 X Protocol 與 X Window System 通訊外，還使用了上述的 OpenGL extension，於是可用很直覺且有效率的途徑，將美妙的 3D Rendering 呈現出來。 可以將上圖中 compiz 運作模式比照前述 control flow of 2D indirect rendering，可以發現，現在 OpenGL command 是直接送到 Gfx hardware 去。 AIGLX 既然有 XGL，為何 RedHat 還要提出 AIGLX 呢？ 最主要的原因是，XGL 的設計 理念的確符合 X.org 發展趨勢， 但現階段採用 Xglx 不甚理想， 多了一層包 袱。 Xglx 顧名思義就是 X on GLX (請參照前述名詞解釋)。 Xglx 的工作原理是透 過一個普通的 X server，在其 GLX 上再運作一個 X server，也就是 Xglx。比 方說 $DISPLAY of Xglx 為 :99， 那麼 compiz 與其他 X client 就運作在該 display 中。 AIGLX 的 "I" 就是 "Indirect'，而 "A" 則是 "Accelerate"，所以就是希望連 同 Indirect Rendering 的部份也能硬體加速，所以比對兩者的架構來說只有細 微的差異。 但是，AIGLX 是修改底層 GLX/DRI driver 的機制， 達到不需要 Xglx 的包袱，並且加速原本 indirect rendering 的 control flow， 所以更 動的幅度比較大，相容性也較差，但效能上可有更具彈性的表現。 See Also http://ircconf.debian.org.tw/log/2006-07-05.log