Jump to content

Is Mali GPU driver available in Mainline for H3?

Nazar Gerasymchuk

By Nazar Gerasymchuk
in Off-topic

 Share

Recommended Posts

Nazar Gerasymchuk

Nazar Gerasymchuk

Posted
Posted

Sorry if this is silly question, but I can't find any straight-forward documentation on this topic.

 

I've seen that Mali drivers was available for older kernel, but what about mainline?

 

Asking this especially in context with this finding -- Maxime Ripard's article "Mali OpenGL support on Allwinner platforms with mainline Linux".

 

Currently on clean Armbian install on NanoPi Neo Air I can't load mali:

  

$ modinfo mali
modinfo: ERROR: Module mali not found.

 

1
Link to comment
Share on other sites
sfx2000

sfx2000

Posted
Posted

it's complicated - and I'm not sure that Allwinner can do this - it's really down to ARM and the license...

 

Quote

However, we are happy to announce that Allwinner gave us clearance to publish the userspace binary blobs that allows to get OpenGL supported on Allwinner platforms that use a Mali GPU from ARM using a recent mainline Linux kernel

 

It would be great - and nothing against Bootlin's efforts on the AW Cedar VPU... and some of that might be in Linux 4.20

 

I think many in the ARM FOSS community would like to see a real open source GPU driver from one of the many vendors...

 

