Demystifying Odroid N2 hardware acceleration

odroidn2user
Posts: 39
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 12 times
Been thanked: 11 times
Contact:

Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Fri Oct 25, 2019 5:27 pm

OK, so I bought the Odroid N2 from Odroid.co.uk and especially using the Manjaro ARM 19.08 KDE Linux environment, it's a pleasure.
KDE Plasma works perfectly fine, even with compositing enabled, Youtube in Firefox is actually watchable at 1080p and video files play somewhat OK.
A desktop replacement unlike some others that claim that fame, the Amlogic S922X combined with the big heat sink... This thing is a real powerhouse.

But... video performance really isn't that great, which is surprising given all that power under the hood.

Let's figure out how and why that is and what actually is happening!?

First of all: Amlogic created the S922X CPU, packages the Mali G52 GPU with it and calls this the G12B soc (system on a chip).
And Hardkernel delivers this all in a neat SBC (single board computer) package called the Odroid N2.
Hardkernel, Amlogic and ARM promote the prowess of the Mali G52 graphics chip as one of the best things on board:
- "a new generation Mali-G52 GPU", "the GPU is 10% faster than the N1" (The Odroid N1 is an RK3399 Mali T860?).
- It supports OpenGL-ES 1.1, 2.0, 3.0, 3.1 and 3.2 as well as OpenCL-1.2 and 2.0
- A hardware accelerated video decoder (VPU) driver is ready.
- the video layer is true 4K.
And that's just on the shop-page on Hardkernel.com.

Also: The S922X’s Amlogic Video Engine (AVE-10) supports hardware video decoding (VDEC) of MVC, MPEG-1/2/4, VC-1/WMV, AVS, AVS+, AVS2 RealVideo, MJPEG streams, H.264, H265-10 and VP9. AV1 hardware acceleration isn’t supported.

However... You are clearly not getting all that even on the official Hardkernel supplied Ubuntu Linux Mate image. The Linux Mate desktop works, but with all that power under the hood... it shouldn't struggle to play an mp4 or mkv video in VLC, MPV or Kodi on KDE / Mate. It should and could work a whole lot better.

So, why isn't this thing flying through video and laughing in the face of 4K resolutions!?
The short answer: Missing software to support the capable hardware.

Now it gets complicated and it turns out this is a big cloudy mystery. So, let's try to figure things out.
For TL;DR readers: just read the Roadmap section. For the actual information and the details, keep on reading.

Also, a little disclaimer first: I don't know the technical details of what I am writing about. I am not developing on these things, nor can I compile a kernel or create an image. This post is just the result of a lot of hours browsing around gathering information. So please correct. If we combine our knowledge, we can make the mystery clear for all.

--[ Demystifying Odroid N2 hardware acceleration ]--

OK, so the N2's system-on-a-chip is the G12B, which uses a Mali G52 GPU and the Amlogic Video Engine AVE-10 VPU.
The GPU does the graphics rendering and the VPU does the video decoding and encoding.
Both are not well supported, contrary to claims and (implicit) promises otherwise.

And to complicate things further, to support both the GPU and the VPU you need:
- Kernel side drivers that support the chipsets. (Hardware kernel drivers.)
- User side software that support the chipsets. (Drivers for X11/Wayland support, Kodi and VLC, etc.)

There are four ways to get to working graphics hardware acceleration:
- Drivers / software from ARM itself,
- Open source stuff from others,
- The 'best' of both worlds.
- Hybrid solutions: Mix and Match

--[ Mali Drivers by ARM]--

Well, we are in luck, somewhat. Through their Android support, ARM made Linux kernel drivers for the G12B soc, including hardware acceleration for the G52 GPU. The problem is, ARM doesn't have X11 drivers and does not support people using it at all. And Linux usually uses X11 for actually showing a desktop. So if you want to use X11 (desktop Linux) you are out of luck.

Luckily there is framebuffer acceleration. If you don't specifically need X11 or the usual Linux desktop environments, you are in luck. There is a hardware accelerated Ubuntu-minimal image using the proprietary Mali binary bits from ARM fixed to Linux kernel 4.9.

There is some very limited hardware accelerated video player support (VPU) for the accelerated framebuffer (GPU) driver: [Added, thanks mad_ady!] Accelerated video players for the Odroid C2 (search for c2play) should also work on the N2. See for example here and here. This requires the ubuntu-minimal, and requires you to play video from the console, only in full screen, not available from the desktop.

We also have Kodi using the same route, and with Kodi comes the wonderful CoreELEC, fully hardware accelerated and all. The N2 is now even marketed as a media device. That is: without all the Mate / KDE / Gnome whatever desktop bits. So Kodi works, just not on your desktop. On your desktop: VLC doesn't do well, MPV neither, etc, etc. So, for normal desktop usage, this is a dead end.

And there is framebuffer retro-gaming support. Through a lot of volunteer effort, accelerated retro gaming is made possible in The Retro Arena / TheRA, batocera and other distributions. A whole lot of fun, and wonderful to see, but this doesn't do much for actual desktop productivity.

On this forum, crashoverride was developing an X11 driver, called Jem, linking the accelerated framebuffer ARM proprietary Mali bits to X11. [Added, thanks mad_ady] This actually worked. It turned out, however, more complicated than expected. Crashoverride was looking for workarounds around workarounds made by ARM on their proprietary Android drivers/support. While having working code in May 2019, development was halted in June awaiting better kernel support.

We are in luck with Wayland, we don't just know it yet. ARM provides Wayland drivers in their proprietary blobs. And they work, sort off. There is Wayland support with proprietary Mali driver bits working in June 2019, using framebuffer acceleration as shown here. And this is where the official Hardkernel/odroid support seems to be. So far, officially, only a specific Chromium browser build was supported on Wayland and some Phoronix GL benchmarking stuff worked. In July 2019 Hardkernel / odroid posted this video showing a working and hardware accelerated WebGL in Chromium. So Wayland (userspace) works, the main problem here appears to be with the kernel drivers. In July 2019, the DRM (that is: Direct Rendering Manager) driver wasn't up to par and things halted.

TL;DR: X11 on the proprietary Mali bits: not happening. The Mali proprietary drivers, supplied for Android support, just aren't up to the task of delivering a real, working desktop. For Wayland however, ARM's Mali drivers might still bring us some benefit.

With Amlogic's / ARM's G12B soc support in their proprietary binary bits which are bolted onto kernel 4.9 (used for Android support), combined with pre-existing graphics software in the standard Linux Mesa 3D graphics library for doing graphics on the CPU, we do have a fully working Linux desktop! So while we don't get much in the way of hardware acceleration on Mate / KDE / Gnome / X11 / Wayland, the Amlogic S922X CPU is fairly capable of closing that gap.

--[ Open Source Drivers ]--

ARM doesn't do open source development for Mali drivers. There are, however, alternatives.

For this discussion to be meaningful, we have to look at ARM's Mali Graphics line-up. There are three product lines.
- Utgard: The Mali 200-470 line as of 2007,
- Midgard: The Mali T-line as of 2012, with the T600 through T880 products,
- Bifrost: The Mali G-line as of 2016, with the G71 and the G52 found on the Odroid N2.

For the Utgard line (Mali 200-470), open source support is landing in the kernel (mainline) using the Lima driver and support in Mesa 19.1 for X11/Wayland. Wonderful developments indeed, but for N2 (Bifrost) users, not that helpful.

Panfrost: Panfrost is a reverse engineered open source driver for Mali graphics chips, a bit like nouveau is the open source alternative for Nvidia propiertary bits software. Panfrost supports (or: plans to support) both Midgard and Bifrost. The official webpage for Panfrost has however nothing much to see. There is also this overview article on Panfrost and there is an informative, detailed video about Panfrost here.

The idea here is that, with their Panfrost kernel driver and the Panfrost Mesa Gallium 3D driver for X11 and Wayland, we get hardware support on the desktop, this includes support for the GPU as well as the VPU. The main developers on Panfrost is the company Collabora. And Collabora delivers. In March 2019 Tomeu Vizoso demonstrated an accelerated Wayland (using Weston) on Mali T860, as shown here and here. During the summer Collabora worked on the Panfrost Mesa driver. And with more good results, Collabora's Alyssa Rosenzweig demonstrated a working accelerated Wayland with a working accelerated Gnome environment as of June 2019. However, Collabora focusses on Midgard (the T600-T880 line) first, and not so much Bifrost (which is the G52). Though Bifrost is being worked on by Collabora as well, the priority is clearly on Midgard first. So this might take a while yet. The Panfrost work does land in the mainline kernel.

Ironically, this actually means Odroid N1 boards would have been supported about now on mainline Linux desktops, as there is now support for the Mali T860. While Panfrost kernel drivers now work for RK3399 boards, they were mainly waiting for the Mesa 3D drivers to catch up for X11/Wayland desktops to actually accelerate on the Mali hardware. With Mesa 19.2 released as of September 25th, hardware acceleration should now work for Rockchip RK3399 CPUs with Mali T860 GPU (e.g. the Rockpro64 and Rock Pi4). Fedora 31 now supports Panfrost on Wayland out of the box for RK3399, including a Firefox rebased on Wayland for a hardware accelerated Firefox experience.

While the Panfrost driver for Midgard on Wayland is still under active development, it does work pretty well already. Apparently even with full (non-ES) OpenGL 2.1 support! It even appears that the Panfrost Midgard drivers are already running quicker than ARM's Mali proprietary blobs. With working support for the Mali T860, they have made huge steps towards G52 support as well. So, clear steps are being taking towards a working ARM64 / ARMv8 Mali driver for the G52 there.

Meson: Open source Linux kernel support for Amlogic socs happens in the Meson kernel driver, with detailed information on their website. Through the Meson development, work is happening on G12B soc support as we speak. And it appears as though mainline Linux kernel 5.3+ now indeed has some N2 support. The Meson G12B drivers includes support specifically for Hardkernels Odroid N2 board: e.g. here, here, here, here, here and here.

