[REFERENCE] Mali r4p0 for Image builders

memeka · Unread post by **memeka** » Wed Aug 20, 2014 6:04 am

what was the issue?

OverSun · Unread post by **OverSun** » Wed Aug 20, 2014 6:11 am

vsync I think. seems that egl is too fast (sometimes it jumps to 120fps), which made frames to change faster than they should sometimes. which makes next frames be delayed probably. and it looks like faltering playback.
vsynced output look very smooth.
but again, all this was my code to access frame buffer directly (similar to amlogic), maybe there is much more polished way in xbmc to use it and I just did unneeded work implementing it.

Vanfanel · Unread post by **Vanfanel** » Thu Aug 21, 2014 11:33 pm

OverSun: how did you get your program to wait for vsync? EGL/GLES2 on fbdev looks good, but has a lot of tearing here, so waiting for vsync is needed.
However, according to this other thread,
http://forum.odroid.com/viewtopic.php?f=9&t=4116
the fbdev implementation on Odroid lacks the FBIO_WAITFORVSYNC ioctl, so how are EGL/GLES2 apps running on fbdev going to be able to wait for vsync?
(And no, it's not a matter of adding multiple buffers...)

OverSun · Unread post by **OverSun** » Thu Aug 21, 2014 11:44 pm

Don't know about lacking, but I've inserted FBIO_WAITFORVSYNC before eglSwapBuffers and it worked out just fine.

Unread post by **mdrjr** » Fri Aug 22, 2014 12:27 am

Here's a blog entry about DRM and vsync
http://dvdhrm.wordpress.com/2012/12/21/ ... tting-api/

Vanfanel · Unread post by **Vanfanel** » Fri Aug 22, 2014 12:45 am

OverSun: a simple test. If I do this on my buffer swapping function:

Code: Select all

static void gfx_ctx_swap_buffers(void *data)
{
  if(ioctl(fb, FBIO_WAITFORVSYNC, 0) < 0){ 
        printf ("waitvsync failed!!\n");    
  }   
  eglSwapBuffers(g_egl_dpy, g_egl_surf);
}

then I get "waitvsync failed!!" printed to console in every frame. So it's not working, at least here. Are you guys sure this IOCTL is implemented in the fbdev? Where? I can't find it. And of course there is still tearing here with the FBIO_WAITFORVSYNC added ioctl as OverSun suggested.
Maybe I'm missing something?

Unread post by **mdrjr** » Fri Aug 22, 2014 12:47 am

Its not implemented. Refer to my post above.

Vanfanel · Unread post by **Vanfanel** » Fri Aug 22, 2014 12:54 am

@mdrjr: If it's not implemented, then some questions arise:
1) How's OverSun supposed to be using it?

2) Could it be implemented?

3) The link you posted talks about DRM framebuffer, not fbdev. And the binary blobs you posted work on fbdev (which in turn is emulated over DRM if I understood well). So, what does it have to do?
Is it somehow possible to use a DRM framebuffer instead of fbdev for GLES2? Is there a simple example for this?

OverSun · Unread post by **OverSun** » Fri Aug 22, 2014 1:05 am

Well maybe I was wrong then and vsync is done by some other code in EGL part, for example by this:

Code: Select all

  // depending how buffers are setup, eglSwapInterval
  // might fail so let caller decide if this is an error.
  enable = true; // Very dirty fix for vsync
  status = eglSwapInterval(display, enable ? 1 : 0);

The thing is that it was not working without that ioctl...

OverSun · Unread post by **OverSun** » Fri Aug 22, 2014 1:53 am

Long story short, I was wrong, you were right. ioctl call does nothing.
Looks like vsync is implemented by XBMC somewhere and you can trigger it by just checking an option in GUI. It was just a coincidence that I checked this option and implemented the call and thought that that was it.
Can't help you much digging how it is done, it's inside XBMC egl code.

memeka · Unread post by **memeka** » Fri Aug 22, 2014 2:01 am

probably need the same thing for hybris

Vanfanel · Unread post by **Vanfanel** » Fri Aug 22, 2014 2:05 am

I configure the eglSwapInterval in my init routines. No need to do that in every frame.
Without FBIO_WAITFORVSYNC ioctl, it's just impossible that you don't see erratic screen refresh *if* you are using EGL/GLES2 on fbdev, OverSun.

