logo
Willkommen, Gast. Bitte Login oder Registrieren.
17. Juni 2019, 13:44:53


Übersicht Hilfe Suche Login Registrieren

Amateurfunk Sulingen
Diskussions- und Newsboard des DARC-Ortsverbandes I40  |  allgemeine Kategorie  |  UHSDR Firmware (Moderatoren: DF8OE, DL1PQ)  |  Thema: Benchmark for LCD. <- zurück vorwärts ->
Seiten: [1] 2 3 nach unten Drucken
   Autor  Thema: Benchmark for LCD.  (Gelesen 1394 mal)
RV9YW
Neuling
*

Offline

Einträge: 15





Profil anzeigen
Benchmark for LCD.
« am: 04. Dezember 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 ->
 DebugMCHF.zip
Moderator benachrichtigen   Gespeichert
RV9YW
Neuling
*

Offline

Einträge: 15





Profil anzeigen
Re:Benchmark for LCD.
« Antwort #1 am: 04. Dezember 2018, 06:04:23 »

BTW: my result is with recent code from repo is

with SPI_BAUDRATEPRESCALER_4
Moderator benachrichtigen   Gespeichert
DF8OE
Administrator
*****

Offline

Einträge: 5116



Jugend- und Nachwuchsreferent des I40

Profil anzeigen WWW
Re:Benchmark for LCD.
« Antwort #2 am: 04. Dezember 2018, 06:27:43 »

Hi Maksim,

this is the result from my last SPI driven device (SPI is very rare used and is replaced by parallel in most devices - OVI40 does not support SPI at all):

FullRect          -> 11748
ColorPoint      -> 6088
LineWithGrad  -> 3026
TextSmall        -> 1049
TextLarge        -> 4526
TextRight        -> 4526
TextCentered  -> 7000
Text8Bit          -> 9608
Type of display -> 3.2" SPI

vy 73
Andreas
Moderator benachrichtigen   Gespeichert

Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
DB4PLE
positron
Urgestein
*****

Offline

Einträge: 1158





Profil anzeigen
Re:Benchmark for LCD.
« Antwort #3 am: 04. Dezember 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

Moderator benachrichtigen   Gespeichert
DF8OE
Administrator
*****

Offline

Einträge: 5116



Jugend- und Nachwuchsreferent des I40

Profil anzeigen WWW
Re:Benchmark for LCD.
« Antwort #4 am: 04. Dezember 2018, 07:14:14 »

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" parallel @480x320

I think lower values are better performance... If so: this shows in an impressive way the difference between the LCD types and operating modes. 3.5" LCD whith higher resolution has better performance (at same resolution) than HY28B so performance with full resolution is only a bit slower than "original LCD". All tests done with F429 MCU.

vy 73
Andreas
« Letzte Änderung: 05. Dezember 2018, 05:30:05 von DF8OE » Moderator benachrichtigen   Gespeichert

Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
SP9BSL
positron
noch länger dabei
***

Offline

Einträge: 204





Profil anzeigen
Re:Benchmark for LCD.
« Antwort #5 am: 04. Dezember 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...
« Letzte Änderung: 04. Dezember 2018, 18:02:17 von SP9BSL » Moderator benachrichtigen   Gespeichert

73 Slawek
RV9YW
Neuling
*

Offline

Einträge: 15





Profil anzeigen
Re:Benchmark for LCD.
« Antwort #6 am: 04. Dezember 2018, 21:05:49 »

Hi all. Yes the numbers in ms, so less number is better...

Zitat von: DF8OE am 04. Dezember 2018, 06:27:43
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.)

Moderator benachrichtigen   Gespeichert
RV9YW
Neuling
*

Offline

Einträge: 15





Profil anzeigen
Re:Benchmark for LCD.
« Antwort #7 am: 04. Dezember 2018, 21:07:09 »

Zitat von: DF8OE am 04. Dezember 2018, 07:14:14
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?
Moderator benachrichtigen   Gespeichert
RV9YW
Neuling
*

Offline

Einträge: 15





Profil anzeigen
Re:Benchmark for LCD.
« Antwort #8 am: 04. Dezember 2018, 21:13:48 »

Zitat von: SP9BSL am 04. Dezember 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...

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.

Moderator benachrichtigen   Gespeichert
RV9YW
Neuling
*

Offline

Einträge: 15





Profil anzeigen
Re:Benchmark for LCD.
« Antwort #9 am: 04. Dezember 2018, 21:20:00 »

Zitat von: DB4PLE am 04. Dezember 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



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.
Moderator benachrichtigen   Gespeichert
DB4PLE
positron
Urgestein
*****

Offline

Einträge: 1158





Profil anzeigen
Re:Benchmark for LCD.
« Antwort #10 am: 05. Dezember 2018, 02:07:27 »

Hi,

Zitat von: RV9YW am 04. Dezember 2018, 21:20:00
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
« Letzte Änderung: 05. Dezember 2018, 02:07:53 von DB4PLE » Moderator benachrichtigen   Gespeichert
RV9YW
Neuling
*

Offline

Einträge: 15





Profil anzeigen
Re:Benchmark for LCD.
« Antwort #11 am: 05. Dezember 2018, 03:32:40 »

Zitat von: DB4PLE am 05. Dezember 2018, 02:07:27
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

Zitat von: DB4PLE am 05. Dezember 2018, 02:07:27
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...

Zitat von: DB4PLE am 05. Dezember 2018, 02:07:27
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?


 lcd_benchmark.zip
Moderator benachrichtigen   Gespeichert
DB4PLE
positron
Urgestein
*****

Offline

Einträge: 1158





Profil anzeigen
Re:Benchmark for LCD.
« Antwort #12 am: 05. Dezember 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

 
Moderator benachrichtigen   Gespeichert
RV9YW
Neuling
*

Offline

Einträge: 15





Profil anzeigen
Re:Benchmark for LCD.
« Antwort #13 am: 05. Dezember 2018, 04:54:35 »

Zitat von: DB4PLE am 05. Dezember 2018, 04:28:33
you are running this with the audio interrupt active?

Could you suggest easiest way to disable them? Thank you
Moderator benachrichtigen   Gespeichert
DB4PLE
positron
Urgestein
*****

Offline

Einträge: 1158





Profil anzeigen
Re:Benchmark for LCD.
« Antwort #14 am: 05. Dezember 2018, 05:21:54 »

Hi Maksim,


Comment out AudioDriver_Init()

https://github.com/df8oe/UHSDR/blob/active-devel/mchf-eclipse/src/uhsdr_main.c#L572

73
Danilo
Moderator benachrichtigen   Gespeichert
Seiten: [1] 2 3 nach oben Drucken 
Diskussions- und Newsboard des DARC-Ortsverbandes I40  |  allgemeine Kategorie  |  UHSDR Firmware (Moderatoren: DF8OE, DL1PQ)  |  Thema: Benchmark for LCD. <- zurück vorwärts ->
Gehe zu: 


Login mit Username, Passwort und Session Länge

 Es wird die Verwendung von Browsern die auf der "Blink"-Engine basieren und mindestens 1024x768 Pixel Bildschirmauflösung für die beste Darstellung empfohlen 
Amateurfunk Die Beiträge sind, sofern nicht anders vermerkt, unter der folgenden Lizenz veröffentlicht:
GNU Free Documentation License 1.3 GNU Free Documentation License 1.3
verbindet!
Powered by MySQL Powered by PHP Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2004, YaBB SE Dev Team. All Rights Reserved.
- modified by Andreas Richter (DF8OE)
Impressum & Disclaimer
Valid XHTML 1.0! Valid CSS!