Through the open source Meson kernel driver, things like the CPU, Ethernet, audio, USB, eMMC are now reported as supported as of mainline kernel 5.4 with thermal sensor support in 5.5. This now includes a functional DRM (Direct Rendering Manager) which brings 3D acceleration supported kernel side. The current work-in-progress seems to be (VPU) video decoding (MPEG1 and 2 works, x264 in kernel 5.5, x265/HEVC is work in progress). There is a G12B kernel support roadmap published on our forum here, with more detailed information on the Meson driver support in mainline Linux on the Meson website.

With both Meson and Panfrost, at some point in the future, we can have a fully open sourced mainline Linux kernel supported fully accelerated Linux desktop. Wonderful prospects, but not here now.

--[ The 'Best' of Both Worlds ]--

OK, so as of kernel 5.4 (now released) the G12B chipset is supported through Meson drivers, which means we can get hardware acceleration on the Desktop. But the VPU (video processing unit) still needs work. As we are now running the 4.9 patched kernel created for Android, we get pretty decent G12B chipset support already. The main problems being hardware acceleration - which is fairly capably rendered by the processor. The Odroid's processor however isn't powerfull enough to do full screen video playing smoothly. A fully working accelerated desktop (both GPU and VPU) now hinges on getting the VPU working. And that support (at least MP2 and x264) comes with kernel 5.5.

That still leaves us out an X11 or Wayland userspace graphics driver. Panfrost is just not up to speed for G52/Bifrost yet and nowhere near. Luckily, at least in theory, we should be able to combine the Meson DRM (Direct Rendering Manager) in the mainline kernel (5.4 onwards) with the ARM Wayland driver userspace blobs. The Meson DRM driver should now be advanced enough for ARM's Mali Wayland driver to actually work.

So, if anyone is adventurous enough... Kernel 5.4 with the Meson DRM driver, combined with the Mali Wayland driver, Mutter as Wayland implementation and Gnome 3 (probably the best supported Wayland desktop) should get us a working graphics accelerated desktop, however still with a somewhat unsupported VPU. So smooth video probably still not there even on a hardware accelerated Wayland. So, actual visual progress is probably not yet available if you use Wayland on Odroid N2.

--[ Hybrid solutions: Mix and Match ]--

And then there are some really alternative solutions, that might work but require some mixing and matching of technologies.

First off, there is a Kodi with hardware (GPU and VPU) acceleration. You can load it from the terminal/TTY, just not from the desktop. We've mentioned this above.

With Petitboot you can multiboot into CoreELEC, which is Kodi on a minimal GNU/Linux environment with fully GPU/VPU accelerated drivers. Works wonderfully well.

Using Petitboot you can also multiboot into Android when you want to do some hardware accelerated video viewing or use any of its accelerated apps. Android is well supported with both Android 9 AOSP by Hardkernel and Lineage OS 16 (Android 9) and Lineage OS 17 (Android 10) by Voodik. There is hardware support here for both the GPU and the VPU. Look at the N2 Android forum here.

Then there might be possibilities to use the working Android VPU/GPU drivers on Linux using Hybris / Libhybris. You could even start a Wayland session on the Android driver using Libhybris and start accelerated GNU/Linux apps from there. It appears as though you could even run a KDE/Kwin session, using this construction.

And finally, you could install Android as OS and start a Linux desktop from Android as an app, and switch back and forth. You could do this with VolksPC, and Android OS with built in Linux Desktop as an app. Read here and here. Or a build it yourself using a debian chroot and an Android XServer or VNC session. For example, with: LinuxOnAndroid (Complete Linux Installer) and UserLAnd (GNURoot Debian), or alike. See also the ChrootOnAndroid page on the debian wiki. That way you leverage Android's accelerated functionalities to augment the GNU/Linux environment where things haven't caught up to a fully accelerated experience just yet. These are temporary stop-gap solutions though. And: remember to do all this without using anything Google if you value your privacy and freedom. You can actually do quite well without that Orwellian organization being involved. So: yes, you can run Android without Google.

--[ Roadmap: Towards a free accelerated Odroid N2 package ]--

For a fully hardware accelerated desktop we now have two options. Hardkernel - or enthusiasts on the forum here - could do:
- An image with kernel 5.4(+), Meson G12B and Direct Rendering (DRM) support with Wayland drivers, running (probably) Mutter & Gnome3.
- An image with kernel 5.5(+), Meson G12B/DRM with Panfrost support through Mesa 20.0 whenever that will happen.

Getting your hands on working code? Build it yourself, or perhaps one of these two:
- Kernel 5.4 is available for the Odroid N2 now. If you like to live on the bleeding edge of development, then this is your chance. Read here and more specifically: here and here.
- Over at Armbian, Balbes150 is building S9xxx kernel 5.x images based on Ubuntu and Debian, including a Linux 5.4 release candidate testing image. Getting started on that, is somewhat daunting at first. Useful information is read on the original Armbian for Amlogic S905 thread. More info available in this tutorial on youtube. Also see the Armbian for Odroid N2 thread on our forum.

Graphics acceleration is now a (very near) possibility. But: wrinkles still need to be ironed out and real visible progress comes only with kernel 5.5 which has (improved) VPU support. And only when Panfrost for Bifrost (Odroid N2) matures, would we get having a mainline kernel image without the ARM proprietary stuff and with fully working G52 acceleration. This would then bring us a real free, open, accelerated desktop on Odroid N2 with X11 and Wayland, Kodi, VLC, GL-games, etc, etc.

If/when this all arrives in a working GPU and VPU accelerated package for Odroid N2 remains to be seen. Kernel 5.5 is expected well into Q1 2020, but also well in time for the Ubuntu 20.04 LTS (Long Term Support) release. As Ubuntu just started development for 20.04 LTS Focal Fossa, we will have to wait and see. And when then next real Long Term Service kernel 5.9 arrives, we should be golden!

OK, please correct me where I am wrong, am missing bits, etc.
Last edited by odroidn2user on Tue Dec 10, 2019 11:50 pm, edited 271 times in total.
These users thanked the author odroidn2user for the post (total 7):
istanbulls (Fri Oct 25, 2019 10:00 pm) • easybob95 (Sat Oct 26, 2019 3:55 am) • superpowter77 (Wed Oct 30, 2019 11:28 am) • ab1jx (Fri Nov 01, 2019 10:45 pm) • wdehoog (Tue Nov 05, 2019 6:47 am) • joshua.yang (Thu Nov 28, 2019 11:01 am) • gounthar (Sun Dec 01, 2019 7:46 pm)

User avatar
mad_ady
Posts: 6888
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Has thanked: 248 times
Been thanked: 181 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by mad_ady » Fri Oct 25, 2019 6:33 pm

You're correct. There is some work by crashoverride to implement a gpu accelerated x11 driver - search for "jem", but for a reason that elludes me, was not used mainstream, though results were promissing.

For the vpu - amlogic uses a separate video plane when decoding/displaying video. Accelerated video players for c2 (search for c2play) should work on the n2, but only in full screen..

Android offers best support for the hardware currently...
These users thanked the author mad_ady for the post:
odroidn2user (Fri Oct 25, 2019 7:26 pm)

istanbulls
Posts: 86
Joined: Tue May 14, 2019 10:18 pm
languages_spoken: Turkish
ODROIDs: ODROID N2
Has thanked: 27 times
Been thanked: 2 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by istanbulls » Fri Oct 25, 2019 10:27 pm

@odroidn2user
Very nice expression, thank you.

My first sbc experience was RockPro64 and my first Linux experience. After a few months, the drivers worked very well in Mali. I was hoping it would be the same for the N2, and these promises were made (the words were open-ended. A complete disappointment)

RockPro64 crashed, took N2 and was very famous at all forums at that time.
It's a good motherboard for Anbdroid and coreelec, but it's disappointing for Linux.
Not good for novice linux users like me at all.