EDIT: Ok, you found out. Now I just need to know how XBMC does it, but I highly doubt it's possible. I think you're seeing some "good frames" but erratic refresh is going to appear sooner or later. Perfectly smooth refresh on the fbdev NEEDS this ioct implemented.

OverSun · Unread post by **OverSun** » Fri Aug 22, 2014 2:14 am

It's possible. The picture was definitely much wronger yesterday. I have perfect example with fast moving scenes at the very beginning and they was skewed badly previously, but now I'm testing on them always and they are good.

Vanfanel · Unread post by **Vanfanel** » Fri Aug 22, 2014 2:31 am

Well, if someone can explain how it's possible at all, I'd be thankful. I think that, if fbdev can't wait for vsync AND we're drawing on it, it's not phisically possible to get smooth, tearing-less screen refresh.
For XBMC, I don't think it does anything special.

Unread post by **mdrjr** » Fri Aug 22, 2014 2:33 am

Vanfanel wrote:Well, if someone can explain how it's possible at all, I'd be thankful. I think that, if fbdev can't wait for vsync AND we're drawing on it, it's not phisically possible to get smooth, tearing-less screen refresh.
For XBMC, I don't think it does anything special.

Have you at least tried the link I've told you?

Vanfanel · Unread post by **Vanfanel** » Fri Aug 22, 2014 2:35 am

Vanfanel wrote:@mdrjr: If it's not implemented, then some questions arise:

3) The link you posted talks about DRM framebuffer, not fbdev. And the binary blobs you posted work on fbdev (which in turn is emulated over DRM if I understood well). So, what does it have to do?
Is it somehow possible to use a DRM framebuffer instead of fbdev for GLES2? Is there a simple example for this?

^^^As you can see, I did.

Unread post by **mdrjr** » Fri Aug 22, 2014 12:27 pm

Updated mp400 fbdev binaries.. the kernel patch is not needed anymore.

AreaScout · Unread post by **AreaScout** » Fri Aug 22, 2014 5:23 pm

Like it !

┈┈┈┈┈┈▕▔╲
┈┈┈┈┈┈┈▏▕
┈┈┈┈┈┈┈▏▕▂▂▂
▂▂▂▂▂▂╱┈▕▂▂▂▏
▉▉▉▉▉┈┈┈▕▂▂▂▏
▉▉▉▉▉┈┈┈▕▂▂▂▏
▔▔▔▔▔▔╲▂▕▂▂▂▏

marlemion · Unread post by **marlemion** » Fri Aug 22, 2014 8:35 pm

Where can I get it?

Edit: Ah, shit, don't mind, I just read the first post.

Thanks!

Vanfanel · Unread post by **Vanfanel** » Sat Aug 23, 2014 8:36 pm

@AreaScout: do you get tearing with this on RetroArch? I've fixed the mali_fbdev backend to use the fbdev_window struct in EGL intit so I now have RA working on non-X GLES on the U3, but there's a lot of tearing because the eglSwapBuffers() function doesn't wait for vsync (because of the mentioned fbdev missing iotct). I'm sure you've done the same by now, so, how does it work for you?

AreaScout · Unread post by **AreaScout** » Sun Aug 24, 2014 3:17 am

Hi Vanfanel

Not so good ( finally got it working ), vsync is not working as you already mentioned, a blinking cursor in the back ( shine through effect, same pane/mixer surface as console ) - but he ! i for sure can't do it better and it's a start

we have to wait here

P.S.: I was testing mupen64plus-libretro with glide64 video plugin and it has some very strange effects on the graphic, picture is completely messed up while under X11 it runs like a charm !

RG

youka · Unread post by **youka** » Mon Aug 25, 2014 2:38 am

I wish I had the time to test the U3's fbdev drivers...Only been working with the XU3's for a bit, noticed there's no vsync there either.

As for the blinking cursor...

Code: Select all

echo "0">/sys/class/graphics/fbcon/cursor_blink

Works for me on the XU3, not too sure about the U3 tho

kiwi_jonathan · Unread post by **kiwi_jonathan** » Wed Aug 27, 2014 4:08 am

For reference: where is the git source for the armsoc_drv.so shipped on an -xu3? Is it still dsd's armoc_drv r4p0, or something different?

Unread post by **mdrjr** » Wed Aug 27, 2014 4:45 am

kiwi_jonathan wrote:For reference: where is the git source for the armsoc_drv.so shipped on an -xu3? Is it still dsd's armoc_drv r4p0, or something different?

