Difference between revisions of "Graphics"

From Rockchip open source Document
Jump to: navigation, search
Line 39: Line 39:
DefaultDepth 24
DefaultDepth 24
=== UMPLOCK ===
=== UMPLOCK ===
source code: wget [http://malideveloper.arm.com/downloads/drivers/DX910/r6p1- http://malideveloper.arm.com/downloads/drivers/DX910/r6p1-]01rel0/DX910-SW-99002-r6p1-01rel0.tgz<br/> Patch the umplock patch to kernel, then you can find the umplock device node:
source code: wget http://malideveloper.arm.com/downloads/drivers/DX910/r6p1-01rel0/DX910-SW-99002-r6p1-01rel0.tgz<br/> Patch the umplock patch to kernel, then you can find the umplock device node:

Revision as of 03:55, 17 March 2017

Graphics Introduce

This article will give an overview of how graphics are generated on a rockchip platform.

Graphics with X11

Xserver is the display system used on regular desktop Linux platforms.

Rockchip have a custom Xserver which have enable glamor 2D acceleration.

Xserver usually have a good compatibility, but the performance may be little less and its size is more large than other display system.

Gstreamer X11 sink have DRM 4k-Video render support(though hacky).


X11 structure in Linux OS



source code: git clone git@github.com:markyzq/xf86-video-armsoc.git
maliline: git://anongit.freedesktop.org/xorg/driver/xf86-video-armsoc
The DDX support:

  1. support common x11 display and Hwcursor
  2. DRI2 (request by EGL X11 client)
  3. umplock(support non-tearing on EGL x11 client)

/etc/X11/xorg.conf: Xserver will parse this config to find DDX and configure info

Section "Device"
Identifier  "Mali-Fbdev"
Driver "armsoc"
Option           "UMP_LOCK"   "true"
Section "Screen"
Identifier   "Default Screen"
Device       "Mali-Fbdev"
DefaultDepth 24


source code: wget http://malideveloper.arm.com/downloads/drivers/DX910/r6p1-01rel0/DX910-SW-99002-r6p1-01rel0.tgz
Patch the umplock patch to kernel, then you can find the umplock device node:


Don't forget enable DDX umplock option:

Option           "UMP_LOCK"   "true"

The umplock only use for x11 graphic stack, no need for wayland, because mali 
already do the wayland sync on its driver.

X11 performance test

2D performace:


3D preformace:


X11perf tools can easy get from x11-apps.
glmark2-es2 can get from https://github.com/glmark2/glmark2
The glmark2-es2 source code can also build for x11, drm(gbm) and wayland.

Graphics with Wayland

Weston is the reference implementation of a Wayland compositor, and a
useful compositor in its own right.


File:Wayland structure.png


The Weston reference implementation of a Wayland compositor.

     1. run wayland with drm and gpu renderer

export XDG_RUNTIME_DIR=/tmp
weston --backend=drm-backend.so --idle-time=100 

      2. run wayland with drm and cpu renderer

weston --backend=drm-backend.so --idle-time=100 --use-pixman

--idle-time: how many seconds the weston got to sleep, it's usefull to test wayland 
suspend and resume.
--use-pixman: it's usefull to compare gpu or non-gpu performance and behavior.

Wayland performance test

3D preformance:  glmark2-es2-wayland
glmark2-es2 can get from https://github.com/glmark2/glmark2

OpenVG test: vg_api_tests
build from mali DDK, build with make bin/vg_api_tests

Graphics with None

If you don't want to use X11 or wayland, there are some chooses for you.

Libdrm and libmali-gbm can be used to draw UI without display systems.

QT can work without x11 or wayland, it run Qt5 applications on top of EGL(libmali-gbm).
WIth qt eglfs, video player can reach 1080-60fps.

MALI GPU driver


File:Mali driver structure.png

Mali Build option

Build for X11:
Build for Wayland:
X11 stack only use gpu x11 backend, 
Wayland use two gpu backend, drm(gbm) and wayland

-x11-: x11 backend
-drm-: GBM backend
-wayland: wayland backend
-sse-: similar with neon, Accelerate memcpy on mali, speed up some api like 
-vg-: openVG support, tested with vg_api_tests on wayland backend
-dma_buf-: support dma_buf



File:Drm structure.png

Source code

mainline source code: git clone git://anongit.freedesktop.org/mesa/drm
LIBDRM is the cross-driver middleware which allows user-space applications (such 
as Mesa and 2D drivers) to communicate with the Kernel by the means of the DRI 

Mailing list

General developers discussions occur on the dri-devel@lists.freedesktop.org 
mailing list.
Subscribe to the list at http://lists.freedesktop.org/mailman/listinfo/dri-devel.
Archives are found at http://lists.freedesktop.org/archives/dri-devel/.

Kernel Driver porting


For details of the full Linux graphics stack, please refer to online documents in FreedesktopARMArch wiki…..