worst feeling, uncertainty. (Is it not clear whether the mali driver will be for the desktop?

English is not the main language. sorry for typos

SlappyMcPhee
Posts: 96
Joined: Fri Aug 18, 2017 2:09 pm
languages_spoken: english
ODROIDs: XU4 (3 of them)
Has thanked: 0
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by SlappyMcPhee » Sat Oct 26, 2019 1:38 pm

In all honesty even though we over at The Retro Arena have made a great base retrogaming image for the public it has taken us much longer to go public than I wanted. The elephant in the room is that is Android makes these chipmakers all of their $$$. They seemingly could care less about traditional Linux or at least that is the perception in much of the community. This SoC should be delivering MUCH more, but since there isn't necessarily cash in Linux why bother right? Yes, I am very frustrated at this point because it won't be too long until this board will have been out for a year already and the likes of the Pi 4 will realistically make it fall into the shadows even though it really is a decent product. The thing is that it appears for the first time with the Pi 4 the RPi foundation has followed suit in dropping a product into the public space as if it a console game from the likes of Ubisoft, Activision, or the next WWE 2k game; half baked expecting the community to do all of the heavy lifting. Once again because of cash. The efforts by the community have seemed to be stellar in the amount put into it. I know that we have literally hundreds of man hours again into the N2 just as we have thousands into the XU4. Maybe with Microsoft becoming invested in both ARM and Linux we'll finally see progress that doesn't take multiple years to get to where things should be BEFORE a product goes public, but who knows. As I stated, this is ALL very frustrating as even though the challenge can be enjoyable to a point when you are constantly being beaten up by a public so already invested in the Raspberry Pi line of products it will always be an uphill battle. It really shouldn't be if a board is released as a solid and we'll developed product.

Sent from my Pixel 3a using Tapatalk

Owner The Retro Arena and Odroid Retro Arena

crashoverride
Posts: 4552
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 83 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by crashoverride » Sat Oct 26, 2019 2:21 pm

SlappyMcPhee wrote:
Sat Oct 26, 2019 1:38 pm
The thing is that it appears for the first time with the Pi 4 the RPi foundation has followed suit in dropping a product into the public space [...] half baked expecting the community to do all of the heavy lifting.
Not the first time. It was the same story when the RPi was first introduced (I know because I was one of the community members doing the 'heavy lifting'). Since all RPis have been the same hardware (VC4), there was little further effort required. The RPi4 is the first new hardware (VC-something-else). The main difference now is that nobody is even pretending its a 'charity' anymore so nobody is doing the work for them anymore (not even Broadcom).

FWIW, as a developer myself, I certainly share the N2 frustration: awesome SoC from Amlogic, but only Android makes the most of it.
These users thanked the author crashoverride for the post (total 3):
istanbulls (Sat Oct 26, 2019 5:26 pm) • rooted (Sun Oct 27, 2019 12:26 am) • odroidn2user (Mon Oct 28, 2019 7:03 pm)

SlappyMcPhee
Posts: 96
Joined: Fri Aug 18, 2017 2:09 pm
languages_spoken: english
ODROIDs: XU4 (3 of them)
Has thanked: 0
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by SlappyMcPhee » Sat Oct 26, 2019 2:44 pm

crashoverride wrote:
SlappyMcPhee wrote:
Sat Oct 26, 2019 1:38 pm
The thing is that it appears for the first time with the Pi 4 the RPi foundation has followed suit in dropping a product into the public space [...] half baked expecting the community to do all of the heavy lifting.
Not the first time. It was the same story when the RPi was first introduced (I know because I was one of the community members doing the 'heavy lifting'). Since all RPis have been the same hardware (VC4), there was little further effort required. The RPi4 is the first new hardware (VC-something-else). The main difference now is that nobody is even pretending its a 'charity' anymore so nobody is doing the work for them anymore (not even Broadcom).

FWIW, as a developer myself, I certainly share the N2 frustration: awesome SoC from Amlogic, but only Android makes the most of it.
And let's face it....it is because there is profit to be had with Android be it by directly licensing applications or through ad revenue. I get it, economics 101, however at the same time it is terrible how short sighted certain entities are with how true progress and possible future profit could be driven if development happened with a more open mindset. These chipset makers for at least the last half decade have seen the financial gain written on the wall with Android therefore that is their only true concern. Perhaps if genuine proof can be provided by one of their representatives steps up to prove different I'll learn to feel otherwise. It is truly sad because Android is far from a fun or less than frustrating OS to develop for. I personally find it annoying to deal with. I am still learning a lot about Linux as it is, but I find nothing enjoyable about Android. To me it is a phone OS and not much worth time other than for communication devices. I for example bought my ShieldTV not because it has Android, but because I can view all of my Plex content flawlessly most times. I did give core emulation some time, but the permissions issues and dealing with them on Android is far from intuitive and it always seems like a complete PITA. It is also not end user friendly to make any types of customization. For it being built from Linux that is quite sad really, but I digress. Hopefully the opensource driver development community can continue to crack things open and stick it to those that are too foolish to realize the true potential of the hardware being created.

Sent from my Pixel 3a using Tapatalk

These users thanked the author SlappyMcPhee for the post:
odroidn2user (Mon Oct 28, 2019 7:03 pm)
Owner The Retro Arena and Odroid Retro Arena

odroidn2user
Posts: 39
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 12 times
Been thanked: 11 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Sat Oct 26, 2019 10:50 pm

We should indeed be thankful for everyone who spends time supporting these ARM devices and finishing the half-***ed work that Mali did with their software. And indeed, it could have been so much better, and it isn't.

That said, even without the hardware acceleration, this is a *very* capable device. I am amazed at how well it performs even on the normal non-accelerated Manjaro KDE image - or even the supplied Ubuntu Mate. This thing does 1080p in youtube on Firefox on CPU alone! It is pretty powerful even without the G52 hardware running. The eMMC thing kicks ass obviously, quick ethernet, USB3 (even if not perfect), the petitboot / SPI thing works wonders and even without that it can boot from SD. The huge heatsink is also a big blessing, an excellent design decision right there. The Odroid N2 rocks! (It could rock a lot harder, sure, but still...) This thing packs quite a punch. And the GNU/Linux environment from Ubuntu, Debian or Manjaro/Arch makes it a Swiss Army knife powerhouse!

If anyone has any additional information or experiences about getting the hardware acceleration going... or pointers where we can find more information... that would be much appreciated!

(Also, I added a bunch of additional information in the opening post, and corrected some typo's in this post.)
Last edited by odroidn2user on Sun Oct 27, 2019 3:20 am, edited 3 times in total.

back2future
Posts: 265
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Has thanked: 11 times
Been thanked: 5 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by back2future » Sun Oct 27, 2019 1:42 am

Hardware progresses faster than software for that hardware can (depending on resources).
[Edit: Rockchip rk3399 SoC was introduced to public on Mobile World Congress, February 2016 (RK3399pro ~Jan2018) and that's around 3 (1/2) years for coding support for T860 (proprietary/panfrost performance(Wayland glmark2) ~1:1.4 improvement) in mainline kernel and integrating api/(e)abi library/user_space_driver into common desktop managers like Wayland protocol based, Gnome or Plasma.
How much are we willing to pay for having faster support for a G52 and VPU?
Amlogic doesn't even list g12b cores at their products page and Rk3588 is ~Q1/Q2_2020 and probably more extended PCIe support.
S922D=A311D? https://dl.khadas.com/Hardware/VIM3/Dat ... Wesion.pdf pages 3-4 for G52 and VPU overview
What's the gain, we can expect from hardware accelerated gp?]
Idling G52 saves power and reduces heat addition.
General purpose programming on G52 is available.
That said for Linux developers and not for Android users.
( Thx for this overview of widespread possibilities for contribution and me would not call it that much "demystifying". )
Last edited by back2future on Sun Dec 08, 2019 4:16 pm, edited 7 times in total.

odroidn2user
Posts: 39
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 12 times
Been thanked: 11 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Sun Oct 27, 2019 5:36 am

Hmm, reading up on the Meson driver support for the G12B soc (which is Odroid N2) ... Things seem to progress actually pretty quickly. I am not qualified to actually understand much of it, but the table here: http://linux-meson.com/doku.php#target_hardware seems to suggest things are looking up with even 3D acceleration reported as working and the VPU (video decoding) being worked on.

Now: if, how and when all that sweet software actually arrives in a working package...

Update: OK, added yet more info in the opening post. It seems to me I'm about done with it.
So if anyone has anything to add...

odroidn2user
Posts: 39
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 12 times
Been thanked: 11 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Mon Oct 28, 2019 11:53 pm

Meanwhile, over at Armbian, Balbes150 is building S9xxx kernel 5.x images, and seems to have some success.
https://forum.armbian.com/topic/7930-ar ... x/page/49/

Getting started on that, however, is way above my knowledge level.
Anyone here up to speed on this?

User avatar
tobetter
Posts: 4265
Joined: Mon Feb 25, 2013 10:55 am
languages_spoken: Korean, English
ODROIDs: X, X2, U2, U3, XU3, C1
Location: Paju, South Korea
Has thanked: 59 times
Been thanked: 235 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by tobetter » Tue Oct 29, 2019 4:17 am

odroidn2user wrote:
Mon Oct 28, 2019 11:53 pm
Meanwhile, over at Armbian, Balbes150 is building S9xxx kernel 5.x images, and seems to have some success.
https://forum.armbian.com/topic/7930-ar ... x/page/49/

Getting started on that, however, is way above my knowledge level.
Anyone here up to speed on this?
If you are fine to play with a headless image (no H/W acceleration), please refer to the link. The 5.4.0-rc5 kernel is finally reached to my repository as well.
viewtopic.php?f=176&t=33993&hilit=mainl ... 50#p268080
These users thanked the author tobetter for the post:
odroidn2user (Tue Oct 29, 2019 4:18 pm)

odroidn2user
Posts: 39
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 12 times
Been thanked: 11 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Tue Oct 29, 2019 4:01 pm

Well, headless without a working X/Wayland somewhere wouldn't be that much progress :)
But I'll take it you mean that there is no hardware acceleration.

I'll study the thread some more. Just installing the kernel probably won't boot it up, so I have some more studying to do how this N2-thing actually boots, "Demystifying the Odroid N2 boot process" ? :)

Also: updated the opening post with information on kernel 5.4 tests happening at Armbian and here on forum.odroid.com with tobetter.

elatllat
Posts: 1590
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 75 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by elatllat » Wed Oct 30, 2019 11:04 am

odroidn2user wrote:
Tue Oct 29, 2019 4:01 pm
..."Demystifying the Odroid N2 boot process" ? :)...
1 SPI, sdcard, or eMMc flash is selected based on availability and hardware switch
2 UBoot (located in the first few sectors of the boot medium) is executed and runs the boot.ini script in the first fat32 partition (no sure if anyone has a mainline version of that working)
3 The kernel and dtb are loaded and run by the script (upstream 5.3+ works, N2 specific distributions tend to adjust the default kernel config)
4 Any (18+) distributions offing an arm64 build takes it from there. (boot.ini script can select which partition to use as root with some limitations )
These users thanked the author elatllat for the post:
odroidn2user (Thu Oct 31, 2019 6:42 pm)

odroidn2user
Posts: 39
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 12 times
Been thanked: 11 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Thu Oct 31, 2019 6:44 pm

Fedora ARM now supports Panfrost and Wayland out of the box for RK3399s with their 31 release. No Panfrost for G12B/G52/Odroid N2 yet, but clear steps in the right direction.
See https://fedoramagazine.org/announcing-fedora-31/ and https://alt.fedoraproject.org/alt/

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Sat Nov 02, 2019 3:08 am

A more direct answer is at https://community.arm.com/developer/too ... li-gpu-ddk That was years ago but ARM apparently hasn't changed their policy.

Anybody can sign up to the ARM forum, I just did it. Maybe if they hear directly from more end-users grumbling that will help. For years I've heard great things about the famous Mali, now that I own a couple I can't do anything with them. I want to learn OpenGL ES on one, not the VideoCore in a Raspberry Pi.

https://community.arm.com/community-help/f/discussions

-------------

Well, OK, a 1 year license for Arm Development Studio Gold is $6500, that'll keep end-users out. https://store.developer.arm.com/store/e ... ition=1166

They don't care, they make their money on stuff for Android phones. There are millions of them sold and the phone manufacturers and retailers provide layers of insulation between ARM and consumers. User support can be time consuming and expensive, so just avoid it. Ever notice how most Chinese products are missing stuff like brand names, URLs, model numbers, and contact info? Same idea. Not sure what open source resources exist.

The Compute Library is MIT licensed, haven't explored it much yet. It's 31 MB as an xz file https://github.com/ARM-software/ComputeLibrary. The Neural Network stuff and documentation looks like it's probably external. An ls of the root dir looks like:

Code: Select all

arm_compute
data
docs
documentation
documentation.xhtml
examples
include
LICENSE
opencl-1.2-stubs
opengles-3.1-stubs
README.md
SConscript
SConstruct
scripts
src
support
tests
utils
This is from docs/00_introduction.dox inside:

Code: Select all

This archive contains:
 - The arm_compute header and source files
 - The latest Khronos OpenCL 1.2 C headers from the <a href="https://www.khronos.org/registry/cl/">Khronos OpenCL registry</a>
 - The latest Khronos cl2.hpp from the <a href="https://www.khronos.org/registry/cl/">Khronos OpenCL registry</a> (API version 2.1 when this document was written)
 - The latest Khronos OpenGL ES 3.1 C headers from the <a href="https://www.khronos.org/registry/gles/">Khronos OpenGL ES registry</a>
 - The latest Khronos EGL 1.5 C headers from the <a href="https://www.khronos.org/registry/gles/">Khronos EGL registry</a>
 - The sources for a stub version of libOpenCL.so, libGLESv1_CM.so, libGLESv2.so and libEGL.so to help you build your application.
 - An examples folder containing a few examples to compile and link against the library.
 - A @ref utils folder containing headers with some boiler plate code used by the examples.
 - This documentation.

You should have the following file organisation:

	.
	├── arm_compute --> All the arm_compute headers
	│   ├── graph.h --> Includes all the Graph headers at once.
	│   ├── core
	│   │   ├── CL
	│   │   │   ├── CLKernelLibrary.h --> Manages all the OpenCL kernels compilation and caching, provides accessors for the OpenCL Context.
	│   │   │   ├── CLKernels.h --> Includes all the OpenCL kernels at once
	│   │   │   ├── CL specialisation of all the generic objects interfaces (ICLTensor, ICLImage, etc.)
	│   │   │   ├── kernels --> Folder containing all the OpenCL kernels
	│   │   │   │   └── CL*Kernel.h
	│   │   │   └── OpenCL.h --> Wrapper to configure the Khronos OpenCL C++ header
	│   │   ├── CPP
	│   │   │   ├── CPPKernels.h --> Includes all the CPP kernels at once
	│   │   │   └── kernels --> Folder containing all the CPP kernels
	│   │   │       └── CPP*Kernel.h
	│   │   ├── GLES_COMPUTE
	│   │   │   ├── GCKernelLibrary.h --> Manages all the GLES kernels compilation and caching, provides accessors for the GLES Context.
	│   │   │   ├── GCKernels.h --> Includes all the GLES kernels at once
	│   │   │   ├── GLES specialisation of all the generic objects interfaces (IGCTensor, IGCImage, etc.)
	│   │   │   ├── kernels --> Folder containing all the GLES kernels
	│   │   │   │   └── GC*Kernel.h
	│   │   │   └── OpenGLES.h --> Wrapper to configure the Khronos EGL and OpenGL ES C header
	│   │   ├── NEON
	│   │   │   ├── kernels --> Folder containing all the NEON kernels
	│   │   │   │   ├── assembly --> headers for assembly optimised NEON kernels.
	│   │   │   │   ├── convolution --> headers for convolution assembly optimised NEON kernels.
	│   │   │   │   │   ├── common --> headers for code which is common to several convolution implementations.
	│   │   │   │   │   ├── depthwise --> headers for Depthwise convolultion assembly implementation
	│   │   │   │   │   └── winograd --> headers for Winograd convolution assembly implementation
	│   │   │   │   ├── detail --> Common code for several intrinsics implementations.
	│   │   │   │   └── NE*Kernel.h
	│   │   │   └── NEKernels.h --> Includes all the NEON kernels at once
	│   │   ├── All common basic types (Types.h, Window, Coordinates, Iterator, etc.)
	│   │   ├── All generic objects interfaces (ITensor, IImage, etc.)
	│   │   └── Objects metadata classes (ImageInfo, TensorInfo, MultiImageInfo)
	│   ├── graph
	│   │   ├── algorithms
	│   │   │   └── Generic algorithms used by the graph backend (e.g Order of traversal)
	│   │   ├── backends --> The backend specific code
	│   │   │   ├── CL --> OpenCL specific operations
	│   │   │   ├── GLES  --> OpenGLES Compute Shaders specific operations
	│   │   │   └── NEON --> NEON specific operations
	│   │   ├── detail
	│   │   │   └── Collection of internal utilities.
	│   │   ├── frontend
	│   │   │   └── Code related to the stream frontend interface.
	│   │   ├── mutators
	│   │   │   └── Used to modify / optimise the Graph intermediate representation(Operator fusion, in place operations, etc.)
	│   │   ├── nodes
	│   │   │   └── The various nodes supported by the graph API
	│   │   ├── printers
	│   │   │   └── Debug printers
	│   │   └── Graph objects ( INode, ITensorAccessor, Graph, etc.)
	│   └── runtime
	│       ├── CL
	│       │   ├── CL objects & allocators (CLArray, CLImage, CLTensor, etc.)
	│       │   ├── functions --> Folder containing all the OpenCL functions
	│       │   │   └── CL*.h
	│       │   ├── CLScheduler.h --> Interface to enqueue OpenCL kernels and get/set the OpenCL CommandQueue and ICLTuner.
	│       │   ├── CLFunctions.h --> Includes all the OpenCL functions at once
	│       │   └── tuners
	│       │       └── Local workgroup size tuners for specific architectures / GPUs
	│       ├── CPP
	│       │   ├── CPPKernels.h --> Includes all the CPP functions at once.
	│       │   ├── CPPScheduler.h --> Basic pool of threads to execute CPP/NEON code on several cores in parallel
	│       │   └── functions --> Folder containing all the CPP functions
	│       │       └── CPP*.h
	│       ├── GLES_COMPUTE
	│       │   ├── GLES objects & allocators (GCArray, GCImage, GCTensor, etc.)
	│       │   ├── functions --> Folder containing all the GLES functions
	│       │   │   └── GC*.h
	│       │   ├── GCScheduler.h --> Interface to enqueue GLES kernels and get/set the GLES CommandQueue.
	│       │   └── GCFunctions.h --> Includes all the GLES functions at once
	│       ├── NEON
	│       │   ├── functions --> Folder containing all the NEON functions
	│       │   │   └── NE*.h
	│       │   └── NEFunctions.h --> Includes all the NEON functions at once
	│       ├── OMP
	│       │   └── OMPScheduler.h --> OpenMP scheduler (Alternative to the CPPScheduler)
	│       ├── Memory manager files (LifetimeManager, PoolManager, etc.)
	│       └── Basic implementations of the generic object interfaces (Array, Image, Tensor, etc.)
	├── data -> Contains test images and reference data dumps used by validation tests
	├── docs -> Contains Doxyfile and Doxygen sources used to generate the HTML pages in the documentation folder.
	├── documentation
	│   ├── index.xhtml
	│   └── ...
	├── documentation.xhtml -> documentation/index.xhtml
	├── examples
	│   ├── cl_*.cpp --> OpenCL examples
	│   ├── gc_*.cpp --> GLES compute shaders examples
	│   ├── graph_*.cpp --> Graph examples
	│   ├── neoncl_*.cpp --> NEON / OpenCL interoperability examples
	│   └── neon_*.cpp --> NEON examples
	├── include
	│   ├── CL
	│   │   └── Khronos OpenCL C headers and C++ wrapper
	│   ├── half --> FP16 library available from http://half.sourceforge.net
	│   ├── libnpy --> Library to load / write npy buffers, available from https://github.com/llohse/libnpy
	│   └── linux --> Headers only needed for Linux builds
	│       └── Khronos EGL and OpenGLES headers
	├── opencl-1.2-stubs
	│   └── opencl_stubs.c --> OpenCL stubs implementation
	├── opengles-3.1-stubs
	│   ├── EGL.c --> EGL stubs implementation
	│   └── GLESv2.c --> GLESv2 stubs implementation
	├── scripts
	│   ├── caffe_data_extractor.py --> Basic script to export weights from Caffe to npy files
	│   └── tensorflow_data_extractor.py --> Basic script to export weights from Tensor Flow to npy files
	├── src
	│   ├── core
	│   │   └── ... (Same structure as headers)
	│   │       ├── CL
	│   │       │   └── cl_kernels --> All the OpenCL kernels
	│   │       └── GLES_COMPUTE
	│   │           └── cs_shaders --> All the OpenGL ES Compute Shaders
	│   ├── graph
	│   │   └── ... (Same structure as headers)
	│   └── runtime
	│       └── ... (Same structure as headers)
	├── support
	│   └── Various headers to work around toolchains / platform issues.
	├── tests
	│   ├── All test related files shared between validation and benchmark
	│   ├── benchmark --> Sources for benchmarking
	│   │   ├── Benchmark specific files
	│   │   ├── fixtures
	│   │   │   └── Backend agnostic fixtures to initialise and run the functions to test.
	│   │   ├── CL --> OpenCL benchmarking tests
	│   │   ├── GLES_COMPUTE --> GLES benchmarking tests
	│   │   └── NEON --> NEON benchmarking tests
	│   ├── CL --> OpenCL accessors
	│   ├── GLES_COMPUTE --> GLES accessors
	│   ├── NEON --> NEON accessors
	│   ├── datasets
	│   │   └── Datasets for all the validation / benchmark tests, layer configurations for various networks, etc.
	│   ├── framework
	│   │   └── Boiler plate code for both validation and benchmark test suites (Command line parsers, instruments, output loggers, etc.)
	│   └── validation --> Sources for validation
	│       ├── Validation specific files
	│       ├── fixtures
	│       │   └── Backend agnostic fixtures to initialise and run the functions to test.
	│       ├── reference
	│       │   └── Reference implementation used to validate the results of the various backends.
	│       ├── CL --> OpenCL validation tests
	│       ├── GLES_COMPUTE --> GLES validation tests
	│       ├── CPP --> C++ reference implementations
	│       └── NEON --> NEON validation tests
	└── utils --> Boiler plate code used by examples
	    └── Various utilities to print types, load / store assets, etc.

back2future
Posts: 265
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Has thanked: 11 times
Been thanked: 5 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by back2future » Sat Nov 16, 2019 11:08 pm

[ What has to be done, converting midgard-performance-analyze into bifro(e)st-performance-analyze?
What has to be done, converting bifrost-performance-analyze into vallhal-performance-analyze?
definition of /* (Performance counters for the) Job Manager */, /* Tiler */, /* Shader Core */, /* L2 and MMU */
https://gitlab.freedesktop.org/panfrost ... ce-analyze
gcc analyze.c -o mdgprf-analyze -I ./include

supported by drm/panfrost: Add initial panfrost driver March2019

Seems N2 has no V52 processor, but AVE-10.¹ ]
Last edited by back2future on Sun Nov 17, 2019 5:50 am, edited 1 time in total.

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Sun Nov 17, 2019 2:05 am

Well, I built Panfrost and installed it but
Use a mainline kernel version 5.2 or later with CONFIG_DRM_PANFROST enabled.
will take some doing. I have 4.9.190.

I hadn't heard of Panfrost, for anybody else that hasn't you can find it at https://gitlab.freedesktop.org/panfrost ... esktop.org The instructions at https://panfrost.freedesktop.org/buildi ... -mesa.html mostly worked, I had to install half a dozen things. Probably the show stopper for the longest is that the Debian name for pip3 is python3-pip so it doesn't come up in a search in Synaptic. pip installs into Python2, pip3 installs into Python3. I really dislike Python so I have limited patience with it.

I installed over ssh over wifi, my Odroid N2 is downstairs, haven't played with it yet. The midgard-performance-analyze built fine but without Panfrost I had nothing to feed into it.

quartexNOR
Posts: 10
Joined: Fri Sep 06, 2019 3:46 pm
languages_spoken: english
ODROIDs: XU4, N2
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by quartexNOR » Sun Nov 17, 2019 2:47 pm

If Hardkernel doesnt fix this, i think everyone should demand their money back.
I for one will do all i can to inform people NOT to buy from hardkernel if this isnt fixed soon.
This trend of selling boards first and leaving users to fend for themselves have to stop, this put a huge dent in my budget - and im now using a Jetson Nano where i wanted to use my N2.
Having bought 4 x N2, i find this insulting - and it caused great harm to my project too (a cluster system based on Hardkernel boards, 4 x XU4 + 1 x N2).

Having to buy new boards and redesigning my case has cost a fortune. I hope hardkernel get their act together.

User avatar
mad_ady
Posts: 6888
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Has thanked: 248 times
Been thanked: 181 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by mad_ady » Sun Nov 17, 2019 3:10 pm

To be fair, this is written on the product page:
Unfortunately, there is no X11 GPU driver since Arm has no plan to support X11 for Bifrost GPUs anymore. Therefore you have to consider ODROID-XU4 if you really need the OpenGL-ES acceleration on X11.
If this is what you're referring to...

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Sun Nov 17, 2019 10:57 pm

Well, so it's a good excuse to learn Wayland, look at it that way. I've never seen Wayland do much useful, but it will come along if people start writing stuff for it. I spend most of my time in terminal emulators and Firefox anyway. I'm resurrecting my Rock64 for OpenGL ES, which I'm mostly only interested in for one project.

How would OpenGL ES be useful in a cluster anyway? You're going to have machines with synchronized graphics? Whoopie. OpenCL maybe, but we have that now.

bumbum
Posts: 6
Joined: Wed Jan 09, 2019 6:41 pm
languages_spoken: English,Samoan,Norsk
ODROIDs: Odroid XU4
Odroid N2
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by bumbum » Mon Nov 18, 2019 6:20 pm

hey ppz, im not sure if this is the right place to ask but any info would be amazballz :) ..
I need info on if &/ when it would be possible to use the GPU for HW encoding of HEVC as running on cpu is at 0.1x :,(

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Mon Nov 18, 2019 10:28 pm

If you mean this HEVC (I had to look it up) https://en.m.wikipedia.org/wiki/High_Ef ... deo_Coding then possibly. Not necessarily in realtime but if you want to turn a bunch of old WMV and AVI files into (h.265?) maybe. But it's just the latest greatest format du jour, there'l be something better before long. I just use ffmpeg, before that it was mencoder.

The bottleneck with OpenCL is that the more global the memory is, the slower access is. It's great for manipulating matrices of numbers fast but reading and writing files to get and store them is slow. Rotating objects in 3D is done by manipulating matrices of numbers that are the x,y,z coordinates of them. You have maybe hundreds of little processors in there. Each has a little memory, it can share its workgroup memory with another bunch, maybe there's another level, but access to global memory is slowest.

Similar question: https://stackoverflow.com/questions/182 ... -using-gpu and see https://trac.ffmpeg.org/wiki/HWAccelIntro specifically https://trac.ffmpeg.org/wiki/HWAccelIntro#OpenCL You'd need to get OpenCL set up and working (clinfo should work) and then build ffmpeg from source to enable OpenCL and make sure it detects it.

bumbum
Posts: 6
Joined: Wed Jan 09, 2019 6:41 pm
languages_spoken: English,Samoan,Norsk
ODROIDs: Odroid XU4
Odroid N2
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by bumbum » Mon Nov 18, 2019 11:13 pm

Yea mainly looking to encode into HLS h265 or even if i have to h264 ( non hls :P) *my server is a mashup of all vid formats, i wanna standardize them and using the cpu would take months :P*
Using OpenCL only really deals with surfaces and filtering not the hardcore encoding and decoding im looking for.
i have used the v4l2m2m libz b4 on my xu4 and the vaapi on my laptop but the v4l2m2m doesnt work on my N2 ATM well the h264 decoder does-ish, So im wondering mainly when, if anyone knows these will be implemented

elatllat
Posts: 1590
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 75 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by elatllat » Mon Nov 18, 2019 11:21 pm

ab1jx wrote:
Mon Nov 18, 2019 10:28 pm
...Not necessarily in realtime...h.265...OpenCL...
The data sheet indicates "H.265/H.264 video encoding up to 1080P@60fps with low latency" I assume in real time via a VPU sub-module. (as mentioned c2play uses this, but maybe someone will add gstreamer or ffmpeg support)

User avatar
memeka
Posts: 4398
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 1 time
Been thanked: 45 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by memeka » Tue Nov 19, 2019 3:28 am

If you want to reencode movies, I recommend using the software encoder In the background. It’s slow, but you get nicer quality. The hardware encoding is useful only if you want to get real-time encoding, for real-time stream conversion.
That said, there won’t be any support added to ffmpeg for the amlogic encoder, and it will be added only later in mainline kernel as v4l2m2m - but currently they are still working on decoder.

back2future
Posts: 265
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Has thanked: 11 times
Been thanked: 5 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by back2future » Sat Nov 23, 2019 2:41 am

...
I hadn't heard of Panfrost,
...
We are also interested in Khronos' dev.
https://www.khronos.org/vulkan/
@themoment G71 (surroundings: HiKey970_4xA73/4xA53/NPU_lpddr4@6GB_G72MP12_GPS_PCIEGen3_$299 > HiKey960_4xA73/4xA53_lpddr4@4GB_G71MP8_$259_Vulkan1.0 > OdroidH2_CeleronN4105_ddr4@32GB_UHD600_$245_Vulkan1.1 > JetsonNano_4xA57_lpdrr4@4GB_128-coreMaxwell_$99-109_Vulkan1.1 > OdroidN2_4xA73/2xA53_ddr4@4GB_G52MP4(6EE)_$70 > Intel_NeuralComputeStick2_$69) only: https://developer.arm.com/tools-and-sof ... ost-kernel
[ 11/24/2019: Estimation possible how many S922X (or A311D) SoCs were produced or sold being advertised as (Android supported) MediaCores? What's the cost for one S922X compared to a rk3399?
https://androidpctv.com/comparative-amlogic-s922x/ S908X
Question can be for some: Do I want to have a HiKey960 and supported G71 or a tripleN2, that's a 18core,12GB_ddr4, usb3.0 or Gbe connected SoC cluster without G52 *nix based OS support @themoment, for comparable cost? ]
Last edited by back2future on Sun Nov 24, 2019 10:20 pm, edited 9 times in total.

ASword
Posts: 195
Joined: Fri Aug 04, 2017 12:48 pm
languages_spoken: english
ODROIDs: XU4, HC1, 2x N2
Has thanked: 6 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ASword » Sat Nov 23, 2019 3:44 am

quartexNOR wrote:
Sun Nov 17, 2019 2:47 pm
If Hardkernel doesnt fix this, i think everyone should demand their money back.
I for one will do all i can to inform people NOT to buy from hardkernel if this isnt fixed soon.
This trend of selling boards first and leaving users to fend for themselves have to stop, this put a huge dent in my budget - and im now using a Jetson Nano where i wanted to use my N2.
Having bought 4 x N2, i find this insulting - and it caused great harm to my project too (a cluster system based on Hardkernel boards, 4 x XU4 + 1 x N2).

Having to buy new boards and redesigning my case has cost a fortune. I hope hardkernel get their act together.
Wow, that's a bit sensationalist. There are plenty of use cases for the N2 that don't go anywhere near what you perceive as missing capabilities. These are sold as open developer solutions, not shrink wrapped solutions to YOUR particular problem. It is therefore on YOU to assess whether any product like the N2 can actually meet your need(s) prior to purchasing them.

quartexNOR
Posts: 10
Joined: Fri Sep 06, 2019 3:46 pm
languages_spoken: english
ODROIDs: XU4, N2
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by quartexNOR » Sun Nov 24, 2019 11:31 am

ASword wrote:
Sat Nov 23, 2019 3:44 am
Wow, that's a bit sensationalist. There are plenty of use cases for the N2 that don't go anywhere near what you perceive as missing capabilities. These are sold as open developer solutions, not shrink wrapped solutions to YOUR particular problem. It is therefore on YOU to assess whether any product like the N2 can actually meet your need(s) prior to purchasing them.
You seem to forget the long pre-order wait. It said nothing about this in the pre-order promo. They even posted a video to youtube showing chrome rendering WebGL.
As for the rest of your text -- when did I have some notion that they should provide me with anything in particular?
When a product is promoted as "A better XU4", and doesnt list that X drivers wont be there - its not entitled to believe it will be.
Asking that the desktop uses the GPU in todays SBC climate is very reasonable i think.

I wouldnt even bother complaining about it - if I didnt see the potential in this SBC. The CPU power alone is fantastic.
Which its why it's such a shame that I wont be able to use it as I hoped.
Not exactly a huge drama this, just a costly customer experience.

And last: The reason I used ODroids, was to help promote the brand.
Its great boards and I think they deserve more attention.
So again, very little drama - except being annoyed that I spent so much money, and have to recycle these wonderful machines as routers and game machines (which i have more than enough of already).

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Sun Nov 24, 2019 12:48 pm

As I understand it somebody didn't pay to have the X11 drivers written when they paid for the Wayland one, for whatever reason. As a marketing decision it sucks. The advertising is maybe slightly misleading but having both drivers would have been ideal. I'm sitting at my Rock64 which does have acceleration and for less money but only 4 cores. And waiting for my Pinebook Pro.

I don't think it's unreasonable to hope that something in the open source world can be adapted. It's rarely profitable to write new drivers for old hardware, that just doesn't happen. But because it's a great machine otherwise somebody might spend the time on it, free operating systems tend to support older hardware. If somebody donates or loans one to somebody capable of writing the driver that could change things. But also I don't know how much of a white elephant it is, whether the driver will only work on an N2. Being a commercially written blob would turn OpenBSD people off, they wouldn't touch the Raspberry Pi for a long time. They do list the N2, not sure how well it's supported. https://www.openbsd.org/arm64.html

crashoverride
Posts: 4552
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 83 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by crashoverride » Sun Nov 24, 2019 7:40 pm

ab1jx wrote:
Sun Nov 24, 2019 12:48 pm
As I understand it somebody didn't pay to have the X11 drivers written when they paid for the Wayland one, for whatever reason.
ARM makes the GPU (Mali-G52) that Amlogic used (S922 SoC [system-on-chip]). Hardkernel is one of many companies that purchases the S922 (family) and makes boards (N2).

ARM dropped support for X11 in its newer (Bifrost and later) GPUs. There is no driver license to purchase. If there was, it would be up to Amlogic to purchase it and provide it as part of their BSP (board support package). HardKernel and other companies then use the BSP to support their customized hardware boards and customers.

The most likely reasons for ARM dropping X11 support is that 1) Android is the dominate OS and does not use X11 along with 2) RedHat, Intel, etc. deprecating X11 in favor of Wayland (which after more than a decade of development is still not ready).

