Reduced graphic performance with rotated screen (imx6, sabresd)

[jonashöppner]

Hello everybody,

we saw a massivly reduced graphic performance on our boards as well as on the sabresd with imx6q when the screen was rotated in X.

To reproduce this behaviour one could use either the hellogl_es2 tool or x11perf. The rotatation was done with xrandr -o "inverted" or xrandr -o "normal".

Test images on the sabre board have been

fsl-image-qt5-x11-imx6qdlsolo.sdcard from the L3.10.53_1.1.0_ga_images_MX6 release and

fsl-image-x11-imx6qdlsolo.sdcard from the  L3.10.17_1.0.2_141020_images_MX6 release.

For hellogl_es2 the frame rate reduce from about 100 FPS to 16 FPS.

In top you can see the process  Xorg has about 95% cpu usage in the rotated case, while using about 10% in normal mode.

With the x11perf tool I got following results:

xrandr -o "normal"

x11perf -scroll500 -copypixwin500 -comppixwin500 -compwinwin500 -repeat 1

  20000 reps @   0.4391 msec (  2280.0/sec): Scroll 500x500 pixels

  12000 reps @   0.5007 msec (  2000.0/sec): Copy 500x500 from pixmap to window

  12000 reps @   0.5003 msec (  2000.0/sec): Composite 500x500 from window to window

  12000 reps @   0.5007 msec (  2000.0/sec): Composite 500x500 from pixmap to window

xrandr -o "inverted"

x11perf -scroll500 -copypixwin500 -comppixwin500 -compwinwin500 -repeat 1

   5000 reps @   1.2182 msec (   821.0/sec): Scroll 500x500 pixels

   3600 reps @   1.4377 msec (   696.0/sec): Copy 500x500 from pixmap to window

   3600 reps @   1.4278 msec (   700.0/sec): Composite 500x500 from window to window

   3600 reps @   1.4383 msec (   695.0/sec): Composite 500x500 from pixmap to window

It seems that the rotation is done completly in software by the Xserver.

Has anybody noticed the same or is there even a solution to this?

Regards, Jonas

[jonashöppner · Accepted solution]

Hello Everybody,

I repeated the test with the new release L3.14.52_1.1.0-ga, ( X11 qt5). The rotation performance bug seems to be fixed now.

There is still a gap when rotated but much less then in prior versions.

Regards, Jonas

root@imx6qdlsolo:~# uname -a

Linux imx6qdlsolo 3.14.52-1.1.0_ga+g5f6f0a5 #1 SMP PREEMPT Fri Dec 4 21:37:19 CST 2015 armv7l GNU/Linux

root@imx6qdlsolo:~# export DISPLAY=:0.0

root@imx6qdlsolo:~# xrandr -o "normal"

root@imx6qdlsolo:~# x11perf -scroll500 -copypixwin500 -comppixwin500 -compwinwin 500 -repeat 1

x11perf - X11 performance program, version 1.2

The X.Org Foundation server version 11702000 on :0.0

from imx6qdlsolo

Fri Dec  4 15:03:07 2015

Sync time adjustment is 0.1093 msecs.

  20000 reps @   0.4392 msec (  2280.0/sec): Scroll 500x500 pixels

  12000 reps @   0.5008 msec (  2000.0/sec): Copy 500x500 from pixmap to window

  12000 reps @   0.5004 msec (  2000.0/sec): Composite 500x500 from window to window

  12000 reps @   0.5008 msec (  2000.0/sec): Composite 500x500 from pixmap to window

root@imx6qdlsolo:~# glxgears

902 frames in 5.0 seconds = 180.396 FPS

root@imx6qdlsolo:~# xrandr -o "inverted"

root@imx6qdlsolo:~# x11perf -scroll500 -copypixwin500 -comppixwin500 -compwinwin 500 -repeat 1

x11perf - X11 performance program, version 1.2

The X.Org Foundation server version 11702000 on :0.0

from imx6qdlsolo

Fri Dec  4 15:04:50 2015

