HW Acceleration Working

[longsleep]

Yes that's why it is not built in my kernel :-)

I've just found someone that updated mali_drm to work with the new drm kernel functions (for kernel 3.x)

https://github.com/loboris/OrangePI-Kern...dules/mali

It compiles just fine using your kernel source (3.10.65). But I cannot insert the module, maybe something I'm missing:

insmod: ERROR: could not insert module mali_drm.ko: Invalid module format

Ok, i'm having some problems with the magicversion (somehow it added a plus sign after the extra version), forcing is not working either, I will check this later.

Compiling is not the issue - problem is that this module uses drm_sman all overthe place which has been removed. The tree you linked is even older and i am unable to see a "fix" or change for that problem there.

[lenny.raposo-pine64.pro]

waiting on tllim for the libMali.so and associated files for aarch

[moondark]

Compiling is not the issue - problem is that this module uses drm_sman all overthe place which has been removed. The tree you linked is even older and i am unable to see a "fix" or change for that problem there.

Yes I understand, but this version fixes several problems, such as the init functions and allocation functions that does not exist anymore, (e.g., drm_init and drm_exit). Another example are memory zones, this was removed in the drm of 3.x kernels, this version uses some placeholders and other replacements.

They also implemented replacements for sman drm functions based on mm to maintain the compatibility among structs. Please, take a look at the mali_drv.c, for instance, all missing functions from pre-3.0 were replaced or implemented somehow. I'm talking about these files: 

https://github.com/loboris/OrangePI-Kern...e/mali_drm

However, I'm not sure about the compatibility of the drm headers available in the include directory and those in the kernel. Some careful inspection is needed.

In addition, after compiling it I built the modules symbols and checked for missing symbols, none were missing, however I do not have much experience building kernel modules and dealing with kernel compiling scripts, thus I don't know where to change the mod_layout and magic version. I think I may need to install the new kernel and modules altogether. I may try to do this in the weekend.

To sum up, I think it is possible to compile and run mali_drm, this tree seems to fix many problems related to the kernel version incompatibilities. Although I'm not optimistic about the userland driver, i.e. libMali.so for arm64, which is available for Mali450. They are distributed in binary form, so it is impossible to fix any possible incompatibility.

libmali for arm64 is available in : http://malideveloper.arm.com/resources/d...e-drivers/

I'm not sure if they can be used with Mali-400, but because they are user space drivers, there may be some kind of compatibility layer.

---

waiting on tllim for the libMali.so and associated files for aarch

Looking forward to it.
Can't wait to use GL ES on the pine.

[longsleep]

They also implemented replacements for sman drm functions based on mm to maintain the compatibility among structs. Please, take a look at the mali_drv.c, for instance, all missing functions from pre-3.0 were replaced or implemented somehow. I'm talking about these files: 

https://github.com/loboris/OrangePI-Kern...e/mali_drm

However, I'm not sure about the compatibility of the drm headers available in the include directory and those in the kernel. Some careful inspection is needed.

In addition, after compiling it I built the modules symbols and checked for missing symbols, none were missing, however I do not have much experience building kernel modules and dealing with kernel compiling scripts, thus I don't know where to change the mod_layout and magic version. I think I may need to install the new kernel and modules altogether. I may try to do this in the weekend.

Yes, but i tried the patched version already - does not work for me.

Code:

insmod mali_drm.ko
[  458.086883] mali_drm: Unknown symbol drm_sman_cleanup (err 0)
[  458.086942] mali_drm: Unknown symbol drm_sman_set_range (err 0)
[  458.086975] mali_drm: Unknown symbol drm_sman_takedown (err 0)
[  458.086999] mali_drm: Unknown symbol drm_sman_alloc (err 0)
[  458.087067] mali_drm: Unknown symbol drm_sman_init (err 0)
[  458.087110] mali_drm: Unknown symbol drm_sman_owner_clean (err 0)
[  458.087140] mali_drm: Unknown symbol drm_sman_owner_cleanup (err 0)
[  458.087164] mali_drm: Unknown symbol drm_sman_set_manager (err 0)
[  458.087187] mali_drm: Unknown symbol drm_sman_free_key (err 0)

Where are those symbols supposed to come from?

[Luke]

As someone with considerably lesser technical know-how than most on this forum, all I will ask are these two questions: 1) do you guys think that will we have/ you will get hw acceleration working on the Pine64 in the coming weeks ?; and 2) any chance for accelerated desktop environment ?

Thanks, I very much appreciate your work !

[rahlquist]

As someone with considerably lesser technical know-how than most on this forum, all I will ask are these two questions: 1) do you guys think that will we have/ you will get hw acceleration working on the Pine64 in the coming weeks ?; and 2) any chance for accelerated desktop environment ?

Thanks, I very much appreciate your work !

The talent here is quite good but everyone is at the mercy of Allwinner and their willingness to provide... 

I think I wouldn't hold my breath.

[moondark]

They also implemented replacements for sman drm functions based on mm to maintain the compatibility among structs. Please, take a look at the mali_drv.c, for instance, all missing functions from pre-3.0 were replaced or implemented somehow. I'm talking about these files: 

https://github.com/loboris/OrangePI-Kern...e/mali_drm

However, I'm not sure about the compatibility of the drm headers available in the include directory and those in the kernel. Some careful inspection is needed.

In addition, after compiling it I built the modules symbols and checked for missing symbols, none were missing, however I do not have much experience building kernel modules and dealing with kernel compiling scripts, thus I don't know where to change the mod_layout and magic version. I think I may need to install the new kernel and modules altogether. I may try to do this in the weekend.

Yes, but i tried the patched version already - does not work for me.

Code:

insmod mali_drm.ko
[  458.086883] mali_drm: Unknown symbol drm_sman_cleanup (err 0)
[  458.086942] mali_drm: Unknown symbol drm_sman_set_range (err 0)
[  458.086975] mali_drm: Unknown symbol drm_sman_takedown (err 0)
[  458.086999] mali_drm: Unknown symbol drm_sman_alloc (err 0)
[  458.087067] mali_drm: Unknown symbol drm_sman_init (err 0)
[  458.087110] mali_drm: Unknown symbol drm_sman_owner_clean (err 0)
[  458.087140] mali_drm: Unknown symbol drm_sman_owner_cleanup (err 0)
[  458.087164] mali_drm: Unknown symbol drm_sman_set_manager (err 0)
[  458.087187] mali_drm: Unknown symbol drm_sman_free_key (err 0)

Where are those symbols supposed to come from?

Sorry, I messed up the things. Before trying to compile the modified module I tried other approaches and added some code for sman missing symbols to the drm module, but the unmodified module could not be compiled because of drm_init and exit functions, this was before I tried to compile the modified version. In such way, I forgot that I added those missing symbols before from:

https://github.com/loboris/OrangePI-Kern...drm_sman.c

They already implemented those functions over drm_mm. Such functions are very simple, each correspond to a drm_mm allocation/cleanup/free function while also carrying on the ownership in the struct. This is already implemented in drm_sman.c, and seems to be compatible with linux 3.x . I added this code directly to the to the drm module, however it can also be added only to the mali_drm.

The main thing I'm not sure about is the struct size compatibility between the provided headers for drm, and those present in your source tree. This weekend I will check this and also try to compile it. I'm not 100% confident, but I think that with such workarounds we can have a functional mali_drm.

[rdPine64]

I have binaries for Ubuntu of xf86-video-fbturbo in a PPA at https://launchpad.net/~longsleep/+archiv...our-makers - the ppa is added by default with my Xenial image.

How do we get this going as a video accelerator? I see the driver files on the system however I don't know what to edit to have the fbturbo as the video accellerator... Thanks

[lenny.raposo-pine64.pro]

OK we are getting the Mali binaries that utilize DMA Buffers instead of UMP DRM. There has been some headway on other boards utilizing this method.

http://forum.odroid.com/viewtopic.php?f=8&t=3706

---

also got the bug tracker up and running for Android/Remix/Linux which will post back to the forums here

http://www.pine64.pro/bug-reports-3-10-65-bsp/

http://www.pine64.pro/bug-reports-lollipop/

http://www.pine64.pro/bug-reports-remix-os-2-0/

[sirhcjw]

So over on the kodi forum I just got a reply from one of the devs stating

We don't ship code that would be able to do VDPAU on your hardware. Only a special patched version without any mainline support was done by a dev "somewhere on the internet". mplayer does not use OpenGL. To use VDPAU on kodi glinterop extension is mandatory, which your mesa / glx drivers don't have.

Does anyone think this this extension will be available on the pine64 hardware with the Mali driver / kernel module?

Or should I plan to use my pine for something else and get a different board for Kodi?