Pages: [1] 2 3 
|
 |
|
|
Author
|
Topic: Benchmark for LCD. (Read 4964 times)
|
|
RV9YW
Neuling
 Offline
Posts: 15
|
 |
Benchmark for LCD.
« on: 04. December 2018, 05:59:26 »
|
|
Hi all, as long as I started reconstruct display module I wrote benchmark to see progress. I strongly believe that we can more then double performance of SPI displays.
I compiled only for F4. Could you test and post your results here in the next format... ( for now only SPI displays interested by me )
V.0.0
FullRect ->
ColorPoint ->
LineWithGrad ->
TextSmall ->
TextLarge ->
TextRight ->
TextCentered ->
Text8Bit ->
Type of display ->
|
|
|
|
|
RV9YW
Neuling
Offline
Posts: 15
|
|
Re:Benchmark for LCD.
« Reply #1 on: 04. December 2018, 06:04:23 »
|
|
BTW: my result is with recent code from repo is
with SPI_BAUDRATEPRESCALER_4
|
|
 Logged
|
|
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:Benchmark for LCD.
« Reply #3 on: 04. December 2018, 06:51:57 »
|
|
Hi Maksim,
how do you plan to double the performance, if the SPI clock is not being changed? Waiting for the SPI to finish the previous transfer is probably the largest influence. You can't be faster than back to back transfer?
There is potential for speeding up, but only the waterfall could benefit from that really: Drawing in the "background", i.e. the SPI DMA interrupt nows what to draw next without the CPU waiting. But this "autonomous drawing" would have to be synchronized with other lcd operations.
So, please share your idea. More than happy to test these, since I do own a SPI mcHF.
73
Danilo
|
|
Logged
|
|
|
|
|
|
SP9BSL
positron
alter Hase
Offline
Posts: 443
|
|
Re:Benchmark for LCD.
« Reply #5 on: 04. December 2018, 17:34:07 »
|
|
Hi Maksim,
One thing from me: simple speedup of the SPI by changing the prescaler will cause the crash of some LCDs. We had this a year ago with RPI3.5" SPI lcd and F7...
Like Danilo said, the main bootleneck is with waterfall update. The real possibility we have in new RA8875 driver, we can use some of its hardware features to lower the data amount, but this is future.
As usual: I will gladly learn something new if you show us...
|
| « Last Edit: 04. December 2018, 18:02:17 by SP9BSL » |
Logged
|
73 Slawek
|
|
|
RV9YW
Neuling
Offline
Posts: 15
|
|
Re:Benchmark for LCD.
« Reply #6 on: 04. December 2018, 21:05:49 »
|
|
Hi all. Yes the numbers in ms, so less number is better...
this is the result from my last SPI driven device:
FullRect -> 11748
ColorPoint -> 6088
LineWithGrad -> 3026
TextSmall -> 1049
TextLarge -> 4526
TextRight -> 4526
TextCentered -> 7000
Text8Bit -> 9608
Type of display -> 3.2" SPI
|
|
Interesting, do you see on my display (It's 2.4" 240x320 ILI9341) to draw ColorPoints took less (2087ms) then on yours display (3026ms)...
I do mention that 8bit font is not print properly on my display, is it the same on yours? (The last print before result.)
|
|
Logged
|
|
|
|
RV9YW
Neuling
Offline
Posts: 15
|
|
Re:Benchmark for LCD.
« Reply #7 on: 04. December 2018, 21:07:09 »
|
|
Just for information two other results:
FullRect -> 1258
ColorPoint -> 397
LineWithGrad -> 499
TextSmall -> 168
TextLarge -> 956
TextRight -> 956
TextCentered -> 1211
Text8Bit -> 2235
Type of display -> HY28B parallel
FullRect -> 1006
ColorPoint -> 187
LineWithGrad -> 429
TextSmall -> 132
TextLarge -> 857
TextRight -> 857
TextCentered -> 1059
Text8Bit -> 2030
Type of display ->3.5" @ 480x320
|
|
All of them are also SPI?
|
|
Logged
|
|
|
|
RV9YW
Neuling
Offline
Posts: 15
|
|
Re:Benchmark for LCD.
« Reply #8 on: 04. December 2018, 21:13:48 »
|
|
Hi Maksim,
One thing from me: simple speedup of the SPI by changing the prescaler will cause the crash of some LCDs. We had this a year ago with RPI3.5" SPI lcd and F7...
|
|
Thank you for heads-up. That's why I started by posted benchmark FW before making PR to be sure that's it's still working.
|
|
Logged
|
|
|
|
RV9YW
Neuling
Offline
Posts: 15
|
|
Re:Benchmark for LCD.
« Reply #9 on: 04. December 2018, 21:20:00 »
|
|
Hi Maksim,
how do you plan to double the performance, if the SPI clock is not being changed? Waiting for the SPI to finish the previous transfer is probably the largest influence. You can't be faster than back to back transfer?
There is potential for speeding up, but only the waterfall could benefit from that really: Drawing in the "background", i.e. the SPI DMA interrupt nows what to draw next without the CPU waiting. But this "autonomous drawing" would have to be synchronized with other lcd operations.
So, please share your idea. More than happy to test these, since I do own a SPI mcHF.
73
Danilo
|
|
We do not use some features of STM SPI hardware, such cycle mode and 16bit transfers...
We can improve DrawFullRect by 10 times I believe, some others two times.
I'll post later the next benchmark, we will see.
PS, Danilo could you share your results, please.
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:Benchmark for LCD.
« Reply #10 on: 05. December 2018, 02:07:27 »
|
|
Hi,
We do not use some features of STM SPI hardware, such cycle mode and 16bit transfers...
We can improve DrawFullRect by 10 times I believe, some others two times.
I'll post later the next benchmark, we will see.
PS, Danilo could you share your results, please.
|
|
The main screen activity is the waterfall, everything else is even on the SPI display decent (not that it cannot get better or that you could make use of the added speed). Doubling speed of functions not really contributing to the overall load is nice, but what would be the point of this? And should we pay the price in terms of more complex software for it? Nothing comes for free.
For waterfall the SPI transfers we use should ensure back to back transfers, even in 8bit mode, and I don't how much you can save with 16bit vs. 2x8 bit. Its is surely some percentage but not like two times faster.
That should not stop you, but I would really urge everyone (including myself!) to consider making things not too complex for just a little gain. Synthetic benchmarks are good and important but they often tell you little about the real world.
I cannot share my results at the moment, because I can't run the benchmark. BTW, if the benchmark is based on the UHSDR software which runs under GPLv3 , you have to give everyone who asks for it access to the source code used to compile the benchmark binary.
Consider yourself ask. I just want to see how you are measuring the performance.
73
Danilo
|
| « Last Edit: 05. December 2018, 02:07:53 by DB4PLE » |
Logged
|
|
|
|
RV9YW
Neuling
Offline
Posts: 15
|
|
Re:Benchmark for LCD.
« Reply #11 on: 05. December 2018, 03:32:40 »
|
|
For waterfall the SPI transfers we use should ensure back to back transfers, even in 8bit mode, and I don't how much you can save with 16bit vs. 2x8 bit. Its is surely some percentage but not like two times faster.
|
|
Yes, you are right it's not two times, but we can buy some time for another tasks. And my main purpose to rewrite this to make it easy later to adopt with rtos... We would just need to change couple lines by take and give semaphore... No it's more complex.
Even if we get 1..5 % it's worth
Synthetic benchmarks are good and important but they often tell you little about the real world.
|
|
I would not call it pure synthetic because I call it from main loop instead of calling UI. So, all interrupts are up and triggering. Only I2c parts are missed. Nothing connected...
BTW, if the benchmark is based on the UHSDR software which runs under GPLv3 , you have to give everyone who asks for it access to the source code used to compile the benchmark binary.
Consider yourself ask. I just want to see how you are measuring the performance.
|
|
Sure, there is nothing fancy....
I know it's not good to use HAL tick timer because PendSV has higher priority and eat CPU cycles, but it's OK for relative measurements.
I've attached, take a look please... and I call UiLcdHy28_DoBenchmark() instead of UiDriver_TaskHandler_MainTasks()
BTW, does any one see that 8bitFont is not working properly? Or it's only on my side?
|
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:Benchmark for LCD.
« Reply #12 on: 05. December 2018, 04:28:33 »
|
|
Hi Maksim,
you are running this with the audio interrupt active?
Then your benchmark is not comparable between machines. Comment it out, since depending on the user's last settings we have different load in the audio interrupt, which affects the produced numbers more a lot.
And, no I don't think 1.5% performance improvement on a function which may be responsible for 10% of the total load (which makes it an improvement of 0.15% with respect to full system load) alone is worth much more complex code or difficult code. I am not saying that your idea has any of this. It is just my general opinion.
The main improvement in terms of freeing time for other stuff (not for making the graphics as such faster) would be to make the waterfall code running the screen update in parallel to other activities (right now we wait most of the time for the previous spi transfer to be finished...).
But this is all theory without seeing what you are to achieve and how, so go ahead and let us see.
73
Danilo
|
|
Logged
|
|
|
|
RV9YW
Neuling
Offline
Posts: 15
|
|
Re:Benchmark for LCD.
« Reply #13 on: 05. December 2018, 04:54:35 »
|
|
you are running this with the audio interrupt active?
|
|
Could you suggest easiest way to disable them? Thank you
|
|
Logged
|
|
|
|
|
|
Pages: [1] 2 3 
|
|
|
|
|
|
|
DebugMCHF.zip