Read OP...

kiwi_jonathan · Unread post by **kiwi_jonathan** » Wed Aug 27, 2014 5:53 am

By the time I figured out and tried to delete my question, you'd already replied

kiwi_jonathan · Unread post by **kiwi_jonathan** » Wed Nov 05, 2014 4:33 am

Any plans to update to r4p1?

Unread post by **mdrjr** » Wed Nov 05, 2014 4:35 am

kiwi_jonathan wrote:Any plans to update to r4p1?

No, doesn't bring anything useful for us.. Only Android stuff

ScottE · Unread post by **ScottE** » Thu Nov 20, 2014 2:29 am

It looks like there's an r5-series on the ARM site now. I didn't look to see what the changes are, but FYI, for those who want to be on the leading edge.

meveric · Unread post by **meveric** » Thu Nov 20, 2014 5:42 am

they only have the kernel drivers, which won't work without the userspace binary blobs.. but maybe HardKernel can ask for them if it's worth it.

Unread post by **mdrjr** » Thu Nov 20, 2014 5:47 am

r5 is worth and we'll update it...
We'll announce an ETA once we start to work on it.

meveric · Unread post by **meveric** » Thu Nov 20, 2014 6:05 am

can you give some info about what's new and worth having? What new features can we expect, what bugfixes/improvements?

Unread post by **mdrjr** » Thu Nov 20, 2014 6:09 am

Not ATM...

Legath · Unread post by **Legath** » Tue Jan 13, 2015 11:59 pm

Hi mdrjr,
can you help and rebuild FBDEV MP400-4 blobs with musleabi toolchain also?
musl is a perspective C library.

Unread post by **mdrjr** » Wed Jan 14, 2015 12:00 am

No. It can't be done.

meveric · Unread post by **meveric** » Wed Jan 14, 2015 12:12 am

Any signs of r5? Especially on the XU3 and C1 it might be interesting..

marlemion · Unread post by **marlemion** » Mon Feb 02, 2015 2:59 am

He, maybe somebody can give me a hint. I have XBMC very nicely running on my U2 with the r4p0 drivers on X11. However, I wanted to try the framebuffer Mali driver and possibly get rid of X. So far I did this:

Installed the Mali fbdev binary as I did before with the X11 binary (replaced the latter one).
Recompiled XBMC with X11 disabled.

Tried to start XBMC directly from the command line. I get:

ERROR: Unable to create GUI. Exiting.

I have tried it as a user and as root. I straced it and found this:

open("/sys/class/graphics/fb0/device/modalias", O_RDONLY|O_LARGEFILE) = 17
read(17, "platform:exynos-drm\n", 254) = 20
close(17) = 0
open("/sys/class/graphics/fb0/fsl_disp_dev_property", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
futex(0xb2800010, FUTEX_WAKE_PRIVATE, 1) = 0
gettimeofday({1422812789, 106032}, NULL) = 0
write(8, "18:46:29 T:3038761872 ERROR: I"..., 70) = 70
gettimeofday({1422812789, 106680}, NULL) = 0
write(8, "18:46:29 T:3038761872 FATAL: C"..., 85) = 85
write(2, "ERROR: Unable to create GUI. Exi"..., 37) = 37

So, apparently, it is missing some information or what? Do I need to load a module? Kernel is most recent and 'stock' config. Any help is very much appreciated.

Thx in advance!

OverSun · Unread post by **OverSun** » Mon Feb 02, 2015 5:30 am

The xbmc video initialization process probes all drivers one by one and when first driver "agrees" that the system is something it can work with it uses it.
Trying to read /sys/class/graphics/fb0/fsl_disp_dev_property is a part of initialization of EGL fbdev driver for i.MX board. I can tell you there are more drivers failing before and more drivers failing after. There is nothing special in it. XBMC just tells you at the end that no driver that agreed to work on this system was found, therefore EGL cannot be initialized.
There is no default plain fbdev driver in the XBMC right now, except the one in my git that I've created exactly for this.

memeka · Unread post by **memeka** » Mon Feb 02, 2015 7:48 am

so the solution is to use the xbmc fbdev init code from oversun's repo.

egan-ru · Unread post by **egan-ru** » Mon Sep 21, 2015 3:04 pm

I can't find simple example how to correctly run wayland based shells on exynos4412 mali400 drivers.
What i should do?

Where can I read about this?