Experimental ARMSOC black screen fix

Post Reply
crashoverride
Posts: 5276
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 418 times
Contact:

Experimental ARMSOC black screen fix

Post by crashoverride »

For experienced developers, please test the following patches to resolve the kernel panics and black screen issues with the armsoc driver:
https://github.com/OtherCrashOverride/l ... armsoc-fix

Code: Select all

commit 2c2883948f0c010eafaabe1c52dd1f7eb1f6f116
Author: OtherCrashOverride <OtherCrashOverride@github.com>
Date:   Wed Nov 4 10:24:38 2015 +0000

    Do not re-use scatter/gather tables. When a sg_table is iommu mapped, its contents are modified. Currently, if the dma-buf is mapped/ummaped and then mapped again the table is not valid for the second mapping.

commit 42c27724c61e2fcd9b453c15a33613827fc80dad
Author: OtherCrashOverride <OtherCrashOverride@github.com>
Date:   Wed Nov 4 10:04:42 2015 +0000

    Fix incorrect page count calculation.

commit fbc344329a4e5effb0bf2476e90d24eed606f5c7
Author: OtherCrashOverride <OtherCrashOverride@github.com>
Date:   Wed Nov 4 10:01:18 2015 +0000

    drm/exynos: fix plane-framebuffer linkage. See: http://lists.freedesktop.org/archives/dri-devel/2014-September/068299.html

commit ecb0d4ef6e847632c235f58ccb0d5099cb332c59
Author: OtherCrashOverride <OtherCrashOverride@github.com>
Date:   Wed Nov 4 09:50:16 2015 +0000

    WORKAROUND: helper functions return incorrect values.

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

*building new Kernel packages*
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

XeoSal
Posts: 925
Joined: Sun Aug 30, 2015 11:21 pm
languages_spoken: English
ODROIDs: C1, C1+, C2 & XU4
Has thanked: 0
Been thanked: 0
Contact:

Re: Experimental ARMSOC black screen fix

Post by XeoSal »

Nice work man =)

gadgetdoctor
Posts: 20
Joined: Thu Oct 29, 2015 6:16 am
languages_spoken: english, german
Has thanked: 0
Been thanked: 0
Contact:

Re: Experimental ARMSOC black screen fix

Post by gadgetdoctor »

So this god damn random crashes when leaving fullscreen apps are completely fixed :) ??

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

It's just for testing at the moment, not a fix yet.

@crashoverride
I did some testing with the new fix, it's behaving a little strange.
Black-Screen issue is still present, but "different". It's now reversed, and gets triggered if you switch from window mode to full screen mode, rather than the other way around.
Another major difference is that it now seems to recover after a few seconds, means the black screen happens and about 6 seconds later the screen recovers and you can see everything again.

Sadly performance dropped significantly. In the past Window mode was kinda slow, about 50~72 FPS depending on circumstances, driver versions, etc. but fullscreen went up to 120 FPS.
Right now both window mode and full screen mode are at the same speed, sadly it's not even 60 FPS but rather about 53 FPS, just menu of retroarch with nothing running already only reports about 44 FPS.

Interesting is that the crashes seem to be gone, which happen earlier with the drm patch from dsd you found earlier.

Right now I'd still prefer the drm patch from dsd, since it fixes the black screen issue, while still having the 120 FPS speed.

Maybe if we can find out what's causing (and in your current patches fixing) the crashes, a combination of both patches could work to fix the issue once and for all.
I guess having to wait a couple of seconds until screen resets is something everyone can live with if it fixes the current issues. :)

At least we have 4 differnt ways to fix the black screen issue at the moment. Now if only one would work perfectly :D

Edit:
Ok, I've checked your patches and it seems you incoorporated the patch from dsd, so it seems this is working as expected.
Now just to figure out what could cause the new issues, especially the slow down.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

