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