對于Android開發(fā)者來說,基本不用關(guān)心圖形方案這些細(xì)節(jié),你只要調(diào)用java的class,最后的性能都是有原廠和谷歌驗(yàn)證過的。 但對Linux開發(fā)者來說,情況要復(fù)雜的多,沒有一個完美方案。。所以當(dāng)你決定要在Linux要開發(fā)應(yīng)用的時候,一定要明確你的需求,對比方案間的優(yōu)劣。
小框圖:
X11
X11的基礎(chǔ)構(gòu)架,建議先谷歌一下,太龐大,歷史遺留比較多,到現(xiàn)在我也沒弄清楚一些調(diào)用流程。下面主要講講dri2。dri2是xserver用來連接gpu的結(jié)構(gòu),下面這個鏈接里蠻詳細(xì)的。大概理解,dri2自己管理一個window下面的buffers, xserver都不會過問,只有swap front buffer的時候,才會調(diào)一些函數(shù)來wait page flip來進(jìn)行畫面的同步。
不過這個front buffer是false的,要注意,最后顯示還要進(jìn)行compoiste(以rk的xserver為例,這里會用到cpu blit, 而wayland和qt eglfs這步是gpu做的)。dri2全屏和不全屏的性能差距會比較大,因?yàn)槿恋那闆r下,dri2出來的flase front buffer,也就是這個window的drawbuffer, 是直接被作為全局的font buffer,送到ddx顯示的,省去了compoiste。
所以在x11下開發(fā)3d應(yīng)用的時候,一定要全屏,保證沒有多余的compoiste,比如qt的qmlwindow就是一個完整的gl窗口(注:debian上不是)。另外一提,rk平臺上的xserver,還支持了glamor,意味一些compoiste可以被gpu加速到,如果是做多窗口的應(yīng)用或者desktop類型的產(chǎn)品,這個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的問題,而是debian的程序編譯選項(xiàng)一般沒帶上gles。
QT EGLFS
QT EGLFS是qt自己實(shí)現(xiàn)的一個gui系統(tǒng),不支持多窗口,但也因此少了window compoiste。QT EGLFS和dri2的方式也差不多,區(qū)別就在于,qt eglfs的font buffer在自己用gpu compoiste后,是直接送給drm去顯示,而X里是送Window manager去做compoiste,所以EGLFS在效率上是有優(yōu)勢的。另外除了QT,常用的UI庫里,SDL也是支持這種DRM+GL的方式的。
2017.3.11
QT EGLFS的流程其實(shí)可以通過代碼追蹤一下。根據(jù)代碼,一個qmlvideo的顯示過程會是這樣的(非qml的話不一樣,會優(yōu)先用xvimagesink的subwindow),surface路徑會是QDeclarativeVideoOutput->QDeclarativeVideoRendererBackend,顯示一幀frame的話,會先調(diào)用到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,從結(jié)構(gòu)上來講,也最相近android上的HWC,全部的compoiste都是gpu來做的,不會有xserver那樣cpu合成的場景。wayland除了gpu合成以外,另一個優(yōu)勢,就是overlay接口的存在,能允許移動平臺上的一些2d加速模塊,display模塊在這個接口上被調(diào)用(這些模塊才是移動平臺能跑大分辨率ui的關(guān)鍵)。wayland主要的問題是兼容性,比如你用qtmultimedia的話,會發(fā)現(xiàn)video sink不能換,因?yàn)椴患嫒輜ayland的窗口api。
應(yīng)用場景
3d應(yīng)用
3d應(yīng)用的瓶頸最主要在計(jì)算單元上,拷貝,compoiste一類的開銷,根據(jù)具體場景再考慮。建議直接raw的drm api或者qt eglfs。
視頻播放
對視頻播放來說,拷貝,compoiste的開銷是決定性的。Spec上的視頻播放極限,比如rk3399,rk3288播放4k,rk3036播放1080p,基本上是不可能在通用框架,也就是走gpu實(shí)現(xiàn)的。 因?yàn)檫_(dá)到了芯片bandwidth的上限場景,如果讓gpu去拷貝和轉(zhuǎn)格式的話速度會很慢,必須要display的部分自己去處理顯示視頻數(shù)據(jù)。
但想讓display部分去處理的話,軟件上必須有對應(yīng)的支持——-然而desktop based的gui framework大多缺失了這樣一個東西。之前在rk的系統(tǒng)上,我base X11做了一個“gstreamer sink” 。通過x的api獲取窗口的位置,然后直接drm的api,繞過X系統(tǒng),overlay畫在窗口的位置。
這樣做確實(shí)可以發(fā)揮視頻播放的極限,主要的問題就是沒辦法和gui系統(tǒng)融合,沒辦法疊加控件,如果使用的場景都是fullscreen,可以試試這做。上文提了下wayland框架支持overlay,所以最理想的,還是wayland通過overlay的機(jī)制直接call的display單元顯示,像android那樣。
總結(jié)一下,所以如果視頻性能不是那么高,又需要復(fù)雜UI,建議用gpu的框架。qt eglfs,放視頻,按rk3288的性能,可以達(dá)到1080p 60fps。x11,gles在rk平臺的軟件上,測試下來,性能比較差;不過已經(jīng)有rkximagesink的overlay顯示方案。wayland暫時沒有研究,理論上原生支持overlay的wayland是最好的,但是我覺得應(yīng)該也就類似rkximageisnk的那種效果,不能和正常的窗口兼容。
Tips
libmali
libmali是mali gpu的userspace library,我也看不到代碼,完全是黑盒,只能說根據(jù)一些類似的代碼和文檔猜測他的實(shí)現(xiàn)方式。libmali有很多編譯選項(xiàng),我猜的話,除了軟件硬件版本,還有下面兩種。一個是fbdev和gbm,分別對應(yīng)了fbdev和drm兩種內(nèi)核驅(qū)動的場景。fbdev對比gbm有幾個差異。
1.vblank用fbdev去跑on-screen的glmark,分?jǐn)?shù)一般是要比gbm的高,原因就是這套流程沒有去等待vblank。gbm的實(shí)現(xiàn)都會在最后swap front buffer的時候等待vblank,所以on-screen只能跑幾十fps,fbdev的不會去等,因此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)里。如果這個texture數(shù)據(jù)本來就在一個dma-buf里的話,可以通過特定的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。 這個就是支持在display server下運(yùn)行,沒什么好說的。
libdrm
drm的api分legacy api和新一點(diǎn)的atomic api,如果你直接用drm api開發(fā)程序,一定要注意這兩個api的區(qū)別。legacy api:drmModeSetCrtc, drmModeSetPlane, drmModePageFlip都是legacy的api,這些函數(shù)什么意思,怎么用,可以搜索下網(wǎng)絡(luò)資料。
大致上,drmModeSetCrtc包括了drmModeSetPlane包括了drmModePageFlip。在rk平臺上,drmModeSetCrtc和drmModeSetPlane都是atomic的,意味著你調(diào)用這些api后會一直block到vblank,drmModePageFlip是noneblock的,你調(diào)用后就會返回。
一般來說不在一個程序里順序調(diào)用會block的api,性能不會有太大問題。atomic api:legacy的api都是atomic的,而且容易重復(fù)調(diào)用,這就導(dǎo)致有些場景會很沒效率。比如wayland drm的場景下,有3個plane,每個周期內(nèi)要更新這幾個plane,如果全用drmModeSetPlane的話,就意味著要等待3次vblank,那么一個60hz的屏幕,你的fps最高只會有20fps。
為了解決這種情況,我們就需要有一個api,能在一次調(diào)用里,解決掉所有的事情,比如更新所有的plane,然后只用等一次vblank。drmModeAtomicCommit,具體用法請谷歌。
-
Linux
+關(guān)注
關(guān)注
87文章
11411瀏覽量
212233 -
JAVA
+關(guān)注
關(guān)注
20文章
2982瀏覽量
106451
原文標(biāo)題:怎么選擇 Embedded Linux 的圖形框架
文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
Mentor Graphics新擴(kuò)展Mentor Embedded Linux功能
嵌入式Linux圖形系統(tǒng)(GUI)快速參考手冊
基于NXP iMX6Q SoC平臺的Apalis iMX6 ARM核心板的相關(guān)資料推薦
Embedded SIG | 多 OS 混合部署框架
基于Qt/Embedded的嵌入式控制界面開發(fā)
基于QT/Embedded的可變情報板應(yīng)用程序開發(fā)
Qt/Embedded開發(fā)入門

采用Linux還是Windows Embedded,研華選擇后者
Linux DMA Engine框架的介紹
你對Linux總線設(shè)備驅(qū)動框架是否了解
當(dāng)前HarmonyOS輕設(shè)備圖形框架的總體特性介紹

ThunderGP:基于HLS的FPGA圖形處理框架

評論