meveric wrote:Black-Screen issue is still present, but "different". It's now reversed, and gets triggered if you switch from window mode to full screen mode, rather than the other way around.
Another major difference is that it now seems to recover after a few seconds, means the black screen happens and about 6 seconds later the screen recovers and you can see everything again.
Make sure you are testing with unmodified HK armsoc driver.
meveric wrote:Sadly performance dropped significantly.
I also observed this. What I believe we are seeing is VSYNC trying to work. The 120fps was an artifact of incorrect operation. We should be seeing 60fps in both window and fullscreen. I will investigate this further when time permits. (starting with disabling vsync in armsoc). Be aware this may require someone looking at the Mali code (that is private) and see if its waiting on vsync notifications (eglSwapInterval).
meveric wrote:Interesting is that the crashes seem to be gone, which happen earlier with the drm patch from dsd you found earlier.
There were two sources of the crash. The first being the NULL pointer dereference the second being an IOMMU fault. The drm patch alone did not resolve the issue for me.
meveric wrote:At least we have 4 differnt ways to fix the black screen issue at the moment.
This is why everyone should test on official Ubuntu 15.xx from HK using the HK default armsoc driver and default xorg.conf. This eliminates the other workarounds that have been tried and allows me to reproduce the issue to troubleshoot it.
meveric wrote:Another major difference is that it now seems to recover after a few seconds, means the black screen happens and about 6 seconds later the screen recovers and you can see everything again.
This means the patch is working. The NULL pointer deref and the IOMMU fault both crash the kernel and are unrecoverable.

-----
My testing was done with "glmark2-es --fullscreen" on hk ubuntu 15.04 with hk armsoc. I started and stopped (sometimes forcefull) repeatedly the program to observe that entering and exiting fullscren did not fault the system.

I have noticed that it seems every time I fix something in kernel code, it seems to expose other issues. This has been part of my private hell arriving at these patches. :lol:
As strange as it sounds, if you are not seeing kernel panics, then this patch works. Its now a matter of correcting all the other components that come together to make the X11 experience.

This should be seen as a start to fixing things.

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

unmodified version from hardkernel (mdrjr) results in a the old bug that had this version all along on the XU3/XU4.
Only the first frame of a fullscreen application is shown, nothing else.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

I know I have seen that bug before, but I dont recall what conditions are relevant to it.

This is the version I am using in addition to the one shipped with Ubuntu 15.04
https://github.com/mdrjr/xf86-video-arm ... /5422_r5p1
branch 5422_r5p1

If you can share the image you are testing with, I will try putting it on a sdcard to troubleshoot it when time permits.

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

yeah, I noticed you use a different branch which already has one of your older patches applied, so you are actually using a the modified version from hardkernel.

but I guess that depends on the point of view.. anyway I tested with the version from hardkernels 5422_r5p1 branch.
I don't see any difference to the version I use, but I found a new constellation of the black screen issue.

If you switch to full screen mode which causes the black screen, but return to window mode before it can recover, the screen will not automatically recover again, but instead stay black until you manually trigger a screen refresh.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

I disabled the vsync mechanism in armsoc. I still get the same sub 60fps values in glmark2-es. This means someone probably needs to look at the Mali X11 driver.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

meveric wrote:If you switch to full screen mode which causes the black screen, but return to window mode before it can recover, the screen will not automatically recover again, but instead stay black until you manually trigger a screen refresh.
As long as its not kernel panic-ing, this patch is doing what is expected of it. There may be other issues in X11, armsoc, and/or mali that will need to be addressed.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

Btw, if someone can tell me how to keep Kodi from shutting off my TV on exit and pissing me off. I will test that too. ;)

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

I figured out how to disable CEC and test kodi. It starts and exits fine. Video plays tear free.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

A reminder to make sure you do not have the following option in your /etc/X11/xorg.conf

Code: Select all

Option          "NoFlip"        "true"

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

it's an CEC setting, just disable CEC, or disable that CEC is suppose to shut off your TV System -> Settings -> System -> Input Devices
Edit:
damn it, too slow :D
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

Tried out moonlight_embedded. It also enters and exits fullscreen without issue. However, due to the decreased framerate, it exhibits graphical issues.

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

The last commit is what reduces the speed, i built a Kernel without it, right now the image is behaving the same as before, black screen when going to full screen, with auto-recovering, while still having 120 FPS speed in fullscreen mode.

Not sure about crashes though.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

The commit "Do not re-use scatter/gather tables." is necessary for proper operation. The armsoc driver dma-buf maps the pixmap GEM buffer objects to have access to them. From debugging output I observed the mappings were incorrect without that patch. The operations performed in the patch should not be time consuming.
meveric wrote:But it seems the crashes are gone as well, while still having 120 FPS speed in fullscreen mode.
While your instinct tells you that faster is better, in this case its not. It supposed to be 60fps. 120fps means that incorrect memory is being addressed. Its a long standing bug that we have all gotten used to.

With VSYNC disabled (and all patches applied), we should be seeing close to the same numbers as we see with the new fbdev driver which is far greater than 120fps. (for fullsceen only)

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

I know that faster not equals better, but it's where the difference in speed comes from, and maybe investigating here might lead to more stable 60 FPS.