The lack of X11 support for newer ARM GPUs affects all SoC makers integrating Mali GPUs (Amlogic, Rockchip, etc.).

[This information is provided to help 'demystify' the situation. It represents my understanding at the time of writing.]
These users thanked the author crashoverride for the post (total 2):
meveric (Sun Nov 24, 2019 8:55 pm) • mad_ady (Sun Nov 24, 2019 9:06 pm)

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Sun Nov 24, 2019 10:47 pm

https://en.wikipedia.org/wiki/Mali_(GPU) so don't buy a new Mali. I'm hoping something like this could be adapted https://github.com/ayufan-rock64-packag ... deo-armsoc A Rock64 has a Mali 450MP2 which is Utgard (I still can't keep the Mali families straight). https://developer.arm.com/ip-products/g ... li-450-gpu But it comes with "OpenGL ES 1.1 and 2.0, OpenVG1.1". Newer isn't better in this case. https://wiki.pine64.org/index.php/ROCK64_Main_Page

The Odroid N2 comes with a Mali G-52 (2018) which is Bifrost 2nd generation by the Wikipedia page. Utgard was 2007 - 2015 roughly.

quartexNOR
Posts: 10
Joined: Fri Sep 06, 2019 3:46 pm
languages_spoken: english
ODROIDs: XU4, N2
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by quartexNOR » Tue Nov 26, 2019 6:48 am

