C1 Mali GPU driver with the VSYNC

User avatar
odroid
Site Admin
Posts: 34536
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean, Japanese
ODROIDs: ODROID
Has thanked: 804 times
Been thanked: 696 times
Contact:

C1 Mali GPU driver with the VSYNC

Post by odroid » Wed Jun 17, 2015 6:00 pm

We've implemented the VSYNC function in the C1 Mali user land driver.
The glSwapBuffers API is tightly coupled with the Vsync IRQ of the frame buffer driver now.
Apt-get upgrade will give you the latest driver. x11-mali and fbdev-mali packages are available to try.

We've built the Lakka(RetroArch) emulation system with the new driver.
It looks okay.
s_20150617_115057.jpg
s_20150617_115057.jpg (312.25 KiB) Viewed 45399 times
The FPS is locked at 50FPS because I tried a Europe ROM file. The HDMI output was set to 1080p/50hz for the synchronization.
fps.jpg
fps.jpg (9.69 KiB) Viewed 45399 times

If you know well the OpenGL-ES2 and VSYNC, please try it and get back to us.
Because we have not enough experience of EGL application, we need your help to know whether our developement direction is correct or not.

If this approach is helpful and useful, we will try it on the U3 and XU3 too even we don't know the feasibility at this moment.

User avatar
AreaScout
Posts: 1349
Joined: Sun Jul 07, 2013 3:05 am
languages_spoken: german, english
ODROIDs: X2, U3, XU3, C2, HiFi Shield, XU4, XU4Q,
N1, Go, VU5A, Show2, CloudShell2,
H2, N2, VU7A, VuShell, Go2, C4
Has thanked: 58 times
Been thanked: 193 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by AreaScout » Wed Jun 17, 2015 9:17 pm

Respect !! That's cool

RG

robotza
Posts: 66
Joined: Fri Jan 30, 2015 4:44 am
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 0
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by robotza » Thu Jun 18, 2015 1:59 am

finally !! Thankyou!!

stmicro
Posts: 251
Joined: Tue Apr 28, 2015 4:23 pm
languages_spoken: english, chinese
ODROIDs: Many Odroids and Rpis.
Location: shenzhen china
Has thanked: 0
Been thanked: 1 time
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by stmicro » Thu Jun 18, 2015 6:48 am

Greatest news in this year!
"glmark2-es2 --annotate" shows stable 60fps without tearing now. I love you guys. C1 is getting better and better everyday. :twisted:
XU3 can be an amazing emulating machine when the vsync is available. Please keep it up.

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Fri Jun 19, 2015 6:15 am

so you have access to mali user space drivers source codes??
Can you also make wayland version??

And what about double/triple buffering ?
Last edited by miskol on Fri Jun 19, 2015 7:54 am, edited 1 time in total.

User avatar
rooted
Posts: 7740
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Has thanked: 717 times
Been thanked: 206 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by rooted » Fri Jun 19, 2015 6:40 am

Definitely needed on the XU3

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Fri Jun 19, 2015 7:53 am

stmicro wrote:Greatest news in this year!
"glmark2-es2 --annotate" shows stable 60fps without tearing now. I love you guys. C1 is getting better and better everyday. :twisted:
XU3 can be an amazing emulating machine when the vsync is available. Please keep it up.
How do you configure x.org to work without tearing ?
I get glmark2-es2 in 60fps but I still see tearing when I move glmark window

User avatar
rooted
Posts: 7740
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Has thanked: 717 times
Been thanked: 206 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by rooted » Fri Jun 19, 2015 8:13 am

miskol wrote:
stmicro wrote:Greatest news in this year!
"glmark2-es2 --annotate" shows stable 60fps without tearing now. I love you guys. C1 is getting better and better everyday. :twisted:
XU3 can be an amazing emulating machine when the vsync is available. Please keep it up.
How do you configure x.org to work without tearing ?
I get glmark2-es2 in 60fps but I still see tearing when I move glmark window
All updated and rebooted?

crashoverride
Posts: 5005
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 305 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by crashoverride » Fri Jun 19, 2015 12:04 pm

When X11 is used, the X11 driver (not mali) is responsible for VSYNC when drawing the desktop and windows. Additionally, the last time I looked at the X11 driver it used software (not hardware) blitting. This means that when a window is moved, regardless of whether it has 3D content or not, its contents are copied by the CPU to the new location. Ideally, the X11 driver detects the condition when a window is fullscreen and does buffer flipping rather than buffer copying.

The interaction of GLES with X11 is rather complicated to explain. With the framebuffer driver, 3D graphics are rendered directly to the framebuffer and changes the memory location where it display from at each page flip (double buffering). This means the contents of memory are not copied, instead the memory location being displayed is changed. To achieve tear free rendering, the memory location is only changed during the VSYNC time period when nothing is being sent to the monitor. If the change happens while the framebuffer is being scanned out to the display, you see the change on screen as tearing. When X11 is used, it owns the framebuffer. 3D graphics are rendered to a block of memory that is never scanned out to the display. X11 then copies this memory along with any other window's content being displayed to the framebuffer. If X11 does this while the display is being scanned out or can not complete it before the next VSYNC, you will see tearing. A 3D application running in a X11 window should receive VSYNC notifications to prevent it from updating its contents before the existing content has been fully displayed. However, it can not control when the X11 driver will copy its contents to the framebuffer for display. It should be noted that the situation gets even more complicated when a compositor is used with X11.

