screen rotation performance problem
Peter Zumtobel
peter.zumtobel at sigmatek.at
Mon May 7 09:25:04 UTC 2018
Hi Lucas,
On 2018-05-03 13:55, Lucas Stach wrote:
> 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
>
Sorry for the late response and thanks for the explanation.
On first sight, I could not encounter the part were the rotation is
exactly done. Are there architectural documents for the armada driver
(or the etnaviv driver stack in general)?
I'm not sure, but the mailing list for the armada driver would be
linux-arm at lists.infradead.org, right?
Best regards
--
Peter Zumtobel
Operating system development
________________________________
SIGMATEK GmbH & Co KG
Sigmatekstraße 1
5112 Lamprechtshausen
Österreich / Austria
Tel.: +43/6274/4321-0
Fax: +43/6274/4321-300
E-Mail: peter.zumtobel at sigmatek.at
PGP-ID: 0x92758A23
http://www.sigmatek-automation.at
****************************Please note: ****************************
This email and all attachments are confidential and intended solely
for the person or entity to whom it is addressed. If you are not the
named addressee you must not make this email and all attachments
accessible to any other person. If you have received this email in
error please delete it together with all attachments.
*********************************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/etnaviv/attachments/20180507/84f524ac/attachment.sig>
More information about the etnaviv
mailing list