對于Android開發者來說，基本不用關心圖形方案這些細節，你只要調用java的class，最后的性能都是有原廠和谷歌驗證過的。 但對Linux開發者來說，情況要復雜的多，沒有一個完美方案。。所以當你決定要在Linux要開發應用的時候，一定要明確你的需求,對比方案間的優劣。

小框圖：

X11

X11的基礎構架，建議先谷歌一下，太龐大，歷史遺留比較多，到現在我也沒弄清楚一些調用流程。下面主要講講dri2。dri2是xserver用來連接gpu的結構，下面這個鏈接里蠻詳細的。大概理解，dri2自己管理一個window下面的buffers， xserver都不會過問，只有swap front buffer的時候，才會調一些函數來wait page flip來進行畫面的同步。
不過這個front buffer是false的，要注意，最后顯示還要進行compoiste（以rk的xserver為例，這里會用到cpu blit， 而wayland和qt eglfs這步是gpu做的）。dri2全屏和不全屏的性能差距會比較大，因為全屏的情況下，dri2出來的flase front buffer，也就是這個window的drawbuffer， 是直接被作為全局的font buffer，送到ddx顯示的，省去了compoiste。
所以在x11下開發3d應用的時候，一定要全屏，保證沒有多余的compoiste，比如qt的qmlwindow就是一個完整的gl窗口（注：debian上不是）。另外一提，rk平臺上的xserver，還支持了glamor，意味一些compoiste可以被gpu加速到，如果是做多窗口的應用或者desktop類型的產品，這個featrue還是非常有用的，能運行x11上的所有軟件，又有gpu加速合成。

2017.3.10

做了些實驗，x11下egl的lag，在拉高cpu頻率之后，顯著的緩解，所以應該就是cpu參與了合成步驟，導致效率變低。

2017.5.21

在debian看到一些比較慢的現象，要注意不是x11的問題，而是debian的程序編譯選項一般沒帶上gles。

QT EGLFS

QT EGLFS是qt自己實現的一個gui系統，不支持多窗口，但也因此少了window compoiste。QT EGLFS和dri2的方式也差不多，區別就在于，qt eglfs的font buffer在自己用gpu compoiste后，是直接送給drm去顯示，而X里是送Window manager去做compoiste，所以EGLFS在效率上是有優勢的。另外除了QT，常用的UI庫里，SDL也是支持這種DRM+GL的方式的。

2017.3.11

QT EGLFS的流程其實可以通過代碼追蹤一下。根據代碼，一個qmlvideo的顯示過程會是這樣的(非qml的話不一樣，會優先用xvimagesink的subwindow)，surface路徑會是QDeclarativeVideoOutput->QDeclarativeVideoRendererBackend,顯示一幀frame的話，會先調用到QDeclarativeVideoRendererBackend::updatePaintNode，然后就是返回一個NV12 to RGB的shader，走正常qtquick程序的顯示顯示，最后QOpenGLCompositor會合成所有的window。Qt EGLFS的流程還是很清晰的，就是先window自己render(qquickwindow是用的GPU)一個buffer， 然后QOpenGLCompositor把所有的window再render到一個buffer上，然后這個buffer送drm顯示（如果就是一個primary window，就直接送drm了）。

Wayland

wayland是Linux上下一代的display server，從結構上來講，也最相近android上的HWC，全部的compoiste都是gpu來做的，不會有xserver那樣cpu合成的場景。wayland除了gpu合成以外，另一個優勢，就是overlay接口的存在，能允許移動平臺上的一些2d加速模塊，display模塊在這個接口上被調用（這些模塊才是移動平臺能跑大分辨率ui的關鍵）。wayland主要的問題是兼容性，比如你用qtmultimedia的話，會發現video sink不能換，因為不兼容wayland的窗口api。

應用場景

3d應用

3d應用的瓶頸最主要在計算單元上，拷貝，compoiste一類的開銷，根據具體場景再考慮。建議直接raw的drm api或者qt eglfs。

視頻播放

