Sunday, March 1, 2009

編譯 Wayland

Wayland 是一個極精簡的 display server。它是由 Kristian Høgsberg 在工作之餘所進行的實驗性計畫。與 X server 不同,Wayland client 要負責所有的繪圖動作,server 只處理最後的合成與顯示。這邊的繪圖動作還包含視窗邊框,這在 X 的世界裡是由 window manager 完成。

client 必須把它想顯示的畫面畫在 GEM buffer 上。GEM buffer 是 kernel 在管理的資源,它在不同的時間點可能會存在於不同的地方,例如它可能在系統記憶體或者是顯示卡的記憶體上。client 想要繪圖時可以利用 mmap 取得 GEM buffer 的指標,直接對它進行操作。client 與 server 的資料交換,圖形以外的部份是透過 unix socket;圖形部份因為使用 GEM buffer,server 可以直接取得。server 最後再透過 compositor 把 client 的畫面合成並顯示到螢幕上。

Wayland 還在早期的階段,這邊提到的編譯方法可能很快就不適用 (或被簡化)。編譯 Wayland 之所以困難,主要原因在於它用到的 git repository 不好找。先讓我們找到 DRM 並且安裝起來
$ git clone git://anongit.freedesktop.org/git/mesa/drm
$ cd drm
$ ./autogen.sh --prefix=/opt/gfx
$ make
$ make install
$ export PKG_CONFIG_PATH=/opt/gfx/lib/pkgconfig
$ export LD_LIBRARY_PATH=/opt/gfx/lib


再來安裝 Mesa 跟 DRI driver (這邊選用 i915)
$ git clone git://anongit.freedesktop.org/git/mesa/mesa
$ cd mesa
$ git remote add krh git://people.freedesktop.org/~krh/mesa
$ git fetch krh
$ git checkout -b eagle krh/eagle
$ ./autogen.sh --prefix=/opt/gfx --with-dri-drivers=i915 \
--disable-gallium --disable-glw --disable-glut --disable-glu \
--without-demos
$ make
$ make install


Wayland 會用到 udev 136 之後提供的 libudev,雖然這邊只安裝 libudev,但要注意它可能會覆蓋系統上本來的檔案
$ git clone git://git.kernel.org/pub/scm/linux/hotplug/udev.git
$ cd udev
$ ./autogen.sh
$ cd udev/lib
$ make
$ make install


Wayland 目前的 compositor 是採用 eagle 這個 EGL 實作
$ git clone git://anongit.freedesktop.org/~krh/eagle
$ cd eagle
$ autoreconf -vif
$ ./configure --prefix=/opt/gfx
$ make
$ make install
$ export EAGLE_DRIVER_PATH=/opt/gfx/lib/dri


大部份的 example client 用到了 cairo-drm,這是一個直接以 GEM buffer 為 surface backend 的 cairo 分支
$ git clone git://anongit.freedesktop.org/git/cairo
$ cd cairo
$ git remote add ickle git://anongit.freedesktop.org/~ickle/cairo
$ git fetch ickle
$ git checkout -b drm ickle/drm
$ ./autogen.sh --prefix=/opt/gfx --disable-xlib
$ make
$ make install


最後,Wayland
$ git clone git://people.freedesktop.org/~krh/wayland.git
$ cd wayland
$ autoreconf -vif
$ ./configure --prefix=/opt/gfx
$ make
$ make install


Wayland 需要 kernel modesetting 的支援 (linux kernel >= 2.6.29)。再克服這一關,一個晚上折騰的結果

8 comments:

Hello World! said...

我还在使用 2.6.27-14 ……

【Palatis】 said...

Wayland 麻煩的地方在 backend.
目前支援 GEM/DRI2 比較完整的只有 intel 的 driver 而已.
像我這種都是 AMD 機器的窮人就都沒的玩...
等待 ati driver 中!

Justin Lee said...

我總是會把 Wayland 和 MicroXwin 聯想在一起,兩者感覺上都是跳過 X Server 以提升圖形上的效能,不過 MicroXwin 能在 embeded system 上跑,至於 Wayland 我就不確定了... Blg

olv said...

Wayland 是 DRI2/GEM 底定後,對 display system 的重新思考。我覺得最重要的特徵是:client 不能直接繪圖到螢幕上。

Justin Lee said...