The Mali thing is actually something I have stayed clear of up until now.
I tested 20 different SBC boards between 2017 and 2018, and every single board that had issues, both graphically or otherwise, were fitted with a mali gpu.
This is also why ODroid came as such a fresh breath of air, because they made the mali work.

I remember the ODroid XU4 was a let-down when it just came out, graphics was slow as hell. So I put it on the shelf with the others figuring I would never buy a mali SBC ever again.
8-9 months later I decided to give it a second chance, so i downloaded the latest image and gave it a test.
Graphics was stellar! Drivers had finally arrived and performance was exceptional -- so much so that I bought 15 of them to use in my cluster system.

Which is also why I placed my trust in Hardkernel, because they seemed to pay more attention to things like drivers, compared to other board makers.
There is this trend lately, of companies putting together boards in haste to tap into the IoT market (Tinkerboard being a prime example), and then leaving drivers up to the community to fix themselves.
This is a trend that I really want to see gone, because it creates an intrinsic distrust that solid companies end up paying for.
You wouldn't get away with something like this under Windows or OS X. Try releasing a PC without drivers, it would be returned within minutes.

So if they truly skipped ordering drivers for X11, or if it's mali that is more interested in Android from a financial point of view -- I still think Hardkernel should roll up their sleeves and rectify this.
A full boycott is perhaps a bit radical, but i was angry when i posted that.