Sync time adjustment is 0.1097 msecs.

   9000 reps @   0.5955 msec (  1680.0/sec): Scroll 500x500 pixels

   8000 reps @   0.7351 msec (  1360.0/sec): Copy 500x500 from pixmap to window

   8000 reps @   0.7566 msec (  1320.0/sec): Composite 500x500 from window to window

   8000 reps @   0.7556 msec (  1320.0/sec): Composite 500x500 from pixmap to window

root@imx6qdlsolo:~# glxgears

910 frames in 5.0 seconds = 181.993 FPS

[florianvoit]

Hi Jonas,

can you also confirm that rotating fullscreen applications is fixed now? (see Marc-Oliver Westerburg: https://community.freescale.com/message/632706#comment-507726 )

Regards,

Florian

[MOW]

Hi Florian

We're currently in the process of upgrading our BSPs for our systems to include NXPs recent changes -- first release will only upgrade Yocto itself including X-Servers, GPU-drivers, etc but still leave the kernel at 3.10.17, our second or third upcoming release will upgrade the kernel, as well. As far as we can see right now, the problem with rotated fullscreen OpenGL-applications still seems to persist with an updated BSP (but still old kernel). Whether this will be gone once we update the kernel, as well, we don't know, yet.

We haven't checked with NXPs demo-images on the Sabre-boards, though.

Regards,

Marc

[florianvoit]

Hi Marc-Oliver,

i was able to test the 4.1.15 release today and unfortunately saw the same issues with fullscreen applications (glxgears -fullscreen) and xrandr rotation. The screen remained black.

When started without fullscreen i got a reduced framerate 47.572 FPS (rotated) vs 145.660 FPS (without rotation).

Regards,

Florian

[MOW]

Hi Florian

Thanks for the information. Bad news, though. We had hoped for some improvements in newer BSPs/kernels. Jonas has "sort-of" found the missing GL-screen a few days ago, though: Fullscreen GL-applications seem to render the (unrotated) frame to a buffer at the very start of the memory area reserved for framebuffers (at least on our devices). This gives the impression that in case of fullscreen GL-applications with display rotations the GPU is still rendering properly, but the task responsible for the actual rotation is either not working at all or doesn't get informed that there are new frames to be displayed.

We still have no idea how to get the rotation-task working, though.

Our best theory, so far: The rotation is probably implemented in our controled by the X-Server. Fullscren GL-applications might be using some kind of DRI short-cut-path for improved rendering speed compared to windowed-mode and therefore entirely bypassing the X-Server and the rotation.

This is just a theory, though, because way back in the past -- talking about OpenGL-/Linux-x86-dinosaurs, here -- there used to be several short-cut paths for OpenGL drivers to e.g. bypass the X-/GLX-Protocol when rendering locally on a machine (instead of via network somewhere remote) or really bypass X altogether for local fullscreen rendering.

No idea if there is any way to force rendering via the full X-/GLX-stack in all cases or if such short-cut pathes might be implemented somewhere in the open-source parts of the drivers.

Regards,

Marc

[andre_silva]

I will check that and let you know

[andre_silva]

Hello,

this issue was already fixed in 3.14.28 BSP. Please consider upgrading to the newest release.

regards,

Andre

[jonashöppner]

Hello Andre,

Thanks for your reply. I have repeated the test with 3.14.28-1.0.0. I'm seeing the same ratio of performance between 'normal' and 'inverted'. I which version can I find the fix, the normal images I'm using don't seem to contain them as one can see in the results below.

Regards, Jonas

root@imx6qdlsolo:~# uname -a
Linux imx6qdlsolo 3.14.28-1.0.0_ga+g91cf351 #1 SMP PREEMPT Fri Mar 20 21:49:03 CST 2015 armv7l GNU/Linux
root@imx6qdlsolo:~ export DISPLAY=:0.0
root@imx6qdlsolo:~# xrandr -o "normal"
root@imx6qdlsolo:~# x11perf -scroll500 -copypixwin500 -comppixwin500 -compwinwin500 -repeat 1
x11perf - X11 performance program, version 1.2
The X.Org Foundation server version 11601000 on :0.0
from imx6qdlsolo
Fri Mar 20 15:58:40 2015

Sync time adjustment is 0.1141 msecs.

  20000 reps @  0.4391 msec (  2280.0/sec): Scroll 500x500 pixels

  12000 reps @  0.5008 msec (  2000.0/sec): Copy 500x500 from pixmap to window

  12000 reps @  0.5003 msec (  2000.0/sec): Composite 500x500 from window to window

  12000 reps @  0.5008 msec (  2000.0/sec): Composite 500x500 from pixmap to window

root@imx6qdlsolo:~# xrandr -o "inverted"
root@imx6qdlsolo:~# x11perf -scroll500 -copypixwin500 -comppixwin500 -compwinwin500 -repeat 1
x11perf - X11 performance program, version 1.2
The X.Org Foundation server version 11601000 on :0.0
from imx6qdlsolo
Fri Mar 20 15:59:55 2015

Sync time adjustment is 0.1160 msecs.

  5000 reps @  1.2183 msec (  821.0/sec): Scroll 500x500 pixels

  3600 reps @  1.4382 msec (  695.0/sec): Copy 500x500 from pixmap to window

  3600 reps @  1.4385 msec (  695.0/sec): Composite 500x500 from window to window

  3600 reps @  1.4396 msec (  695.0/sec): Composite 500x500 from pixmap to window

root@imx6qdlsolo:~# glxgears
73 frames in 5.0 seconds = 14.491 FPS
root@imx6qdlsolo:~# xrandr -o "normal"
root@imx6qdlsolo:~# glxgears
1468 frames in 5.0 seconds = 293.424 FPS

[andre_silva]

Hi Jonas,

I just got the information that it will be available in 3.14.52 consolidate GA release in december.

regards,

Andre

[jmp]

Could you point us to where the patch/commit was made or at least which library it was made in?

It seem like the default response from NXP in the forums seems to be "just upgrade to the latest BSP", particularly for the VPU and GPU issues that I've been trying to sort out. For those of us with systems in the field, just doing a BSP upgrade isn't really an option. It would be extremely helpful if you guys could help narrow the scope.

[Bio_TICFSL]

Hi Jonas,

This is currently a bug, current xrand rotation is not accelerated by GPU. Hope to have the fix soon in the next BSP/driver release, we apologize for the inconvenience.

Regards

[jeancôté]

Hi,

Have same problem. xrandr -o "left"  is 3x slower than native orientation for my Qt5/Ogre3D application.

Using Nigrogen6x_MAX board.

Is there a fix available soon?

I'm using freescale/fido, should I use freescale/master or freescale/master-next?

Regards,

Jean

[MOW]

Hi

I just noticed, that OpenGL-ES applications running in fullscreen mode do not work at all when the display is rotated, e.g. glxgears:

Rotation off (application shows expected graphics on the display):

# glxgears

588 frames in 5.0 seconds = 117.532 FPS

568 frames in 5.0 seconds = 113.561 FPS

# glxgears -fullscreen

679 frames in 5.0 seconds = 135.622 FPS

647 frames in 5.0 seconds = 129.357 FPS

Display rotation of 180° (application only works in non-fullscreen-mode. With -fullscreen flag specified, display remains completely black):

# glxgears

89 frames in 5.0 seconds = 17.711 FPS

89 frames in 5.1 seconds = 17.603 FPS

# glxgears -fullscreen

1287 frames in 5.0 seconds = 257.311 FPS

1285 frames in 5.0 seconds = 256.966 FPS

Is this caused by the same xrand rotation-bug you mentioned or is this another, different bug? Similar behavior can be seen not only with glxgears, but also with glmark2-es2 (called with "--fullscreen"-flag) and Chromium v40, v41, and v42 (called with "-kiosk"-flag): With these flags specified, nothing is shown on the display when rotation is configured, without these flags the application show properly but terribly slow.

Regards,

Marc

[jonashöppner]

Hi,

Thanks for the reply. Is there a time schedule when those fixes are expected to be released ?

Regards