HW Acceleration Working

[xalius]

Overscan is something your TV does, but it is not easy to fix I think for the Pine HDMI output since the display driver allows only for the 15 or so HDMI modes of the latest standard which all assume that your display can do 1:1 pixel mapping with no overscan. A lot of older TVs do have overscan enabled by default. It was easy to fix with my new Philips TV (enabling computer mode, or 1:1 as it was called in the menu). But on the 7 year old Panasonic I have in the basement it took me 2 days to figure out the scaling options.... http://www.cnet.com/news/overscan-youre-...n-your-tv/ I have the same problems when I use my Xperia Z3 Tablet with a HDMI adapter...

[ssvb]

Great news!

So forgive my ignorance but what are the practical implications of this driver release? Does this improve video performance across the board, or only in cases where 3D acceleration is needed? I have been playing with mine as a headless server thus far due to the various bugs in HDMI output (overscan, generally slow rendering). Will this fix the overscan?

A short answer. Mali is only useful for 3D graphics. In principle, 2D graphics can be treated as a subset of 3D and some 2D applications may be accelerated too (such as Qt5 applications), but this is rather uncommon in Linux. For example, the popular lightweight LXDE/XFCE/MATE desktops don't use or need any 3D acceleration at all.

HDMI/LCD is handled by the display driver, which is already available as part of the kernel and is open source (though earlier it was missing GPL license notices in the source files, bringing it into a legal gray area). Guess why we can see something on the screen even without the Mali driver? ;-)

Hardware video decoding for H.264 and other media codecs is done by the Cedar VPU accelerator and it is already supported to some extent: http://forum.pine64.org/showthread.php?tid=424

Now a somewhat tricky part is to make all these pieces of hardware play nicely together. This may take a bit of time and efforts.

[lenny.raposo-pine64.pro]

new kernel compiled moving on to xserver portions fingers crossed everyone

[lenny.raposo-pine64.pro]

ok everything built but Mali is not cooperating

mali: Unknown symbol g_fb_addr (err 0)

waiting on feedback from tllim

[Sak3r]

hi, I'm a backer of the 2gb pine and have been following this github request from Recalbox (github.com/recalbox/recalbox-os/issues/674#issuecomment-228308760) as it was my intention to make a console with the pine.
In a nutshell
Creator : For the pine64, i don't manage to get a kernel with a working framebuffer, so, it's in pause for the moment.

Sak3r: Allwinner just released the mali 400 64 driver for pine64!

Creator: The user space driver was already available for the 450 which is known to work on the 400 too.
The missing part is the kernel : http://malideveloper.arm.com/wp-content/...stack1.png
The board manufacturer is supposed to make a kernel available for his board.
This is done for the rpi or the odroids. For the pine64, the official website refers to some community kernels. When you talk to the people of the community who did these kernel, these say that the job is not done from the manufacturer, and that their kernel probably doesn't work for the gpu while this is not the part there have worked on.

Does this mean this driver is next to useless?

[xalius]

ok everything built but Mali is not cooperating

mali: Unknown symbol g_fb_addr (err 0)

waiting on feedback from tllim

I looked at /drivers/video/sunxi/disp2/disp/dev_fb.c:

Code:

static struct __fb_addr_para g_fb_addr;

Is a global static struct and hence the symbol is not known outside that object (Correct me if I'm wrong).

It basically points to where the framebuffer is in RAM after the memory allocation:

Code:

static int Fb_map_video_memory(struct fb_info *info)
{
       info->screen_base = (char __iomem *)disp_malloc(info->fix.smem_len, (u32 *)(&info->fix.smem_start));
       if (info->screen_base)  {
               __inf("Fb_map_video_memory(reserve), pa=0x%p size:0x%x\n",(void*)info->fix.smem_start, (unsigned int)info->fix.smem_len);
               memset((void* __force)info->screen_base,0x0,info->fix.smem_len);

               g_fb_addr.fb_paddr = (uintptr_t)info->fix.smem_start;
               g_fb_addr.fb_size = info->fix.smem_len;

               return 0;
       } else {
               __wrn("disp_malloc fail!\n");
               return -ENOMEM;
       }

       return 0;
}
               g_fb_addr.fb_size = info->fix.smem_len;

               return 0;
       } else {
               __wrn("disp_malloc fail!\n");
               return -ENOMEM;
       }

       return 0;
}

So I guess the mali blob wants to know where the framebuffer is. How the symbol is properly exported I dont know...

[ssvb]

hi, I'm a backer of the 2gb pine and have been following this github request from Recalbox (github.com/recalbox/recalbox-os/issues/674#issuecomment-228308760) as it was my intention to make a console with the pine.
In a nutshell
Creator : For the pine64, i don't manage to get a kernel with a working framebuffer, so, it's in pause for the moment.

This person apparently wants a framebuffer variant of the mali driver (not x11). It's better to ask for some additional details there.

[Xabaras76]

Thanks a lot guys...!!!!!

Let's test them..!!!

[ssvb]

Some quick comments about the Allwinner's Mali package. It seems to be missing the EULA notice, which is normally required to be present:

Code:

1.2 If you choose to redistribute the whole or any part of the
Software pursuant to the licences granted in Clause 1.1(ii), you
agree: (i) not to use ARM's or any of its licensors names, logos or
trademarks to market Applications; (ii) to retain any and all
copyright notices and other notices (whether ARM's or its licensor's)
which are included with the Software; and (iii) include a copy of this
Licence with such redistribution.

This was a part of the EULA text for the r6p0-01rel0 Mali-450 userland blob from: http://malideveloper.arm.com/resources/d...e-drivers/
And I believe that the r6p0 Mali-400 userland blob provided by Allwinner is supposed to have similar licensing requirements.

A few of the kernel source files in this package still have the "all rights reserved" license notice instead of the GPL license. They are "sun50iw1_transform.c" and "transform.h". The "drm_al.c" file has no license notices at all. But I'm happy that at least the HDMI parts are now GPL licensed, so this code can be adapted to the mainline Linux kernel and U-Boot and there are no licensing incompatibilities.

About the blobs themselves. It would be nice if Allwinner could also provide the framebuffer variant of the Mali userland blob in addition to the X11 variant. This is going to be useful for Kodi.

Also lennyraposo and longsleep had some comments regarding compiling the kernel parts of these drivers.

[longsleep]

A few of the kernel source files in this package still have the "all rights reserved" license notice instead of the GPL license. They are "sun50iw1_transform.c" and "transform.h". The "drm_al.c" file has no license notices at all. But I'm happy that at least the HDMI parts are now GPL licensed, so this code can be adapted to the mainline Linux kernel and U-Boot and there are no licensing incompatibilities.

Where do you see the HDMI parts as GPL? It still links to libhdmi.a which is not in the tarball and comes from the disp2 folder of the BSP package as binary.