I'm looking for some guidance on how to make my EGLFS qt application perform as well under the etnaviv driver as it does under the proprietary Vivante driver on an IMX6.
With a simple qt test application that draws only a QLabel widget, the performance under the Etnaviv driver is signficiantly worse than under the Vivnate driver. Render times are approx 5-6 times higher (~9mS up to around 45-55mS) and CPU load 3 times higher (3% up to ~9%). The (software rendered) mouse is also sluggish, with mouse to cursor latency up from around 100mS to 300mS.
There are a number of large software differences between the two system seteps, but before investing a lot of time removing those differences, I'd like to investigate what might be causing this slow-down. Essentially I am comparing:
- A Vivante-based system running on Yocto Krogarth (Qt 5.4 and Kernel 4.1.15) with NXP's proprietary driver. This system is using a EGLFS iMX6 backend.
- A Etnaviv-based system running on Yocto Dunfell (with Qt 5.14.2 and Kernel 5.10.73-RT). This system is using a EGLFS KMS backend (GBMs), pulling in MESA/libdrm etc.
The rendered output is identifical between them, but the Etnaviv performance is poor. 'perf' shows that more than 43% of the applications time is spent on drm_ioctl calls for Etnaviv.
I've already read and tried most of the applicable environment variables on the Qt EGLFS website but none made any meaningful difference. The Mesa and Qt configs both look reasonable (and are the stock config for Yocto Dunfell with Etnaviv).
Any suggestions on things that I could try/check to see what's causing my performance issues? (Kernel config, Mesa config, Qt config, environment variables, DTS etc).
Responding to my own question. The issue was caused by 2 problems: (1) an errata workaround in U-boot that decreased memcpy performance by around 33%; (2) misconfiguration of a clock for LDB that resulted in the frame rate locking to either ~14fps or ~28fps depending on how the pixel clock was setup.
The errata workaround in U-boot is here: https://community.nxp.com/t5/i-MX-Processors/Cortex-A9-ARM-Errata-845369/td-p/399972 This workaround got implicitly enabled for IMX6Q in U-boot versions after 18-Aug-2020 (with SHA1 f27ffe4177a7cc09614e2f87012234c1e260c8f2). Modifying U-boot to forcibly disable this errata workaround fixes the issue. To my knowledge we have never hit the condition described in the errata, however others facing this issue will need to verify that the errata is not impacting them before disabling the workaround.
The LDB clock issue was resolved by setting the clock parent to the video PLL, as also done in arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi