HW Acceleration Working

[tkaiser]

That is the direction this discussion should go.

It's great that you constantly remind all of us where we have to look for, in which direction we should walk and even what we have to think. Really love this

May I remind you that problem N°1 of the Pine64 user community is the big difference between expectations raised and reality? And now please read through post #114 of this thread and #120.

BTW: A few months ago I also looked into this Mali madness. But for A64's little sibling H3 (Pine64 is nothing special, just a new member in the large linux-sunxi family of SBCs). I found exactly one application that made use of this 'Mali acceleration' everyone is talking about: es2_gears, that's a benchmark making use of OpenGLES. But I'm no gamer and then others reported that retro games would run fluently now (obviouly making use of OpenGLES acceleration). And after we decided to patch H3 BSP kernel to let Mali400 in H3 run with 600 MHz instead of 252 MHz retro gamers reported that they now get 40 instead of 30 fps in Quake.

In the meantime we tried hard to find any useable use cases for this Mali thingie while wasting hours of our life to find countless bugs/restrictions (eg. Chromium would need Mali driver revision x.y.z since versions prior to that can not accelerate WebGL through OpenGLES and so on). And also in the meantime people here wait for this Mali stuff for video acceleration instead of using it (with an appropriate player that makes use of vdpau/cedrus of course -- and not in any of the browsers since we're talking about aarch64 here and situation is special anyway)

---

My bad! I totally forgot our Mali400 use case N°1: Testing DRAM reliability on Allwinner SoCs! For example H3: http://forum.armbian.com/index.php/topic...nanopi-m1/

Using the GPU is great since GPU and CPU cores fight for DRAM ressources and by running heavy tasks on the GPU cores and running memtester in parallel we could reliably determine DRAM clockspeed limits and also DRAM calibration issues (that's the reason we at Armbian do limit every H3 board out there to 624 MHz since 672 MHz have to be found not reliable on every board).

So now with Mali400 being able to be accessed on A64 we could start with DRAM reliability testing too on Pine64 and do not have to trust in the vendor's 672 MHz. So I stand corrected. Mali400 acceleration is really useful!

[MarkHaysHarris777]

That is the direction this discussion should go.

It's great that you constantly remind all of us where we have to look for, in which direction we should walk and even what we have to think. Really love this  

marcus:
Please leave the commentary at home.  Stay with the technical topic , and leave the personal attacks at the door; last warning.  As long as its there, this is not just my opinion either... this has been stated many many times by longsleep as well. VDPAU and Cedrus are the key.  Mali is NOT the key.  The problem is that normal general population have no idea what mali is , nor is not , nor what drm is , nor is not , and they're confused.  That should be painfully obvious, even to you.


tkaiser
May I remind you that problem N°1 of the Pine64 user community is the big difference between expectations raised and reality? And now please read through post #114 of this thread and #120.

BTW: A few months ago I also looked into this Mali madness. But for A64's little sibling H3 (Pine64 is nothing special, just a new member in the large linux-sunxi family of SBCs). I found exactly one application that made use of this 'Mali acceleration' everyone is talking about: es2_gears, that's a benchmark making use of OpenGLES. But I'm no gamer and then others reported that retro games would run fluently now (obviouly making use of OpenGLES acceleration). And after we decided to patch H3 BSP kernel to let Mali400 in H3 run with 600 MHz instead of 252 MHz retro gamers reported that they now get 40 instead of 30 fps in Quake. [/quote]

marcus:
I agree with most of what you have said here. And, I think this is longsleep's point too... if the only reason you want or need mali is to run openGLES ( Gears !!!)  you don't need mali !!!!

tkaiser
In the meantime we tried hard to find any useable use cases for this Mali thingie while wasting hours of our life to find countless bugs/restrictions (eg. Chromium would need Mali driver revision x.y.z since versions prior to that can not accelerate WebGL through OpenGLES and so on). And also in the meantime people here wait for this Mali stuff for video acceleration instead of using it (with an appropriate player that makes use of vdpau/cedrus of course -- and not in any of the browsers since we're talking about aarch64 here and situation is special anyway)[/quote]

marcus:
Yes, I could not agree more. Which is why I suggested that we might want to take this discussion in the direction of Cedrus and VDPAU !!

[tkaiser]

What do you want to discuss regarding Cedrus/vdpau here? The only problem or three to be more precise are

• confusion constantly being spread (non-technical issue)
  
• expectations raised to the maximum (non-technical issue)
  
• ignorance (non-technical issue)
  

Cedrus/vdpau development happens completely in the open. This 'huuuuge' commit added support for A64 (6 months ago -- six months, that's half a year!) since jemk had all the work already done for H3 before and fortunately A64 is nearly the same here. And this is where we are with Cedrus.

Longsleep immediately added the necessary stuff to his BSP kernel sources and also provided immediately a PPA (integrated in his image by default!) with additional packages to make use of 2D and video acceleration. By using his image you can benefit from all of this since ages! The only thing that was missing is 'the Mali' as some call it.

And what happened in the meantime? Crappy OS images using outdated kernel versions and not containing the additions to make use of HW acceleration were used and even featured by the Pine64 folks themselves on their download page. It took them ages to provide OS images with less mistakes that contained more recent packages. And the only really working OS image they did not even mentioned at all in the wiki (took them weeks until this happened in the form of a link no one will click onto since too small and labeled wrong)

So all the important stuff was already there but Pine64 users have been kept away from it. Instead the arrival of 'the Mali' was announced. As if then every remaining issue would be fixed. 'The Mali' might help in a few other areas than retro gaming when real developers would start hacking around. But primarly it's just OpenGLES and will neither help with video acceleration nor 2D. And no youtube videos or Firefox as well.

If you've an application that benefits from OpenGLES (not OpenGL) acceleration then 'the Mali' is for you, otherwise not. And all of this does not change a bit regarding limited HDMI situation anyway (driver still using blobs, no useable license, no way to fix it). So why should we need a discussion of technical topics? Simply skip all posts in this lengthy thread except those from ssvb and longsleep and you know where we are from a technical point of view. The rest is confusion, raised expectations and ignorance. These are the real problems.

[adamw]

Hey guys...I'm having trouble deciphering all the tech-talk here.
Can I ask a question, and see where it takes me?

As I previously posted, I'm drawing to the screen using SFML.
My update rates are absolutely horrible (around 1fps or less for 1024x600 screen).

Is there any hardware acceleration on the A64 that I'm not currently using, that could be made available (MALI or otherwise), that would improve my fps?

[tkaiser]

I'm having trouble deciphering all the tech-talk here.

Then you will most probably have a really hard time going through the process of patching and compiling your application of choice to use OpenGLES with Mali400 (which will be a requirement for anything useful beyond running silly OpenGLES benchmarks or Quake3 with slightly higher framerates)

Just look through this http://forum.odroid.com/viewtopic.php?f=...06#p120706 and keep in mind that they're talking there also about an OpenGL ES Mali GPU but this is a different architecture (armhf vs. arm64) and you would still need to choose longsleep's drm branch and also extract the Mali blobs as described here somewhere in this thread.

In case you don't know what I'm talking about the simple answer to the question is: no, unfortunately not.

[jrullan]

Guys,

I don't want to be misunderstood, so I want to clarify a couple of points about my previous posts. (Feel free to point out any discrepancies , omissions and errors in the following statements in the spirit of helping to educate the community at large)
First, what I am personally excited about is the possibility of having hardware accelerated 3d Graphics in our Pines. Similar to the following:

http://www.linuxjournal.com/content/rasp...gl-support
https://www.raspberrypi.org/blog/another...n-release/

As far as my understanding goes (granted, it is limited compared to the pool of expertise in this thread) the application must have been written to use OpenGL (OpenGL ES in our case) and X must have a driver that relays the calls to the GPU to offload the task of rendering those images from the main processor, i.e. providing the performance gain we are excited about for the applications that use it.

In our case, the GPU is the Mali-400 MP2.  As far as I know, the driver for our GPU and architecture (arm64) was released by AllWinner recently, and its being referred here in the thread as the MALI blob because it is a binary provided by AllWinner, not the source code.

This caused a major "hype" if you will, for many people here in the forum. We still celebrate it in our IRC channel (see below - that screenshot is from today). AllWinner even dedicated or partially assigned (with the help of tllim) an engineer to help iron out how to integrate the arm64 version of the driver in X. Work by Lenny Raposo, ssvb, xalius, longsleep and others helped lenny.raposo-pine64.org enable and test the driver in our platform. Yes, there is at least one Pine using hardware acceleration for 3d graphics, albeit in a rudimentary fashion as pointed out by ssvb.



We though we had cracked the HW Acceleration issue when several community members noted the absence of an EULA (End user license agreement) that needs to be in place to be able to create a linux image that can be redistributed to the community, thus inflicting a major blow to the efforts of using it in a future image of debian or ubuntu. And I guess that's when the hype cooled down. Maybe the absence of an EULA have some legal implications that will forbid, for the time being, the distribution of the driver inside an image.

So what happened next? Well one member of the community suggested (and I echoed the suggestion) why instead of (or in addition to) waiting for the EULA, the community creates a How-To to follow the steps used by lenny.raposo-pine64.org for those who want to go ahead and try hardware acceleration of 3D graphics for themselves in the meantime? This suggestion might have been misunderstood because the reaction to it has been a bit harsh from some of the most influential members in the community, IMHO.

So in the end, I still believe that HW Acceleration is valuable, at least the folks at Raspberry PI seem to agree. Maybe we as a community are still too young to engage in this effort, but we were very close to do it and the best part is that we have a native arm64 distribution, so we would have been ahead of RPI3 which still uses a 32 bit architecture in a 64bit platform.

There... I hope this clarifies at least my position and requests in this thread.

[tkaiser]

This caused a major "hype"

And that's the only problem. As soon as you start to differentiate between 2D, 3D and video acceleration the hype is gone (unless you want to get more fps playing Quake3 being the type of retro gamer able to benefit from old boring Mali400)

[jkmooney]

First off, although I intellectually accept that Quake 3 is retr.....retuuuhhhh.......<wait, I can do this>......RETRO!!! seeing it so casually typed makes me feel old. I'll get over it though, just so long as my GameSpy account is still active

All that aside though, Cedrus does kind of look like the horse to bet on and working it on this board benefits that community. I did recently play with Kodi (via Android) for the first time and that was kind impressive. I could see rigging that to the basement TV. Although, I think you need some OpenGL (or OpenGL ES as the case may be) support to run that interface?

As for games, SBCs in general would probably be better for streaming from the more "beefy" computer on your network. I think you just need good video acceleration for that.

I do hope we get a Mali driver on the Pine but, maybe that's not the optimal target right now?

[MarkHaysHarris777]

All that aside though, Cedrus does kind of look like the horse to bet on and working it on this board benefits that community. 

That is the point precisely.

... if we want video for gnu+linux on the PineA64 (and I'm not at all talking about hardware acceleration) the Cedrus project is the right direction to go, and developing a browser that supports VDPAU.  It does not matter how we got to this point, nor who is responsible for the hype, nor who is to blame for crappy this or that, all that matters is that some developers step up to the problem and come up with a solution. The blame-game is a ridiculous waste of time. If you folks do not want to develop a VDPAU browser for the PineA64, well, use Android for video and use your gnu+linux for server and virtualization or simple hdmi (the way many of us already are!).

[jrullan]

Guys, please enlighten the rest of us because I'm actually quite confused here.

Is Cedrus/VPDAU related to 3D HW Acceleration?

I just took a quick look at it, and this is from the sunxi page:

Cedrus is a project intended for fully 100% libre and open source software, for using the hardware accelerated video decoding/encoding engine found in sunxi devices.

It seems to me it refers to hardware acceleration of video decoding/encoding. If it is so, then I think we are talking about something entirely different. All the Mali stuff is not related to video decoding. From Wikipedia (Mali):

Instead the Mali ARM core is a pure 3D engine that renders graphics into memory and hands the rendered image over to another core that handles the display.

Can you confirm this? If this is the case, then this thread needs to be split into two different threads: Video decoding/encoding and 3D Hardware Acceleration. And that will clear up about 80% of the discussions in this thread.