I still don't understand why the speed difference is so extreme. Even if it wouldn't be able to "hold" 60 FPS, wouldn't you expect to the framerate somewhat close around 60 FPS?
But retroarch is showing only 44 FPS (without even having a game started), and I bet, if I start a game and probably apply a shader it's gonna drop even more.
That doesn't look like it's an issue with vsync not being able to stay at 60 FPS.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

Some background info:
When the Mali driver gets its eglInit on a display, it should hook its DRM vsync event. Then depending on the value of eglSwapInterval, it should either wait for a number of those events or finish immediately if vsync is off. With X11, this gets more complicated than fbdev. Although Mali may update a buffer at a faster rate than vsync, the X11 driver may choose to only flip pages during vsync. So its possible for glmark2-es to run at 400fps, but armsoc to only display at 60fps.

This further explains why 120fps is wrong: its neither armsoc's rater nor mali's rate. It means there is a rendering error.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

meveric wrote:But retroarch is showing only 44 FPS
When GLES is locked to vsync, a frame rendering must complete faster than 1/60s in order to have a stable fps. The process does not do any work during the wait for vsync, instead, it sleeps. This is why I believe the problem is not actually in the patch or armsoc but in the mali driver. We never had real vsync for mali X11 to be validated against before now. This is similar to how we have vsync issues with fbdev even though its the same DRM device and the same dma-buf/gem objects as X11 uses on exynos.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

While I'm thinking about it: a good test would be to use ARM's official Mali X11 binary driver instead of HK's and see what happens.

Update: i just tried the official ARM mali drivers with glmark-es2 and there is no difference.

User avatar
memeka
Posts: 4420
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 2 times
Been thanked: 60 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by memeka »

that 120 fps is throwing you off. it's not actually 2xvsync, it's that vsync is not working at all. I am getting 129, 130, 133, 134 fps in fullscreen glmark2, so around ~130 not 120.
so, there is no vsync at all. it should not be capped at 60.

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

I did some more testing with all patches.
With interesting results. If i start just retroarch, it's idleing around 44 FPS, but if I start a game, it seems to be full speed at 60 FPS (sometimes I see 30 FPS), so retroarch seems to work fine.
While XBMC/Kodi seems to be slightly to slow. Many other applications report about 1/2 of their previous framerate. But still seem to run "ok".
I saw some performance loss in PPSSPP, where it's actually noticable.
Kodi menu seems to be a little bit sluggish, and i often have to start videos "twice" the first time, there are laggy, then i restart the same movie and they play fine, but if you leave fullscreen video (pressing ESC to go back to menu) the video gets very laggy.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

I wrote a program that creates a full screen X11 window for EGL/GLES.

In the first step of testing, all it does is swap buffers. It does not perform ANY rendering (not even clearing the screen). It simply loops calling eglSwapBuffers().

Code: Select all

FPS=55.390530
FPS=60.733566
FPS=61.324364
FPS=61.239468
FPS=61.306992
FPS=61.254253
FPS=61.126225
FPS=61.112347
FPS=61.199207
FPS=61.170719
The value of eglSwapInterval is completely ignored. So, yes, the mali driver is indeed broken.

[edit]
Clearing the screen with glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT) has the following effect:

Code: Select all

FPS=48.311440
FPS=52.652542
FPS=52.848572
FPS=52.816898
FPS=52.796928
FPS=52.774197
FPS=52.803905
FPS=52.679081
FPS=52.790546
FPS=52.791939
FPS=52.756737
FPS=52.773960
FPS=52.763229
FPS=52.824516
This is conclusive proof that the issue is in libmali.so and not armsoc, the kernel, or the patches.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

I should note that the above test was done with the ARM supplied Mali drivers for r5p0.

(I should also note that my full screen program enters and exits fullscreen without causing kernel panices or other faults.)

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

Not that it's gonna make much of a difference, but on the XU3/XU4 we use r5p1 Kernel drivers, not r5p0.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

User avatar
memeka
Posts: 4420
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 2 times
Been thanked: 60 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by memeka »

the issue here is not vsync. i told you before, there is no vsync. i've observed this a long time ago. don't know why ppl thought there was.
but thats not the cause for black screen. let's fix the impt problems first, then ask for a vsync mali.so

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

memeka wrote: let's fix the impt problems first, then ask for a vsync mali.so
The problem is fixed. I can enter and exit fullscreen X11 windows with EGL/GLES without any kernel panics. Nobody else has reported kernel panics.

The issue is that the patch exposes a defect in mali now that the system is operating correctly (DMA/IOMMU address).