TL;DR -
The test for this working is that framebuffer applications (non X11) display tear free when VSYNC is set by eglSwapInterval with an interval of 1 or greater and also they render as fast as possible when the interval is 0. For X11 applications, the test is whether they render no faster than VSYNC also depending on the setting of eglSwapInterval, not whether they are tear free.

If after the above is met, any tearing present is an issue in the X11 driver and/or compositor, not the Mali driver.

User avatar
odroid
Site Admin
Posts: 34536
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean, Japanese
ODROIDs: ODROID
Has thanked: 804 times
Been thanked: 696 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by odroid » Fri Jun 19, 2015 12:25 pm

crashoverride wrote: TL;DR -
The test for this working is that framebuffer applications (non X11) display tear free when VSYNC is set by eglSwapInterval with an interval of 1 or greater and also they render as fast as possible when the interval is 0. For X11 applications, the test is whether they render no faster than VSYNC also depending on the setting of eglSwapInterval, not whether they are tear free.

If after the above is met, any tearing present is an issue in the X11 driver and/or compositor, not the Mali driver.
Thank you for the valuable inputs. In fact, we've waited your idea and knowledge. :)
I have a couple of questions.

<1> Should we disable the VSYNC when the eglSwapInterval is zero?

<2> Can you explain the relation between the value of eglSwapInterval and the number of frame buffers?
Normally we can implement the double buffers or tripple buffers.

crashoverride
Posts: 5005
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 305 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by crashoverride » Fri Jun 19, 2015 3:39 pm

odroid wrote:<1> Should we disable the VSYNC when the eglSwapInterval is zero?
https://www.khronos.org/registry/egl/sd ... rval.xhtml
interval - Specifies the minimum number of video frames that are displayed before a buffer swap will occur.
If interval is set to a value of 0, buffer swaps are not synchronized to a video frame, and the swap happens as soon as the render is complete.
The value determines how many times to wait for vsync before it switches to the next available buffer. If the setting is 0, then it never waits for vsync and immediately swaps to the next buffer. This results in tearing but is commonly used in benchmarking. If the setting is greater than 0, then it counts that many vsync events before swapping to the next available buffer.
odroid wrote:<2> Can you explain the relation between the value of eglSwapInterval and the number of frame buffers?
There is no direct relationship between the interval and the number of buffers. The interval only specifies how many times to wait for vsync to happen before switching to the next buffer. As an example, if the interval is 2 and vsync happens at 60Hz, there will be a delay of 2 vsync events before the next buffer is displayed making the frame rate 30Hz (60 / 2). If the interval is 3, the frame rate will be 20Hz (60 / 3).

The buffers are consumed in order regardless of the interval setting:

With interval of 1 and double buffering : Vsync, Buffer1, Vsync, Buffer2, Vsync, Buffer1 ...
With interval of 2 and double buffering : Vsync, Vysnc, Buffer1, Vsync, Vsync, Buffer2, VSync, Vsync, Buffer1 ...

With interval of 1 and tripple buffering : Vsync, Buffer1, Vsync, Buffer2, Vsync, Buffer3, Vsync, Buffer1 ...
With interval of 2 and tripple buffering : Vsync, Vsync, Buffer1, Vsync, Vsync, Buffer2, Vsync, Vsync, Buffer3, Vsync, Vsync, Buffer1 ...

The interval is just the how many Vsync events to count before displaying the next buffer.

User avatar
odroid
Site Admin
Posts: 34536
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean, Japanese
ODROIDs: ODROID
Has thanked: 804 times
Been thanked: 696 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by odroid » Fri Jun 19, 2015 4:00 pm

Thank you for the detail explanation.
We will check the frame rate with various eglSwapInterval values (0,1 and 2).

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Sat Jun 20, 2015 3:25 am

rooted wrote:
miskol wrote:
stmicro wrote:Greatest news in this year!
"glmark2-es2 --annotate" shows stable 60fps without tearing now. I love you guys. C1 is getting better and better everyday. :twisted:
XU3 can be an amazing emulating machine when the vsync is available. Please keep it up.
How do you configure x.org to work without tearing ?
I get glmark2-es2 in 60fps but I still see tearing when I move glmark window
All updated and rebooted?
yes all updated and rebooted
my xorg.conf

# X.Org X server configuration file for xfree86-video-mali

Section "Device"
Identifier "Mali-Fbdev"
Driver "mali"
Option "fbdev" "/dev/fb0"
Option "DRI2" "true"
Option "DRI2_PAGE_FLIP" "false"
Option "DRI2_WAIT_VSYNC" "false"
Option "UMP_CACHED" "true"
Option "UMP_LOCK" "false"
Option "SWCursor" "true"
Option "HWCursor" "false"

EndSection

Section "ServerFlags"
Option "NoTrapSignals" "true"
Option "DontZap" "false"
Option "BlankTime" "0"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"
EndSection

Section "DRI"
Mode 0666
EndSection

and installed versions
xserver-xorg-video-mali_20150118-fa6394b-3_armhf.deb
mali-x11_20150616-r5p0-0cb5ca4-16_armhf.deb
and this image
http://de.eu.odroid.in/ubuntu_14.04lts/ ... 401.img.xz

Any idea why I see tearing in window movement??