I read somewhere on Reddit that Arch-linux for the N2 ships with the 5.x kernel, and that drivers are either released there, or scheduled upstream shortly.
I dunno, I have already started designing a cradle for the Jetson Nano that goes into the clustering cube. But there is ZERO doubt, the N2 is the best hardware available under $100 right now.
I can only imagine the performance when the GPU is fully utilized by Linux.

It makes no sense that Hardkernel dont fix this. With the Raspberry PI v4 having issues, the situation is ripe to strengthen their market position.

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Tue Nov 26, 2019 9:34 am

I'm not sure who needs to fix it, is it Hardkernel or Amlogic? I have Raspberry Pis, but they're sort of slaves to what Broadcom/Videocore is willing to release. Omxplayer does very well, but if you dig into the programming examples in /opt/vc you find they depend on Dispmanx which is nonstandard, it's something from Broadcom. ARM/Mali is also complicated because ARM is in the UK yet they own parts of the designs of chips made in Asia. So Hardkernel may have been as snowed as you were.

I'm finding a similar situation on my Rock64. Supposedly there's an accelerated driver but only a full-screen one. You can't have an accelerated window with widgets/controls around it. It's like it needs to control the whole framebuffer. I can already write programs that use the CPU to write to the framebuffer but I'd like to put text and buttons around it. QT maybe. What's really a shame is that all these designs in chipland fly by so fast that they're obsolete next week, there's no profit in going back to write more drivers for one, they just crank out the next generation and sell those. Mostly they aim at the cell phone market where millions of them are sold.

I'm at least a little curious about Wayland so I decided to play with it. Not the first time but there aren't many useful programs yet that run under it.
https://linoxide.com/linux-how-to/run-w ... rch-linux/ Start by installing Wayland and Weston, they can coexist with xorg stuff.
x11_weston.jpg
x11_weston.jpg (198.74 KiB) Viewed 1592 times
Here I did an apt search wayland in a Wayland terminal in a Weston window in an xorg screen. But it's in its infancy: notice the terminal emulator has no scroll bars, I can't scroll up the list of stufff.

User avatar
memeka
Posts: 4398
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 1 time
Been thanked: 45 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by memeka » Tue Nov 26, 2019 10:57 am

Neither HK or Amlogic can fix it.
To write a driver for the GPU, you need to know some details that neither HK or Amlogic know, they are just integrators.

ARM -> soc maker -> board maker

For the XU4, Samsung (soc maker) did not provide mali drivers to HK (although you can find some in their repositories, like I found mali drivers for Tizen and make them work on Ubuntu). But HK went directly to ARM and got a license, which means ARM sold the drivers source code to HK. HK can compile the code and distribute the driver.

