<@kanru> jserv--, 要開始了嗎？ haha kanru, 快了 :) 好興奮!! 洗耳恭聽＠＠ kanru, 十五秒後開始 --------------------------------------------------------------------- --------------------------------------------------------------------- 15 14 13 12 11 1 :P --------------------------------------------------------------------- # 時間: July 5, 2006 (週三) 20:00-21:30 台北時間 # 題目: Xorg 嶄新的硬體加速與效能提昇機制各位好，在下是 Jim Huang (黃敬群 / "jserv")，有幸能在此與各位朋友分享一些經驗。本次 IRC Conference 基本上是 FreeDesktop.org 與 X.org 嶄新發展介紹的進階議題，這裡假設與會的朋友已有上一場的經驗與認知，如果沒有，可以自行 <-- cookys has quit (helium.oftc.net xenon.oftc.net) <-- whiteg has quit (helium.oftc.net xenon.oftc.net) <-- jouston has quit (helium.oftc.net xenon.oftc.net) 參閱過去的 IRC log： http://ircconf.debian.org.tw/ 感謝各位朋友抽空共襄盛舉，再來要感謝神奇的網路把物理距離遙遠的我們， «IRCConf» http://tinyurl.com/4stwl 能夠透過 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. --------------------------------------------------------------------- 今年五月 23 日，小弟應 TOSSUG (台北開放原始碼軟體使用者社群 / Taipei Open Source Software User Group)[1] 之邀，作心得分享，題目是「Linux 3D 技術：淺談 DRI / GL Acceleration、Xgl、AIGLX 以及相關技術發展」，涵蓋三個大方向： * User Interface概況 * 為何要 3D？ * 快速釐清觀念： Mesa/GL DRI / DRM / Framebuffer GLX / GL extension Direct / Indirect GL、3D Acceleration * Xgl、AIGLX 與相關技術探討 * 3D：究竟是 Eye-candy 還是未來？感謝與會朋友的捧場，當時也引來一些有趣的討論，於是小弟決定透過 IRC Conference 的方式，作進一步的技術分享與交流，該次演講的 slides 已開放下載： http://jserv.sayya.org/freedesktop/linux-3d-technologies.pdf 另外，去年應 TnLUG / StudyArea 之邀的演講「綜觀 X Window System 新發展」，探討了 X Window System 的基本概念、X Extension、Linux Desktop 的設計議題，以及進行中的技術突破項目，也可當作本議程的參考，其 slides 也開放下載： http://jserv.sayya.org/freedesktop/x-dev-2005.pdf [1] http://wiki.tossug.org/ 而本次 Debian@Taiwan IRC Conference 大綱如下： # X Window System 的 Transport 效能與改善議題 «TOSSUG - TOSSUG Wiki» http://tinyurl.com/kfw6x # 2D Rendering 的突破 * XFree86 4.x 的 Render extension * XAA 與其限制 * 嶄新的 EXA 與設計概念 --> jouston (~jouston@59-105-136-199.adsl.static.seed.net.tw) has joined #dot --> whiteg (~whiteg@xen5.ttul.org) has joined #dot --> cookys (~cookys@220-134-232-80.HINET-IP.hinet.net) has joined #dot # 3D Rendering 與 DRI * 探索 3D Rendering 模型 * 既有硬體加速機制 * 迎向未來：Xgl 與 AIGLX # 實做層面的效能提昇 --------------------------------------------------------------------- [-] X Window System 的 Transport 效能與改善議題咱們先來複習過去提到 X Window System 種種變革的基礎。在許多層面，現在的 Xorg (X Window System Reference Implementation) 已經跳脫傳統 Client- Server 的架構了。Client / Server 架構下使用相當緩慢的 transport 機制，從 Client 端將 rendering 指令，送到 Server 端，這在普通的應用來說，已經足夠了，但是對於 2D / 3D Graphics 顯然是很大的效能瓶頸 -- 耗費太多時間在 round-trip (繪圖指令的往返) 通信上，回頭看看過去的示意圖： http://gallery.debian.org.tw/2004-10-21/x_arch_comparison X Window System 的設計不像傳統的 GUI system，反而跟關聯性資料庫的架構神似，因為考慮到網路的通透性 (network transparency)，將 primitive graphical operations 包裝成一個又一個的指令，其中的 transport engine 則需要額外的 decode 動作，然而，在圖形應用日趨複雜的今日，開發者展開了新的思索：能否提供更為直覺、簡單的設計，讓 X client 可以直接與圖形硬體裝置對話、進而充分發揮硬體加速的能力 (2D / 3D 基本操作、OpenGL、MPEG-2/4 Acceleration) 呢？直接與硬體溝通的 Graphics Toolkits / Window System 相繼被提出，也有不錯的效能表現，比方說 DirectFB[2] 與 KGI[3]，但是在 X Window System 的設計原則，是希望透過層層的架構，讓硬體能夠抽象化，是否意味著我們將無法以更好的效能處理 2D /3D Graphics 呢？這是個相當大的挑戰，一方面要能處理硬體，另一方面要保留既有 X Window System 的相容設計原則，也就是 1987 年 X 第 11 版 (X11) 這個重要里程碑的 Protocol / API 相容性，於是 XFree86 Developer 提出 DRI (Direct Rendering Infrastructure) 的機制。 <-- ducati_ has quit (Quit: 暫離) [2] http://www.directfb.org/ [3] http://www.kgi-project.org/ - Kernel Graphics Interface <-- kanru has kicked bibot3 from #dot (bibot3) 以 Linux kernel 來說，make menuconfig 中 Device Drivers-> Character devices-> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) 此 DRM (Direct Rendering Manager) 即運作於 kernel-level 的 driver，隨後在 X server 層面實做 DRI 並適當驅動 (/etc/X11/xorg.conf 中 Option "RenderAccel") 後，即可展現 DRI 的威力，至於詳情，在上一場 IRC conference 「FreeDesktop.org 與 X.org 嶄新發展概況(續集)」已經提過。簡單來說，X Window System 的 Transport 效能改善因素是廣泛的，為了徹底解決既有的問題必須考慮以下議題： . 硬體的驅動程式 . 支援 Xorg 種種變革的新 Driver Framework，如 EXA 與 XGL --> SuperMMX (~SuperMMX@222.67.46.31) has joined #dot . DRI/Mesa 對 Indirect rendering 與 EGL 的支援至於 EXA、XGL、EGL，以及 indirect rendering 等新名詞，稍後會提及，接下來我們要探討 2D Rendering 的突破。 --------------------------------------------------------------------- Questions ? --> richliu (~richliu@218-168-166-82.dynamic.hinet.net) has joined #dot --> paulliu (~paulliu@176.249.192.210.dynamic.ttn.net) has joined #dot 前面的開場白，假設都能理解 <@kanru> 慢點.. <@kanru> cc 接下來就是重頭戲了 :) * sunmoon1997 期待中。。。 * sunmoon1997 :D --> Checko (~chatzilla@61.58.184.110) has joined #dot * tsaikd 眼花撩亂...Orz 簡報好像無法下載 yungyuc, 是的，server 出問題 :( 先繼續好了 -- [-] 2D Rendering 的突破 2003 年，X.org 的領導人物 James Gettys 與 Keith Packard 共同撰寫了 "The (Re)Architecture of the X Window System"[4]，自始展開了這幾年 X Winow System 與 FreeDesktop 重大的突破，有幾個重點： . Text and Graphics . Cairo . Accessibility and Eye-Candy . OpenGL based X . Kernel support for graphics cards . Housecleaning and Latency Elimination and Latency Hiding 在這幾年的光影都有了頗大建樹，這些突破中，首要要克服的問題，都始於 X11 2D bit-blit 為基礎的 text 與 graphics system 設計。所謂的 bit-blit 也稱 BitBLT 或 Bit Block Transfer，示意圖可參考： http://gallery.debian.org.tw/Xorg-Hardware_Acceleration_Mechanism/blit 原文的解釋為 "Copy image data (eg. copying a surface on another), applying image combination operations."，對於基本的繪圖操作雖游刃有餘，然而，圖形處理是人類視覺永無止盡的妥協與突破，光是 text 的部份，一旦需要作 antialiasing 或 vector graphics，或者 gradient 一類的操作，不僅功能有所不足，原本處理的效能更是低落，不得不引入新機制以克服這些問題。 [4] http://keithp.com/~keithp/talks/xarch_ols2004/xarch-ols2004-html/ ?? 隨著 GPU (Graphics Processing Unit) 的突飛猛進，ATI 與 nVIDIA 的繪圖顯示卡早已突破百萬個電晶體的數量，之所以有如此複雜的硬體支援，超過九成是針對 3D / OpenGL 的需求，以下是 SGI (Silicon Graphics, Inc.) 規範於 OpenGL graphics system 的圖例： http://gallery.debian.org.tw/Xorg-Hardware_Acceleration_Mechanism/opengl_key_operations 較為先進的硬體，甚至是手持裝置的繪圖晶片，都在硬體層面實現了這一系列的基本操作，包含 Vertices、Primitives，以及 Fragments 的支援，姑且不探究細節，這些都是所謂的 3D pipeline，然而，沒有在架構上作突破的 X Window System 是完全無法使用到這些機制，換言之，過去頂多只使用不到一成的硬體設計。說到這邊，有個迷思需要澄清：既然常見的桌面系統，如 KDE、GNOME、XFCE，或其他輕量級的軟體組合，都還僅限於 2D 操作，那麼探討 3D 與硬體加速的議題，是否有意義呢？事實上，2D 的螢幕，本身就是一個 surface，而 "surface" 這詞在圖學中就是表示允許繪圖操作的單元，就現在輸出裝置與投影的系統來說，3D / OpenGL 硬體最終的描繪就是普通的 2D 平面，而在前述的 3D pipeline 與 Kery operations 中，其實涵蓋了硬體層面的支援項目。 --------------------------------------------------------------------- Questions ? <@kanru> 請繼續 :) 這裡補充一下 gradient http://blog.linux.org.tw/~jserv/archives/001444.html 之前我做的一個實驗 based on Xorz/Embedded <-- rocfatcat has quit (Read error: Connection reset by peer) 簡單來說，gradient 是文字或圖樣中，顏色平順的變化好的，繼續 -- --------------------------------------------------------------------- 具體來說，XFree86 4.x 的 Render extension 是 2D Rendering 突破的第一步。2000 年時，當時是 XFree86 core team member 的 Keith Packard 在既有 XFree86 的 codebase 為基礎，加入 X Render extension，最早要克服的議題就是 antialiased text，運作中的 anti-aliasing text 可參考以下展示： http://gallery.debian.org.tw/Xorg-Hardware_Acceleration_Mechanism/antialiasing_text 為了滿足進階繪圖的需求，實做於 X server-side 的 X Render 增加了 Porter- Duff operation，也就是在 1984 年 Thomas Porter 與 Tom Duff 合著的 "Compositing Digital Images"[5] 中描述 12 則基本規則的集合，簡單來說，這些基本的 Alpha 合成規則，將源色與目標色組合，在圖形和像素中，實現了混合與透明的效果，示意圖如下： http://gallery.debian.org.tw/Xorg-Hardware_Acceleration_Mechanism/porterduff [5] SIGGRAPH 84, 253-259 這些操作允許 surface 以許多不同的途徑或規則作結合，類似 OpenGL 的規範，這也使得除了 anti-aliasing text 外，X Render 逐漸用於進階的繪圖應用中。附帶一提，FreeDesktop 有個計畫 glitz[6] 可視為 OpenGL 硬體加速版本的 X Render 實做，除了 X Render extension 規範的 component alpha 與 image transformations 外，glitz 還添增了 convolution filters 與 color gradients 支援，因為這些重要的特徵，Cairo Graphics[7] 與 Xgl 都大量使用 glitz。 [6] http://www.freedesktop.org/wiki/Software/glitz [7] http://www.cairographics.org/ 重點回顧：X Render extension 的特徵： * 延伸 X Drawable 型態並擴展為 Picture 型態 * 增加 Alpha channel * 增加 (選擇性) 座標轉換 * Server 端的 Rendering * 提供新的途徑以做出原始 Picture 與 mask'ed Picture 間的合成處理 - 矩形區域 - 三角區域 - 不規則區域 - "Component alpha" 概念 --------------------------------------------------------------------- <-- candyz has quit (Ping timeout: 480 seconds) Questions ? <@kanru> 『大量使用 glitz』? <@kanru> 好像不太能用 :-/ kanru, glitz 需要 OpenGL / DRI 的驅動在一般的 distribution 為求穩定性可能會直接 turn off --> RT (~roger1_ts@220-133-92-144.HINET-IP.hinet.net) has joined #dot 稍後會繼續談 glitz <@kanru> 嗯.. ok --------------------------------------------------------------------- 這裡將 glitz 也歸類於 X Render 中，glitz 的主要開發者 David Raveman 撰寫一篇重要的論文 "Glitz: Hardware Accelerated Image Compositing using OpenGL"[8] [8] http://www.cs.umu.se/~c99drn/opengl_freenix04.pdf 在探討細節之前，先看看 Cairo、Glitz，以及 OpenGL 這三者的關係圖： http://gallery.debian.org.tw/Xorg-Hardware_Acceleration_Mechanism/glitz_cairo_hierarchy Cairo (舊稱：Xr 或 Xr/Xc) 是個 vector graphics library，除了向量繪圖操作外，Cairo 的設計允許多種設備的交叉輸出，就目前的實做 (cairo-1.2) 來說，支援 Xlib、in-memory image buffer、Glitz/OpenGL、PNG、PostScript、PDF、 GDI (Win32)、Quartz (Mac OS X)、SVG，以及 XCB (X C Binding) 等。Cairo 的目標就是在多樣化的輸出裝置提供一致的輸出結果，並支持硬體加速的機制，舉例來說，在 X Window System 上會透過 X Render extension 或 Glitz，而允許的操作有描線、貝氏曲線、平面轉換、圖像透明度合成、anti-aliasing、... 等。除了 Gtk+ 2.8 採用 Cairo 作為底層 GDK Graphics 的基礎外，Mozilla/Firefox 在 Version 2.0 中，也採用 Cairo 作為跨平台的 vector graphics engine，即著眼於前述的特徵。對了，Cairo 開發團隊中有位大陸的 committer，做了很多 text 方面的改良，日前也實做了中文直排的基本支援。 --------------------------------------------------------------------- sunmoon1997, 這樣寫沒錯吧 :-) jserv--, 没有:) sunmoon1997, 要不要順便談談 Cairo 在多國語文的議題呢？支持 sunmoon1997, 理論上 CJK text layout 是不是都能在 Cairo 支持呢？ jserv--, 这个倒没啥。cairo 做的主要是最基本的。 sunmoon1997, 我有另外一個問題 sunmoon1997, Firefox 2.0 採用 Cairo 作為 vector graphics engine sunmoon1997, 那 text engine 會不會直接採用 Cairo 呢？ jserv--, 似乎是 cairo + pango sunmoon1997, 喔如果用的 toolkit 是 gtk-cairo. sunmoon1997, pango的cairo后端和freetype后端有很大区别吗？ jac, 不知道。。 hmm * jserv-- 先記錄下來好的，我們繼續 :-) * FourDollars 趕上~ cairo 做得事情都是很基础的。 --> alicekey (~alicekey@59-112-171-71.dynamic.hinet.net) has joined #dot --------------------------------------------------------------------- 這裡用簡單的例子展示 Cairo 的 programming model，作為向量繪圖的說明。原本 Xlib 中的 int XDrawLine(Display *display, Drawable d, GC gc, int x1, int y1, int x2, int y2); 以 Cairo 繪圖的思維則是： cairo_move_to (cr, x1, y1); cairo_line_to (cr, x2, y2); cairo_stroke (cr); Cairo 被賦予的使命是如此重大，Glitz/OpenGL 也被視為 FreeDesktop 效能的指標之一，前面提過 OpenGL graphics system，這裡再詳細看看 OpenGL Rendering pipeline： http://gallery.debian.org.tw/Xorg-Hardware_Acceleration_Mechanism/opengl_rendering_pipeline David Raveman 的論文詳細探討了 Glitz 的實做模式，而這裡簡述 Glitz 利用 OpenGL rendering 達到圖形加速的方式： (1) Offscreen Drawing 透過 OpenGL 的 pixel buffer (pbuffer) 處理 offscreen drawing 需要注意的是，理想情況下，pbuffer 的操作完全是儲存於 video memory http://gallery.debian.org.tw/Xorg-Hardware_Acceleration_Mechanism/pbuffer (2) User-Provided Immediate Data 提供直接存取圖形硬體的 API / Data 操作 (3) Image Compositing 將 surface 視為 texture，再以 OpenGL 的 fragment programs 來實做混合多個 textures 的操作 [按] 原文 - Fragment programs allow for fragment level programmability in OpenGL, and in combination with multi-texturing, Glitz can perform composite operations with a mask surface very efciently. (4) Image transformations OpenGL 的強項，Glitz 完全採用 OpenGL 來實現 [Performance] 的部份探討了 Glitz 相較於 Enlightenment imlib2 與 X Render extension，結果 Glitz 在許多操作都有優越的表現，而透過 nVIDIA binary driver 來驅動 X Render extension 並與 Glitz 比較，後者仍略勝一籌。 --------------------------------------------------------------------- Question ? 再補充一下 X Render 一開始雖然設計為解決 X 上實現 anti-aliasing text 的問題後來廣泛應用在許多 graphics OP OP? 就現在的桌面應用來說，可以說繪圖動作大都耗費在 Render extension 中 OP = operation thx 比较慢 :P <@kanru> 比較慢？ <@kanru> 跟誰比呢？ <@kanru> glitz? glitz 不僅引入 OpenGL 的思維，還試圖以 OpenGL 來改進 X Render kanru, X Render 通常比较慢，没有加速。這一段要解釋的話，很花時間，很多 OpenGL 的術語第一次看到這些術語，請不要被嚇到 <@kanru> 嗯請記住一點，現代的繪圖硬體對 3D 有很強大的支援 90% 的電晶體都在實做這些 Render 很多動作都是軟體實現 --------------------------------------------------------------------- 意思是用 3D 會比 2D 快嗎?? 看硬體設計吧? paulliu, 應該說，要提出一個機制讓不必要的 CPU bound 移轉到 GPU 過去的設計是沒有機會意思是現在的硬體傾向以3D 為優先最佳化? 另一篇值得參考的文獻是 Keith Packard 的論文 "Getting X Off The Hardware"[9]，主要是探討將硬體相關的函式庫抽離出 X server 的可能性，並舉 KDrive 的開發過程中，Eric Anholt 利用既有 ATI Radeon DRI driver 來加速 2D 繪圖操作的實驗，給定兩個圖形硬體支援可能的方向： . With an OpenGL-based X server . With a 2D-only X server based on a simple loadable driver API. 而 Glitz 也在 [Graphics Acceleration] 中被提及，作為 OpenGL 加速 2D 顯示的效能與可行性。 [9] http://keithp.com/~keithp/talks/xserver_ols2004/xserver-ols2004-html/ --------------------------------------------------------------------- 補充一下，Eric Anholt 是 X.org 中 ATI driver 的維護人、FreeBSD committer Questions ? With a 2D-only X server based on a simple loadable driver API 指普通的X server? jacky, 比較像是 Xgl 現在的作法 Xgl 的遠程目標是 X on GL 但是目前處於一個過度因為 X on GL software stack 還沒有穩定到可以使用那 OpenGL-based X server 呢？我以为xgl就是 OpenGL-based X server 所以，Xgl 的務實作法是 Xglx 也就是 Xgl on GLX jacky, 是那樣沒錯，以 OpenGL + OpenGL driver 改寫 DDX Xgl on GLX 的好處是 <-- Nouk has quit (Quit: Computer goes to sleep!) 無論底層 X 有多 weak What does DDX stand for ? 只要 loadable module on user space 能夠驅動這樣還是有機會直接驅動硬體 DDX = Device-Dependent X Quaternion, 2004 年的 IRC Conference 有提過 oh, thanks. 回去补课所以呢，Xgl on GLX 的設計，最底層的 X 只是為了滿足 X protocol 而在 Quaternion, :) 那就先繼續了 --------------------------------------------------------------------- 之前的 IRC Conference「FreeDesktop.org 與 X.org 嶄新發展介紹」提過 "X-on-GL" (or X-over-GL) 的概念，而 X Developer Conference[10] 2006 中， NVIDIA Corporation 的代表 Andy Ritger 在議程中，歸納 "The X-on-OpenGL Model" 有以下考量： . Motivated partly by lack of hardware-acceleration of the Render extension - A successful implementation of X-on-OpenGL, Xgl, is in progress . Replace XFree86/X.Org DDX with DDX that renders using OpenGL . No hardware-specific X driver - Instead use hardware-specific OpenGL driver . Traditional X driver tasks (rendering, modesetting) handled by X-on-OpenGL DDX - X-on-OpenGL DDX calls stand-alone OpenGL driver to perform low-level rendering and modesetting [10] http://wiki.x.org/wiki/XDevConf 在 X-on-GL 中，DDX (Device-Dependent X) 被大量替換成 OpenGL 與其 driver 的實做，對硬體來說，整個 X server 就是一個 OpenGL context 的 owner，系統架構如下圖： http://gallery.debian.org.tw/Xorg-Hardware_Acceleration_Mechanism/xgl_arch_glitz 就目前的實做來說，Novell 主導的 Xgl (實際上採用 Xglx) 是朝這個方向開發，而 nVIDIA 也在 DDX 與 hardware-specific OpenGL driver 的部份，提供 native Linux 的支援。在 Novell Xgl 搭配 compiz (以 OpenGL 實做的 Window Manager 的 Composite Manager) 運作的情況，其架構圖可簡化為如下： http://gallery.debian.org.tw/Xorg-Hardware_Acceleration_Mechanism/xgl_compiz_arch_glitz 具體運作的內容，稍後會作介紹。但是我們也可從架構看到一個重點：以往的 X11 Application (X client) 執行任何 primitive graphics operations 時，都需要透過 DIX 作 protocol engine 的 decoding，接下來這些解譯過的 command 才依據內容需求，透過 DDX 與 X Device Driver 來對硬體要求作繪圖操作，然而，compiz 雖然本質上是個 X client，但我們可從架構圖看出，compiz 為了圖形處理的加速，可以透過 GLX 更快的路徑，直接操作硬體，如圖中的 FBO (FrameBuffer Object) 與 pBuffer。 --------------------------------------------------------------------- Questions ? (大概是本次 conference 最難的部份了) 难的不懂... 所以也提不出问题了 :P 簡單來說，需要把過去 X client-server 的想法屏除儘管很多部份還是 client-server 設計 --> lancetw (~lancetw@219-68-241-121.adsl.dynamic.giga.net.tw) has joined #dot 不過呢，路徑卻有全然的改觀那就不能在网络上运作了吗？ jacky, 是的，這是一個問題如果是走 X11 protocol, 看起來沒影響啊的確有些 Window System 的設計是 OpenGL-based，但是還能滿足 network transparency 但是，就 X11 最近的改變來說 --> hers (~bbbush@222.248.205.111) has joined #dot 很難也同時滿足高效能的繪圖與 network transparency 投影片的內容是不是說X11 protocl和 GLX protocl雖然都經過Xserver，但是XServer會區分出兩者? 而採用不同的硬體控制方法? Checko, 對 Checko, 但是差別在於如何 decode X11 protocol 的 decoding 是全面的 GLX protocol 事實上只是轉包的動作 GLX protocol 只要在 GLX extension 可配合的情況下，會轉包給 Mesa/GL 與硬體參考資料不用經過XServer ? (socket ) ---> http://docs.hp.com/en/B6196-90001/ch04s02.html Checko, 其實都要，但是 transport 的介入層面有差別 Checko, 其實比較好理解的方式，是去看 X11 protocol analyzer 或 recoder 的 log OK :) Virtual GLX (VGL) 的設計很特別，可以說是讓 OpenGL 跨越網路限制 jserv--, 我觉得网络透明用XUL和widget server会好些 --> candyz (~candyz@dns.kandix.idv.tw) has joined #dot 除非 Xorg 也朝這個方向努力，否則 X-on-GL 與 network transparent 會存在相容問題 widget server: http://starynkevitch.net/Basile/guisdoc.html jacky, 不過那樣包裝就太多層了而且就不能以 GL or DirectX acceleration 的角度去設計系統