mdrjr
Site Admin
Posts: 11753
Joined: Fri Feb 22, 2013 11:34 pm
languages_spoken: english, portuguese
ODROIDs: -
Location: Brazil
Has thanked: 1 time
Been thanked: 25 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by mdrjr » Sat Jun 20, 2015 4:14 am

When you move the window tearing is another issue that is yet to be addressed.

Pretty much crashoverride explained it above.

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Mon Jun 22, 2015 5:39 am

So I did tests with fb version of drivers with some qt5 quick examples.
And it looks likeeverting is working good with some examples
QT_QPA_EGLFS_FORCE888=1 QT_QPA_EGLFS_FORCEVSYNC=1 QT_QPA_EGLFS_DEBUG=1 QT_QPA_PLATFORM=eglfs ./rssnews

and I get wired tearing in some window quadrants
https://github.com/rzr/qt5-cinematic-experience

It is really interesting that I need to add QT_QPA_EGLFS_FORCEVSYNC=1 so it really wait for FBIO_WAITFORVSYNC
I hope that swap..... in opengl handle this for me
But I miss double/ triple buffering :)

I saw some examples in amlogic page
that we can set up fb with double of screen height
and one draw will end in top part win screen and second part with end in bottom

I build qt5 on device with
./configure -opengl es2 -prefix /usr/local/qt5 -opensource -confirm-license -no-xcb -no-directfb -no-xcb-xlib -no-kms

mdrjr
Site Admin
Posts: 11753
Joined: Fri Feb 22, 2013 11:34 pm
languages_spoken: english, portuguese
ODROIDs: -
Location: Brazil
Has thanked: 1 time
Been thanked: 25 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by mdrjr » Mon Jun 22, 2015 8:00 am

Miskol,

IIRC we are already using double buffering.. (You can run fbset) and check that virtual Y is Y*2

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Mon Jun 22, 2015 8:15 am

mdrjr wrote:Miskol,

IIRC we are already using double buffering.. (You can run fbset) and check that virtual Y is Y*2
odroid@odroid:~$ fbset

mode "1920x1080"
geometry 1920 1080 1920 2160 32
timings 0 0 0 0 0 0 0
rgba 8/16,8/8,8/0,8/24
endmode

so doublebuffering

when I removed QT_QPA_EGLFS_FORCEVSYNC=1 I have 60fps
but more artifacts, wired :(

mdrjr
Site Admin
Posts: 11753
Joined: Fri Feb 22, 2013 11:34 pm
languages_spoken: english, portuguese
ODROIDs: -
Location: Brazil
Has thanked: 1 time
Been thanked: 25 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by mdrjr » Mon Jun 22, 2015 8:54 am

Are you using the new mali binaries?
New Mali binaries will enforce VSYNC whenver eglSwapBuffers() is called.

If eglSwapBuffers isn't called by your application you have to do the ioctl call for VSYNC.

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Mon Jun 22, 2015 9:02 am

mali-fbdev_20150616-r5p0-0cb5ca4-16_armhf.deb

mdrjr
Site Admin
Posts: 11753
Joined: Fri Feb 22, 2013 11:34 pm
languages_spoken: english, portuguese
ODROIDs: -
Location: Brazil
Has thanked: 1 time
Been thanked: 25 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by mdrjr » Mon Jun 22, 2015 9:37 am

miskol wrote:mali-fbdev_20150616-r5p0-0cb5ca4-16_armhf.deb
Yep, that one should be the latest one.

So you are falling in the second this I explained on my previous post.

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Mon Jun 22, 2015 4:21 pm

from qt5 source codes

EGLSurface eglSurface = eglSurfaceForPlatformSurface(surface);
bool ok = eglSwapBuffers(m_eglDisplay, eglSurface);

so it looks like it really call eglSwapBuffers

mdrjr
Site Admin
Posts: 11753
Joined: Fri Feb 22, 2013 11:34 pm
languages_spoken: english, portuguese
ODROIDs: -
Location: Brazil
Has thanked: 1 time
Been thanked: 25 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by mdrjr » Mon Jun 22, 2015 8:50 pm

You need to make sure that this code is being executed and VSYNC will happen on your application.

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Tue Jun 23, 2015 3:17 am

yes, qt call eglSwapBuffers
I did add some debug logs and it really call swapbuffers

I also get this from EGL init

Created context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile 0) with config:
EGL_BUFFER_SIZE: 32
EGL_ALPHA_SIZE: 8
EGL_BLUE_SIZE: 8
EGL_GREEN_SIZE: 8
EGL_RED_SIZE: 8
EGL_DEPTH_SIZE: 24
EGL_STENCIL_SIZE: 8
EGL_CONFIG_CAVEAT: 12344
EGL_CONFIG_ID: 9
EGL_LEVEL: 0
EGL_MAX_PBUFFER_HEIGHT: 4096
EGL_MAX_PBUFFER_PIXELS: 16777216
EGL_MAX_PBUFFER_WIDTH: 4096
EGL_NATIVE_RENDERABLE: 1
EGL_NATIVE_VISUAL_ID: 0
EGL_NATIVE_VISUAL_TYPE: 0
EGL_SAMPLES: 0
EGL_SAMPLE_BUFFERS: 0
EGL_SURFACE_TYPE: 1031
EGL_TRANSPARENT_TYPE: 12344
EGL_TRANSPARENT_BLUE_VALUE: -1
EGL_TRANSPARENT_GREEN_VALUE: -1
EGL_TRANSPARENT_RED_VALUE: -1
EGL_BIND_TO_TEXTURE_RGB: 1
EGL_BIND_TO_TEXTURE_RGBA: 1
EGL_MIN_SWAP_INTERVAL: 0
EGL_MAX_SWAP_INTERVAL: 10