For the N2, Amlogic bought the license from ARM, so ARM gave the code to Amlogic they compiled it and gave the binary driver to HK.

But in all and everywhere, everyone with mali end up with a driver which was developed by ARM.

ARM drivers can be compiled for different platforms: fbdev, X11 and wayland. Based on the license they give you the code to compile for the platform you pay :) you want to distribute drivers for X11 and wayland, you pay double to ARM :)

With the N2, ARM did not develop a driver for X11. This means neither HK or Amlogic can do anything about it, they never write any mali driver just bought it from ARM. And only ARM can write the driver since they know the GPU internals.

Given all this, there is the Lima/Panfrost projects that try to reverse engineer the internals of the mali GPU and its architecture and write a driver for it. But since it’s reverse engineering it’s a lot of try and error and it will take time to develop. I hope it’s more clear now :)
These users thanked the author memeka for the post:
gounthar (Sun Dec 01, 2019 8:18 pm)

User avatar
memeka
Posts: 4398
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 1 time
Been thanked: 45 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by memeka » Tue Nov 26, 2019 11:56 am

@ab1jx
many programs run well under wayland. wayland is supported by GTK3 and QT5, so all gnome and all kde apps are running under wayland (with GPU acceleration).
also, instead of weston, you can run gnome or kde. but not under x11, but directly so that wayland can get direct access to the GPU and run accelerated.

odroidn2user
Posts: 39
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 12 times
Been thanked: 11 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Tue Nov 26, 2019 8:18 pm

memeka wrote:
Tue Nov 26, 2019 11:56 am
@ab1jx
many programs run well under wayland. wayland is supported by GTK3 and QT5, so all gnome and all kde apps are running under wayland (with GPU acceleration).
also, instead of weston, you can run gnome or kde. but not under x11, but directly so that wayland can get direct access to the GPU and run accelerated.
As a general statement, this is true. Fedora runs Wayland and that seems to work well enough.
But specifically for the Odroid N2 and the ARM / Mali driver, that just doesn't seem to be true.

At least, I can't find any good evidence that we could get a working Wayland desktop on the proprietary Amlogic/ARM/Mali blobby bits.

The closest I can find was running one Chromium version and some OpenGL testing suite stuff.
I.e.: viewtopic.php?f=177&t=35255&start=50#p263741 and viewtopic.php?f=177&t=35255#p258332
But given that no other results are reported as of July 2019... and quite a few people are looking for a working solution...

Wayland on proprietary Mali blobs doesn't seem to be a working solution / route to a working solution.
I'd be more than happy to run Gnome on Wayland, if that means smooth video playback and smooth graphics...

If anyone has a working, hardware accelerated Wayland desktop Linux setup for the Odroid N2, please share!

User avatar
memeka
Posts: 4398
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 1 time
Been thanked: 45 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by memeka » Tue Nov 26, 2019 11:02 pm

@odroidn2user
ok let's continue demystifying :)
running wayland, in addition to the mali drivers, require drm drivers.
this is a driver which was supposed to be written by amlogic (it's the meson drm ip from amlogic socs).
initially, there was no drm driver, only fbdev. this is also when initially N2 was released with the fbdev mali drivers too.
next, i know there was some effort from HK to fix a buggy meson drm driver from amlogic to work so that wayland mali drivers would work. there were bugs and not ideal solution, but it resulted in the posts you linked, having weston and chromium running, although quite buggy. this is all with the original 4.9 kernel that came from amlogic.

in parallel, i actually ran gnome3 on wayland working very nicely at release time, before the posts you linked. this was on mainline linux (5.0 i think it was back then) with the meson drm driver from mainline.
but at that time, there were a few issues with the mainline kernel:
1. no CPU DVFS. clocks were statically set to 1.2Ghz or something like that. CPU performance was far from ideal, even if GPU was working nice. CPU DVFS for N2 was added in mainline kernel 5.4 released this week.
2. no VPU drivers. only mpeg i think. i didn't track this one as much, but i think 4K support and H264 support was added in kernel 5.3, and H265 is now being worked on.
3. other things not in mainline yet :) USB3 was untested at that time too.

So, the other option, mainline linux, was running wayland and all wayland and GPU acceleration nicely, but no VPU and other things not working.
In the meantime, there has been lots of progress, and N2 with mainline is becoming quite usable - although i did not try it for some time :D
Depending on your use case, N2 on latest kernel released this week should be quite usable. 5.4 kernel is a LTS kernel, but a short one (2021). I suspect 5.9 will be a long LTS kernel, supported to 2025. By the next LTS in the middle of next year, i think N2 will have all essential systems working - gpu, vpu, sound, 4k, usb3.... at the next LTS i will def take my N2 off the shelf and set it up with ubuntu 20.04 lts as well, should be a solid system for 5 years time.

EDIT: my mistake, H264 support was added 4 hours ago: https://www.spinics.net/lists/arm-kernel/msg770840.html :)
These users thanked the author memeka for the post:
odroidn2user (Wed Nov 27, 2019 2:00 am)

