On Tue, Aug 5, 2025 at 10:19 AM Lucas Stach <l.st...@pengutronix.de> wrote: > > Am Dienstag, dem 05.08.2025 um 08:46 +0200 schrieb Josef Luštický: > > On Mon, Aug 4, 2025 at 11:59 AM Lucas Stach <l.st...@pengutronix.de> wrote: > > > > > > Hi Josef, > > Hello Lucas, thank you for answering. > > > > > > Am Freitag, dem 01.08.2025 um 13:06 +0200 schrieb Josef Luštický: > > > > Hello, > > > > I am trying to get GPU acceleration to work with SPI display using > > > > ili9225_dri.so, > > > > and I use kmscube to test. > > > > The SoC is STM32MP157c with Vivante GC400 GPU and I use Mesa3D 24.0.9 > > > > (rootfs generated with Buildroot 2025.02.3) and kernel 5.10.176 (from > > > > STM). > > > > > > > > I also have the same system with MIPI Display attached. > > > > While kmscube renders at 60 fps with the MIPI Display system, I get > > > > only 11 fps with the SPI display. Apart from that both systems are the > > > > same. > > > > > > The question is what can you expect from a SPI display? SPI is not a > > > great interface for isochronous traffic with quite high bandwidth > > > demands. Even at really low resolutions you need a lot of bandwidth to > > > update a display. What is the resolution and color depth of you > > > display? How fast is your SPI connection? > > The display is 320x480 with 16bpp, so the screen is 307200 bytes. > > The SPI clock is set to 50MHz in device-tree and I also tried 100MHz > > with no change. > > From the clock tree configuration, it seems the SPI peripheral gets 64MHz, > > but I'll check what's the real frequency of SPI CLK output. > > If this is a standard SPI connection with a single bit per clock > transfer rate, 50 MHz SPI clock rate works out to ~20 frames per > second, limited by pure transfer time. This means no other overhead > like SPI message setup in the host controller and userspace waiting for > flip completion or anything like that. I measured the SPI CLK frequency and it turns out it was 32MHz. After increasing to 50MHz I am now getting 17 fps with the kmscube demo. With 32MHz the theoretical maximum is 32000000 / (320*480*16) = 13 fps, while with 50MHZ it is 50000000 / (320*480*16) = 20.3 fps.
So you're right Lucas, Thank you Josef > > Given that, your measured 11 fps doesn't sound that much off from what > you could expect from such a setup. > > Regards, > Lucas > > > > > > > You might run modetest -v to get a reference point on how fast the > > > display can be updated without any GPU rendering going on. > > > > > > Regards, > > > Lucas > > > > > > > > > > > I checked the output of kmscube and it prints the exact same extensions > > > > on both, > > > > the only difference is the framerate. > > > > I also checked output of kmscube's /proc/PID/maps and the only > > > > difference is that with MIPI Display it loads /usr/lib/dri/stm_dri.so > > > > while with the SPI Display it loads /usr/lib/dri/ili9225_dri.so, > > > > but I see those files are the same (hardlinks). > > > > Both open /dev/dri/renderD128 (GPU). > > > > > > > > Why am I getting just 11 fps on the system with SPI Display? > > > > Is there some architectural limitation, either in Mesa, kernel, or > > > > HW-related? > > > > I suppose both setups use kernel's KMS as renderer only (kmsro), thus > > > > it should render at the same framerate. > > > > The difference in HW is the peripheral the displays use - LTDC > > > > (stm_dri.so) vs. SPI (eventually ili9225_dri.so). > > > > Why do I see no /usr/lib/etnaviv_dri.so loaded? > > > > > > > > The MIPI Display is attached to the LTDC (LCD Timing Display > > > > Controller) peripheral of the STM SoC and the display driver is > > > > drivers/gpu/drm/panel/panel-sitronix-st7703.c (DRM panel). > > > > > > > > The SPI display driver uses the kernel's TinyDRM API and its driver is > > > > drivers/gpu/drm/tiny/ili9225.c. > > > > > > > > I also tried softpipe (disabled GPU in device-tree) and it renders 7 > > > > fps on both systems. > > > > > > > > I attach the output from kmscube on the SPI Display system (the MIPI > > > > Display is the same except framerate is 60 fps.) > > > > > > > > Kind regards > > > > Josef Lusticky > > > >