(and no - RPI's Broadcom VC4 is still not open, just in case someone brings that up)

Link to comment
Share on other sites
Tido

Tido

Posted
Posted
12 hours ago, sfx2000 said:

I'm not sure that Allwinner can do this

It looks like you read the article, but did you understand  - they (bootlin) have to spend time to get it working under a recent mainline Linux kernel (they were not looking at his SoC H3, but A23 & A33).  While not being payed for this work,  unless they have a customer who has a need for that.

 

@Nazar Gerasymchuk if you can fund their efforts,  and you may get it sooner. However, if not you may be able to help the open LIMA development here for H3 T400/450  https://gitlab.freedesktop.org/lima/linux     

 

On the other hand you maybe also interested to read this about Midgard (Mali T6xx, T7xx, T8xx) and Bifrost (G7x)   https://rosenzweig.io/blog/panfrost-on-the-rk3399-meow.html  

 

in conclusion ARM Mali driver is not available in Mainline. If you depend on that and do not/cannot support development of it in any way. You want to look at Android.

Link to comment
Share on other sites
Nazar Gerasymchuk

Nazar Gerasymchuk

Posted
  • Author
Posted

@Tido Thank you for your quick answer.

 

I've heard about Lima, and I can see that it is in deep development right now (at least as it is stated on Sunxi site http://linux-sunxi.org/Mali).

 

My main confusion came from situation that there are lots of H3 boards that works quite well with mainline kernel, and there is no option to use GPU. from customer side it looks very strange.

 

---

 

One more (silly) question, what does it means that there is dts already in mainline kernel -- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun8i-h3.dtsi#n156? Doesn't it make usable Mali driver?

 

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted
1 hour ago, Nazar Gerasymchuk said:

My main confusion came from situation that there are lots of H3 boards that works quite well with mainline kernel, and there is no option to use GPU. from customer side it looks very strange.

Who is the customer of who here?

 

AFAIK most Chinese makers sell these boards not much above the BOM cost, and even Allwinner tries to cut their cost as much as possible, i.e. by not purchasing Mali driver licenses that are useless for them with Android: https://irclog.whitequark.org/linux-sunxi/2017-12-07#20730568; (timestamp 07:39)

 

1 hour ago, Nazar Gerasymchuk said:

Doesn't it make usable Mali driver?

It only helps running the kernel-side driver. It still requires a userspace closed-source driver of a specific type (framebuffer, Xorg, Wayland) and applications that can use this driver, i.e. you need a special shim (xf86-video-armsoc) to make use of Mali with X.org.

Link to comment
Share on other sites
Nazar Gerasymchuk

Nazar Gerasymchuk

Posted
  • Author
Posted
49 minutes ago, zador.blood.stained said:

Who is the customer of who here?

Customers: for example me and you (I suppose), since we both purchased H3 boards, and its GPU can't be used with mainline. 

 

54 minutes ago, zador.blood.stained said:

It only helps running the kernel-side driver. It still requires a userspace closed-source driver of a specific type (framebuffer, Xorg, Wayland) and applications that can use this driver, i.e. you need a special shim (xf86-video-armsoc) to make use of Mali with X.org.

I'm Ok with running closed-sourced or partially open-sourced drivers, but how can I do it on H3 with mainline? If this is possible, I'd like to ask you to share any useful documentation here. Thanks.

Link to comment
Share on other sites
jock

jock

Posted
Posted
18 hours ago, Nazar Gerasymchuk said:

Sorry if this is silly question, but I can't find any straight-forward documentation on this topic.

 

I've seen that Mali drivers was available for older kernel, but what about mainline?

 

Asking this especially in context with this finding -- Maxime Ripard's article "Mali OpenGL support on Allwinner platforms with mainline Linux".

 

Currently on clean Armbian install on NanoPi Neo Air I can't load mali:

  


$ modinfo mali
modinfo: ERROR: Module mali not found.

 

The answer is yes, it can be done, but you need a bit of knowledge about compiling kernel modules.

I made it on an Orange PI PC (Allwinner H3) to test my armsoc drivers and it worked, although Mali-400 MP2 embedded into H3 was quite slow.

 

You should be able to take everything you need (both the kernel driver and the userland EGL+OpenGL ES drivers) from https://github.com/mripard/sunxi-mali

Kernel and userland libraries should match their versions to be sure that they work correctly together: if you use r6p2 kernel driver, use r6p2 for userland too.

Instructions are easy but here are some hints:

  • You need the kernel headers package installed, you won't get far without this; you should be able to use apt-get to install the appropriate package for your armbian version
  • You can compile the kernel driver on your very same board (I strongly suggest this), so you don't need to export the CROSS_COMPILE environment variable
  • export the KDIR env variable to point to your kernel headers. Typically: export KDIR=/lib/modules/$(uname -r)/build
  • export INSTALL_MOD_PATH env variable to point to your kernel modules:. Typically: export INSTALL_MOD_PATH=/lib/modules/$(uname -r)/kernel
  • follow the instructions as described, but expect some patch won't work or compile fail. Just don't be scared to get your hands dirty, it is common that you may need to do some little manual adjustments (a missing kernel file here, a missing header there...)

Once the driver is compiled and installed, you should be already able to modprobe it.

 

Follow the instructions to install the userland EGL and OpenGL ES libraries too.

If you are using the X server, you need the x11_dma_buf flavour and you also need to compile this armsoc driver too (maybe you can try the already compiled version I published on this post, it should work for your SoC too. Ignore the media script part which is for rockchip socs).

If you don't use X you can use the fbdev flavour, in this case add extraargs=drm_kms_helper.drm_fbdev_overalloc=200 to /boot/armbianEnv.txt as per-instructions.

 

 

 

 

2
Link to comment
Share on other sites
sfx2000

sfx2000

Posted
Posted
13 hours ago, Tido said:

It looks like you read the article, but did you understand  - they (bootlin) have to spend time to get it working under a recent mainline Linux kernel (they were not looking at his SoC H3, but A23 & A33).  While not being payed for this work,  unless they have a customer who has a need for that.

 

My point is Allwinner is not the only licensee for Mali in various flavors - It would have been more beneficial to the community for Bootlin to approach ARM directly and make it more open friendly - which would be a win for ARM and a win for developers and end users...

Link to comment
Share on other sites
devman

devman

Posted
Posted

I remember reading the history of the Lima project a while ago, and it basically comes down to that ARM doesn't WANT an open-source implementation of the graphics drivers, as they make a not-insignificant amount of money licensing theirs.

1
Link to comment
Share on other sites
MX_Master

MX_Master

Posted
Posted

Hi, guys, I'm trying to install the mali driver to the latest armbian desktop image (20.02.1, debian buster, current, 5.4.20, x11, lima).  My board is Orange Pi PC (H3). I have a good progress but still have a few questions.

 

The list of my successful steps:

 

1. Getting `mali` blobs 

git clone https://github.com/bootlin/mali-blobs.git
sudo mkdir /usr/lib/mali
sudo cp -a mali-blobs/r6p2/arm/x11_dma_buf/lib* /usr/lib/mali/
sudo sed -i -e '1 s/^/\/usr\/lib\/mali\/\n/;' /etc/ld.so.conf
sudo ldconfig

2. Blacklisting the `lima` driver 

touch blacklist.conf
echo "blacklist lima" >> blacklist.conf
echo "blacklist gpu_sched" >> blacklist.conf
sudo mv blacklist.conf /etc/modprobe.d/blacklist.conf
sudo reboot

3.  Building and installing `mali` driver 

sudo apt-get install linux-headers-current-sunxi
sudo apt-get install quilt xorg-dev xterm libudev-dev xutils-dev libtool 
sudo apt-get install mesa-utils mesa-utils-extra cmake

git clone https://github.com/mripard/sunxi-mali
cd sunxi-mali
export CROSS_COMPILE=arm-linux-gnueabihf-
export KDIR=/lib/modules/$(uname -r)/build
./build.sh -r r6p2 -b
sudo mkdir /lib/modules/$(uname -r)/kernel/drivers/gpu/mali
sudo cp mali.ko /lib/modules/$(uname -r)/kernel/drivers/gpu/mali/
cd ..
sudo depmod
sudo modprobe mali

4. Building and installing `xf86-video-armsoc` 

git clone https://github.com/paolosabatino/xf86-video-armsoc
cd xf86-video-armsoc
autoreconf -vi
./configure --with-drmmode=sun4i
make
sudo make install
sudo cp /usr/local/lib/xorg/modules/drivers/* /usr/lib/xorg/modules/drivers/
cd ..
sudo reboot

These steps were done successfully. Of course, there are no egl/gles HW acceleration at this moment. es2_info and es2gears show me the "EGL init error" message. So.. what steps can I do next? Do I need some special settings for the X server?

Link to comment
Share on other sites
jock

jock

Posted
Posted

@MX_Master

 

Yes, you need to create a configuration file for X to use armsoc driver. Edit a file /etc/X11/xorg.conf.d/10-armsoc.conf and put this into: 

Section "Device"
	Identifier "mali"
    Driver "armsoc"
EndSection

also you must be sure that libEGL* and libGLES* libraries are all pointing to libMali.so. Be also sure that the Mali library userspace library has really name libMali.so, because otherwise it won't work!

1
Link to comment
Share on other sites
MX_Master

MX_Master

Posted
Posted

Thanks, guys. Just added these new steps to the list:

 

5. Granting access to the `/dev/mali` for the current user 

sudo usermod -a -G video $USER
touch 50-mali.rules
echo 'KERNEL=="mali", MODE="0660", GROUP="video"' >> 50-mali.rules
echo 'KERNEL=="mali0", MODE="0660", GROUP="video"' >> 50-mali.rules
sudo mv 50-mali.rules /etc/udev/rules.d/50-mali.rules

6. Enabling the `armsoc` driver for the X server 

sudo sed -i -e 's/modesetting/armsoc/' /etc/X11/xorg.conf.d/01-armbian-defaults.conf
sudo sed -i -e 's/.*glamor.*//' /etc/X11/xorg.conf.d/01-armbian-defaults.conf
sudo reboot

These steps were done successfully too. But.. still have no egl/gles HW acceleration :rolleyes: And this time, when I'm trying to use es2gears or es2_info, the X server immediately crashes. Interesting..  May be a few more components needs access rights to the /dev/mali and /usr/lib/mali/* too?

 

Xorg logs shows me some errors at the start. And there are no interesting info about Xorg crash. 

.....

[    20.080] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Feb 23 04:42:20 2020
[    20.087] (==) Using config directory: "/etc/X11/xorg.conf.d"
[    20.087] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[    20.103] (==) No Layout section.  Using the first Screen section.
[    20.103] (==) No screen section available. Using defaults.
[    20.103] (**) |-->Screen "Default Screen Section" (0)
[    20.103] (**) |   |-->Monitor "<default monitor>"
[    20.104] (==) No device specified for screen "Default Screen Section".
	Using the first device section listed.
[    20.104] (**) |   |-->Device "Default Device"
[    20.104] (**) |   |-->GPUDevice "mali"
[    20.105] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[    20.105] (**) Option "BlankTime" "0"
[    20.105] (**) Option "StandbyTime" "0"
[    20.105] (**) Option "SuspendTime" "0"
[    20.105] (**) Option "OffTime" "0"
[    20.105] (==) Automatically adding devices
[    20.105] (==) Automatically enabling devices
[    20.105] (==) Automatically adding GPU devices

.....

[    20.118] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
[    20.122] (II) xfree86: Adding drm device (/dev/dri/card0)
[    20.127] (II) no primary bus or device found
[    20.128] 	falling back to /sys/devices/platform/display-engine/drm/card0
[    20.128] (II) LoadModule: "glx"
[    20.139] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[    20.291] (II) Module glx: vendor="X.Org Foundation"
[    20.291] 	compiled for 1.20.4, module version = 1.0.0
[    20.291] 	ABI class: X.Org Server Extension, version 10.0
[    20.291] (II) LoadModule: "modesetting"
[    20.304] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    20.313] (II) Module modesetting: vendor="X.Org Foundation"
[    20.314] 	compiled for 1.20.4, module version = 1.20.4
[    20.314] 	Module class: X.Org Video Driver
[    20.314] 	ABI class: X.Org Video Driver, version 24.0
[    20.314] (II) LoadModule: "armsoc"
[    20.325] (II) Loading /usr/lib/xorg/modules/drivers/armsoc_drv.so
[    20.352] (II) Module armsoc: vendor="X.Org Foundation"
[    20.352] 	compiled for 1.20.4, module version = 1.4.1
[    20.352] 	Module class: X.Org Video Driver
[    20.352] 	ABI class: X.Org Video Driver, version 24.0
[    20.352] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[    20.353] (II) ARMSOC: Driver for ARM Mali compatible chipsets
[    20.393] (II) modeset(0): using drv /dev/dri/card0
[    20.394] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[    20.394] (II) modeset(0): Creating default Display subsection in Screen section
	"Default Screen Section" for depth/fbbpp 24/32