User avatar
AreaScout
Posts: 1130
Joined: Sun Jul 07, 2013 3:05 am
languages_spoken: german, english
ODROIDs: X2, U3, XU3, C2, HiFi Shield, XU4, XU4Q,
N1, Go, VU5A, Show2, CloudShell2,
H2, N2, VU7A, VuShell
Has thanked: 26 times
Been thanked: 76 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by AreaScout » Tue Nov 26, 2019 11:53 pm

    @ab1jx

    I think the main problem is, Mali can't write a DRM driver for the N2 and it did not write one for the XU4 because they are all use it's own Display Processor aka DP and unique Video Processors if they would use the Display Processors from Mali you could easily download the open source kernel drivers and integrate it like you do with the GPU kernel side open source drivers then things would be a looot easier https://developer.arm.com/tools-and-sof ... adf-kernel and Mali could just ship you a user space library with DRM support but this is not the case and so Mali send you an ordinary fbdev user space library (blob) or the source code to write your own.

    https://developer.arm.com/ip-products/g ... -processor

    RG

    User avatar
    igorpec
    Posts: 421
    Joined: Sat Dec 12, 2015 4:34 pm
    languages_spoken: english,german,slovene
    ODROIDs: XU4, HC1, C2, C1+
    Has thanked: 11 times
    Been thanked: 32 times
    Contact:

    Re: Demystifying Odroid N2 hardware acceleration

    Unread post by igorpec » Wed Nov 27, 2019 1:00 am

    "ARM diversity fires back" ;)

    If we combine proprietary libraries with open source and pack/sell as "opensource" product people will always found themselves in the corner. It is also a reason to drive and support true open source projects such as Lima / Panfrost, Allwinner opensource video acceleration drivers ...

    Corporations will not give their keys away just like that.

    Google recently proposed changes to the kernel which are good - setting some standards, while purpose is less modest. Initially they only want to simplify maintaining of (their) proprietary code. OK, let's leave economical reasons on a side even this is IMO the core why we have this mess in first place - maintaining is simply too expensive and Linux (ARM) desktop market is too small. It is hard to said if proposed solution will be supported/accepted and if that will create gain for us - better, updated closed drivers?
    ARMBIAN - follow on Twitter
    linux for ARM development boards with user friendly development tools

    odroidn2user
    Posts: 39
    Joined: Fri Oct 25, 2019 4:14 pm
    languages_spoken: english
    ODROIDs: N2
    Has thanked: 12 times
    Been thanked: 11 times
    Contact:

    Re: Demystifying Odroid N2 hardware acceleration

    Unread post by odroidn2user » Wed Nov 27, 2019 1:59 am

    memeka wrote:
    Tue Nov 26, 2019 11:02 pm
    i actually ran gnome3 on wayland working very nicely at release time, before the posts you linked. this was on mainline linux (5.0 i think it was back then) with the meson drm driver from mainline.
    ---8<--
    In the meantime, there has been lots of progress, and N2 with mainline is becoming quite usable - although i did not try it for some time :D
    Depending on your use case, N2 on latest kernel released this week should be quite usable. 5.4 kernel is a LTS kernel, but a short one (2021). I suspect 5.9 will be a long LTS kernel, supported to 2025. By the next LTS in the middle of next year, i think N2 will have all essential systems working - gpu, vpu, sound, 4k, usb3.... at the next LTS i will def take my N2 off the shelf and set it up with ubuntu 20.04 lts as well, should be a solid system for 5 years time.
    Thanks for the demystification! :)
    And the middle of next year (if you mean 2020) is not too bad!

    However, if I understand your post correctly, the solution to a working accelerated desktop is this formula:

    - Mainline kernel (5.4) with mainline Meson DRM module - which is now: check, available
    - Mali Wayland user space drivers - which are: check, available
    - A Wayland implementation: check, available (somewhere in the Debian repo, Weston, or as it is Gnome: Mutter?)
    - Gnome3: check, available (somewhere in the Debian repo)

    And:
    - No (hard) need for panfrost, as we have the open Meson DRM thing and the closed Mali Wayland userspace drivers, which contrary to earlier posts DO work, just not on the DRM implementation at the time of kernel 5.0.

    Which to me sounds like we have all the puzzle pieces available right now.
    Sounds like a package it up and put a ribbon on it, kinda deal?
    Which means... we should be golden now?
    Last edited by odroidn2user on Wed Nov 27, 2019 3:01 am, edited 2 times in total.

    User avatar
    AreaScout
    Posts: 1130
    Joined: Sun Jul 07, 2013 3:05 am
    languages_spoken: german, english
    ODROIDs: X2, U3, XU3, C2, HiFi Shield, XU4, XU4Q,
    N1, Go, VU5A, Show2, CloudShell2,
    H2, N2, VU7A, VuShell
    Has thanked: 26 times
    Been thanked: 76 times
    Contact:

    Re: Demystifying Odroid N2 hardware acceleration

    Unread post by AreaScout » Wed Nov 27, 2019 2:37 am

    @odroidn2user

    Sorry I addressed my post above to the wrong user I was meant to address it to you :D

    Yes you are right if Meson DRM is fully working in kernel >= 5.4 then all you need is a working binary blob aka user space library from AmLogic which has support for it and all should be fine, oh and libdrm support would be cool too, that would enable x11 because xf86 armsoc driver uses libdrm iirc, at least from a user space library point of view not much would be needed to support it I believe.

    RG

    odroidn2user
    Posts: 39
    Joined: Fri Oct 25, 2019 4:14 pm
    languages_spoken: english
    ODROIDs: N2
    Has thanked: 12 times
    Been thanked: 11 times
    Contact:

    Re: Demystifying Odroid N2 hardware acceleration

    Unread post by odroidn2user » Wed Nov 27, 2019 3:11 am

    AreaScout wrote:
    Wed Nov 27, 2019 2:37 am
    Yes you are right if Meson DRM is fully working in kernel >= 5.4 then all you need is a working binary blob aka user space library from AmLogic which has support for it and all should be fine, oh and libdrm support would be cool too, that would enable x11 because xf86 armsoc driver uses libdrm iirc, at least from a user space library point of view not much would be needed to support it I believe.
    Aah, good news then: So close, so close!
    It remains to be seen just how good it works, but based on Memeka's experience with 5.0 kernel and an otherwise working graphics hardware acceleration and even mentions of a working and compliant VPU... I don't remember seeing much about libdrm though.

    If the Gnome3 -> Mutter -> Mali Blobs -> Meson DRM connection is as it seems, we should be able to fabricate a working accelerated desktop! Just add a boat load of plugins and addons onto Gnome - to get something you actually want to use - and we are done!

    And I say we, having no experience packaging anything and being very well experienced in breaking stuff... :)
    (So: hint, hint!)

    User avatar
    AreaScout
    Posts: 1130
    Joined: Sun Jul 07, 2013 3:05 am
    languages_spoken: german, english
    ODROIDs: X2, U3, XU3, C2, HiFi Shield, XU4, XU4Q,
    N1, Go, VU5A, Show2, CloudShell2,
    H2, N2, VU7A, VuShell
    Has thanked: 26 times
    Been thanked: 76 times
    Contact:

    Re: Demystifying Odroid N2 hardware acceleration

    Unread post by AreaScout » Wed Nov 27, 2019 3:27 am

      Breaking stuff is part of the "game" :lol:

      libdrm would be needed for apps using DRM/KMS like Kodi with GBM backend, but Kodi also supports pure Wayland so it should be needed more or less only if the binary blobs would support X11

      RG

      edit: Wayland also uses libdrm so that would be needed

      odroidn2user
      Posts: 39
      Joined: Fri Oct 25, 2019 4:14 pm
      languages_spoken: english
      ODROIDs: N2
      Has thanked: 12 times
      Been thanked: 11 times
      Contact:

      Re: Demystifying Odroid N2 hardware acceleration

      Unread post by odroidn2user » Wed Nov 27, 2019 3:54 am

      AreaScout wrote:
      Wed Nov 27, 2019 3:27 am
        libdrm would be needed for apps using DRM/KMS like Kodi with GBM backend, but Kodi also supports pure Wayland so it should be needed more or less only if the binary blobs would support X11
        edit: Wayland also uses libdrm so that would be needed
        Well, looking at the pretty pictures (I can do that!) on Wikipedia...
        https://en.wikipedia.org/wiki/Direct_Rendering_Manager AND specifically: https://en.wikipedia.org/wiki/File:Linu ... _stack.svg
        ... It seems that Wayland on itself can make do without a libdrm.

        But man, that wikipedia page is long...

        User avatar
        AreaScout
        Posts: 1130
        Joined: Sun Jul 07, 2013 3:05 am
        languages_spoken: german, english
        ODROIDs: X2, U3, XU3, C2, HiFi Shield, XU4, XU4Q,
        N1, Go, VU5A, Show2, CloudShell2,
        H2, N2, VU7A, VuShell
        Has thanked: 26 times
        Been thanked: 76 times
        Contact:

        Re: Demystifying Odroid N2 hardware acceleration

        Unread post by AreaScout » Wed Nov 27, 2019 4:02 am

          Yea damn long, Wayland is Greek for me :lol: , maybe memeka is enlighten us, I was reading here https://elinux.org/images/9/93/The-Mode ... tronix.pdf

          edit: maybe he had Wayland with G2D mesa software renderer running ?

          RG

          User avatar
          memeka
          Posts: 4398
          Joined: Mon May 20, 2013 10:22 am
          languages_spoken: english
          ODROIDs: XU rev2 + eMMC + UART
          U3 + eMMC + IO Shield + UART
          Has thanked: 1 time
          Been thanked: 45 times
          Contact:

          Re: Demystifying Odroid N2 hardware acceleration

          Unread post by memeka » Wed Nov 27, 2019 5:40 am

          Let me say again: wayland with full gpu hardware acceleration was working on mainline for a long time.
          But HK could not use mainline since cpu was crippled, and there was no vpu driver back then...
          So there’s no solution where “everything works”.
          Mainline now should be mostly working, and getting better :)
          But even if you can get a fully accelerated desktop now without panfrost using the binary blobs, there are still reasons to want panfrost:
          1. X11 :) if you really want X11, it will work with panfrost. Won’t ever work with binary blob since arm said so :)
          2. Small things - there are small bugs in the arm driver. Usual software like kodi and retroarch is ok, but in bit projects like chrome you do hit some annoyances that will crash the app sometimes. Usually the developer response is: I’m not gonna do a workaround for your issue, fix your drivers.
          These users thanked the author memeka for the post:
          AreaScout (Wed Nov 27, 2019 5:46 am)

          User avatar
          AreaScout
          Posts: 1130
          Joined: Sun Jul 07, 2013 3:05 am
          languages_spoken: german, english
          ODROIDs: X2, U3, XU3, C2, HiFi Shield, XU4, XU4Q,
          N1, Go, VU5A, Show2, CloudShell2,
          H2, N2, VU7A, VuShell
          Has thanked: 26 times
          Been thanked: 76 times
          Contact:

          Re: Demystifying Odroid N2 hardware acceleration

          Unread post by AreaScout » Wed Nov 27, 2019 5:53 am

            @memeka

            Sure panfrost is a must for me too in the long run, most applications are supporting Mesa best :)

            RG

            odroidn2user
            Posts: 39
            Joined: Fri Oct 25, 2019 4:14 pm
            languages_spoken: english
            ODROIDs: N2
            Has thanked: 12 times
            Been thanked: 11 times
            Contact:

            Re: Demystifying Odroid N2 hardware acceleration

            Unread post by odroidn2user » Wed Nov 27, 2019 6:59 am

            memeka wrote:
            Wed Nov 27, 2019 5:40 am
            Mainline now should be mostly working, and getting better :)
            But even if you can get a fully accelerated desktop now without panfrost using the binary blobs..
            I like the part where Memeka casually mentions we can now have a fully accelerated desktop on Odroid N2. :)

            Sure, it is with Mali blobs and it isn't free and open source. But hey, I like watching fullscreen video without painful eyes!
            So if that is possible with the Odroid N2 now, I vote for us not waiting until such time comes that Panfrost starts supporting Bifrost.

            Fedora on Intel/x86 runs Wayland just fine, it's their default choice. So if we can have an accelerated desktop on Wayland on ARM/Odroid N2... I'd say: let's not wait for X11 Panfrost support and go with what we can have today: a fully accelerated Linux desktop on Wayland.

            User avatar
            memeka
            Posts: 4398
            Joined: Mon May 20, 2013 10:22 am
            languages_spoken: english
            ODROIDs: XU rev2 + eMMC + UART
            U3 + eMMC + IO Shield + UART
            Has thanked: 1 time
            Been thanked: 45 times
            Contact:

            Re: Demystifying Odroid N2 hardware acceleration

            Unread post by memeka » Wed Nov 27, 2019 11:10 am

            @odroidn2user - a good description of the current status is here: viewtopic.php?f=176&t=33993&p=273683#p273680

            for video, you don't need GPU, you need VPU drivers, which are the ones just submitted for 5.5 (H264 only, no H265 yet).

            odroidn2user
            Posts: 39
            Joined: Fri Oct 25, 2019 4:14 pm
            languages_spoken: english
            ODROIDs: N2
            Has thanked: 12 times
            Been thanked: 11 times
            Contact:

            Re: Demystifying Odroid N2 hardware acceleration

            Unread post by odroidn2user » Wed Nov 27, 2019 5:27 pm

            memeka wrote:
            Wed Nov 27, 2019 11:10 am
            @odroidn2user - a good description of the current status is here: viewtopic.php?f=176&t=33993&p=273683#p273680

            for video, you don't need GPU, you need VPU drivers, which are the ones just submitted for 5.5 (H264 only, no H265 yet).
            Thanks.
            And: Good point. The main sticky point is video playing acceleration, and that isn't up to speed yet.
            I've updated the opening post with the status, as far as I understand it based on reading the linked report and your posts here.

            It looks to me though, as we could have used the Wayland userspace drivers from Mali, combined it with the G12B soc support based on Mali patches in kernel 4.9 and have a working accelerated desktop? It seems the Wayland tests that were done, were done using a mainline kernel? I know it isn't as easy as that, but:

            Did anyone ever test the Mali Wayland drivers with the Mali kernel 4.9 in a Wayland (Mutter/Gnome3) kinda desktop setup?

            Post Reply

            Return to “General Topics”

            Who is online

            Users browsing this forum: No registered users and 1 guest