am335x + sgx + qt5 eglfs : how to avoid tearing and obtain reasonable fps?

Cody Schafer

I currently have a Qt5 app that runs fine with `./app -platform eglfs` with `WindowSystem=libpvrPVR2D_FRONTWSEGL.so.1` in /etc/powervr.ini _except_ for the tearing to the screen that is visible in horizontal motion.

Switching to `WindowSystem=libpvrPVR2D_FLIPWSEGL.so.1` does eliminate the tearing, but also introduces noticable lag in dragging the horizontal list. It also causes the displayed colors to increase and decrease in intensity fairly quickly which the dragging (and the resulting updating of the screen) is occuring.

I've also noted that running `sgx_flip_test` results in FAIL - PVRSRV_ERROR_TOOMANYBUFFERS (full output here: https://gist.github.com/e8a4902e4ae33ef6ed49 )

Based on this, I've considered that perhaps the sgx or associated drivers doesn't have enough ram, so I've added `cma=64M vram=32M` to the kernel command line. Unfortunately, this doesn't appear to have any affect on the behavior (though the ram amount does look like it shows up in `sgx_flip_test`'s output that lists avaliable memory).

At this point it looks like the problem is (from `sgx_flip_test`'s output) that "MaxSwapChainBuffers:2" needs to be a larger value than '2'.

What things affect the max swap chain buffers?

Is there something else causing awful performance with FLIP?

Or am I way off base here?

Some more info:

root@ikabit:~# fbset -i

mode "480x272"

geometry 480 272 480 816 32

timings 0 0 0 0 0 0 0

accel true

rgba 8/16,8/8,8/0,8/24

endmode

Frame buffer device information:

Name :

Address : 0x98100000

Size : 1566720

Type : PACKED PIXELS

Visual : TRUECOLOR

XPanStep : 1

YPanStep : 1

YWrapStep : 0

LineLength : 1920

Accelerator : No

root@ikabit:~# uname -a

Linux ikabit 3.19.8-yocto-standard #1 PREEMPT Wed Jul 1 12:29:13 EDT 2015 armv7l GNU/Linux

root@ikabit:~# cat /proc/pvr/

nodes queue version

root@ikabit:~# cat /proc/pvr/version

Version SGX_DDK_Linux_CustomerTI sgxddk 1.10@2359475 (release) /home/cody/obj/y/tmp/work/beaglebone-poky-linux-gnueabi/omap3-sgx-modules/5.01.01.02-b/Graphics_SDK_5_01_01_02/GFX_Linux_KM

System Version String: SGX revision = 125

Note: I'm running the version of SGX shipped by the meta-ti layer (libgles-omap3_5.01.01.02.bb and omap3-sgx-modules_5.01.01.02.bb)

over 8 years ago

0 Biser Gatchev-XID over 8 years ago

TI__Guru**** 393215 points

Hi Cody,

This forum supports only the TI distributed Linux SDK, currently v3.14.26. From your log I guess you are using a different Linux version. Can you try the same with the TI SDK?

0 Cody Schafer over 8 years ago in reply to Biser Gatchev-XID

Prodigy 50 points

Our application requires the 3.19.8 or newer kernel, so I'm hesitant to spend time testing a kernel we can't use.

However, I am asking specific questions about the libgles-omap3 binary and it's supporting programs, which are exactly the versions shipped by TI.

If there is some iteraction that these have with the kernel which could affect the answer to those specific questions, description of that interaction would be appreciated (and might help me resolve this issue).

0 Biser Gatchev-XID over 8 years ago in reply to Cody Schafer

TI__Guru**** 393215 points

I have asked the SW experts to help on this.

0 Cody Schafer over 8 years ago

Prodigy 50 points

Hi,

We're still trying to understand what is causing this so we can correct these visual defects that show up when running on the am335x.

Any update on the queries in the first post?

0 Biser Gatchev-XID over 8 years ago in reply to Cody Schafer

TI__Guru**** 393215 points

No feedback yet. I have asked again.

0 Cody Schafer over 8 years ago in reply to Biser Gatchev-XID

Prodigy 50 points

I've noticed that meta-ti has a `linux-ti-staging-4.1` (which would be new enough for our application).

Is it known whether this kernel supports FLIP properly on the am335x?

Also, any update on how MaxSwapChainBuffers can be increased? (ie: what parameters control it) Or other advise on getting FLIP working on the am335x?

0 Cody Schafer over 8 years ago

Prodigy 50 points

Just to give an update:

At the moment I've become more focused on the display distortions that occur when FLIP is enabled instead of the perceived slowness (I think the perception of slowness could just be a result of the display artifacts).

To give a better description of the display artifacts: it appears that every other line of the display is shifted to the left or right when a drag left-or-right occurs. No distortion occurs when the display is not changing. No distortion (other than the expected tearing) occurs when using FRONT.

All of this seems to point to an issue with when the display buffers are swapped. After googling around a bit, this patch https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/sgx/0003-drm-tilcdc-fix-the-ping-pong-dma-tearing-issue-seen-.patch Seems relevent, but we already include it.

Also, I tried building the ti-staging-4.1 kernel, but it appears to be missing a header required for the sgx kernel modules to build.

0 Manisha Agrawal over 8 years ago in reply to Cody Schafer

TI__Mastermind 22386 points

Can you please share sgx_flip_test output? Would like to examine following prints -
Display Class API: Get display info OK
.... Name:PowerVR OMAP Linux Display Driver .... MaxSwapChains:1 .... MaxSwapChainBuffers:3 .... MinSwapInterval:0 .... MaxSwapInterval:1

0 Manisha Agrawal over 8 years ago in reply to Manisha Agrawal

TI__Mastermind 22386 points

The total size of the FBdev frame buffers allocated by the current DRM driver will be slightly smaller than it should be

if the size of each frame buffer is not fully aligned to the page size (4096) because the kernel driver adds the required padding for the entire buffer instead of the individual frame buffer.

To allocate more FLIP buffers, we can simply increase the #define DRM_NUM_FBDEV_BUFFERS at Linux/driver/gpu/drm/drm_fb_cma_helper.c as proof of concept.

#define DRM_NUM_FBDEV_BUFFERS 3 to #define DRM_NUM_FBDEV_BUFFERS 4

With this change, the sgx_flip_test should work and display "MaxSwapChainBuffers:3".

Please try and see whether you still see display problems with MaxSwapChainBuffer=3. If it is still the case, then it could be a performance issue.

If you can share the application binary, we can further look at our end the cause of the issue.

0 Manuel Odendahl32 over 8 years ago in reply to Manisha Agrawal

Intellectual 280 points

We are seeing a similar issue with the FLIP buffers probably overlaying kernel memory. We applied the suggested patch, and it does allocate enough memory for 3 FLIP buffers (and thus sgx_flip_test runs), but we are seeing issues of graphical artefacts and glitches. We have a thread here:

https://e2e.ti.com/support/arm/sitara_arm/f/791/p/446385/1641965#1641965

We are also using am335x and QT5 EGLFS.

Maybe we are looking at something similar?

Processors

Processors forum

am335x + sgx + qt5 eglfs : how to avoid tearing and obtain reasonable fps?