Performance testing for more tiny TFTs

[gdampf]

@notro: You published some results of performance testing one year ago. I am looking for other cheap but fast displays and tested waveshare35a and others. I am using latest kernel (4.4.22+) with a patch to correct fbtft-core.c DEBUG Messages. I have three questions on your work last year:

1. I am forced to use SDL as workaround for mplayer. Do you think, the results are comparable?
2. After the test, in dmesg, I see a wide difference between the FPS in several parts of the little movie (between 5 and 33), but stable update time (around 2300 kB/s). Would you agree, that the time between the frames is more depending on mplayer than on the TFT-Hardware?
3. How can I detect, if DMA is available or not? I am using the overlay-file to load driver and didn't found a DMA-Parameter to pass. Is it correct, that this is enabled by default and can be switched off somehow?

Thank you a lot for answering this few beginners questions. BR Guido

[notro]

fbtft uses fb_feferred_io to collect framebuffer changes (mmap). It tracks changes in PAGE_SIZE (4k) blocks. So if you change a pixel in the first and last page of the framebuffer, a full update is started. The spi controller driver spi-bcm2835 uses DMA by default regardless of what fbtft does. You can disable it by using txbuflen=64 I guess, since that is below the DMA threshold (96) of the spi driver.

[NdK73]

I'm using a SpotPear 3.5" and redraw is easily visible. For 640x480 it requires a bit more than 300ms. Test is a simple dd if=/dev/urandom of=/dev/fb1 bs=$((640*480*2)) count=1 I tried using mmap from a C program but the update speed is the same. Even tried double buffering (drawing in a temp buffer then using memcpy() to copy it to mmapped region). A (marginal) improvement is speeding up SPI bus using speed=24000000 (32MHz seems too much and some colors aren't drawn properly but strangely enough 31MHz still work...). I'm using minibian on a Rpi B (the old one, w/ 26 pins connector). Is there something I can do to at least make refresh invisible? Too bad the display seems not to support double buffering... :( Kernel is stock 4.4.26+ shipped by Debian. . Tks.

[gdampf]

Are you sure, urandom isn't slowing down your test significant? Compare it with copying the same amount to /dev/null.

[NdK73]

Yup. Tested with /dev/zero (not /dev/null) too. Actually that's what I use to delete the last image drawn when I don't do it from my program. I don't actually need 20fps, but less than 3fps doesn't sound right to me (well, it could be OK, if only it wasn't for the redraw that IIUC can't be removed since the 'vblank' signal is not brought out). I even tried setting fps=1 but that made the redraw even slower (??? why???). Maybe I have to increase the DMA size used for the SPI transfer?

[gdampf]

I wondering, why you try a spotpear 3.5" with a resolution of 640x480, as this display has only 320x480 pixel !? Further, the ILI-display itself has a parallel interface, which is feed by some shift-registers at the Spotpear-board. This is depending a lot on timing. 3 fps are a bit to slow (6 would be reasonable), but anyhow, just a few shift-register-devices are able to handle high transfer rates (up to 125 Mhz clock). This devices are using special programmable Logic-Circuits and are not build from standard logic, as spotpear do it. They are much more expensive or hard to get or both.

[NdK73]

Sorry. Numerical dyslexia and an attempt at double buffering :( Actually it's correctly detected as 480x320: [ 7.104395] graphics fb1: flexfb frame buffer, 480x320, 300 KiB video memory, 4 KiB DMA buffer memory, fps=33, spi0.0 at 16 MHz I don't know why SpotPear did it this way... I bought it quite some time ago (it was the only one I could find at the time) then discovered it only worked with their image and left it in a drawer. Now I have another project that doesn't require high framerate but requires the refresh is not visible...

[gdampf]

If you manage to get a tontec35, you may be lucky. For my location, shipping is too expensive - so I don't own one. But afaik, this is one of the fastest 3.5 inch displays for raspi.

[NdK73]

Only if it's definitely not possible to make the current one work. And I don't need a fast display (for videos) but just one where I can redraw the GUI without seeing the redrawing itself.

[gdampf]

Well, this sounds a bit odd for me, as the limitating factor is the transfer rate. To shorten the redraw, you need a fast display. If the limitating factor would be the drawing (in a Buffer), you could use the fb-copy-tool to draw in fb0 (with hw-acceleration) and copy it into fb1 with that tool. But the copy itself will take time depending on the speed of the interface. Some displays have the ability to switch of backlight during this copy-process, if that helps. But I don't know, if yours has this feature. For Frambuffer-Copy see: https://github.com/notro/fbtft/wiki/Framebuffer-use#framebuffer-mirroring

[notro]

AFAIK that display uses an interface circuit like this: https://github.com/notro/fbtft/wiki/SPI-interface-circuit

I made that page 3 years ago when there wasn't so many displays to chooses from. Nowadays there are plenty, so choose one that uses a display controller with native SPI. The controllers datasheets I have looked at state a max speed of 10MHz, but usually they run fine at 32MHz.

Or one that does it good like the Tontec display which is the fastest SPI display I know about.

Maybe someone with knowledge about these displays could make a Waveshare wiki page: https://github.com/notro/fbtft/wiki/Waveshare detailing it's woes. And if their displays still are really bad, maybe link to it from the front page: https://github.com/notro/fbtft/wiki to warn people.

It's a bit sad to see so many people having problems with these displays.

[NdK73]

Well, the display works... more or less. It's just that the redraw is visible. Retrying the SpotPear's image I could notice it's just a bit snappier: redraw is still visible, but X is quite usable. I see messages about ili9486, but that controller uses a parallel interface...

[gdampf]

That's what notro mentioned: The SPI-interface build from cheap shift registers is used to convert SPI (serial) to the ili9486-Interface (parallel). And this cheap registers aren't fast enough to be driven with high rate. That X doesn't show the effect as much as your test-routine has a simple reason: X is not redrawing the whole screen each time. It can redraw it partially - just the area, which has changed. I analyzed the Image provided by waveshare. There is nothing special within - except the fact, that they tied everything necessary together with an more or less old kernel. It isn't worth to invest too much time in this images - they don't help at all.

[NdK73]

Tks. I'll see if I can find better displays in the future. The wiki page could be useful. Even better if it could give some directions to avoid the "bad" ones.

[notro]

Closing issue since there has been no activity for more than 2 months. Reopen if needed.