screen rotation performance problem

[Lucas Stach]

Hi Peter,

Am Mittwoch, den 02.05.2018, 15:54 +0200 schrieb Peter Zumtobel:
> Hi,
> 
> we have a performance problem regarding etnaviv on a 90 degree
> rotated
> screen. Maybe somebody with deeper knowledge of the etnaviv graphics
> stack could help me or explain to me the current state of development
> and/or what needs to be done for rotation to work with better
> performance.
> 
> The soc we're using is an i.mx6dl running Debian Stretch (armhf)
> The versions of the etnaviv parts are:
> Kernel 4.9.68-rt60
> libdrm and Mesa are from Buster:
> 
> :~# dpkg -l 'libdrm*' '*mesa*'
> Desired=Unknown/Install/Remove/Purge/Hold
> > 
> 
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-
> aWait/Trig-pend
> > / Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> > > / Name                         Version             Architecture
> 
> +++-============================-===================-
> ===================
> ii  libdrm-amdgpu1:armhf         2.4.91-2            armhf
> ii  libdrm-armada2:armhf         2.0.3-1             armhf
> ii  libdrm-common                2.4.91-2            all
> ii  libdrm-etnaviv1:armhf        2.4.91-2            armhf
> ii  libdrm-freedreno1:armhf      2.4.91-2            armhf
> ii  libdrm-nouveau2:armhf        2.4.91-2            armhf
> ii  libdrm-radeon1:armhf         2.4.91-2            armhf
> ii  libdrm2:armhf                2.4.91-2            armhf
> ii  libegl-mesa0:armhf           17.3.8-1            armhf
> ii  libegl1-mesa:armhf           17.3.8-1            armhf
> ii  libgl1-mesa-dri:armhf        17.3.8-1            armhf
> ii  libgl1-mesa-glx:armhf        17.3.8-1            armhf
> un  libgl1-mesa-swx11            <none>              <none>
> ii  libglapi-mesa:armhf          17.3.8-1            armhf
> ii  libglu1-mesa:armhf           9.0.0-2.1           armhf
> ii  libglx-mesa0:armhf           17.3.8-1            armhf
> ii  libwayland-egl1-mesa:armhf   17.3.8-1            armhf
> ii  mesa-utils                   8.4.0-1             armhf
> un  mesag3                       <none>              <none>
> un  xlibmesa3                    <none>              <none>
> 
> xf86-video-armada is from
> http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/
> where the HEAD is on unstable-devel commit
> 04748ff4fb30370086cc97b9487a32951c5600ba
> 
> The screen is rotated by xrandr -o right in the openbox autostart.
> Also kernel cmdline passes cma=256M to the contiguous memory
> allocator,
> although I did not observe any problems without it.
> 
> Our customer is using a java application and chromium, which both
> show
> performance problems during scrolling.
> 
> A test with glxgears shows following results:
> 
> # vblank_mode=0 glxgears -fullscreen
> ATTENTION: default value of option vblank_mode overridden by
> environment.
> 485 frames in 5.0 seconds = 96.982 FPS
> 491 frames in 5.0 seconds = 98.082 FPS
> 499 frames in 5.0 seconds = 99.730 FPS
> 493 frames in 5.0 seconds = 98.446 FPS
> 496 frames in 5.0 seconds = 99.048 FPS
> 
> :~# xrandr --output LVDS1 --rotate normal
> :~# glxgears -fullscreen
> Running synchronized to the vertical refresh.  The framerate should
> be
> approximately the same as the monitor refresh rate.
> 260 frames in 5.0 seconds = 51.802 FPS
> 266 frames in 5.0 seconds = 53.154 FPS
> 264 frames in 5.0 seconds = 52.736 FPS
> 265 frames in 5.0 seconds = 52.903 FPS
> 265 frames in 5.0 seconds = 52.909 FPS
> 
> :~# xrandr --output LVDS1 --rotate right
> :~# glxgears -fullscreen
> Running synchronized to the vertical refresh.  The framerate should
> be
> approximately the same as the monitor refresh rate.
> 28 frames in 5.1 seconds =  5.538 FPS
> 27 frames in 5.0 seconds =  5.392 FPS
> 27 frames in 5.0 seconds =  5.379 FPS
> 27 frames in 5.0 seconds =  5.381 FPS
> 
> Hopefully someone has some ideas or insights and can elaborate about
> it.
> Or if its the wrong mailinglist, can direct me to the correct one.

The armada driver currently doesn't implement rotated blits. So any
screen rotation means things are rendered accelerated into a shadow
buffer, but the final rotation to the real screen buffer is done using
a software blit from pixman. You should be able to observe a really
high CPU usage when the rotation is enabled.

Regards,
Lucas