Anybody can confirm same behavrior??
VERTICAL artifacts in some quadrants of screen

User avatar
odroid
Site Admin
Posts: 34536
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean, Japanese
ODROIDs: ODROID
Has thanked: 804 times
Been thanked: 696 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by odroid » Tue Jun 23, 2015 10:19 am

We used the cube application in the ARM's SDK to test the VSYNC on the FBDEV.
Can you try it to check the vertical artifacts issue?

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Thu Jun 25, 2015 4:33 am

odroid wrote:We used the cube application in the ARM's SDK to test the VSYNC on the FBDEV.
Can you try it to check the vertical artifacts issue?
I finally have nice demo for you
so you can see the problem
https://github.com/ssvb/glmark2
./waf configure --with-flavors fb-glesv2
./waf
...

for example rotating cube
I did test mali sdk cube example and I get same problem artefacts
I did tune cube example to 1920x1080 so cube is bigger
so any idea?
I get 60fps but with artefacts

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Mon Jun 29, 2015 1:59 am

btw I don't have any artifacts in android on C1

molesmoke
Posts: 29
Joined: Wed Apr 08, 2015 6:26 pm
languages_spoken: english
ODROIDs: C1, C2, U3, XU4
Location: UK
Has thanked: 0
Been thanked: 0
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by molesmoke » Fri Jul 03, 2015 9:30 pm

I've found that there is still tearing with both the latest mali-fbdev and mali-X11 in glmark2-es. The tearing is easiest to spot with the "desktop" scene:
glmark2-es -b desktop

I just downloaded the latest Ubuntu image for the C1 and updated all the packages, so I've got the latest kernel and Mali binaries. I also get tearing in my own applications.

I note that vsync seems OK on the U3 in X11, but only in fullscreen. Also on Android both the C1 and U3 seem to vsync fine. Just vsync in Linux on the C1 still seems to be broken.

I can try and force vsync by waiting on the ioctl, but I get some artefacts in the bottom left of the screen - I assume this is from some kind of tiled copy.

molesmoke
Posts: 29
Joined: Wed Apr 08, 2015 6:26 pm
languages_spoken: english
ODROIDs: C1, C2, U3, XU4
Location: UK
Has thanked: 0
Been thanked: 0
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by molesmoke » Sat Jul 04, 2015 1:31 am

I just thought that it's actually not that easy to see using glmark2-es that vsync isn't working properly so I've made a minimal test project for fbdev on GitHub:
https://github.com/molesmoke/GlesVSyncTest

Hopefully I've just missed something, happy for someone to correct it if it's wrong!

molesmoke
Posts: 29
Joined: Wed Apr 08, 2015 6:26 pm
languages_spoken: english
ODROIDs: C1, C2, U3, XU4
Location: UK
Has thanked: 0
Been thanked: 0
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by molesmoke » Mon Jul 06, 2015 7:02 pm

I thought of an easier way to show that vsync isn't working quite right. Here's a QML snippet that you can run with qmlscene:

Code: Select all

Rectangle {
    id: root
    width: 1280
    height: 720

    Rectangle {
        id: red
        color: "red"
        width: parent.width
        height: parent.height

        NumberAnimation {
            id: animation
            target: red
            property: "x"
            from: 0
            to: root.width
            duration: 1000
            easing.type: Easing.Linear
            loops: Animation.Infinite

            onToChanged: restart();
        }
    }
}
On the C1 with mali-fbdev using the eglfs platform this tears diagonally from the top left at a shallow angle.
On the C1 with mali-x11 using the xcb platform this tears diagonally from the middle of the screen at a shallow angle.
On the U3 the output is as expected on fullscreen X11 (windowed still tears). I can't find fbdev drivers to test that :(

molesmoke
Posts: 29
Joined: Wed Apr 08, 2015 6:26 pm
languages_spoken: english
ODROIDs: C1, C2, U3, XU4
Location: UK
Has thanked: 0
Been thanked: 0
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by molesmoke » Thu Jul 09, 2015 8:11 pm

Slightly off topic I know, but my XU3 arrived yesterday, just got around to testing that for vsync. In short I found that it tears badly for fbdev and windowed X11, and has a shallow tear from the top left for fullscreen X11 like the C1. Retesting the U3 I noticed that the shallow tear is actually present there too, but it's only just noticeable in the top right of the screen at 1080p. So it seems that all the current ODROID devices are affected to some degree :(

mdrjr
Site Admin
Posts: 11753
Joined: Fri Feb 22, 2013 11:34 pm
languages_spoken: english, portuguese
ODROIDs: -
Location: Brazil
Has thanked: 1 time
Been thanked: 25 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by mdrjr » Thu Jul 09, 2015 11:04 pm

Only C1 has VSYNC enabled.

XU3 is a WIP to deal with that yet.
But right now Mali on XU3 fbdev is very slow. Its an issue with the Mali drivers. ARM is working into fix that issue.

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Thu Jul 09, 2015 11:19 pm

mdrjr wrote:Only C1 has VSYNC enabled.

XU3 is a WIP to deal with that yet.
But right now Mali on XU3 fbdev is very slow. Its an issue with the Mali drivers. ARM is working into fix that issue.
And what about wired artefacts(not v-sync style) that we see ? Are you able to reproduce them on fbdev ?

mdrjr
Site Admin
Posts: 11753
Joined: Fri Feb 22, 2013 11:34 pm
languages_spoken: english, portuguese
ODROIDs: -
Location: Brazil
Has thanked: 1 time
Been thanked: 25 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by mdrjr » Thu Jul 09, 2015 11:26 pm

miskol wrote:
mdrjr wrote:Only C1 has VSYNC enabled.

XU3 is a WIP to deal with that yet.
But right now Mali on XU3 fbdev is very slow. Its an issue with the Mali drivers. ARM is working into fix that issue.
And what about wired artefacts(not v-sync style) that we see ? Are you able to reproduce them on fbdev ?
on C1 that?

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Fri Jul 10, 2015 12:59 am

mdrjr wrote:
miskol wrote:
mdrjr wrote:Only C1 has VSYNC enabled.

XU3 is a WIP to deal with that yet.
But right now Mali on XU3 fbdev is very slow. Its an issue with the Mali drivers. ARM is working into fix that issue.
And what about wired artefacts(not v-sync style) that we see ? Are you able to reproduce them on fbdev ?
on C1 that?
Yes, on c1

mdrjr
Site Admin
Posts: 11753
Joined: Fri Feb 22, 2013 11:34 pm
languages_spoken: english, portuguese
ODROIDs: -
Location: Brazil
Has thanked: 1 time
Been thanked: 25 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by mdrjr » Fri Jul 10, 2015 6:38 am

I'm aware of the tearing on the top side issue.

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Mon Jul 13, 2015 8:56 am

mdrjr wrote:I'm aware of the tearing on the top side issue.
I hope you will fix it
until that
I made libhybris working on odroid C1
http://forum.odroid.com/viewtopic.php?f=116&t=14844
And it looks like opengl is working just fine without any artifacts

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Sun Aug 02, 2015 8:32 pm

Sorry that I mystified you all but libhybris test apps works all fine
But when I test some mali examples or qt examples I get artifacts as we have with fbdev
I added some traces to gralloc(it is setup to tipple buffer) but It never use 3. part of framebuffer when it PAN :(

crashoverride
Posts: 5005
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 305 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by crashoverride » Sat Aug 29, 2015 10:54 pm

I finally got around to testing this properly.

1) Tearing is present at the top.
2) eglSwapInterval is not honored. VSync is always on

<Redacted - test source code was out of sync>
My test revealed that the FBIOPAN_DISPLAY call forces a wait for vsync. I explicitly left this out of my patch. So I will have to review the change that was integrated.
</Redacted>

[Edit]
Re-ran test: FBIOPAN_DISPLAY + FBIO_WAITFORVSYNC alone (no egl/gles) does not produce any tearing. This means the visual artifact is coming from libMali.so.

crashoverride
Posts: 5005
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 305 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by crashoverride » Sat Aug 29, 2015 11:18 pm

Here is the code that tests the FBIOPAN_DISPLAY and FBIO_WAITFORVSYNC calls:

I run it from a SSH terminal to observe the FPS counter. You should see the contents of the framebuffer scroll up and down smoothly.

[Edit] For best results with this test, run the Mali EGL/GLES test below first so the framebuffer is set to a different colors for each buffer

Code: Select all

#include <sys/types.h>
#include <fcntl.h>
#include <linux/fb.h>
#include <sys/mman.h>        /* for mmap */
#include <stdio.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <EGL/egl.h>
#include <unistd.h>
#include <GLES2/gl2.h>
#include <sys/time.h>
#include <cstdlib>

// To compile
//  g++ pan_vsync_test.cpp -o pan_vsync_test


timeval startTime;
timeval endTime;

void ResetTime()
{
	gettimeofday(&startTime, NULL);
	endTime = startTime;
}

float GetTime()
{
    gettimeofday(&endTime, NULL);
    float seconds = (endTime.tv_sec - startTime.tv_sec);
    float milliseconds = (float(endTime.tv_usec - startTime.tv_usec)) / 1000000.0f;

	startTime = endTime;

    return seconds + milliseconds;
}


int main()
{
	int ret = -1;

    int fd_fb0 = open("/dev/fb0", O_RDWR);
    printf("file handle: %x\n", fd_fb0);


    fb_var_screeninfo info;
    ret = ioctl(fd_fb0, FBIOGET_VSCREENINFO, &info);
	if (ret < 0)
	{
		printf("FBIOGET_VSCREENINFO failed.\n");
		exit(1);
	}

	
	int width = info.xres;
    int height = info.yres;
    int bpp = info.bits_per_pixel;
    int dataLen = width * height * (bpp / 8);

    printf("screen info: width=%d, height=%d, bpp=%d\n", width, height, bpp);


	int frames = 0;
    float totalTime = 0;

    ResetTime();


	int step = 1;
	while (1)
	{
		if (info.yoffset >= info.yres)
		{
			step = -1;
		}
		
		if (info.yoffset <= 0)
		{
			step = 1;
		}
		


		info.yoffset += step;


		// Wait for VSYNC		
		for (int j = 0; j < 1; ++j) // Specify number of VSYNC to count here
		{
			int zero = 0;
			ret = ioctl(fd_fb0, FBIO_WAITFORVSYNC, &zero);
			if (ret < 0)
			{
				printf("FBIO_WAITFORVSYNC failed.\n");
				exit(1);
			}
		}
		

		// Pan the display
		ret = ioctl (fd_fb0, FBIOPAN_DISPLAY, &info);
		if (ret < 0)
		{
			printf("FBIOPAN_DISPLAY failed.\n");
			exit(1);
		}

		
		// Calculate FPS
		float deltaTime = GetTime();

        totalTime += deltaTime;
        ++frames;

        if (totalTime >= 1.0f)
        {
                int fps = (int)(frames / totalTime);
                printf("FPS: %i\n", fps);

                frames = 0;
                totalTime = 0;
        }

	}


	close(fd_fb0);


	return 0;
}
[Edit: No idea why my code indentation has been broken when I copy/paste]
Last edited by crashoverride on Sat Aug 29, 2015 11:42 pm, edited 2 times in total.

