新創公司 DSPSOFT INC 日前提出針對嵌入式系統的高效能 X Window System 實作,即 [MicroXwin],由該公司創辦人兼 CEO,Vasant Kanchan,領導嶄新途徑的開發與產品化。MicroXwin 的思維乃是著眼於拜自由軟體蓬勃發展所賜,豐富的 X 應用程式有如過江之鯽,但,在有限硬體能力的嵌入式環境中,是否有機會獲得良好的呈現與使用者互動能力呢?為此,MicroXwin 用獨特的方式改良 X 的設計。
X Window System 本質上是圍繞於網路通訊的視窗系統,X server 透過硬體,負責將 X client 要求的繪圖動作,予以呈現並處理運作所需的 I/O,而 X protocol 就是如此設計的核心。X 應用程式就是 X client,為了開發豐富的應用程式,會有 Gtk+ 與 Qt 一類的 Toolkit / widget set,下圖是運作示意圖:
在沒有特殊硬體加速機制 (如 DRI 與 GLX/OpenGL) 的前提,以下因素導致原本 X Window System 效能低落並佔用系統資源:
基於 X protocol 的規範,X client 與 X server 各自保有 buffer 與格式化的繪圖指令操作
X client 與 X server 間的必要的同步化通訊與 round-trip
對於 ARM 9 一類廣泛使用的嵌入式處理器架構,系統設計有 MMU/cache 本該能提昇的處理效能與彈性,但頻繁地在 X 應用程式與 X server 間作 context switch,導致 cache flush,致使效能大打折扣
是此,MicroXwin 提出新的途徑,在不更動既有 X client / Toolkit 的前提下,將 X serever 的工作搬移到底層作業系統,成為一個新的服務,並且,捨棄 X protocol 與網路通透性的機制,成為修正性、典型的繪圖系統,以下是示意圖:
由上圖,我們可見到若干元件:
X11.ko kernel module : 實做部份 X server 的功能,並開放 /dev/x11dev 的介面給 X client library 存取
libX11.so 保持與原本 Xlib 二進位相容的 API
libXext.so 等 X extension library 則實做 X extension 所需的呼叫,但針對 /dev/x11devb 介面,而非網路通訊的 X protocol
X core font 由 X11.ko kernel 處理,免除繁複的記憶體操作
針對向量字體,則由 X client 端,透過 Xft/Fontconfig 處理,但更直接的呈現
如此嶄新的設計有著以下優點:
Low latency 與 Low round trip
大幅減少 X request / response 所需的 buffering,免去昂貴的通訊成本
消去 context switch 的負擔,並避免 ARM 9 一類嵌入式硬體的 cache flush 問題
相較而下,Xorg X server 佔用了 1.8M bytes 的空間。而針對 ARM 9 硬體,以 Nokia 770 Linux Tablet 為主要效能評比的對象,OpenHanded (已被 Intel 收購) 與 Nokia 的工程團隊已做了若干效能改進,提出 Xomap,這個奠基於 KDrive / TinyX 架構、針對 TI OMAP 硬體加速的 X server,MicroXwin 與其相較,絲毫不遜色,而且有亮眼的效能突破。網頁 [Demo] 透過 x11perf 羅列了效能評比數據,筆者做了圖表整理如下:
由此可見,MicroXwin 相較於 Xorg X server,在 asynchronous display 有著 62% 的效能提昇,而在 synchronous display of images 則有 384% 的提昇,這是主要架構變異使然,官方也提供若干組態與執行檔供驗證評估。整體來說,MicroXwin 的設計特點:
把 X server 搬進 kernel ,這是過去一直被提起,也是一直被避免的狀況。搬進 kernel 的好處顯而易見,缺點卻是系統crash down 的可能性大大提昇。就算直接把 Xorg 搬進 kernel 裡,不作設計上的變動,只對依賴的 API 進行 porting ,光這樣都有某種程度的改善。若只是做這樣的改善,或許只能以「暴力」兩字加以讚嘆!
我也是認為多一種選擇並沒有什麼不好,若是在穩定上有顧慮的人,還是可以選擇延用舊有的模式.個人的使用經驗來說,X 的效能與 MS Windows 相比,的確反應上是差滿多的.以我個人的偏好來說,我倒是滿樂見 X 被搬進核心成為核心模組的,如果這樣真的能夠有效地加快GUI的反應的話.其實 Linux 的核心在設計上,應該早就受到 desktop user 的需求影響,開始在核心中加入許多原始碼以期能夠最佳化 GUI 的效能 (例如用更即時的 scheduler 或在核心中加入更多的 checkpoint);不過這些改變對效能的增進還是非常有限,反而增加了核心的一些 overhead,所以個人認為要改進 GUI 效能,將 X 搬進去才是最好的方法,也才真正做到最佳化的目的.