nopacity-Imagescaler Performance?

    Hi,


    Ich nutze im Skin flatPlus ja auch den Scaler von nopacity, welcher ja glaub ich ursprünglich von hier ist: [skinnopacity 1.0.0] die ganze Scaler-Diskussion....


    In einer Disskusion mit MegaV0lt ist nun herausgekommen das die Performance stark schwankt.
    Ich habe in meinem Entwicklungsrechner einen aktuellen und mittleren Core I5 und meine Zeiten sehen wie folgt aus:


    Interessant ist dabei die Ausgabe "scale logo:" also bei mir zwischen 2-3ms jeweils.


    MegaV0lt hat einen "AMD Athlon(tm) Dual Core Processor 4850e" (was auch immer das ist :)) und dort sieht es wie folgt aus:


    Hier sind es ~100ms :wow


    Woher kommen diese extremen Unterschiede? Ist die CPU wirklich so schwach, dass kann ich mir fast garnicht vorstellen. Ist das jemanden weiteren schonmal aufgefallen? Woher stammt eigentlich der initiale Scaler? Schön wäre es wenn man vielleicht noch einen zweiten (schnelleren, mit dann natürlich schlechterer Qualität) hätte und man das ganze dann konfigurieren könnte (langsam + gut / schnell + schlechter).
    Leider habe ich mich mit dem Thema nicht weiter beschäftigt sondern einfach von nopacity "geklaut" :D vielleicht kann ja jemand hier etwas dazu sagen bzw. hat Ideen woran das liegen könnte.


    Grüße
    Martin

    Erstmal sind AMD grundsätzlich nicht so performant wie Intel Prozessoren.
    Das habe ich vor kurzem erst wieder feststellen müssen. AMD Athlon II X2 250 ist langsamer als ein Intel Celeron J1900


    Dann kann es aber auch noch andere Gründe geben. Nutzt ihr die gleiche Distribution? Den gleichen GCC? Die gleichen Compile-Parameter?

    Nein das glaube ich nicht, ich nutzte XUbuntu 14.04 auf dem aktuellen Stand. Was MegaV0lt nutzt weiß ich nicht genau. Compiler Parameter war auch schon ein Gedanke von mir. Darauf hatte MegaV0lt noch wie folgt geantwortet:


    Zitat


    Ich kompiliere mit -native CPU sagt:
    ...
    Beim kompilieren kommt das:


    Code
    g++ -Werror=overloaded-virtual -Wno-parentheses -march=native -O3 -pipe -g -ggdb -O0 -D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fPIC -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -I/usr/local/src/VDR/include  -shared config.o setup.o imagecache.o imagescaler.o imagemagickwrapper.o imageloader.o baserender.o complexcontent.o textscroller.o displaychannel.o displaymenu.o displaymessage.o displayreplay.o displaytracks.o displayvolume.o flat.o skinflatplus.o -lMagick++-6.Q16 -lMagickWand-6.Q16 -lMagickCore-6.Q16  -o libvdr-skinflatplus.so


    Zitat


    Damit müssten die optimalen Parameter doch genommen werden.


    Hier noch was native (http://j.mp/1qQwzjc) macht:


    Code
    hdvdr01 skinflatplus # gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.3/cc1 -E -quiet -v - -march=k8-sse3 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=k8


    Dazu kann ich aber nichts sagen ...

    Ich würde mal noch die Größe ausgeben. Wobei die kleinen Bildchen ja kein Problem sein dürften.
    Der 'Rechenaufwand steigt ja mit der Größe quadratisch an.


    Im ffmpeg ist eine ganze Palette an Skaler enthalten. libswscale/swscale.h verwende ich im play Plugin für Bilder.
    Ob das Modul im Play GIT ist, weiß ich im Moment nicht.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    Moin,


    ursprünglich habe ich in nOpacity das Scaling der Bilder direkt per ImageMagick / GraphicsMagick gemacht. Da das insbesondere auf ARM Boxen sehr langsam war und die Qualität auch nicht so berauschend war, habe ich den von S:oren zur Verfügung gestellten nativen Scaler eingebaut. Bei mir ist der schneller und liefert eine bessere Qualität als die ImageMagick Scaler...


    Beim Skalieren werden viele Gleitkommaberechnungen benötigt, ich meine mal gelesen zu haben, dass AMD da im Vergleich zu Intel nicht so performant ist...


    Du kannst ja mal im Internet suchen, ob du noch einen anderen Image Scaler findest, der ggf. schneller ist. Wobei ich mir ffmpeg nicht antun würde, das scheint ja bezüglich Qualitätsmanagement genau so "zuverlässig" zu sein wie ImageMagick ;)


    Ciao Louis

    Ja ich hatte ja vorher ja auch ImageMagick als Scaler. Ich hatte das im besagten Thread auch so gelesen das der Scaler von S:oren schneller sein soll als ImageMagick. Bevor ich mich auf die Suche mache mit einem Thema womit ich mich Null auskenne, wollte ich halt vorher hier mal nachfragen :)
    Aber bisher wäre es ja das einfachste wenn MegaV0lt seinen AMD austauschen würde :P


    Danke für die Antworten & Grüße
    Martin

    Man kann gut die GPU benutzen, aber wer möchte schon die Abhängigkeit haben?


    Ihr solltet mal überlegen, das Laden und Skalieren der Bilder von der Ausgabe zutrennen.
    Also einen eigenen Thread dafür und wenn dann die Bilder bereit stehen, die Ausgabe aktuallisieren.


    Ich weiß nicht wie viele Bilder auf einer Seite sind, aber es dürfte nicht stören wenn nach 1s erst die Bilder kommen.
    Aber es stört wenn 1s nichts passiert.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    Zitat von johns

    Ihr solltet mal überlegen, das Laden und Skalieren der Bilder von der Ausgabe zutrennen.
    Also einen eigenen Thread dafür und wenn dann die Bilder bereit stehen, die Ausgabe aktuallisieren.


    Ich mache das eh schon so ;)


    Ciao Louis

    In meinem Fall waren es ~10 Sekunden, wo nichts passiert. Normal sind so 4-6 Sekunden; abhängig davon wie viele Bilder drin sind. Beim zweiten Aufruf sind es dann "nur" noch 2 Sekunden... Ist der 4850e mit 2,5GHz wirklich so eine Krücke? Ich würde ungern mein Board raus werfen nur wegen der OSD-Performance...


    Die Trennung der Ausgabe hört sich gut an! Ich fürchte nur, das ist sehr viel Aufwand. Einen schnellen scaler in Assembler oder soi kann man nicht einbauen?


    Oder wie wäre es, wenn die Bilder schon von vorn herein auf der Platte in der richtigen Größe vor lägen?

    Zitat von MegaV0lt

    Die Trennung der Ausgabe hört sich gut an! Ich fürchte nur, das ist sehr viel Aufwand.


    Naja, das geht schon. Einfach die Ausgabe der Bilder auf das OSD in einen eigenen Thread packen, das ganze sinnvoll mit Mutexen umgeben, und der Drops ist gelutscht ;)


    Zitat von MegaV0lt

    Einen schnellen scaler in Assembler oder soi kann man nicht einbauen?


    Gehen tut alles...es muss nur jemand machen.


    Zitat von MegaV0lt

    Oder wie wäre es, wenn die Bilder schon von vorn herein auf der Platte in der richtigen Größe vor lägen?


    Das wäre sehr schwierig...ich gehe davon aus, dass skinflatplus auch auf jede beliebige OSD Größe skaliert? Welche Größe sollte man denn dann nehmen? Klar könnte man das fix für 1920 * 1080 ausrechnen, aber dann müsste man das ursprüngliche Bildmaterial auch auf diese Größe skalieren.


    Ciao Louis

    Zitat von louis

    ursprünglich habe ich in nOpacity das Scaling der Bilder direkt per ImageMagick / GraphicsMagick gemacht. Da das insbesondere auf ARM Boxen sehr langsam war und die Qualität auch nicht so berauschend war, habe ich den von S:oren zur Verfügung gestellten nativen Scaler eingebaut. Bei mir ist der schneller und liefert eine bessere Qualität als die ImageMagick Scaler...


    Beim Skalieren werden viele Gleitkommaberechnungen benötigt, ich meine mal gelesen zu haben, dass AMD da im Vergleich zu Intel nicht so performant ist...


    Mein Scaler (genauer der von Niko Meine) benutzt im Gegensatz zu *Magick kein Gleitkomma fuer das eigentliche Skalieren (nur fuer die Berechnung der Filterkoeffizienten), deshalb ist der auf Prozessoren ohne hardfloat sehr viel schneller. Und da der auch noch eine bessere Qualitaet als bei *Magick mit nur ein paar Zeilen Code liefert, ist der in nopacity reingekommen.


    Ich kann mir nicht vorstellen, dass ein Athlon mit diesem reinen Integer-Code im performancerelavanten Teil irgendein Problem haben koennte. Ich schau es mir aber gerne nochmal an, wenn mir jemand einen Testcase gibt (das Bild und die Parameter fuer den Scaler, am besten mit dem Wrappercode zum Laden des Bildes und der Zeitmessung), wo es nicht richtig funktioniert...


    Gruss,
    S:oren

    So ich habe mal schnell etwas zusammengeschrieben, nicht schön aber läuft :)


    Ich habe es so Originalgetreu wie möglich gelassen und nutze deswegen auch cImage und alles aus meinem Skin. Ich habe auch echte actor Images vom tvscraper genommen.


    Zu finden ist das ganze hier http://schirrmacher.eu/scaler_test.tar.gz


    Im Skin haben die Bilder bei einer OSD Auflösung von 1920x1080 eine Breite von ca. 300 Pixel. Dies wird aber im Skin berechnet und kann je nach Einstellung von Rändern etc. um mehrere Pixel abweichen. Beim Testen ist mir etwas interessantes aufgefallen, beim scaling auf 300 Pixel dauert es 1-2ms, beim scaling auf 299 Pixel aber ~30ms. Vermutlich könnte man die Performance schon steigern wenn man die Breite auf-/abrunden würde!?!
    Ich habe deswegen im Testprogram extra die beiden Werte zum scaling genommen.


    so ich bin mal auf eure Werte gespannt.


    Bei mir sieht das ganze dann so aus:


    Grüße Martin

    Hier meins:

    Code
    hdvdr01 scaler_test # cat /proc/cpuinfo | grep "model name"