crashoverride
Posts: 5005
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 305 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by crashoverride » Sat Aug 29, 2015 11:39 pm

Here is the code that test the fbdev Mali EGL/GLES

Code: Select all

#include <sys/types.h>
#include <fcntl.h>
#include <linux/fb.h>
#include <sys/mman.h>        /* for mmap */
#include <stdio.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <EGL/egl.h>
#include <unistd.h>
#include <GLES2/gl2.h>
#include <sys/time.h>
#include <cstdlib>


//  g++ fbdev_egl_test.cpp -lMali -o fbdev_egl_test

/* Need on XU3/XU4 but not C1
typedef struct fbdev_window
{
	unsigned short width;
	unsigned short height;

} fbdev_window;
*/


fbdev_window window;

timeval startTime;
timeval endTime;

void ResetTime()
{
	gettimeofday(&startTime, NULL);
	endTime = startTime;
}

float GetTime()
{
    gettimeofday(&endTime, NULL);
    float seconds = (endTime.tv_sec - startTime.tv_sec);
    float milliseconds = (float(endTime.tv_usec - startTime.tv_usec)) / 1000000.0f;

	startTime = endTime;

    return seconds + milliseconds;
}


int main()
{
	int ret = -1;

    int fd_fb0 = open("/dev/fb0", O_RDWR);
    printf("file handle: %x\n", fd_fb0);


    fb_var_screeninfo info;
    ret = ioctl(fd_fb0, FBIOGET_VSCREENINFO, &info);
	if (ret < 0)
	{
		printf("FBIOGET_VSCREENINFO failed.\n");
		exit(1);
	}

	
	int width = info.xres;
    int height = info.yres;
    int bpp = info.bits_per_pixel;
    int dataLen = width * height * (bpp / 8);

    printf("screen info: width=%d, height=%d, bpp=%d\n", width, height, bpp);



	// Set the EGL window size
	window.width = width;
	window.height = height;


	// Get the EGL display (fb0)
	EGLDisplay display = eglGetDisplay(EGL_DEFAULT_DISPLAY);
	if(display == EGL_NO_DISPLAY)
	{
		printf("eglGetDisplay failed.\n");
		exit(1);
	}


	// Initialize EGL
    EGLBoolean success = eglInitialize(display, NULL, NULL);
    if(success != EGL_TRUE)
    {
        EGLint error = eglGetError();
        printf("eglGetError(): %i (0x%.4x)\n", (int)error, (int)error);
        printf("Failed eglInitialize at %s:%i\n", __FILE__, __LINE__);
        exit(1);
    }


	// Find a config
	int redSize;
	int greenSize;
	int blueSize;
	int alphaSize;
	int depthSize = 24;
	int stencilSize = 8;

	if (bpp < 32)
	{
		redSize = 5;
		greenSize = 6;
		blueSize = 5;
		alphaSize = 0;
	}
	else
	{
		redSize = 8;
		greenSize = 8;
		blueSize = 8;
		alphaSize = 8;
	}


	EGLint configAttributes[] =
    {
		EGL_RED_SIZE,            redSize,
        EGL_GREEN_SIZE,          greenSize,
        EGL_BLUE_SIZE,           blueSize,
        EGL_ALPHA_SIZE,          alphaSize,

        EGL_DEPTH_SIZE,          depthSize,
        EGL_STENCIL_SIZE,        stencilSize,
        
        EGL_SURFACE_TYPE,        EGL_WINDOW_BIT ,

        EGL_NONE
    };


	int num_configs;
	success = eglChooseConfig(display, configAttributes, NULL, 0, &num_configs);
	if(success != EGL_TRUE)
    {
        EGLint error = eglGetError();
        printf("eglGetError(): %i (0x%.4x)\n", (int)error, (int)error);
        printf("Failed eglChooseConfig at %s:%i\n", __FILE__, __LINE__);
        exit(1);
    }


	EGLConfig* configs = new EGLConfig[num_configs];
	success = eglChooseConfig(display, configAttributes, configs, num_configs, &num_configs);
	if(success != EGL_TRUE)
    {
        EGLint error = eglGetError();
        printf("eglGetError(): %i (0x%.4x)\n", (int)error, (int)error);
        printf("Failed eglChooseConfig at %s:%i\n", __FILE__, __LINE__);
        exit(1);
    }


	EGLConfig match = 0;
	
	for (int i = 0; i < num_configs; ++i)
	{
		EGLint configRedSize;
		EGLint configGreenSize;
		EGLint configBlueSize;
		EGLint configAlphaSize;
		EGLint configDepthSize;
		EGLint configStencilSize;

		eglGetConfigAttrib(display, configs[i], EGL_RED_SIZE, &configRedSize);
        eglGetConfigAttrib(display, configs[i], EGL_GREEN_SIZE, &configGreenSize);
        eglGetConfigAttrib(display, configs[i], EGL_BLUE_SIZE, &configBlueSize);
        eglGetConfigAttrib(display, configs[i], EGL_ALPHA_SIZE, &configAlphaSize);
		eglGetConfigAttrib(display, configs[i], EGL_DEPTH_SIZE, &configDepthSize);
		eglGetConfigAttrib(display, configs[i], EGL_STENCIL_SIZE, &configStencilSize);

		if (configRedSize == redSize &&
			configBlueSize == blueSize &&
			configGreenSize == greenSize &&
			configAlphaSize == alphaSize &&
			configDepthSize == depthSize &&
			configStencilSize == stencilSize)
		{
			match = configs[i];
			break;
		}
	}

	delete[] configs;


	if (match == 0)
	{
		printf("No eglConfig match found.\n");
		exit(1);
	}

	printf("EGLConfig match found: (0x%.4x)\n", match);



	EGLint windowAttr[] = { 
		EGL_RENDER_BUFFER, EGL_BACK_BUFFER,
		EGL_NONE };

    EGLSurface surface = eglCreateWindowSurface(display, match, (NativeWindowType)&window, windowAttr);

    if (surface == EGL_NO_SURFACE)
	{
        EGLint error = eglGetError();
        printf("eglGetError(): %i (0x%.4x)\n", (int)error, (int)error);
        printf("Failed eglCreateWindowSurface at %s:%i\n", __FILE__, __LINE__);
        exit(1);
	}


	// Create a context
    eglBindAPI(EGL_OPENGL_ES_API);
	
	EGLint contextAttributes[] = {
		EGL_CONTEXT_CLIENT_VERSION, 2,
		EGL_NONE };

    EGLContext context = eglCreateContext(display, match, EGL_NO_CONTEXT, contextAttributes);
    if(context == EGL_NO_CONTEXT)
    {
        EGLint error = eglGetError();
        printf("eglGetError(): %i (0x%.4x)\n", (int)error, (int)error);
        printf("Failed eglCreateContext at %s:%i\n", __FILE__, __LINE__);
        exit(1);
    }

	success = eglMakeCurrent(display, surface, surface, context);
	if(success != EGL_TRUE)
    {
        EGLint error = eglGetError();
        printf("eglGetError(): %i (0x%.4x)\n", (int)error, (int)error);
        printf("Failed eglMakeCurrent at %s:%i\n", __FILE__, __LINE__);
        exit(1);
    }


	// VSYNC
	success = eglSwapInterval(display, 1);
	if(success != EGL_TRUE)
		{
			EGLint error = eglGetError();
			printf("eglGetError(): %i (0x%.4x)\n", (int)error, (int)error);
			printf("Failed eglSwapInterval at %s:%i\n", __FILE__, __LINE__);
			exit(1);
		}


	// Render
	int frames = 0;
	float totalTime = 0;

	int flag = 0;

	ResetTime();
	

	while(true)
	{
		float red = rand() / (float)RAND_MAX;
		float green = rand() / (float)RAND_MAX;
		float blue = rand() / (float)RAND_MAX;


		glClearColor(red, green, blue, 1);
        glClear(GL_COLOR_BUFFER_BIT |
				 GL_DEPTH_BUFFER_BIT |
				 GL_STENCIL_BUFFER_BIT);




		success = eglSwapBuffers(display, surface);
		if(success != EGL_TRUE)
		{
			EGLint error = eglGetError();
			printf("eglGetError(): %i (0x%.4x)\n", (int)error, (int)error);
			printf("Failed eglSwapBuffers at %s:%i\n", __FILE__, __LINE__);
			exit(1);
		}



		float deltaTime = GetTime();


		totalTime += deltaTime;
		++frames;


		if (totalTime >= 1.0f)
		{
			int fps = (int)(frames / totalTime);
			printf("FPS: %i\n", fps);

			frames = 0;
			totalTime = 0;
		}
	}



	return 0;
}
To disable VSync change the 1 in the following line to 0 in the code above:

Code: Select all

success = eglSwapInterval(display, 1);
You should observer the screen being cleared to random colors. The makes the tearing very evident.

crashoverride
Posts: 5005
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 305 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by crashoverride » Tue Sep 01, 2015 9:32 pm

I conducted some more tests. First to confirm there issue is NOT in FBIOPAN_DISPLAY, I changed the test program to flip entire pages. With each buffer set to a different color, the swap was perfect.

I then performed a strace over the code:

Code: Select all

open("/dev/fb0", O_RDWR)                = 6
gettid()                                = 2658
gettid()                                = 2658
gettid()                                = 2658
ioctl(4, 0xc0188404, 0xbed9d128)        = 0
gettid()                                = 2658
ioctl(4, 0xc030820b, 0xbed9d198)        = 0
ioctl(4, 0xc0208209, 0xbed9d1b0)        = 0
ioctl(6, FBIO_WAITFORVSYNC, 0)          = 0
close(6)                                = 0
This is PROBABLY the culprit. Every frame the /dev/fb0 device is opened and then closed. The mali driver should open "/dev/fb0" during the eglInitialize() call and keep it open until eglTerminate() is called or the program is terminated (the OS will close it at that point).

crashoverride
Posts: 5005
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 305 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by crashoverride » Tue Sep 01, 2015 9:39 pm

