Mali support announced for mainline (Allwinner SOC's)

[makama80]

For what it's worth, and one of the most discussed topics can now hopefully finally closed: Mali in mainline

 

Did not try it, but the source is trustworthy to my humble knowledge... Still no open source release, but I guess it silences a lot of people questioning for Mali support!

 

For the real Mali die hards, here is a link to some more background info: Free Electrons

[Igor]

It's a good news. We are one step closer to farewell with junky Allwinner 3.4 kernels. 

[zador.blood.stained]

So we (or rather Maxime/Free-electrons) got r6p2 Mali400 armhf blobs with a good license. No arm64, no mali450 (?), so I wouldn't call this "closed"

[makama80]

Quote from the Free electrons: and they should work on all Allwinner SoCs using the Mali GPU.

 

Furthermore from the Mr. Torvalds device tree bindings:

 

- compatible

* Must be one of the following:

+ "arm,mali-300"

+ "arm,mali-400"

+ "arm,mali-450" *

 

And, optionally, one of the vendor specific compatible: + allwinner, sun4i-a10-mali + allwinner,sun7i-a20-mali + allwinner, sun50i-h5-mali + amlogic, meson-gxbb-mali + amlogic,meson-gxl-mali + stericsson, db8500-mali

 

So not that bad isn't it? Also the H5 is mentioned...

 

Or am I missing something?

[tkaiser]

1 minute ago, makama80 said:

Or am I missing something?

 

Maybe just a single use case that could benefit from what happened now only 5 years too late (not talking about this stupid benchmark with rotating horses). And whether the type of license 'allows' these blobs to be used with Mali450 in case these are 64-bit ones (AFAIK it's either or)?

 

https://www.cnx-software.com/2017/09/26/allwinner-socs-with-mali-gpu-get-mainline-linux-opengl-es-support/#comment-546293

[zador.blood.stained]

@makama80

The kernel driver is compatible with everything - 400, 450, armhf, arm64. We are talking about the userspace blobs limitations.

 

8 minutes ago, tkaiser said:

Maybe just a single use case that could benefit from what happened now only 5 years too late

Chromium, Kodi (even though useless without Cedrus), retro games, xf86-armsoc, Wayland (even though it's hard to find compatible blobs)

[tkaiser]

1 hour ago, zador.blood.stained said:

So we (or rather Maxime/Free-electrons) got r6p2 Mali400 armhf blobs with a good license.

 

And it took him only one year to get from r6p0 to r6p2. If things are progressing further that nicely I assume we'll have 64-bit blobs for Mali450 already in 2019!

 

1 minute ago, zador.blood.stained said:

Chromium, Kodi (even though useless without Cedrus), retro games, xf86-armsoc, Wayland (even though it's hard to find compatible blobs)

 

What about video decoding?!?!! Just kidding though that's what 99% of people associate now with this 'news'. And if I would want to make use of Mali acceleration with the use cases above why would I rely on these horribly slow Mali4x0 thingies anyway? Mali-T6xx seems to me like the (s)lowest hardware to go with...

[zador.blood.stained]

8 minutes ago, tkaiser said:

And if I would want to make use of Mali acceleration with the use cases above why would I rely on these horribly slow Mali4x0 thingies anyway?

Because I won't call it "acceleration" but "hardware support" (AFAIK Kodi doesn't run on software OpenGL ES (Mesa) at all) or "offloading", and if I really wanted good software support I would look i.e. in the direction of i.MX6 with Vivante GPUs that have Etnaviv open-source drivers.

[hojnikb]

Will armbian support this in future releases ?

[Igor Waracki]

Will be able to to fully use PC2 and other H5 boards on Arabmian with the all of there's potential? We will find out!

more info :

Arabian team im counting on you.

https://www.cnx-software.com/2017/09/26/allwinner-socs-with-mali-gpu-get-mainline-linux-opengl-es-support/

[zador.blood.stained]

Duplicate of https://forum.armbian.com/index.php?/topic/5265-mali-support-announced-for-mainline-allwinner-socs/, will be merged there shortly

In any case there are no arm64 binary drivers yet, so it means nothing for A64 and H5 (where this duplicate thread was posted) yet.

 

[James Kingdon]

Call me boring, but I wish that had been openCL support.

[jernej]

3 hours ago, James Kingdon said:

openCL

Which is not possible with all Mali GPUs Allwinner used till H6.

[James Kingdon]

6 hours ago, jernej said:

Which is not possible with all Mali GPUs Allwinner used till H6.

Ah, that's interesting. Is there a currently available SBC that has working openCL? It's something that I'd like to learn about someday, but hadn't looked into which boards could support it.

[willmore]

There is the Odroid XU4.  There are probably others.

[tkaiser]

31 minutes ago, James Kingdon said:

Is there a currently available SBC that has working openCL?

 

Just check the SoCs: RK3288 does, RK3399 does (you'll find even some performance information here in the forum), Exynos 5422 does. They have Mali Midgard GPUs which is the basic requirement to be able to use OpenCL. Whether performance is sufficient, whether those outdated OpenCL versions are sufficient, whether your skills to write stuff in a way it can benefit from running as OpenCL kernels on GPU cores is sufficient are different questions though

 

(never dealt with this stuff myself but one of my friends got mad over this few years ago)

[James Kingdon]

3 hours ago, tkaiser said:

 

Just check the SoCs: RK3288 does, RK3399 does (you'll find even some performance information here in the forum), Exynos 5422 does. They have Mali Midgard GPUs which is the basic requirement to be able to use OpenCL. Whether performance is sufficient, whether those outdated OpenCL versions are sufficient, whether your skills to write stuff in a way it can benefit from running as OpenCL kernels on GPU cores is sufficient are different questions though

Ah, that rings bells - I have two RK3288 boards, neither of which work. It was a reference to OpenCL on the Q8 that was one of the reasons I got one of those. Your comments about the potential pitfalls made me smile. Good points, but all part of the fun (maybe).

[kutysam]

From what i've seen, hdmi drivers are still not yet up for h3.

Which means,  if we want GUI with this mail accesleration, only possible devices are those with AV out or SPI screens.

 

I hope the devs can take a look at https://github.com/megous/linux/tree/orange-pi-4.13 for 4.13, there are patches for hdmi. I'm not sure if its implemented already

 

[jernej]

1 hour ago, kutysam said:

From what i've seen, hdmi drivers are still not yet up for h3.

Not in mainline, but there is RFC from me in September here. This driver (with some additional patches for audio) is also included in Armbian next. It also has some advantages to that in megous repository:

1. uses common DWC HDMI code (improvements for imx6 hdmi, for example, can improve H3 HDMI - that happened with CEC support, it took one line to make CEC work)

2. supports arbitrary screen resolutions

3. fully supports HDMI CEC

4. driver in megous repo can't be mainlined mostly because it doesn't use common code (point 1, Linux policy is "don't duplicate drivers")

 

So don't worry, Armbian next already has proper DRM HDMI driver, while I'm not sure about Armbian dev (it seems not).

 

Me and @zador.blood.stained already tried to add Mali X11 driver to Armbian next, but for some reason, it is extremly slow (but it works). This needs some more work.

[Igor]

29 minutes ago, jernej said:

while I'm not sure about Armbian dev (it seems not).

Exactly. H3 DEV is going to be ditched/exchanged for common sunxi-next. When DVFS is added, first testing H3 images go out ... 

[jock]

Is the HDMI code required for the fbdev flavour?

Just for curiosity I compiled the kernel driver successfully on an OPi-PC, installed it and also installed the userspace drivers; can't find a valid Device Tree overlay to let the kernel load the driver successfully.

I tried a miserable attempt to use the device tree portion from another a33-based device, manipulated it a bit, but still get a sad "Couldn't retrieve our reset handle" error from the driver

 

[zador.blood.stained]

10 minutes ago, jock said:

Is the HDMI code required for the fbdev flavour?

Yes

 

11 minutes ago, jock said:

Just for curiosity I compiled the kernel driver successfully on an OPi-PC, installed it and also installed the userspace drivers; can't find a valid Device Tree overlay to let the kernel load the driver successfully.

Are you using the Armbian's next branch or are you trying to compile a clean mainline kernel? In the latter case you'll need some extra patches that may be already present in linux-next or sunxi-next but may not be in the stable or 4.14-rcX branches.

[jock]

53 minutes ago, zador.blood.stained said:

Are you using the Armbian's next branch or are you trying to compile a clean mainline kernel? In the latter case you'll need some extra patches that may be already present in linux-next or sunxi-next but may not be in the stable or 4.14-rcX branches.

 

Clean mainline, actually the latest nightly from the armbian repository for H3 with kernel 4.11.12. With this kernel I'm already able to drive a HDMI panel and the framebuffer console works.

I'll give a shot then for latest sunxi-next kernel, yet the device tree should be manually fixed to load the kernel driver, I guess?

[zador.blood.stained]

8 minutes ago, jock said:

I'll give a shot then for latest sunxi-next kernel, yet the device tree should be manually fixed to load the kernel driver, I guess?

DT changes should look like this: https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/32-h3-DT-add-mali-node.patch.disabled

[Menion]

On 9/26/2017 at 10:06 PM, zador.blood.stained said:

Duplicate of https://forum.armbian.com/index.php?/topic/5265-mali-support-announced-for-mainline-allwinner-socs/, will be merged there shortly

In any case there are no arm64 binary drivers yet, so it means nothing for A64 and H5 (where this duplicate thread was posted) yet.

 

 

Well, another good reason to add Armbian option for building armhf userland for these SoC

[zador.blood.stained]

50 minutes ago, Menion said:

Well, another good reason to add Armbian option for building armhf userland for these SoC

If I understand it correctly Allwinner released only Mali400 blob, and H5 requires Mali450 one, so building armhf images won't help here either 

[Menion]

You are right...

But, well I admit I have never dig carefully in the Mali stack, but I see on the arm.developer website that there is the Mali userspace blog for Mali 450 mp4 and there is a kernel driver for it.

So I wondering what we miss, apart from a valid license of course...

[zador.blood.stained]

1 hour ago, Menion said:

So I wondering what we miss, apart from a valid license of course...

I'm not sure what we miss. Icenowy reported that she was able to run Mali on H3 and I think A64 (don't remember exactly) using NextThingCo and Rockchip blobs, but last time I tested Mali with H3, X11 and armsoc driver there was a performance issue, so next thing would be trying to test fbdev mali to check if it has similar problems.

[jernej]

4 hours ago, zador.blood.stained said:

so next thing would be trying to test fbdev mali to check if it has similar problems.

I can tell that I tested Mali wayland/gbm driver version and it works well.

[jock]

I'm back. Finally I managed to compile the sunxi-next kernel coming with armbian (4.13.y).

I had to remove the .disable suffix and patch the patch (no pun) Zador pointed above because the DTS section to be edited is in file sunxi-h3-h5.dtsi and not in sun8i-h3.dtsi.

 

Once I did that, compilation went fine, installed the proper .deb packages on my orange pi pc, rebooted and I got kernel 4.13.y working.

Then I compiled the mali kernel module on the OPi using the instructions from Free Electrons having care to export the shell variables this way:

export CROSS_COMPILE=arm-linux-gnueabihf-
export KDIR=/lib/modules/4.13.y/build

The build process produced the mali.ko driver and put it into /lib/modules/4.13.y/extra directory.

• I moved the module inside the kernel directory,
• run depmod
• finally run modprobe mali

and at last I got the module loaded by the kernel.

Nonetheless I could not run any of the benchmarks/utilities to query the EGL/OpenGL capabilities: all of them told me they could not find any suitable display :/

 

I guess you all already did this, but as long as I couldn't find suitable instructions nowhere, maybe this rough tutorial could be useful for someone else.