[    20.394] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
[    20.395] (**) modeset(0): Option "AccelMethod" "glamor"
[    20.395] (==) modeset(0): RGB weight 888
[    20.395] (==) modeset(0): Default visual is TrueColor
[    20.395] (II) Loading sub module "glamoregl"
[    20.395] (II) LoadModule: "glamoregl"
[    20.407] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[    20.495] (II) Module glamoregl: vendor="X.Org Foundation"
[    20.495] 	compiled for 1.20.4, module version = 1.0.1
[    20.496] 	ABI class: X.Org ANSI C Emulation, version 0.4
[    22.263] (EE) modeset(0): eglGetDisplay() failed
[    22.271] (EE) modeset(0): glamor initialization failed

.....

[    22.694] (II) Loading sub module "fb"
[    22.694] (II) LoadModule: "fb"
[    22.695] (II) Loading /usr/lib/xorg/modules/libfb.so
[    22.703] (II) Module fb: vendor="X.Org Foundation"
[    22.703] 	compiled for 1.20.4, module version = 1.0.0
[    22.703] 	ABI class: X.Org ANSI C Emulation, version 0.4
[    22.703] (II) UnloadModule: "armsoc"
[    22.703] (II) Unloading armsoc

.....

 

Link to comment
Share on other sites
hexdump