model name  	: AMD Athlon(tm) Dual Core Processor 4850e
model name  	: AMD Athlon(tm) Dual Core Processor 4850e

    2x2,5GHz


    Hmm da sieht man es ja ganz schön, die 100ms hattest du ja auch bei redmine gepostet. Wahrscheinlich sind durch deine Einstellungen im Skin die Breite der Actor Images "unglücklich" und daher kommen die hohen scaling-Zeiten zustande. Jetzt müsste man noch weiter testen, wo die Besten Ergebnisse zustande kommen, bei Pixel in 100er Schritte, oder reichen 10er Schritte aus? Aber anscheinend kommen wir das Problem näher :)


    Grüße
    Martin

    Interessant...mit 299px scheint sich der Scaler wirklich wesentlich schwerer zu tun als mit 300px. Ist 299 ne Primzahl? Bin ich jetzt zu faul das zu prüfen, könnte nach kurzem check aber sein ;)


    Ciao Louis

    Kann es sein, dass die Bilder schon in 300 Pixel vorliegen und darum der Scaler "schnell" fertig ist? Ein doofer Zufall?


    Ich habe mal das 81er auf 350 Pixel vergrößert:

    Zitat von MegaV0lt

    Kann es sein, dass die Bilder schon in 300 Pixel vorliegen und darum der Scaler "schnell" fertig ist? Ein doofer Zufall?


    Das ist wohl wahr, da sind die Zahlen ein bisschen unglücklich gewählt ;) Aber das ist ja in der main.cpp schnell geändert:


    Code
    loader.LoadFile(file, 300, 999);
        loader.LoadFile(file, 299, 999);


    Ciao Louis

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden