Etnaviv性能与Vivante的比较

Question

我正在寻找一些关于如何使我的EGLFS应用程序在et导航驱动程序下执行的一些指导，就像它在IMX6上的专有Vivante驱动程序下所做的一样。

对于一个只绘制QLabel小部件的简单qt测试应用程序，Et导航驱动程序的性能比在Vivnate驱动程序下的性能要差得多。渲染次数大约高5-6倍(~9 9mS至45~55 9mS)，CPU负载增加3倍(3%至9%)。(软件渲染)鼠标也是迟缓的，鼠标对光标的延迟从大约100 is上升到300 is。

这两个系统之间有许多巨大的软件差异，但在投入大量时间消除这些差异之前，我想研究一下是什么导致了这种慢下来。我主要是比较：

1. 是一个基于Vivante的系统，运行在Yocto (Qt5.4和Kernel4.1.15)上，并拥有NXP的专有驱动程序。该系统使用的是一个EGLFS iMX6后端.
2. --一个运行在约克托·邓菲尔( Qt 5.14.2和Kernel5.10.73-RT)上的基于Et导航的系统。这个系统使用的是EGLFS KMS后端(GBMs)，拉入MESA/libdrm等

。

呈现的输出在它们之间是可识别的，但是Et导航的性能很差。“‘perf”显示，超过43%的应用程序时间花在了drm_ioctl对Et导航的调用上。

我已经在Qt网站上阅读和试用了大多数适用的环境变量，但是没有一个有意义的区别。Mesa和Qt信任看起来都是合理的(并且是Yocto与Etnaviv的股票配置)。

有什么建议我可以尝试/检查，看看是什么导致了我的性能问题？(内核配置、Mesa配置、Qt配置、环境变量、DTS等)。

Answer 1

回答我自己的问题。这个问题是由两个问题引起的：(1) U引导中的勘误表解决方案使memcpy性能下降了33%左右；(2) LDB时钟配置错误，导致帧速率锁定到~14 for或~28 for，这取决于像素时钟的设置方式。

U-boot中的勘误表解决方案如下：https://community.nxp.com/t5/i-MX-Processors/Cortex-A9-ARM-Errata-845369/td-p/399972这个解决方案在2020年8月18日之后的U版本中隐式地启用了IMX6Q (与SHA1 f27ffe4177a7cc09614e2f87012234c1e260c8f2一起使用)。修改U引导以强制禁用此勘误表解决方案修复了问题。据我所知，我们从来没有达到勘误表中描述的条件，但是其他面临这个问题的人需要在禁用解决方案之前验证勘误表没有影响到他们。

通过将时钟父级设置为视频PLL解决了LDB时钟问题，就像在arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi中所做的那样