[REFERENCE] Mali r4p0 for Image builders

[memeka]

what was the issue?

[OverSun]

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]

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,
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]

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

[mdrjr]

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

[Vanfanel]

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?

[mdrjr]

Its not implemented. Refer to my post above.

[Vanfanel]

@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]

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]

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]

probably need the same thing for hybris

[Vanfanel]

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]

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]

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.

[mdrjr]

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]

@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.

[mdrjr]

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

[AreaScout]

Like it !

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

[marlemion]

Where can I get it?

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

[Vanfanel]

@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]

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]

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]

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?

[mdrjr]

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]

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

[kiwi_jonathan]

Any plans to update to r4p1?

[mdrjr]

Any plans to update to r4p1?

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

[ScottE]

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]

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.

[mdrjr]

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

[meveric]

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

[mdrjr]

Not ATM...

[Legath]

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

[mdrjr]

No. It can't be done.

[meveric]

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

[marlemion]

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]

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]

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

[egan-ru]

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?