差不多要開始了 :-) 再 30 秒 ------------------------------------------------------------------ # 題目: Xorg 嶄新的硬體加速與效能提昇機制 (續集) 各位好，在下是 Jim Huang (黃敬群 / "jserv")，有幸能在此與各位朋友分享一些經驗。本次 IRC Conference 基本上是 FreeDesktop.org 與 X.org 嶄新發展介紹的進階議題，這裡假設與會的朋友已有上一場的經驗與認知，如果沒有，可以自行參閱過去的 IRC log： http://ircconf.debian.org.tw/ 感謝各位朋友抽空共襄盛舉，再來要感謝神奇的網路把物理距離遙遠的我們，能夠透過 IRC 作即時的交流。為了議程的連續性，每一小段落結束後，會提示 "Questions?"，屆時可進行討論，有任何問題或建言，請踴躍提出，但除此之外的時間，請讓主講者能連續發言，感謝合作。 --------------------------------------------------------------------- Copyright (c) 2006 Jim Huang . Verbatim copying and distribution of this entire article and materials (IRC log) is permitted in any medium, provided this notice is preserved. --------------------------------------------------------------------- 本議程延續上一次「Xorg 嶄新的硬體加速與效能提昇機制」的內容，本次 Debian@Taiwan IRC Conference 大綱如下： # 3D Rendering 與 DRI * 探索 3D Rendering 模型 * 既有硬體加速機制 * 迎向新紀元：Xgl 與 AIGLX # 實做層面的效能提昇今年七月份的 IRCConf 已經提及必要的 2D Rendering 的技術細節： http://ircconf.debian.org.tw/log/2006-07-05.html 這裡將進一步邁入 3D Rendering 與 DRI 的新紀元。 -------------------------------------------------------------------- [-] 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 的架構圖： http://gallery.debian.org.tw/2006-12-27/glx 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 的角度切入，搭配的圖示為： http://gallery.debian.org.tw/2004-12-02/dri_gram 這也就是所謂的 "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 一系列的技術變化也可說是往這個方向努力，並維持既有的相容性。 ------------------------------------------------------------------- Questions ? 等等，消化一下找個nopaste？ jserv--: Direct rendering 不走 X Protocol 所以才稱為 "direct" 是嗎？ kanru, 概念上不受 Protocol 限制，而可作 context <--> Hardware access/mapping，就是 "Direct" 2D Rendering 也有 "Direct" path 不過有趣的是，最後都得繞回 protocol engine 所以上面那個表格才會「看起來」一樣 2D Rendering 必須考慮到 Window/Resource Management 所以無論是 Indirect/Direct rendering 的開始或結束，必須得有一段 roundtrip 3D Rendering 的性質比較特別因為很多硬體都提出輔助的機制那也是後面要談的 :-) kanru, 這樣可以理解嗎？ * kanru 消化中想像一個 "Hello World" 的 X client 無論用何種 toolkit 都必定有 X "Window" 建立的動作如果不談 window manager 的影響 "Window" 的建立本身就是一種 protocol communication 的動作而在 "Window" 中的內容我們稱為 "Resource" 假設裡面印出 "Hello World" 字串該如何對應到螢幕顯示呢？ 2D Indirect Rendering ==> 先在 server-side 建立一份資料副本 ==> 然後透過 DDX 顯示 2D Direct Rendering ==> 呼叫 X extension，避免 client <--> server 不必要的資料傳遞，直接將該資料送給 DDX 因為繪圖的 command (in X protocol) 可以說是立即對應到 device (via DDX)，故稱 "Direct" 不過，很不幸的就算那個 "Hello World" 字串與文字可透過 Direct Rendering 顯示最後還是得透過 X protocol 來告知其 clip region 或相關的資訊因為我們得維持 window system 的一致性 ok jserv--: 可以問個問題嗎? Mat--, 請 Mat--, 別客氣 jserv--: 2D時, graph area overlay是不是由window system來處理. Mat--, 是的 jserv--: 那3d如走dri, window overlay的方面,是不是要覆蓋原先window system的功能? xorg 裡面一堆 fb / cfb 的程式碼就是處理 2D Rendering & window system 的部份 Mat--, 是的 Mat--, 現代的硬體都能作 h/w overlay jserv--: soga... Mat--, 不過早期的 3D impl 的確只能 work on fullscreen 好的，繼續 jserv--: 我知道了, 謝謝嘍:-) ------------------------------------------------------------------- 從實做的角度，我們來看看 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 應用程式在執行時期的行為。就目前的設計來說，分成： (1) from Mesa 虛擬的 GLX 實做可用於任何 X server 實做 (2) from XFree86/DRI 真實的 GLX 實做 GLX protocol encoder (3) from specific Vendor (像是 nVIDIA) 真正的 GLX 不走 DRI 也不走 Mesa，直接存取硬體 -------------------------------------------------------------------- Questions ? jserv--: 請問前輩，剛剛那個第一階段table裡面說X Protocol Decode -> GLX走的是Indirect，那我們輸入glxinfo出現的direct rendering: Yes 所代表的意義是? khwu-, 那是 3D Rendering h/w info khwu-, 簡單來說，GLX extension 找到真實的 GLX impl jserv--: 是否就是類似nvidia的作法？@@ 所以，有可運作的 DRI 或者 vendor-specific impl 或者，更簡單的說法就是，非 Mesa software rasterizer 嗯嗯，謝謝 -------------------------------------------------------------------- GLX extension 也稱為 libglx，在 X server 中透過 GLX protoco l 對應用程式提供 OpenGL context 服務，保留給硬體廠商實做或 Xorg 自行處理。NVIDIA closed source driver 即處理此動作，直接對應到硬體加速呼叫 ------------------------------------------------------------------- 補充一下所以，我們可以看到一些有趣的數字 glxinfo 會顯示的 (1) GLX protocol version (2) OpenGL version (3) DRI version 對一般的應用程式來，我們只看 OpenGL version 不過在 3D Desktop 中，這三者的版本都很重要會牽涉到其執行時期的行為這部份還有問題嗎？阿，是今天？哦，对 27 号了 jserv--, 赞～～大概有點概念 @@ khwu-, Good :-) khwu-, 慢慢來 jserv--: thanks ^^ 嗚嗚..看不懂... 先繼續 windtw, 稍後可以提問 ------------------------------------------------------------------- 接著我們繼續解釋名詞。 * 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 # 簡報：自由軟體授權分析阿，剛剛有電話抱歉 @_@ 繼續 ------------------------------------------------------------------ $ apt-cache search xdriinfo xdriinfo - X DRI information utility 可找到印列 DRI 資訊的工具程式，就一般個人電腦上的配置來說，可大致分為以下兩種輸出： (1) GL Vendor: SGI Sample Implementation - 以 SGI 於 2000 年一月釋出的版本為基礎 - OpenGL 1.2 API - GLX 1.3 - XFree86 4.0的一部分 (2) GL Vendor: nVidia - Proprietary / closed-source XFree86 4.0 driver for OpenGL 1.2 - 支援TNT*、GeForce*、Quadro等硬體 - 特性： * Direct Rendering * AGP 4x * NVIDIA extensions ----------------------------------------------------------------- Questions ? 補充一下由 xdriinfo 這個工具程式可以看到一些微妙的變化當我們安裝 Debian 時，如果使用 nVIDIA 的顯示卡預設會安裝 "nv" module 那麼，xdriinfo 會看到前者但我們自行更改為 nVIDIA proprietary "nvidia" module 時，就會看到後者雖然 OpenGL 應用程式仍可在兩種不同組態運作 (我是說一般情況) 但，巨觀與微觀來說，整個 control flow 就不一樣了 jserv--: @@ jserv--: hi jserv--: 請問一下你剛剛提到的授權問題... 為何 ATI 也是走 DRI/DRM ? FourDollars, 畢竟要像 nvidia 那樣作，相當複雜 FourDollars, 而且 ATI 過去將許多 hw spec 公開 jserv--: 言下之意是 ATI 選擇比較容易實作的方法? jserv--: 為何 hw spec 公開與 DRI/DRM 有關？ FourDollars, 因為 MMIO/ioctl 要寫在 kernel module 中 FourDollars, 包含對 GPU (Graphical Processing Unit) 的細部操作，在 DRI 架構下，都是寫在 DRM 中這讓我想到之前有人用 nVIDIA 的 GPU 來作科學運算 jserv--: ping WillH, pong WillH, use PM please. jserv--: 有幫我問了嗎 @_@ ok 好的，繼續 ----------------------------------------------------------------- 既然提到 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 jserv--: I pm from #ch**** ... ---------------------------------------------------------------- Questions ? jserv--: ATI 過去公開的 hw spec 可以在何處取得? FourDollars, ATI developers website FourDollars, 簽署表格即可 FourDollars, 另一種方式是讀 xorg source code FourDollars, 當 keithp 任職於 HP 時，取得很大部份的硬體資訊 jserv--: 嗯... 多謝... :) NDA...? jserv--: 請問前輩，GLX_ARB_multisample跟GL_ARB_multisample都擁有一樣的功能嗎？ jserv--: 都是ARB提供的?@@ khwu-, 問題不好 :P ARB 有點像是 RFC 但是更正式些 GL_ 開頭者為 OpenGL standard or ARB requested jserv--: 還是ARB只訂出規範..分別由GLX or GL實做出extension? GLX_ 開頭者則為 X specific 實做部份 jserv--: 嗯嗯 khwu-, 可以這麼說 priv, ATI 文件本身是 NDA jserv--: 謝謝^^" priv, 但是 driver 又是另一回事 oh priv, "form" 不一樣至少 ATI 的說法是這樣其實我對ATI沒什麼興趣..XD 而且我對graphics也沒研究不過 ATI 這幾年資助 X dev 頗多 jserv--: nVidia 呢？ FourDollars, nv 比較複雜 FourDollars, 很難用簡單的話語說清楚 FourDollars, 總之，nvidia 的束縛比較多，很多開發者得用逆向工程來完成 driver 但某些 developer 總是可以成功逆向工程，甚至做得比官方 driver 還穩定好，繼續 jserv--: 嗯... 這麼說來 ATI 的 driver 都是靠著 hw spec 做出來的 ---------------------------------------------------------------- Xgl 在 OpenGL 需要的 Extensions，列舉如下 (部份)： (1) GL_EXT_framebuffer_object - OpenGL/Mesa Off-screen Rendering - Framebuffer Object (FBO) - back buffer / pbuffers (for pixmaps) (2) GLX_SGIX_pbuffers http://gallery.debian.org.tw/Xorg-Hardware_Acceleration_Mechanism/pbuffer (3) GLX_EXT_texture_from_pixmap - binding redirected top-level windows to texture objects. XGL/compiz 為了圖形處理的加速，可以透過 GLX 更快的路徑，直接操作硬體，會透過 FBO (FrameBuffer Object) 與 pBuffer 來實現，不過在現實考量，則得考慮到 ATI、Intel，或者 nVIDIA 等硬體上不同的 extension 表現。 ---------------------------------------------------------------- (好像又講不完了) ccc Questions ? 好的，繼續 ---------------------------------------------------------------- 在 XGL 搭配 compiz (以 OpenGL 實做的 Window Manager 的 Composite Manager) 運作的情況，其架構圖可簡化為如下： http://gallery.debian.org.tw/Xorg-Hardware_Acceleration_Mechanism/xgl_arch_glitz 我們可以看到 X server 底層的 DDX (Device-Dependent X) 透過 glitz/OpenGL 直接驅動硬體的 3D 加速處理，這也是我們一直提到 "X-on-GL" 的表現。而深入來看則是： http://gallery.debian.org.tw/Xorg-Hardware_Acceleration_Mechanism/xgl_compiz_arch_glitz 我們需要留意的是，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 呈現出來。 --------------------------------------------------------------------- Questions? 補充一下，可以將上圖中 compiz 運作模式比照前述 control flow of 2D indirect rendering 可以發現，現在 OpenGL command 是直接送到 Gfx hardware 去看來是來不及打後面的 text 了用最快的速度解釋 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 所以更動的幅度比較大相容性也較差但效能上可有更具彈性的表現嗯，不知不覺就晚上十點了 Any questions ? 那麼今年度的 IRCConf 就到這裡告一段落了感謝各位上述未完的部份，將繼續在 IRCConf 2007 繼續 * kanru claps 原來現在是在IRCCOnf.. XD * jiing claps * khwu- (鼓掌) * FourDollars 帕~帕~帕~ * priv 啪啪啪啪啪啪 * lancetw 啪啪啪啪啪啪~ 啪啪啪啪啪啪啪～ * windtw 啪啪啪...(雖然聽不太懂= =") * whiteg 鼓掌 windtw, 可以具體說哪個部份嗎？ jserv--: 太多英文名詞@@ windtw, ok windtw, 像是哪些呢？我覺得 OpenGL 的部份比較難 jserv--: 很多...所以收集資料慢慢查= = 市面上可以找到一堆 OpenGL Programming 的書籍但是我還沒找到提到 OpenGL 怎麼跟硬體打交道的書最慘的是，連術語都不太一樣常常有看沒有懂 opengl 既已統一軟體的介面，為甚麼和X Server間還要有這麼多中介的架構呢?--- 抱歉，遲到了，或許這點一開始已經說過:p checko, hi checko, 相容性 checko, 這是 X 最高指導原則之一 checko, 如果你有閱讀 mailing-list，可以看到許多 optimization 因為會打破相容性，所以被 reject 相容性這曾不是由 opengl comformance test 負責? jserv--: 我还真以为会跟您一个月见不着呢.. orz checko, 不是這麼簡單 checko, GLX 有許多 Runtime behavior checko, 比方說 overlay checko, 這是得跟過去那些包袱綁在一起的再者，事實上，GLX 也是 network transparency 只不過在非 SGI 的硬體，通常是把這個功能關掉 fermi, hi jserv--: 您知道中国光缆断的事情吧？ checko, reference: MiniGLX, Mesa/Solo @@ 地震震斷