hexdump

Posted
Posted

maybe build your own kernel with lima disabled (i'm not sure, but i think it might conflict with the old mali driver even if the module is not loaded) ... make sure you apply those two patches:

https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av7/sunxi-drm-gem-cma-Export-with-handle-allocator.patch

https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av7/sunxi-drm-sun4i-Add-GEM-allocator.patch

 

here are my own notes on getting this to work, which are verified to work up until v5.4 kernels:

https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/readme.av7-mali-sunxi

 

good luck and best wishes - hexdump

1
Link to comment
Share on other sites
MX_Master

MX_Master

Posted
Posted
1 hour ago, hexdump said:

maybe build your own kernel with lima disabled (i'm not sure, but i think it might conflict with the old mali driver even if the module is not loaded) ... make sure you apply those two patches:

https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av7/sunxi-drm-gem-cma-Export-with-handle-allocator.patch

https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av7/sunxi-drm-sun4i-Add-GEM-allocator.patch

 

I'm using the image with sunxi-current kernel. And these patches are already there :)

https://github.com/armbian/build/blob/master/patch/kernel/sunxi-current/0005-drm-gem-cma-Export-with-handle-allocator.patch

https://github.com/armbian/build/blob/master/patch/kernel/sunxi-current/0006-drm-sun4i-Add-GEM-allocator.patch

 

But I'm sure I missing something 

[ 22.263] (EE) modeset(0): eglGetDisplay() failed

May be some paths to EGL/GLES libs still incorrect 

sudo ldconfig -p | grep -P "(EGL|GLES)"
        libGLESv2.so.2.0 (libc6,hard-float) => /usr/lib/mali/libGLESv2.so.2.0
        libGLESv2.so.2 (libc6,hard-float) => /usr/lib/mali/libGLESv2.so.2
        libGLESv2.so.2 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2
        libGLESv2.so (libc6,hard-float) => /usr/lib/mali/libGLESv2.so
        libGLESv2.so (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libGLESv2.so
        libGLESv1_CM.so.1.1 (libc6,hard-float) => /usr/lib/mali/libGLESv1_CM.so.1.1
        libGLESv1_CM.so.1 (libc6,hard-float) => /usr/lib/mali/libGLESv1_CM.so.1
        libGLESv1_CM.so.1 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1
        libGLESv1_CM.so (libc6,hard-float) => /usr/lib/mali/libGLESv1_CM.so
        libGLESv1_CM.so (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so
        libEGL_mesa.so.0 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libEGL_mesa.so.0
        libEGL.so.1.4 (libc6,hard-float) => /usr/lib/mali/libEGL.so.1.4
        libEGL.so.1 (libc6,hard-float) => /usr/lib/mali/libEGL.so.1
        libEGL.so.1 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libEGL.so.1
        libEGL.so (libc6,hard-float) => /usr/lib/mali/libEGL.so
        libEGL.so (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libEGL.so

Interesting path is 

        libEGL_mesa.so.0 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libEGL_mesa.so.0

 

Link to comment
Share on other sites
MX_Master

MX_Master

Posted
Posted

Xorg config is standard, by armbian - /etc/X11/xorg.conf.d/01-armbian-defaults.conf 

Section "Monitor"
        Identifier              "Monitor0"
        Option                  "DPMS" "false"
EndSection
Section "ServerFlags"
        Option                  "BlankTime" "0"
        Option                  "StandbyTime" "0"
        Option                  "SuspendTime" "0"
        Option                  "OffTime" "0"
EndSection
Section "Device"
    Identifier  "Default Device"
    Driver      "modesetting"
    Option      "AccelMethod"    "glamor"
EndSection

May be this "Device" section is a source of my problem.

1
Link to comment
Share on other sites
MX_Master

MX_Master

Posted
Posted

Just tested the system using your X conf. And.. YES, I think the egl/gles `acceleration` is present. But any graphics processing is very very slow :o

 

es2gears is working, window has a transparent background and a performance about 20 FPS, Xorg process uses 99% of CPU.

es2_info is working, but it's output ends up with segmentation fault 

EGL_VERSION: 1.4 Linux-r6p2-01rel0
EGL_VENDOR: ARM
EGL_EXTENSIONS:
    EGL_KHR_image, EGL_KHR_image_base, EGL_KHR_image_pixmap, 
    EGL_EXT_image_dma_buf_import, EGL_KHR_gl_texture_2D_image, 
    EGL_KHR_gl_texture_cubemap_image, EGL_KHR_gl_renderbuffer_image, 
    EGL_KHR_reusable_sync, EGL_KHR_fence_sync, 
    EGL_KHR_swap_buffers_with_damage, EGL_EXT_swap_buffers_with_damage, 
    EGL_KHR_lock_surface, EGL_KHR_lock_surface2, 
    EGL_EXT_create_context_robustness, EGL_ANDROID_blob_cache, 
    EGL_KHR_create_context, EGL_KHR_partial_update, 
    EGL_KHR_create_context_no_error
EGL_CLIENT_APIS: OpenGL_ES
GL_VERSION: OpenGL ES 2.0
GL_RENDERER: Mali-400 MP
GL_EXTENSIONS:
    GL_OES_texture_npot, GL_OES_vertex_array_object, 
    GL_OES_compressed_ETC1_RGB8_texture, 
    GL_EXT_compressed_ETC1_RGB8_sub_texture, GL_OES_standard_derivatives, 
    GL_OES_EGL_image, GL_OES_depth24, GL_ARM_rgba8, 
    GL_ARM_mali_shader_binary, GL_OES_depth_texture, 
    GL_OES_packed_depth_stencil, GL_EXT_texture_format_BGRA8888, 
    GL_OES_vertex_half_float, GL_EXT_blend_minmax, GL_OES_EGL_image_external, 
    GL_OES_EGL_sync, GL_OES_rgb8_rgba8, GL_EXT_multisampled_render_to_texture, 
    GL_EXT_discard_framebuffer, GL_OES_get_program_binary, 
    GL_ARM_mali_program_binary, GL_EXT_shader_texture_lod, GL_EXT_robustness, 
    GL_OES_depth_texture_cube_map, GL_KHR_debug, 
    GL_ARM_shader_framebuffer_fetch, 
    GL_ARM_shader_framebuffer_fetch_depth_stencil, GL_OES_mapbuffer, 
    GL_KHR_no_error
Segmentation fault

I think it's a good step in progress :beer: but something is still missing in the system :)

Link to comment
Share on other sites
hexdump

hexdump

Posted
Posted

i think is is as far as you can get - it simply is that slow (but at least the cpu keeps more free as the gpu is doing the rendering - with wayland it is supposed to be a bit faster due to less memory copy around in that case) and i also get those segmentation faults from time to time ... keep in mind those blobs were never ment for mainline :)

Link to comment
Share on other sites
MX_Master

MX_Master

Posted
Posted

There are many use cases of r6p2 blobs a few years ago using kernel v4. 14. And all of them were pretty successful. Performance of es2gears was about 300fps. Software rendering can do only 100 fps on idle system.

 

So, I think, in my case something goes wrong. While running the es2gears, Xorg uses the 99% of CPU core. It's very abnormal for the hardware acceleration :D

Link to comment
Share on other sites
jock

jock

Posted
Posted
39 minutes ago, MX_Master said:

There are many use cases of r6p2 blobs a few years ago using kernel v4. 14. And all of them were pretty successful. Performance of es2gears was about 300fps. Software rendering can do only 100 fps on idle system.

 

So, I think, in my case something goes wrong. While running the es2gears, Xorg uses the 99% of CPU core. It's very abnormal for the hardware acceleration :D

I forgot that in newer armbian images the 01-armbian-default.conf forces the modesetting driver, in fact if you look at the Xorg.0.log you posted the loaded driver is modesetting. Sorry, I totally forgot to mention that.

Anyway es2_info show the ARM driver has been loaded, but notice that non-fullscreen applications will be slow because there is no page flipping, instead buffers are copied around and that uses a lot of cpu power. If you can, always use fullscreen for your applications. Kodi, for example, should run fine.

Also sometimes when you switch resolution it may crash the application. Unfortunately the interaction between mali drivers and X11 is not perfect.

Link to comment
Share on other sites
jock

jock

Posted
Posted
33 minutes ago, MX_Master said:

OK, I will make some fullscreen tests and will show the results. 

 

Also I heard about another installing method for the mali drivers/blobs. It's using ump cacher and libdri2 for direct rendering (without Xorg). 

In theory UMP should not be needed anymore with latest revisions of mali kernel drivers because they use the standard dma_buf kernel api, but you may give a chance.

Link to comment
Share on other sites
MX_Master

MX_Master

Posted
Posted

Just made a fullscreen test with glmark2 and the results are 

glmark2-es2 --fullscreen
=======================================================
    glmark2 2017.07
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-400 MP
    GL_VERSION:    OpenGL ES 2.0
=======================================================
[build] use-vbo=false: FPS: 10 FrameTime: 100.000 ms
[build] use-vbo=true: FPS: 14 FrameTime: 71.429 ms
[texture] texture-filter=nearest: FPS: 16 FrameTime: 62.500 ms
[texture] texture-filter=linear: FPS: 15 FrameTime: 66.667 ms
[texture] texture-filter=mipmap: FPS: 14 FrameTime: 71.429 ms
[shading] shading=gouraud: FPS: 10 FrameTime: 100.000 ms
[shading] shading=blinn-phong-inf: FPS: 9 FrameTime: 111.111 ms
[shading] shading=phong: FPS: 10 FrameTime: 100.000 ms
[shading] shading=cel: FPS: 7 FrameTime: 142.857 ms
[bump] bump-render=high-poly: FPS: 7 FrameTime: 142.857 ms
[bump] bump-render=normals: FPS: 14 FrameTime: 71.429 ms
[bump] bump-render=height: FPS: 11 FrameTime: 90.909 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 7 FrameTime: 142.857 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 7 FrameTime: 142.857 ms
[pulsar] light=false:quads=5:texture=false: FPS: 15 FrameTime: 66.667 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 3 FrameTime: 333.333 ms
[desktop] effect=shadow:windows=4: FPS: 10 FrameTime: 100.000 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 3 FrameTime: 333.333 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 3 FrameTime: 333.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 3 FrameTime: 333.333 ms
[ideas] speed=duration: FPS: 11 FrameTime: 90.909 ms
[jellyfish] <default>: FPS: 7 FrameTime: 142.857 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 7 FrameTime: 142.857 ms
[refract] <default>: FPS: 6 FrameTime: 166.667 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 15 FrameTime: 66.667 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 6 FrameTime: 166.667 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 14 FrameTime: 71.429 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 10 FrameTime: 100.000 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 7 FrameTime: 142.857 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 10 FrameTime: 100.000 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 10 FrameTime: 100.000 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 10 FrameTime: 100.000 ms
=======================================================
                                  glmark2 Score: 9 
=======================================================

I don't no, but performance is very low :D

 

OK, i got it, X11 + mali is totally bad idea.

It's time to test something with direct rendering to fbdev ;)

Link to comment
Share on other sites
jock

jock

Posted
Posted
15 minutes ago, MX_Master said:

Just made a fullscreen test with glmark2 and the results are 


glmark2-es2 --fullscreen
=======================================================
    glmark2 2017.07
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-400 MP
    GL_VERSION:    OpenGL ES 2.0
=======================================================
[build] use-vbo=false: FPS: 10 FrameTime: 100.000 ms
[build] use-vbo=true: FPS: 14 FrameTime: 71.429 ms
[texture] texture-filter=nearest: FPS: 16 FrameTime: 62.500 ms
[texture] texture-filter=linear: FPS: 15 FrameTime: 66.667 ms
[texture] texture-filter=mipmap: FPS: 14 FrameTime: 71.429 ms
[shading] shading=gouraud: FPS: 10 FrameTime: 100.000 ms
[shading] shading=blinn-phong-inf: FPS: 9 FrameTime: 111.111 ms
[shading] shading=phong: FPS: 10 FrameTime: 100.000 ms
[shading] shading=cel: FPS: 7 FrameTime: 142.857 ms
[bump] bump-render=high-poly: FPS: 7 FrameTime: 142.857 ms
[bump] bump-render=normals: FPS: 14 FrameTime: 71.429 ms
[bump] bump-render=height: FPS: 11 FrameTime: 90.909 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 7 FrameTime: 142.857 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 7 FrameTime: 142.857 ms
[pulsar] light=false:quads=5:texture=false: FPS: 15 FrameTime: 66.667 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 3 FrameTime: 333.333 ms
[desktop] effect=shadow:windows=4: FPS: 10 FrameTime: 100.000 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 3 FrameTime: 333.333 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 3 FrameTime: 333.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 3 FrameTime: 333.333 ms
[ideas] speed=duration: FPS: 11 FrameTime: 90.909 ms
[jellyfish] <default>: FPS: 7 FrameTime: 142.857 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 7 FrameTime: 142.857 ms
[refract] <default>: FPS: 6 FrameTime: 166.667 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 15 FrameTime: 66.667 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 6 FrameTime: 166.667 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 14 FrameTime: 71.429 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 10 FrameTime: 100.000 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 7 FrameTime: 142.857 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 10 FrameTime: 100.000 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 10 FrameTime: 100.000 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 10 FrameTime: 100.000 ms
=======================================================
                                  glmark2 Score: 9 
=======================================================

I don't no, but performance is very low :D

 

OK, i got it, X11 + mali is totally bad idea.

It's time to test something with direct rendering to fbdev ;)

Mmmh, no there's definitely something not working... I got totally different results when I tried it myself, but it was with an older kernel and an older X server. It should have worked with latest bits although. I still have the sdcard for the Orange PI PC around here, let me compress and upload it for you.

 

1
Link to comment
Share on other sites
jock

jock

Posted
Posted

@MX_Master I sent you a private message with the link to the sdcard image.

Anyway I thought that you may double check your libEGL* and LibGLES* symbolic links using ldconfig -p.

Otherwise you could create a directory /opt/mali, put in libMali.so and create there all the necessary libEGL and libGLES symbolic links to libMali.so, then run glmark2 (or other gles apps) using LD_LIBRARY_PATH=/opt/mali glmark2-es2 --fullscreen command line, so the app will first check the libraries in /opt/mali, bypassing the - messy IMHO - mesa/glvnd machinery.

1
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept