如何選擇Embedded Linux的圖形框架

對(duì)于Android開(kāi)發(fā)者來(lái)說(shuō)，基本不用關(guān)心圖形方案這些細(xì)節(jié)，你只要調(diào)用java的class，最后的性能都是有原廠(chǎng)和谷歌驗(yàn)證過(guò)的。 但對(duì)Linux開(kāi)發(fā)者來(lái)說(shuō)，情況要復(fù)雜的多，沒(méi)有一個(gè)完美方案。。所以當(dāng)你決定要在Linux要開(kāi)發(fā)應(yīng)用的時(shí)候，一定要明確你的需求,對(duì)比方案間的優(yōu)劣。

小框圖：

X11

X11的基礎(chǔ)構(gòu)架，建議先谷歌一下，太龐大，歷史遺留比較多，到現(xiàn)在我也沒(méi)弄清楚一些調(diào)用流程。下面主要講講dri2。dri2是xserver用來(lái)連接gpu的結(jié)構(gòu)，下面這個(gè)鏈接里蠻詳細(xì)的。大概理解，dri2自己管理一個(gè)window下面的buffers， xserver都不會(huì)過(guò)問(wèn)，只有swap front buffer的時(shí)候，才會(huì)調(diào)一些函數(shù)來(lái)wait page flip來(lái)進(jìn)行畫(huà)面的同步。
不過(guò)這個(gè)front buffer是false的，要注意，最后顯示還要進(jìn)行compoiste（以rk的xserver為例，這里會(huì)用到cpu blit， 而wayland和qt eglfs這步是gpu做的）。dri2全屏和不全屏的性能差距會(huì)比較大，因?yàn)槿恋那闆r下，dri2出來(lái)的flase front buffer，也就是這個(gè)window的drawbuffer， 是直接被作為全局的font buffer，送到ddx顯示的，省去了compoiste。
所以在x11下開(kāi)發(fā)3d應(yīng)用的時(shí)候，一定要全屏，保證沒(méi)有多余的compoiste，比如qt的qmlwindow就是一個(gè)完整的gl窗口（注：debian上不是）。另外一提，rk平臺(tái)上的xserver，還支持了glamor，意味一些compoiste可以被gpu加速到，如果是做多窗口的應(yīng)用或者desktop類(lèi)型的產(chǎn)品，這個(gè)featrue還是非常有用的，能運(yùn)行x11上的所有軟件，又有g(shù)pu加速合成。

2017.3.10

做了些實(shí)驗(yàn)，x11下egl的lag，在拉高cpu頻率之后，顯著的緩解，所以應(yīng)該就是cpu參與了合成步驟，導(dǎo)致效率變低。

2017.5.21

在debian看到一些比較慢的現(xiàn)象，要注意不是x11的問(wèn)題，而是debian的程序編譯選項(xiàng)一般沒(méi)帶上gles。

QT EGLFS

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

2017.3.11

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

Wayland

wayland是Linux上下一代的display server，從結(jié)構(gòu)上來(lái)講，也最相近android上的HWC，全部的compoiste都是gpu來(lái)做的，不會(huì)有xserver那樣cpu合成的場(chǎng)景。wayland除了gpu合成以外，另一個(gè)優(yōu)勢(shì)，就是overlay接口的存在，能允許移動(dòng)平臺(tái)上的一些2d加速模塊，display模塊在這個(gè)接口上被調(diào)用（這些模塊才是移動(dòng)平臺(tái)能跑大分辨率ui的關(guān)鍵）。wayland主要的問(wèn)題是兼容性，比如你用qtmultimedia的話(huà)，會(huì)發(fā)現(xiàn)video sink不能換，因?yàn)椴患嫒輜ayland的窗口api。

應(yīng)用場(chǎng)景

3d應(yīng)用

3d應(yīng)用的瓶頸最主要在計(jì)算單元上，拷貝，compoiste一類(lèi)的開(kāi)銷(xiāo)，根據(jù)具體場(chǎng)景再考慮。建議直接raw的drm api或者qt eglfs。

視頻播放

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

Tips

libmali

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

libdrm

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