Is one line rendering so much faster than full frame rendering (full screen rendering)?

[yanshay]

I'm trying to maximize fps on esp32s3 with I8080 display interface, so I benchmarked one line rendering (render_by_line) vs. full frame rendering (render). In the docs I saw full frame rendering is supposed to be faster, but in my tests, the one line rendering performs much better, at least in my setup.

I wonder if I'm doing something wrong or if indeed one line rendering is just more optimized.

My scenario is animation that scrolls the screen and doing full screen rendering (practically renders the entire screen every time, no case of partial screen rendering).

To use full screen I'm using esp32s3 psram which is slower than the internal ram, so to compare apples to apples what I did is render using both full frame render and one line rendering the entire screen to psram (in both cases), and only then output the entire frame to the display (so no caching is involved).

Actually, the comparison measurements are after removing the display code so I will compare just the rendering time.
I'm using the RepaintBufferType::ReuseBuffer. I also verified by counting reoprted pixels and lines that every time is a full screen redraw.

In my results:

• Rendering an entire screen to psram using one line rendering - 48 msec
• Renderig an entire screen to psram using full frame rendering - 146 msc (3 times more).

Am I doing something wrong and not gaining the performance benefits I could from the full frame rendeting?

On a side note (doesn't matter that much but just to extract actual rendering time from writing to memory) - the one line rendering mrasurement is consistent with psram performance difference

• Rendering an entire screen to sdram using one line rendering - 30 msec
• Just filling a screen size buffer of psram - 20 msec
• So total of 48 is approximately consistent

[ogoffart]

I'm as surprised as you. In principle, it should be faster to render the whole buffer at once.
I was able to reproduce it on desktop that line by line is faster which is strange.
Maybe this is a cache issue...
I'll investigate that.

[ogoffart]

Further analysis shows indeed that this is a cache issue:
I ran cachegrind on the desktop to draw the printer demo 500 times with and without the line by line renderer (modified so that they both use the same pixel and draw directly on the softbuffer.)

The result are: line-by-line:

==614684== Events    : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw Bc Bcm Bi Bim
==614684== Collected : 1285231793 197828623 125343363 2243860 2304872 3249825 16445 22500 31158 116412963 5054298 4247696 670801
==614684== 
==614684== I   refs:      1,285,231,793
==614684== I1  misses:        2,243,860
==614684== LLi misses:           16,445
==614684== I1  miss rate:          0.17%
==614684== LLi miss rate:          0.00%
==614684== 
==614684== D   refs:        323,171,986  (197,828,623 rd + 125,343,363 wr)
==614684== D1  misses:        5,554,697  (  2,304,872 rd +   3,249,825 wr)
==614684== LLd misses:           53,658  (     22,500 rd +      31,158 wr)
==614684== D1  miss rate:           1.7% (        1.2%   +         2.6%  )
==614684== LLd miss rate:           0.0% (        0.0%   +         0.0%  )
==614684== 
==614684== LL refs:           7,798,557  (  4,548,732 rd +   3,249,825 wr)
==614684== LL misses:            70,103  (     38,945 rd +      31,158 wr)
==614684== LL miss rate:            0.0% (        0.0%   +         0.0%  )
==614684== 
==614684== Branches:        120,660,659  (116,412,963 cond +   4,247,696 ind)
==614684== Mispredicts:       5,725,099  (  5,054,298 cond +     670,801 ind)
==614684== Mispred rate:            4.7% (        4.3%     +        15.8%   )

full buffer:

==614773== Events    : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw Bc Bcm Bi Bim
==614773== Collected : 1172231945 175777665 114518874 2475568 2794455 9020957 16364 22492 30649 98615724 3514706 3169324 199028
==614773== 
==614773== I   refs:      1,172,231,945
==614773== I1  misses:        2,475,568
==614773== LLi misses:           16,364
==614773== I1  miss rate:          0.21%
==614773== LLi miss rate:          0.00%
==614773== 
==614773== D   refs:        290,296,539  (175,777,665 rd + 114,518,874 wr)
==614773== D1  misses:       11,815,412  (  2,794,455 rd +   9,020,957 wr)
==614773== LLd misses:           53,141  (     22,492 rd +      30,649 wr)
==614773== D1  miss rate:           4.1% (        1.6%   +         7.9%  )
==614773== LLd miss rate:           0.0% (        0.0%   +         0.0%  )
==614773== 
==614773== LL refs:          14,290,980  (  5,270,023 rd +   9,020,957 wr)
==614773== LL misses:            69,505  (     38,856 rd +      30,649 wr)
==614773== LL miss rate:            0.0% (        0.0%   +         0.0%  )
==614773== 
==614773== Branches:        101,785,048  ( 98,615,724 cond +   3,169,324 ind)
==614773== Mispredicts:       3,713,734  (  3,514,706 cond +     199,028 ind)
==614773== Mispred rate:            3.6% (        3.6%     +         6.3%   )

We can see that despite the instruction count being lower for the full buffer, the data cache miss rate is much bigger.
This is probably what makes the full screen rendering much slower.

I did not expect such a 3 times difference though

maybe we should implement the normal render() in term of line_by_line rendering
but we did it that way in order to benefit from some hardware acceleration provided by the hardware for rendering images. (altough they would not work on esp32 anyway)

(note: this is the compilation command cargo build -p printerdemo_mcu --features=simulator --no-default-features --release of modified backend-winit/sw.rs so that it terminates the process after 500 refresh and that the line renderer draws directly in the buffer). then i ran valgrind with (SLINT_LINE_BY_LINE=1) SLINT_DEBUG_PERFORMANCE=console,refresh_full_speed,overlay,no_partial SLINT_SCALE_FACTOR=1 valgrind --tool=callgrind --dump-instr=yes --cache-sim=yes --branch-sim=yes target/release/printerdemo_mcu)