X clients 不能直接繪圖到螢幕上,必須先繪到 framebuffers 最後再由 compositor 或 compositing window manager 做合成的動作,然後才將合成的影像繪圖到螢幕上,相信不論是在 Wayland、X.Org 或 XFree86 上,只要是需要合成的地方都必須多一層繪圖的間接性,否則 compositor 或 WM 便無法介入。
Wayland 似乎需要顯示卡支援特定先進的規格 (intel, ATI) 才能發揮作用,而 MicroXwin 則應該沒有這樣的限制,通常使用一般的顯示卡就足夠了。

olv said...

X server 在沒有 COMPOSITE extension 的情況下,client 畫到 Window 上的結果會直接顯示在螢幕上。就算有了 COMPOSITE extension,DRI client 還是會直接繪圖在螢幕上。這是 DRI2 要解決的問題之一:

http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html

GEM 在 Wayland 裡是基本的型別,所以 driver 要支授 GEM 才能使用,這算是一個缺點。

Justin Lee said...

在 Jserv MicroXwin 文章裡提到:「...MicroXwin 的思維乃是著眼於拜自由軟體蓬勃發展所賜,豐富的 X 應用程式有如過江之鯽,但,在有限硬體能力的嵌入式環境中,是否有機會獲得良好的呈現與使用者互動能力呢?...」。

承接上下文,上面這句話言下之意應是說,在有限硬體能力之下 MicroXwin 確實可以改善圖形的效能,這裡所謂的硬體應該就是指硬體加速的機制,換句話說, 在沒有硬體加速機制的情況下 MicroXwin 仍然可以提升圖形的效能...不過這不禁讓我懷疑,當在沒有硬體加速機制的情況下 Wayland 是否也同 MicroXwin 能夠改善圖形的效能?如果繼續往下讀,問題似乎變得更明朗:

Jserv:「...在沒有特殊硬體加速機制 (如 DRI 與 GLX/OpenGL) 的前提,以下因素導致原本 X Window System 效能低落並佔用系統資源...」。

雖然對 DRI/DRI2 以及 Wayland 的了解非常有限,但就我個人的認知如果沒錯的話,Wayland 是需要依賴 DRI/DRI2 來運作的,此外 DRI/DRI2 同時也是 Wayland 之所以能夠改善圖形效能的關鍵因素,而 Jserv 上面那句話言下之意應是說 DRI/DRI2 無法在沒有硬體加速的機制下運作,這間說明了:Wayland 要能夠正常運作,必須要有硬體加速 (即 2D??/3D 加速卡) 的配合。

如果上面的推論沒錯的話,那麼 Wayland 能夠應用的範圍可能還是有其限制。因為不只是嵌入式的系統,甚至是連一般個人電腦也都不見得會安裝 3D 加速卡,這聽起來實在是讓人感到有點遺憾。如果 Linux 的 GUI 要能夠媲美 Windows 的圖形效能,除非能夠確定加速卡將會在個人電腦及嵌入式系統迅速地普及化,否則這方面可能還有改進的空間。

Justin Lee said...

今天看了 Wayland 論壇上的 Lessons learned from QWS 發現這邊的討論似乎是說,即使沒有硬體加速的一般顯示卡 Wayland 也能在上面執行:

Question by Tom Cooksey:

One last thing - have you thought about non-GL hardware? I think it would be pretty easy to implement all this in software or with simple blit-only type hardware. These nasty things aren't ever going away - there'll always be a bottom end market segment with no HW acceleration. The question is - should they be in scope? Personally I'd like to see Wayland be _the_ graphics API on Linux, in which case it will have to support these kind of devices.

Answer by Kristian Høgsberg:

Sure, that's how wayland started out :) It's all in the clients and compositor. The only requirement in the core is that you have a memory manager/shared memory mechanism in place that lets you identify buffers by an integer. How you go from buffer contents to handle and vice versa is up to the clients and the compositor. Except for the egl gears I added to the window.c client recently, all clients were just using cairo sw rendering and pushing that into a gem buffer. And the initial compositor would just mmap /dev/fb and memcpy the pixels in there.

如果 Kristian 所言屬實,那麼問題就回歸到上次您提到 GEM 的缺點上 (或是 driver 支不支援的問題),而與顯示卡硬體的新、舊、優、劣都沒有關係 ... 所以我想最後問題可能還是落在 driver 的支援性或是廠商是否公佈 data sheet 的問題上,排除這些問題 Wayland 應是大有可為。