blit buffer problems with 4-wire-spi and DMA

[simeonfelis]

ATSAMD51G19A
GFX 3.11.1

ST7789S display (320x240), SPI with 55MHz, using DMA

Display is not correctly transferred to the screen. Behavior is optimization dependent. This is with 2 scratch buffers each 32k, -O0:

This is with 2 scratch buffers each 32k, -O1:

This is with 2 scratch buffers each 32k, -O2:

This is with 2 scratch buffers each 32k, -O3:

Using 1 scratch buffer with 32k or 64k works fine in any optimization level:

Example project:

https://github.com/simeonfelis/gfx/raw/master/grotest.zip

[MHGC]

Hi, it seems the problem occurs when using two scratch buffers, correct?

[simeonfelis]

Yes, correct. Am 5. Oktober 2022 20:24:39 MESZ schrieb MHGC ***@***.***>:

…

Hi, it seems the problem occurs when using two scratch buffers, correct? -- Reply to this email directly or view it on GitHub: #26 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[MHGC]

Ok, we will investigate this. Thank you for the report.

[MHGC]

Following up on this. Is multiple scratch buffer necessary for your design?

Harmony have not released any 'high-performance' demos using multi-scratch buffers.

The tradeoff with multi-scratch buffer is the likelihood of more tearing, especially if it takes the MCU longer time to render than to blit and if it's updating a large area of the frame.

[simeonfelis]

Well I thought multiple scratch Buffers are a good thing. We have no final config yet. Blit with IRQs takes about 100ms with IRQs stealing 90% of CPU time. Blit with DMA takes about 13ms. Now in config 1 we would use alpha blending. Rendering requires lots of CPU, more than to blit. In config 2 alpha blending is disabled. Rendering requires far less CPU time, probably same as to blit. Best would be to observe the tearing effect. IMHO this bug looks like a locking or increment problem in DMA.

[simeonfelis]

Just a follow-up:

Following up on this. Is multiple scratch buffer necessary for your design?

Yes. If it does not work why not remove it?

The tradeoff with multi-scratch buffer is the likelihood of more tearing, especially if it takes the MCU longer time to render than to blit and if it's updating a large area of the frame.

I understood training material for legato like this: multiple scratch buffers improve tearing, no matter how fast blitting is.

[MHGC]

Yes. If it does not work why not remove it?

It is not so easily to remove. The scratch buffer setting is in the Graphics Composer, which is device-agnostic. Legato is supporting 30+ device families, each family with upwards of 50 device configurations, with an assortment of graphics driver + display type.

Ultimately, scratch buffer management may need to be moved out of Graphics Composer into display driver settings. But that is a major change and will impact all existing demos and drivers.

I understood training material for legato like this: multiple scratch buffers improve tearing, no matter how fast blitting is.

This statement assumes each scratch buffer encompasses the area of change in entirety. Assuming the change is only one part of the screen, the scratch buffer sizes would have to be calibrated manually for this. Otherwise, the library split the area of change between scratch buffers and that is where the tearing would occur.

If the area of change is substantial, such as sliding of a panel covering much of the screen, the multi-scratch buffers just become a double frame buffer scheme.

We will investigate this.

[mhtmhn]

I tested multiple scratch buffers on the MZ EF connected to a MaxTouch Curiosity display (ILI9488 over 4-Wire SPI) and didn't see any issues pop up.

Can you try blitting a frame with a test pattern or solid color without using legato (comment it out from SYS_Initialize, SYS_Tasks)?

Make sure you test cases where you offset the blit origin from (0,0) to say (100, 100) and see if it reliably paints to the specified location on the screen. Do this multiple times with different offsets, during the same run, to ensure the previous operation doesn't influence the next.