Demystifying Odroid N2 hardware acceleration

Post Reply
odroidn2user
Posts: 6
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 5 times
Been thanked: 5 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 Mali promote the prowess of the 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.

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 Conclusion. 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 an as yet unknown (to me) 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 two ways to get to working graphics hardware acceleration:
- Drivers / software from Mali itself,
- Open source stuff from others (non-Mali).

--[ Drivers by Mali ]--

Well, we are in luck, somewhat. Through their Android support, Mali made Linux kernel drivers for the G12B soc, including hardware acceleration for the G52 GPU. The problem is, Mali 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. And Mali doesn't support the alternative to X11 - Wayland - in any meaningful and usable way either. Mali does the bare minimum to get Android support for the hardware it creates and delivers, but other than that... you are on your own. The Odroid N2 and mainstream Linux are a no-go if you actually want hardware accelerated Linux distributions.

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 binary bits from Mali 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 Mali proprietary 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 Mali on their proprietary Android drivers/support. While having working code in May 2019, development was halted in June awaiting better kernel support.

There is also some Wayland support with Mali proprietary bits working in June 2019, using framebuffer acceleration as shown here. This is where the official Hardkernel/odroid support seems to be, or rather: was. Only a specific Chromium browser version was supported on Wayland and some Phoronix benchmarking stuff worked. In July 2019 Hardkernel / odroid posted this video showing a working and hardware accelerated WebGL in Chromium. Wonderful to see, compliments all around, but this is only for those intimately knowledgeable with Linux, Mali, Wayland, Weston (probably) and Chrome and with much spare time on their hands. The Wayland thread has been silent now as of august 2019 (3 months), with no actually working image available, or progress since.

TL;DR: X11 or Wayland on the proprietary Mali bits: not actually happening. The Mali proprietary drivers, supplied for Android support, just aren't up to the task of delivering a real, working desktop.The proprietary bits (blobs) from Mali are useless for a normal Linux desktop.

With Amlogic's / Mali'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 have 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 ]--

The Odroid N2 has very capable hardware, it just remains unused on Linux desktops. Luckily, there are things afoot in the open source world!

First the bad news: Mali doesn't do open source development, at all. It seems they are scared to show their software. One reason is to prevent IP claims, other reasons are: ugly and messy code. (From what I understand, I haven't actually seen it, needs a few references.)

For this discussion to be meaningful, however, we have to look at the 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.

Then there is 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 the Mali proprietary blobs. With working support for 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.

And then there is 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. As well as, apparently... 3D acceleration is supported kernel side. And the current work-in-progress seems to be (VPU) video decoding (MPEG1 and 2 works, x264 in kernel 5.5, x265/HEVC is probably broken by Amlogic). This means we can say goodbye to the proprietary kernel 4.9 bits and have fully open sourced mainline Linux kernel support. 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.

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

With Meson support becoming available we would be able to create a new mainline Linux 5.4 image with working Meson G12B / Odroid N2 support without the proprietary Mali stuff and without working hardware acceleration soon(ish). Kernel 5.4 will be released somewhere around the end of November 2019. On our forum here, we keep an eye on Meson / Panfrost / Mesa open source developments.. Kernels are compiled and tested by neil armstrong, elatllat and tobetter. They also now have a release candidate 5.4 kernel available for testing purposes. No hardware acceleration yet, but Mali-free! So 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. Balbes150 works on a shared code base (image) for all S9xxx devices, where you just have to manually select and set the correct dtb.img file on the SD-card for the system you have. The letters dtb stand for device tree blob, a sort of roadmap to the hardware of the specific device - all these devices apparently differ a little bit. And it looks like there is a dtb for the Odroid N2 available. More info available in this tutorial on youtube. Also see the Armbian for Odroid N2 thread on our forum.

While a working mainline Kernel 5.4 image with Meson G12B support without the Mali proprietary bits would be awesome on its own already, it would also be an important stepping stone to having a mainline 5.5(+) image without the Mali proprietary stuff and with working Panfrost/G52 acceleration. This would likely be based on Wayland. But if/when kernel 5.5(+) arrives in an GPU 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. So, who knows, maybe Hardkernel could do an official Ubuntu 20.04 LTS Mate image with kernel 5.5, Meson G12B support and Panfrost support through Mesa 20.0. As Ubuntu just started development for 20.04 LTS Focal Fossa, we will have to wait and see.

--[ Conclusion -- TL;DR ]--

So, that's it: G12B soc support with G52 GPU hardware acceleration using the Mali proprietary bits work (sort of) on kernel 4.9, it's however just not good enough for anything desktop related. There is an ubuntu-minimal (non-desktop) image available with the Mali bits that makes it possible to do hardware accelerated Kodi, some retro-gaming and tiny testing-bits of Wayland. But this is a dead end for normal desktop productivity work. The Mali G52 is just not supported but the Amlogic S922X CPU processor is capable of closing some GPU-related gaps. Completely smooth video on a desktop environment is just not happening and we are stuck with kernel 4.9.

For a hardware accelerated desktop, we are waiting for:
- Mali to open and mainline their proprietary bits. This is just not happening.
- A working Wayland environment for desktops on the Mali bits using the accelerated framebuffer device - which just doesn't seem to stabilize into something actually usable.
- Meson and Panfrost open source drivers to advance enough to fully support the G12B soc with the Mali G52. Panfrost is however focusing on de T600-T880 Midgard line, and too many issues remain for it to be useful for us here.

Waiting until one of the above will magically materialize into a working solution will take a good while yet, if it actually happens. But Panfrost and Meson drivers are landing in Linux kernel 5.3 and newer through volunteer effort as we speak. And that clearly is our best bet going forwards. Keep an eye on this thread for actual results.

Until usable G52 support actually lands (if that ever happens) the Amlogic CPU does all the work and we are stuck with kernel 4.9. This happily results in a fully working desktop, just not a very fast or capable one and without newer kernels. But with newer Linux kernels with better support for Amlogic devices on their way... the future looks bright.

OK, please correct me where I am wrong, am missing bits, etc.
Last edited by odroidn2user on Fri Nov 01, 2019 1:01 am, edited 239 times in total.
These users thanked the author odroidn2user for the post (total 5):
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)

User avatar
mad_ady
Posts: 6796
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Has thanked: 216 times
Been thanked: 166 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: 72
Joined: Tue May 14, 2019 10:18 pm
languages_spoken: Turkish
ODROIDs: ODROID N2
Has thanked: 20 times
Been thanked: 1 time
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: 4549
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 77 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: 6
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 5 times
Been thanked: 5 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: 247
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Has thanked: 9 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.
[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 Nov 17, 2019 1:38 am, edited 6 times in total.

odroidn2user
Posts: 6
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 5 times
Been thanked: 5 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: 6
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 5 times
Been thanked: 5 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: 4128
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: 48 times
Been thanked: 214 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: 6
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 5 times
Been thanked: 5 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: 1576
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 24 times
Been thanked: 66 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: 6
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 5 times
Been thanked: 5 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: 72
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 7 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: 247
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Has thanked: 9 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: 72
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 7 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: 7
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: 6796
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Has thanked: 216 times
Been thanked: 166 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: 72
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 7 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: 72
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 7 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: 1576
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 24 times
Been thanked: 66 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: 4370
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: 39 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.

Post Reply

Return to “General Topics”

Who is online

Users browsing this forum: No registered users and 7 guests