對視頻播放來說，拷貝，compoiste的開銷是決定性的。Spec上的視頻播放極限，比如rk3399,rk3288播放4k，rk3036播放1080p，基本上是不可能在通用框架，也就是走gpu實現的。 因為達到了芯片bandwidth的上限場景，如果讓gpu去拷貝和轉格式的話速度會很慢，必須要display的部分自己去處理顯示視頻數據。
但想讓display部分去處理的話，軟件上必須有對應的支持——-然而desktop based的gui framework大多缺失了這樣一個東西。之前在rk的系統上，我base X11做了一個“gstreamer sink” 。通過x的api獲取窗口的位置，然后直接drm的api，繞過X系統，overlay畫在窗口的位置。
這樣做確實可以發揮視頻播放的極限，主要的問題就是沒辦法和gui系統融合，沒辦法疊加控件，如果使用的場景都是fullscreen，可以試試這做。上文提了下wayland框架支持overlay，所以最理想的，還是wayland通過overlay的機制直接call的display單元顯示，像android那樣。
總結一下，所以如果視頻性能不是那么高，又需要復雜UI，建議用gpu的框架。qt eglfs，放視頻，按rk3288的性能，可以達到1080p 60fps。x11，gles在rk平臺的軟件上，測試下來，性能比較差;不過已經有rkximagesink的overlay顯示方案。wayland暫時沒有研究，理論上原生支持overlay的wayland是最好的，但是我覺得應該也就類似rkximageisnk的那種效果，不能和正常的窗口兼容。

Tips

libmali

libmali是mali gpu的userspace library，我也看不到代碼，完全是黑盒，只能說根據一些類似的代碼和文檔猜測他的實現方式。libmali有很多編譯選項，我猜的話，除了軟件硬件版本，還有下面兩種。一個是fbdev和gbm，分別對應了fbdev和drm兩種內核驅動的場景。fbdev對比gbm有幾個差異。
1.vblank用fbdev去跑on-screen的glmark，分數一般是要比gbm的高，原因就是這套流程沒有去等待vblank。gbm的實現都會在最后swap front buffer的時候等待vblank，所以on-screen只能跑幾十fps，fbdev的不會去等，因此fbdev的libmali on-screen的fps和off-screen的差不多。
2.zero-copy所謂zero-copy就是不拷貝texture。一段在內存里的texture，要讓gpu去使用，必須先用cpu把數據從這段內存拷到gpu能用的buf（dma-buf)里。如果這個texture數據本來就在一個dma-buf里的話，可以通過特定的api直接讓gpu load，從而避免拷貝。dma-buf在gbm上的實現，搜索EGL_LINUX_DMA_BUF_EXT就可以。在fbdev上的實現，比較麻煩，“fbdev zero-copy” 。還有就是display server的選項，比如xserver，比如wayland。 這個就是支持在display server下運行，沒什么好說的。

libdrm

drm的api分legacy api和新一點的atomic api，如果你直接用drm api開發程序，一定要注意這兩個api的區別。legacy api：drmModeSetCrtc， drmModeSetPlane， drmModePageFlip都是legacy的api，這些函數什么意思，怎么用，可以搜索下網絡資料。
大致上，drmModeSetCrtc包括了drmModeSetPlane包括了drmModePageFlip。在rk平臺上，drmModeSetCrtc和drmModeSetPlane都是atomic的，意味著你調用這些api后會一直block到vblank，drmModePageFlip是noneblock的，你調用后就會返回。
一般來說不在一個程序里順序調用會block的api，性能不會有太大問題。atomic api：legacy的api都是atomic的，而且容易重復調用，這就導致有些場景會很沒效率。比如wayland drm的場景下，有3個plane，每個周期內要更新這幾個plane，如果全用drmModeSetPlane的話，就意味著要等待3次vblank，那么一個60hz的屏幕，你的fps最高只會有20fps。
為了解決這種情況，我們就需要有一個api，能在一次調用里，解決掉所有的事情，比如更新所有的plane，然后只用等一次vblank。drmModeAtomicCommit，具體用法請谷歌。