Nazar Gerasymchuk Posted January 2, 2019 Posted January 2, 2019 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
sfx2000 Posted January 3, 2019 Posted January 3, 2019 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)
Tido Posted January 3, 2019 Posted January 3, 2019 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.
Nazar Gerasymchuk Posted January 3, 2019 Author Posted January 3, 2019 @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?
zador.blood.stained Posted January 3, 2019 Posted January 3, 2019 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.
Nazar Gerasymchuk Posted January 3, 2019 Author Posted January 3, 2019 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.
zador.blood.stained Posted January 3, 2019 Posted January 3, 2019 Last time I tried it I didn't get it past the low FPS issue described in this thread. The only documentation I can point is this repository which contains some instructions that may or may not work with the kernel currently available in Armbian.
jock Posted January 3, 2019 Posted January 3, 2019 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
sfx2000 Posted January 3, 2019 Posted January 3, 2019 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...
devman Posted January 7, 2019 Posted January 7, 2019 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
MX_Master Posted February 22, 2020 Posted February 22, 2020 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?
jock Posted February 22, 2020 Posted February 22, 2020 @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
hexdump Posted February 22, 2020 Posted February 22, 2020 another thing to keep in mind is that your user needs access to /dev/mali - usually granted via some udev rule and the video group (usermod -a -G video username) ... example udev rule: https://github.com/hexdump0815/imagebuilder/blob/master/files/extra-files/etc/udev/rules.d/50-mali.rules good luck and best wishes - hexdump 2
MX_Master Posted February 23, 2020 Posted February 23, 2020 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 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 .....
hexdump Posted February 23, 2020 Posted February 23, 2020 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
MX_Master Posted February 23, 2020 Posted February 23, 2020 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
hexdump Posted February 23, 2020 Posted February 23, 2020 xorg seems to use the modeset driver, but you need to use the armsoc driver - something is wrong with your xorg config ... for the legacy mali driver the xorg server does not need the mali libs yet - only the gl app need them
MX_Master Posted February 23, 2020 Posted February 23, 2020 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
hexdump Posted February 23, 2020 Posted February 23, 2020 this xorg conf does not refer to the armsoc driver - here is a proven to be working example for an armsoc xorg.conf: https://github.com/hexdump0815/imagebuilder/blob/master/files/extra-files/etc/X11/xorg.conf.d.samples/01-armsoc.conf 1
MX_Master Posted February 23, 2020 Posted February 23, 2020 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 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 but something is still missing in the system
hexdump Posted February 23, 2020 Posted February 23, 2020 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
MX_Master Posted February 23, 2020 Posted February 23, 2020 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
jock Posted February 23, 2020 Posted February 23, 2020 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 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.
MX_Master Posted February 23, 2020 Posted February 23, 2020 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).
jock Posted February 23, 2020 Posted February 23, 2020 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.
MX_Master Posted February 23, 2020 Posted February 23, 2020 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 OK, i got it, X11 + mali is totally bad idea. It's time to test something with direct rendering to fbdev
jock Posted February 23, 2020 Posted February 23, 2020 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 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
jock Posted February 23, 2020 Posted February 23, 2020 @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
Recommended Posts