For whats its worth, I don't actually believe that mali rendered at ~120fps. This is just the number reported based on the completion of eglSwapBuffers. From observation of gl-mark, its more likely that every other frame (buffer swap) failed and was skipped. This caused a report of ~120fps, but the actual fps is what we are seeing now.

My theory is that without this patch the process went:
Render -> Swap -> Fail ->Swap

This would report two frames completion for every actual frame rendered.

[edit]
Actually, it would have to be:
Render -> eglSwapBuffers() -> Swap -> Render-> eglSwapBuffers() -> Fail -> Discard

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

memeka wrote:the issue here is not vsync. i told you before, there is no vsync.
A possible explanation is that there is not real vsync, rather a timed delay somewhere instead. The visual evidence of tearing present when buffer flipping is used suggests this is possible.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

@mdrjr, @odroid can you comment on what the intended vsync behavior is in the mali x11 driver?

User avatar
memeka
Posts: 4420
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 2 times
Been thanked: 60 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by memeka »

I am getting ~130fps not 120. And pretty random around 130 too.
And based on the fact that there is visual tearing when moving windows around with a compositor I would say there never was vsync.

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

Re: Experimental ARMSOC black screen fix

Post by mdrjr »

I did a quick look onto Mali Sources to check this..

For what I can see in a quick look.. there's no vsync at all..

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

It looks like Mali X11 is using DRI2SwapBuffers(). This means the behavior is going to depend on more than just libmali.so itself. DRI2 calls are sent "over the wire" and involve the X Server(Xorg) as well as the DDX (armsoc). This explains why different people are seeing different behavior: different Xorg and/or armsoc versions can produce different results.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

This issue sounds relevant to this discussion:
https://community.arm.com/thread/4977

" r4p0 does seem to fix the problem where the old front buffer was written to immediately after SwapBuffers returns"

If this has regressed, it would explain the observations. As posted earlier, just swapping buffers hits close to 60fps. However, when mali actually uses the buffer (glClear), this drops to 52fps (possible cache contention). Additionally, we see tearing which typically (but not always) happens when a buffer is modified during scan out.

I think the main issue to chase down is the tearing. If the tearing is due to buffer use while awaiting swap, the problem is in mali. If the buffer tear is due to the framebuffer scan out being changed before vsync, then the problem is elsewhere (xserver, armsoc, or exynos kernel driver).

@mdrjr can we raise this issue with ARM and have them investigate? The issue is present in their distribution of the mali binary.

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

Re: Experimental ARMSOC black screen fix

Post by mdrjr »

Hello crash!