Btw, if anyone call tell me what those other ioctl calls are, it would be helpful in understanding whats going on.

crashoverride
Posts: 5005
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 305 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by crashoverride » Tue Sep 01, 2015 10:06 pm

I think I may have decoded them

Code: Select all

ioctl(4, 0xc0188404, 0xbed9d128) = MALI_UK_MAP_MEM
ioctl(4, 0xc030820b, 0xbed9d198) = MALI_UK_SOFT_JOB_START
ioctl(4, 0xc0208209, 0xbed9d1b0) = MALI_UK_TIMELINE_WAIT

crashoverride
Posts: 5005
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 305 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by crashoverride » Tue Sep 01, 2015 10:18 pm

Notably MISSING is any call to FBIOPAN_DISPLAY. Is the driver rendering to the second buffer at all?

The FBIO_PAN should happen immediately after the FBIO_WAITFORVSYNC. The PAN should display the buffer that has just completed rendering.

crashoverride
Posts: 5005
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 305 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by crashoverride » Tue Sep 01, 2015 10:54 pm

After further investigation, it appears FBIOPAN_DISPLAY gets called once at the start of rendering and then never again. This is a more likely cause for the tearing: its effectively operating in single buffer mode.

mdrjr
Site Admin
Posts: 11753
Joined: Fri Feb 22, 2013 11:34 pm
languages_spoken: english, portuguese
ODROIDs: -
Location: Brazil
Has thanked: 1 time
Been thanked: 25 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by mdrjr » Wed Sep 02, 2015 1:28 am

Hello crash,

I saw you sent the same patch for XU3/XU4.. Did you checked is Mali is honoring VSYNC calls? Or should we take a look on that..


On C1,
Should I call PAN after VSYNC ? If so, we can release updated GPU drivers that does such.

crashoverride
Posts: 5005
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 305 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by crashoverride » Wed Sep 02, 2015 3:37 am

mdrjr wrote:Did you checked is Mali is honoring VSYNC calls?
The frame rate is 13fps on XU3/4 fbdev so there is no way for me to know. Even if it was syncing, the display drawing lakes longer than a frame display so there will be tearing.
mdrjr wrote:Should I call PAN after VSYNC ?
The process is:
1) render to the backbuffer (off screen)
2) FBIO_WAITFORVSYNC. (there is now time to switch the buffer being displayed with out it been seen)
3) immediately FBIOPAN_DISPLAY to the backbuffer (this takes place during the vsync so it can not be seen).
4) the backbuffer is now the frontbuffer, start at 1 again.

miskol
Posts: 249
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 1 time
Been thanked: 17 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by miskol » Wed Sep 02, 2015 4:54 am

@mdrjr
And plz test it.
it should not be problem :)

Start with double buffering and then try triplebuffering
https://en.wikipedia.org/wiki/Multiple_buffering

btw I really don't understand why amlogic release drivers that don't work( openlinux.amlogic.com:8000/download/ARM ).
I never saw working amlogic fb drivers

mdrjr
Site Admin
Posts: 11753
Joined: Fri Feb 22, 2013 11:34 pm
languages_spoken: english, portuguese
ODROIDs: -
Location: Brazil
Has thanked: 1 time
Been thanked: 25 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by mdrjr » Wed Sep 02, 2015 5:01 am

miskol wrote:@mdrjr
And plz test it.
it should not be problem :)

Start with double buffering and then try triplebuffering
https://en.wikipedia.org/wiki/Multiple_buffering

btw I really don't understand why amlogic release drivers that don't work( openlinux.amlogic.com:8000/download/ARM ).
I never saw working amlogic fb drivers
Really? You never saw it.. because we have it working on our platform and all you need to do is apt-get install mali-fbdev....

mdrjr
Site Admin
Posts: 11753
Joined: Fri Feb 22, 2013 11:34 pm
languages_spoken: english, portuguese
ODROIDs: -
Location: Brazil
Has thanked: 1 time
Been thanked: 25 times
Contact:

Re: C1 Mali GPU driver with the VSYNC

Post by mdrjr » Wed Sep 02, 2015 5:02 am

crashoverride wrote:
mdrjr wrote:Did you checked is Mali is honoring VSYNC calls?
The frame rate is 13fps on XU3/4 fbdev so there is no way for me to know. Even if it was syncing, the display drawing lakes longer than a frame display so there will be tearing.
mdrjr wrote:Should I call PAN after VSYNC ?
The process is:
1) render to the backbuffer (off screen)
2) FBIO_WAITFORVSYNC. (there is now time to switch the buffer being displayed with out it been seen)
3) immediately FBIOPAN_DISPLAY to the backbuffer (this takes place during the vsync so it can not be seen).
4) the backbuffer is now the frontbuffer, start at 1 again.
On XU3 subject you can test on X11. As for the fbdev drivers, we are working with ARM to address that issue.

for C1.. I'll look onto the Mali drivers and attempt to implement that.

Post Reply

Return to “News”

Who is online

Users browsing this forum: No registered users and 5 guests