linux tinydrm vs fbtft 性能对比测试

本文通过多组对照实验，对 Linux fbdev 接口下 tinydrm 与 fbtft 两种驱动框架的性能进行测试，并根据测试结果分析 tinydrm 相较于 fbtft 的性能提升幅度。

免责声明

由于个人时间和测试条件有限，本文仅进行了有限数量的实验，测试结果仅供参考，不建议作为严谨性能评估或工程选型的唯一依据。

测试环境

项目	参数
开发板	Raspberry Pi Model B（树莓派 1B）
CPU	BCM2835（ARM1176，ARMv6），超频至 1 GHz（详细配置见文末 config.txt）
屏幕	ST7735R，128×160，4-wire SPI，12 MHz

CPU 信息

Architecture:           armv6l
  Byte Order:           Little Endian
CPU(s):                 1
  On-line CPU(s) list:  0
Vendor ID:              ARM
  Model name:           ARM1176
    Model:              7
    Thread(s) per core: 1
    Core(s) per socket: 1
    Socket(s):          1
    Stepping:           r0p7
    CPU(s) scaling MHz: 70%
    CPU max MHz:        1000.0000
    CPU min MHz:        700.0000
    BogoMIPS:           697.95
    Flags:              half thumb fastmult vfp edsp java tls

测试程序

测试程序采用 Linux Framebuffer Benchmark（fbmark）

GitHub：

https://github.com/caramelli/fbmark

编译选项：

-g -O2

测试项目包括：

• fb_rectangle
• fb_sierpinski

工具链信息

❯ /opt/cross-pi-gcc/bin/arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=/opt/cross-pi-gcc/bin/arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/opt/cross-pi-gcc/libexec/gcc/arm-linux-gnueabihf/12.2.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../gcc-12.2.0/configure --prefix=/opt/cross-pi-gcc --target=arm-linux-gnueabihf --enable-languages=c,c++,fortran --with-arch=armv6 --with-fpu=vfp --with-float=hard --disable-multilib --includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)

交叉工具链参考以下文章自行构建：

https://solarianprogrammer.com/2018/05/06/building-gcc-cross-compiler-raspberry-pi/

需要说明的是，该文章提供的配置并不适用于 Raspberry Pi 1。我根据树莓派 1 的硬件平台调整了部分 GCC 编译参数及相关配置，目前正在整理完整的构建流程，后续将单独发布。

对于大多数用户而言，并没有必要自行构建交叉工具链，直接使用发行版（如 Debian/Ubuntu）的 apt 工具链，或 Buildroot 提供的工具链即可满足开发需求。

config.txt

start_file=start.elf
fixup_file=fixup.dat
kernel=zImage

#initramfs rootfs.cpio.gz

disable_overscan=1

gpu_mem_256=100
gpu_mem_512=100
gpu_mem_1024=100

enable_uart=1
dtoverlay=i2c1-overlay
arm_freq=1000
core_freq=500
sdram_freq=600
over_voltage=6

---

成绩对比

测试条件一：CPU 调度模式为 powersave

CPU 工作于节能模式，频率固定为 700 MHz。

echo powersave > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo 0 > /sys/class/graphics/fbcon/cursor_blink

其中第二条命令用于关闭控制台光标闪烁，避免对测试结果造成干扰。

测试结果

	fbtft	tinydrm	提升幅度	单位
Rectangle 32x40	8.55	17.54	51.26%	MPixels/second
Sierpinski 1024	529.41	1138.67	53.51%	Frames/second
Sierpinski 2048	295.23	605.58	51.25%	Frames/second
Sierpinski 4096	156.19	314.06	50.27%	Frames/second
Sierpinski 8192	80.00	160.37	50.12%	Frames/second
Sierpinski 16384	42.86	80.83	46.98%	Frames/second
Sierpinski 32768	23.81	41.01	41.95%	Frames/second
Sierpinski 65536	14.28	20.76	31.21%	Frames/second
Sierpinski 131072	9.53	10.42	8.54%	Frames/second
Sierpinski 262144	5.30	5.30	0.00%	Frames/second

结果分析

可以看到，在大部分测试项目中，tinydrm 相较于 fbtft 的性能提升约为 50%，表现较为明显。

随着 fb_sierpinski 参数不断增大，测试程序本身的计算量逐渐增加，两者之间的性能差距也随之缩小。

推测此时系统瓶颈已经由显示驱动转移至 CPU 运算能力，因此驱动优化带来的收益逐渐被计算开销所掩盖。

以上仅为根据实验现象作出的推测，目前尚未通过性能分析工具进行验证，后续如有更多数据，将进一步补充分析。

---

测试条件二：CPU 调度模式为 performance

CPU 工作于性能模式，频率固定为 1 GHz。

echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo 0 > /sys/class/graphics/fbcon/cursor_blink

测试结果

	fbtft	tinydrm	提升幅度	单位
Rectangle 32x40	17.12	25.84	33.74%	MPixels/second
Sierpinski 1024	1155.75	1701.89	32.09%	Frames/second
Sierpinski 2048	586.88	900.29	34.81%	Frames/second
Sierpinski 4096	319.47	464.54	31.22%	Frames/second
Sierpinski 8192	159.61	236.52	32.51%	Frames/second
Sierpinski 16384	88.58	118.88	25.48%	Frames/second
Sierpinski 32768	49.63	59.97	22.24%	Frames/second
Sierpinski 65536	25.15	30.08	16.38%	Frames/second
Sierpinski 131072	12.50	15.08	17.10%	Frames/second
Sierpinski 262144	7.65	7.65	0.00%	Frames/second

结果分析

将 CPU 提升至 1 GHz 后，两种驱动的性能均有明显提升。

与此同时，tinydrm 相对于 fbtft 的领先优势由约 50% 降低至 30% 左右。

从测试数据来看，CPU 频率提升后，fbtft 的性能增幅明显高于 tinydrm。这说明 fbtft 对 CPU 运算能力更加敏感，而 tinydrm 的整体开销相对较低，因此在 CPU 性能提升后，其收益没有 fbtft 那么明显。

不过，仅凭本次测试还无法完全证明这一结论，仍需要结合 perf 等性能分析工具进一步验证 CPU 时间分布及热点函数。

---

调整 SPI 频率后的测试

测试过程中还尝试提高 SPI 总线频率，但测试成绩几乎没有变化。

对于本次测试所使用的 128×160 分辨率 LCD 来说，SPI 带宽并未成为性能瓶颈，因此提高 SPI 时钟无法带来可观察的性能提升。

若后续测试更高分辨率的 SPI LCD，或者采用更高的刷新频率，SPI 带宽可能会成为影响性能的重要因素，届时值得进一步验证。

总体结论

总体来看，在 fbdev 接口下，对于 ST7735R（128×160）这类低分辨率 SPI LCD，tinydrm 在显示性能方面整体优于 fbtft。在显示操作占主要开销的场景下，性能提升可达到约 50%；随着 CPU 计算负载增加，两者之间的差距逐渐缩小。当系统瓶颈转移至 CPU 运算时，两种驱动的性能趋于一致。