I already raised this issue to ARM :) They are aware of it.
But they take some serious time to address some issues :(

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

thanks!

In the meantime, I will post some more information.
The following is a theory:

The armsoc driver seems to have something called "early display". Going through the code, it seems this actually means "triple buffer".
You have 3 buffers A, B, C.
Front buffer = A, Backbuffers = B,C
Rendering is done to B, then made the front buffer.
Front buffer = B, Backbuffers = C, A
Rendering is dont to C, then made the front buffer.
Front buffer = C, Backbuffers = A, B

[edit]
a better description of triple buff:
display = A, render = B, unused = A
render = c, async wait for vsync and present B
render = A, async wait for vsync and present C
render = B, async wait for vsync and present A

render = C, async wait for vsync and present B
render = A, async wait for vsync and present C
render = B, async wait for vsync and present A


Based on https://github.com/ssvb/xf86-video-fbtu ... li400-DRI2

Code: Select all

DRI2GetBuffers A
 DRI2GetBuffers B
 DRI2SwapBuffers (buffer A becomes visible)
 DRI2SwapBuffers (buffer B becomes visible)
 DRI2SwapBuffers (buffer A becomes visible)
 DRI2SwapBuffers (buffer B becomes visible)
 ...
This means that the 3rd buffer (C) is not actually used by Mali, instead it only swaps A and B. The effect would be as speculated earlier, one frame is always skipped due to the triple buffer rotation.

I disabled "early display" in the armsoc driver, so that it now only double buffers. However, we get 30fps now instead of 60fps.

It appears something is purposely delaying an extra frame in the mali driver as if swap interval was 2 instead of 1.

[edit]
This theory would also explain the tearing as mali is always off by 1 when there are 3 buffers meaning it is indeed updating a buffer while its being used.

[edit]
early display is enabled/disabled here in armsoc
https://github.com/mmind/xf86-video-arm ... nos.c#L149

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

An accidental, but interesting observation:

Code: Select all

[conditionals] fragment-steps=0:vertex-steps=0: FPS: 30 FrameTime: 33.333 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 30 FrameTime: 33.333 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 30 FrameTime: 33.333 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 30 FrameTime: 33.333 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 47 FrameTime: 21.277 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 54 FrameTime: 18.519 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 54 FrameTime: 18.519 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 52 FrameTime: 19.231 ms
Note the jump in FPS from 30 to 54. During that time, the display went to sleep and there was NO VSYNC to report.

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

well I found something else:

Code: Select all

DISPLAY=:0.0 xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 4096 x 4096
HDMI-1 connected 1920x1080+0+0 160mm x 90mm
   1920x1080     60.00 +  50.00*   30.00    25.00    24.00    29.97    23.98
(running on 50Hz)

Code: Select all

DISPLAY=:0.0 glmark2-es2 --fullscreen
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-T628
    GL_VERSION:    OpenGL ES 3.1
=======================================================
[build] use-vbo=false: FPS: 25 FrameTime: 40.000 ms
[build] use-vbo=true: FPS: 49 FrameTime: 20.408 ms
[texture] texture-filter=nearest: FPS: 48 FrameTime: 20.833 ms
[texture] texture-filter=linear: FPS: 49 FrameTime: 20.408 ms
[texture] texture-filter=mipmap: FPS: 48 FrameTime: 20.833 ms
[shading] shading=gouraud: FPS: 49 FrameTime: 20.408 ms
[shading] shading=blinn-phong-inf: FPS: 48 FrameTime: 20.833 ms
[shading] shading=phong: FPS: 48 FrameTime: 20.833 ms
[shading] shading=cel: FPS: 47 FrameTime: 21.277 ms
[bump] bump-render=high-poly: FPS: 39 FrameTime: 25.641 ms
[bump] bump-render=normals: FPS: 45 FrameTime: 22.222 ms
[bump] bump-render=height: FPS: 48 FrameTime: 20.833 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 48 FrameTime: 20.833 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 25 FrameTime: 40.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 49 FrameTime: 20.408 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 25 FrameTime: 40.000 ms
[desktop] effect=shadow:windows=4: FPS: 25 FrameTime: 40.000 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 24 FrameTime: 41.667 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 25 FrameTime: 40.000 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 25 FrameTime: 40.000 ms
[ideas] speed=duration: FPS: 25 FrameTime: 40.000 ms
[jellyfish] <default>: FPS: 25 FrameTime: 40.000 ms
[terrain] <default>: FPS: 12 FrameTime: 83.333 ms
[shadow] <default>: FPS: 25 FrameTime: 40.000 ms
[refract] <default>: FPS: 24 FrameTime: 41.667 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 49 FrameTime: 20.408 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 48 FrameTime: 20.833 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 49 FrameTime: 20.408 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 49 FrameTime: 20.408 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 47 FrameTime: 21.277 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 49 FrameTime: 20.408 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 47 FrameTime: 21.277 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 39 FrameTime: 25.641 ms
=======================================================
                                  glmark2 Score: 38 
=======================================================
It seem at 50Hz it tries to hold 50 FPS, or drops to 25 FPS straight if it's way too slow.
(this test was also done with early display disabled)

please note, I don't see actual output right now, since I'm not near the ODROID atm.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

That is interesting!

[Edit]
I should also note that I have modified this function
https://github.com/mmind/xf86-video-arm ... ri2.c#L420
to always return FALSE;

Here is mine

Code: Select all

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 4096 x 4096
HDMI-1 connected 1920x1080+0+0 16mm x 9mm
   1920x1080      60.0*+   30.0     24.0     30.0     24.0
   1920x1080i     60.1     60.0
   1280x720       60.0     59.9
   1024x768       60.0
   1440x480i      60.1     60.1
   800x600        60.3
   720x480        60.0     59.9
   640x480        60.0
Note that for my 1920x1080 mode, the vsync is 60.0, however, the next vsync is 30.0 which I am seeing as my FPS. This got me thinking and I noticed that my 1280x720 mode has 60.0 and 59.9 only. So I set my resolution to that and it does indeed try to hold 60fps!

Code: Select all

=======================================================
    glmark2 2014.03
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-T628
    GL_VERSION:    OpenGL ES 3.1
=======================================================
[build] use-vbo=false: FPS: 59 FrameTime: 16.949 ms
[build] use-vbo=true: FPS: 59 FrameTime: 16.949 ms
[texture] texture-filter=nearest: FPS: 60 FrameTime: 16.667 ms
[texture] texture-filter=linear: FPS: 60 FrameTime: 16.667 ms
[texture] texture-filter=mipmap: FPS: 60 FrameTime: 16.667 ms
[shading] shading=gouraud: FPS: 60 FrameTime: 16.667 ms
[shading] shading=blinn-phong-inf: FPS: 60 FrameTime: 16.667 ms
[shading] shading=phong: FPS: 60 FrameTime: 16.667 ms
[shading] shading=cel: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=height: FPS: 60 FrameTime: 16.667 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 60 FrameTime: 16.667 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 59 FrameTime: 16.949 ms
[pulsar] light=false:quads=5:texture=false: FPS: 60 FrameTime: 16.667 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 60 FrameTime: 16.667 ms
[desktop] effect=shadow:windows=4: FPS: 60 FrameTime: 16.667 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 30 FrameTime: 33.333 ms
[ideas] speed=duration: FPS: 60 FrameTime: 16.667 ms
[jellyfish] <default>: FPS: 60 FrameTime: 16.667 ms
[terrain] <default>: FPS: 19 FrameTime: 52.632 ms
[shadow] <default>: FPS: 59 FrameTime: 16.949 ms
[refract] <default>: FPS: 41 FrameTime: 24.390 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 60 FrameTime: 16.667 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 60 FrameTime: 16.667 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms
=======================================================
                                  glmark2 Score: 55
=======================================================

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

I decided to just use the "1080p no edid" option in boot.ini to eliminate any additional modes or refresh rates from being used. However, it STILL only outputs at 30fps.

The "720p no edid" outputs at 59fps.

[edit]
This leads me to a new theory:
Since the main difference between 1080p and 720p is the size. I suspect that as part of the buffer flip, X11 is invalidating the windows contents and causing some kind of software redraw that is not visible. This would take longer at 1080p than at 720p causing the frame time to be longer than 1/60s meaning it blocks until next vsync causing 1/30s effective update.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

I used xtrace on glmark2-es2:

Code: Select all

=======================================================
    glmark2 2014.03
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-T628
    GL_VERSION:    OpenGL ES 3.1
=======================================================
[build] use-vbo=false:000:<:001e:  8: Request(8): MapWindow window=0x02c00002
000:>:001e: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:<:001f: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0020: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0020: Event DRI2-BufferSwapComplete(102) drawable=0x00000002 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=1
000:>:001f:32: Reply to SwapBuffers: swap_hi=0 swap_lo=1
000:>:0020:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:0021: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0022: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0022: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0021:32: Reply to SwapBuffers: swap_hi=0 swap_lo=2
000:>:0022: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=2
000:>:0022:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:0023: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0024: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0024: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0023:32: Reply to SwapBuffers: swap_hi=0 swap_lo=3
000:>:0024: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=3
000:>:0024:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:0025: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0026: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0026: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0025:32: Reply to SwapBuffers: swap_hi=0 swap_lo=4
000:>:0026: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=4
000:>:0026:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:0027: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0028: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0028: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0027:32: Reply to SwapBuffers: swap_hi=0 swap_lo=5
000:>:0028: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=5
000:>:0028:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:0029: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:002a: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:002a: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0029:32: Reply to SwapBuffers: swap_hi=0 swap_lo=6
000:>:002a: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=6
000:>:002a:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:002b: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:002c: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:002c: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:002b:32: Reply to SwapBuffers: swap_hi=0 swap_lo=7
000:>:002c: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=7
000:>:002c:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:002d: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:002e: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:002e: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:002d:32: Reply to SwapBuffers: swap_hi=0 swap_lo=8
000:>:002e: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=8
000:>:002e:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:002f: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0030: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0030: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:002f:32: Reply to SwapBuffers: swap_hi=0 swap_lo=9
000:>:0030: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=9
000:>:0030:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:0031: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0032: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0032: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0031:32: Reply to SwapBuffers: swap_hi=0 swap_lo=10
000:>:0032: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=10
000:>:0032:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:0033: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0034: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0034: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0033:32: Reply to SwapBuffers: swap_hi=0 swap_lo=11
000:>:0034: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=11
000:>:0034:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:0035: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0036: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0036: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0035:32: Reply to SwapBuffers: swap_hi=0 swap_lo=12
000:>:0036: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=12
000:>:0036:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:0037: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0038: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0038: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0037:32: Reply to SwapBuffers: swap_hi=0 swap_lo=13
000:>:0038: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=13
000:>:0038:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:0039: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:003a: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:003a: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0039:32: Reply to SwapBuffers: swap_hi=0 swap_lo=14
000:>:003a: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=14
000:>:003a:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:003b: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:003c: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:003c: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:003b:32: Reply to SwapBuffers: swap_hi=0 swap_lo=15
000:>:003c: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=15
000:>:003c:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:003d: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:003e: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:003e: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:003d:32: Reply to SwapBuffers: swap_hi=0 swap_lo=16
000:>:003e: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=16
000:>:003e:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:003f: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0040: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0040: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:003f:32: Reply to SwapBuffers: swap_hi=0 swap_lo=17
000:>:0040: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=17
000:>:0040:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:0041: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0042: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0042: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0041:32: Reply to SwapBuffers: swap_hi=0 swap_lo=18
000:>:0042: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=18
000:>:0042:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:0043: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0044: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0044: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0043:32: Reply to SwapBuffers: swap_hi=0 swap_lo=19
000:>:0044: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=19
000:>:0044:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:0045: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0046: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0046: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0045:32: Reply to SwapBuffers: swap_hi=0 swap_lo=20
000:>:0046: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=20
000:>:0046:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:0047: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0048: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0048: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0047:32: Reply to SwapBuffers: swap_hi=0 swap_lo=21
000:>:0048: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=21
000:>:0048:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:0049: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:004a: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:004a: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0049:32: Reply to SwapBuffers: swap_hi=0 swap_lo=22
000:>:004a: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=22
000:>:004a:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:004b: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:004c: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:004c: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:004b:32: Reply to SwapBuffers: swap_hi=0 swap_lo=23
000:>:004c: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=23
000:>:004c:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:004d: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:004e: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:004e: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:004d:32: Reply to SwapBuffers: swap_hi=0 swap_lo=24
000:>:004e: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=24
000:>:004e:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:004f: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0050: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0050: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:004f:32: Reply to SwapBuffers: swap_hi=0 swap_lo=25
000:>:0050: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=25
000:>:0050:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000002 pitch=7680 cpp=4 flags=0x00000000};
000:<:0051: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0052: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0052: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0051:32: Reply to SwapBuffers: swap_hi=0 swap_lo=26
000:>:0052: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=26
000:>:0052:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:0053: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0054: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0054: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0053:32: Reply to SwapBuffers: swap_hi=0 swap_lo=27
000:>:0054: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=27
000:>:0054:52: Reply to GetBuffers: width=1920 height=1080 buffers=;
000:<:0055: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0056: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0056: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0055:32: Reply to SwapBuffers: swap_hi=0 swap_lo=28
000:>:0056: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=28
It shows the only traffic going back and forth is the Get/Swap each frame.

[edit]
I compared the xtrace to my program that only flips buffers and it shows the same traffic.

Code: Select all

000:<:0021: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0021: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0020:32: Reply to SwapBuffers: swap_hi=0 swap_lo=2
000:>:0021: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=2
000:>:0021:52: Reply to GetBuffers: width=1920 height=1080 buffers={attachment=BackLeft(0x00000001) name=0x00000003 pitch=7680 cpp=4 flags=0x00000000};
000:<:0022: 32: DRI2-Request(152,8): SwapBuffers drawable=0x02c00002 target_msc_hi=0 target_msc_lo=0 divisor_hi=0 divisor_lo=0 remainder_hi=0 remainder_lo=0
000:<:0023: 16: DRI2-Request(152,5): GetBuffers drawable=0x02c00002 attachments={attachment=BackLeft(0x00000001)};
000:>:0023: Event DRI2-InvalidateBuffers(103) drawable=0x02c00002
000:>:0022:32: Reply to SwapBuffers: swap_hi=0 swap_lo=3
000:>:0023: Event DRI2-BufferSwapComplete(102) drawable=0x00000003 ust_hi=46137346 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=3
If the program just flips buffers (eglSwapBuffers), it gets 60fps. If the program clears the screen and flips the buffers, it gets 30fps. This implies that mali takes longer than 1/60s to clear a 1920x1080 buffer. This means all the fixes for "early display" and 1080p will need to occur inside libmali.so. Until then, a workaround is to use a 720p display to get 60fps.
Last edited by crashoverride on Sat Nov 07, 2015 3:38 am, edited 1 time in total.

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

more testing with glmark2-es2 in fullscreen und desktop mode.
It seems no matter what combination, Desktop mode is always at 55 FPS, but fullscreen differes:

early display enabled.. 720p@60 resolution, it tries to hold 90 FPS.
early display enabled.. 720p@59.94 resolution, it tries to hold 90 FPS.
early display enabled.. 720p@50 resolution, it tries to hold 100 FPS

early display enabled.. 1080@60 resolution, max: 55 FPS
early display enabled.. 1080@50 resolution, max: 57 FPS
early display enabled.. 1080@30 resolution, max: 45 FPS
early display enabled.. 1080@25 resolution, tries to hold 50 FPS
early display enabled.. 1080@24 resolution, tries to hold 48 FPS
early display enabled.. 1080@29.97 resolution, max: 46 FPS
early display enabled.. 1080@24.98 resolution, tries to hold 47/48 FPS

It looks like in 1080p it always tries to hold 2x display rate, but can't give more than 55~57 FPS in 1080p.
Looks similar to the Mali DDX issue, where performance dropps dramatically on scaling.

Some tests in low resolution seem to proof my point:
640x480@60 -> tries to hold 120 FPS
800x600@60 -> tries to hold 120 FPS
1024x768@60 -> it tires hard, to hold 120 FPS, but it's a little to slow.. ranges from 90~120 FPS, with most FPS in between 110~118 -> only one that did not crash after exit

during all these tess I actually had a couple of crashes, so it seem the issue with the crashes instead of the blue screen is still not solved.
In fact it happend more and more often the more I tested it, especially in lower resolutions, they happend nearly all the time. (I had to restart the board nearly 20 times :( )

==============================================

Need a break from all the crashes and reboots... gonna test without early display later..
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

Faulting when changing resolutions is a different issue (and I do have a patch for that). The framebuffer needs to map/unmap GEM objects which it currently does not do.
https://github.com/hardkernel/linux/blo ... s_drm_fb.c

After a resolution change, the system needs to be rebooted currently to avoid a fault.

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

it's not only when changing resolution.. It's more I change resolution.. -> everything is fine -> I start glmark2-es2 -> everything is fine -> I quit glmark2-es2 -> crash
The lower the screen resolution, the more likely it happens.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

What I meant was that after you change resolutions, the IOMMU is in an indeterminate state (even though it shouldn't be). The IOMMU driver is complicated. This is why its not working mainstream. Each device has its own IOMMU and some devices like G2D have 2 IOMMUs.

Mali also has its own MMU. Management of all these gets confused somewhere. Each device needs to be patched to explicitly map/unmap GEM object's dma instead of assuming the dma_addr_t assigned during allocation is valid.

TL;DR = the patch is to the exynos drm fb/plane code to make it map/unmap GEM objects used as framebuffer attachements. Under normal operation, nothing is using a IOMMU except HDMI and so even though the problem is present, nothing causes collisions. When using 3D, mali also uses dma causing all the problems to show up. As I said before, this patch set is the start of making things work. Fixing one issue, exposes other issues.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

Let me rephrase my rephrasing before setting unrealistic expectations. :D

I have a patch not included in this set that applies to exynos fb/planes. In my G2D testing, it proved to be beneficial. I am not making any guarantee of its worth for any other issues. Additional patches may be required.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

If anybody has a copy of the patches in the first post, please let me know. I am specifically looking for:

Code: Select all

commit 2c2883948f0c010eafaabe1c52dd1f7eb1f6f116
Author: OtherCrashOverride <OtherCrashOverride@github.com>
Date:   Wed Nov 4 10:24:38 2015 +0000

    Do not re-use scatter/gather tables. When a sg_table is iommu mapped, its contents are modified. Currently, if the dma-buf is mapped/ummaped and then mapped again the table is not valid for the second mapping.

User avatar
meveric
Posts: 11446
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 63 times
Been thanked: 459 times
Contact:

Re: Experimental ARMSOC black screen fix

Post by meveric »

This one?
04_scatter_gather_fix.diff.zip
(1.19 KiB) Downloaded 9 times
These users thanked the author meveric for the post:
odroid (Mon Feb 01, 2021 9:52 am)
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

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

Re: Experimental ARMSOC black screen fix

Post by crashoverride »

Thanks for taking a look. I was investigating an issue that had the same mmap/unmap problem, but it turned out to be isolated to a specific driver (G2D).

For the benefit of others, in the 5.4.x kernel, when G2D-DRM (not V4L2) is given a user pointer, it trashes the kernel page table when that pointer is unmapped by the task owning the pointer. My work-around is to use GEM buffers which do not appear to have the issue.
These users thanked the author crashoverride for the post:
odroid (Mon Feb 01, 2021 9:52 am)

Post Reply

Return to “Ubuntu”

Who is online

Users browsing this forum: joshua.yang and 4 guests