[rpihddevice] OSD mit GPU-Unterstützung

    Hallo zusammen


    Ich habe dem rpihddevice ein High-Level-OSD spendiert womit nun auch das OSD von der GPU profitieren kann - besonders bei Full-HD reagiert der VDR nun sofort und muss nicht erst das OSD "von Hand" rendern und anschliessend Pixel für Pixel kopieren...


    Die Änderungen stehen in Git zum Ausprobieren bereit - falls jemand Zeit und Lust hat zu testen, sind Rückmeldungen sehr willkommen!


    Die GPU-Unterstützung lässt sich im Plugin-Setup deaktivieren, standardmässig ist diese eingeschaltet. Beim erstmaligen Anzeigen eines Fonts vergeht übrigens ein kurzer Moment, bis der Truetype-Font in OpenVG-Pfade konvertiert wurde.


    Gruss
    Thomas

    Ungetestet sage ich schonmal im vorraus VIELEN DANK.


    Schön das es beim RasPi bis jetzt noch nicht zum Stillstand kommt. Ich mag das Teil einfach :D


    Gruß Patrick

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;) *


    vectra --- glasslike ---

    Zitat von binduli

    konnte aber in Verbindung mit skindesigner noch keine Performance-Verbesserung feststellen


    Ich habe mir kurz den skindesigner angeschaut: Dieser arbeitet mit Pixmaps, die wiederum vom VDR gerendert und dann vom Plugin als Bild dargestellt werden... daher auch keine Veränderung zusammen mit skindesigner.


    Das rpihddevice implementiert aktuell die Methoden von cOsd, so wie z.B. auch das dvbhddevice. Dass auch Plugins Pixmaps nutzen dürfen, daran habe ich gar nicht gedacht - wäre aber beim aufmerksamen Lesen von vdr/osd.h klar ersichtlich gewesen.


    Hmm, mal schauen, wie sich das umsetzen liesse...


    Gruss
    Thomas

    Moin,

    Zitat von reufer

    Ich habe mir kurz den skindesigner angeschaut: Dieser arbeitet mit Pixmaps, die wiederum vom VDR gerendert und dann vom Plugin als Bild dargestellt werden...


    hm, ganz so ist es nicht...Skindesigner fordert vom VDR einen Pointer auf das OSD an, darüber können dann Pixmaps erzeugt werden, auf denen gemalt wird. Die Ausgabe der Pixmaps wird dann wieder vom VDR übernommen. So macht das eigentlich jedes Skin Plugin, das true color unterstützt...anders geht das nicht (nach meinem Verständnis zumindest ;) ).


    Ciao Louis

    Ich hab mir eben mal deine Änderungen angesehen...kann es sein, dass du nur Bitmaps per GPU unterstützt? "Moderne" Skins bzw. Plugins, die selbst zeichnen, benutzen keine Bitmaps mehr, sondern Pixmaps. Aber ich denke, das hast das ja schon selbst gesehen.


    Ciao Louis

    Hallo, ist das normal, dass er die Fonts ständig neu lädt, wenn man sich durch das Menü bewegt? Er ist dadurch mit aktiver GPU-Unterstützung recht langsam und scheint dann nach einiger Zeit in ein Ressourcen-Limit zu laufen. Mein Raspberry Pi B mit 256/256 Memory Split läuft unter Arch Linux mit dem STTNG-Skin des VDR an einem Monitor mit 1280x1024


    Gebaut wurde das Plugin mit gcc 4.9.2

    Beim Bauen ist mir diese Warnung aufgefallen:

    Code
    g++ -march=armv6 -mfloat-abi=hard -mfpu=vfp -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -g -fvar-tracking-assignments -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -c -DPLUGIN_NAME_I18N='"rpihddevice"' -DHAVE_LIBOPENMAX=2 -DOMX -DOMX_SKIP64BIT -DUSE_EXTERNAL_OMX -DHAVE_LIBBCM_HOST -DUSE_EXTERNAL_LIBBCM_HOST -DUSE_VCHIQ_ARM -Wno-psabi -Wno-write-strings -fpermissive -DHAVE_LIBSWRESAMPLE -Iilclient -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads  -I/opt/vc/include/interface/vmcs_host/linux    -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz  -o display.o display.c
display.c: In statischer Elementfunktion »static cRpiDisplay* cRpiDisplay::GetInstance()«:
display.c:47:11: Warnung: »false« wird in Zeigertyp »cRpiDisplay*« umgewandelt [-Wconversion-null]
    return false;
           ^

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Hi Louis

    Zitat von louis

    hm, ganz so ist es nicht...Skindesigner fordert vom VDR einen Pointer auf das OSD an, darüber können dann Pixmaps erzeugt werden, auf denen gemalt wird. Die Ausgabe der Pixmaps wird dann wieder vom VDR übernommen. So macht das eigentlich jedes Skin Plugin, das true color unterstützt...anders geht das nicht (nach meinem Verständnis zumindest ;) ).

    Das stimmt schon - die Aussage war jetzt auf das rpihddevice-Plugin bezogen. Die OSD-Implementation von rpihddevice müsste nun bei CreatePixmap() eine eigene, GPU-unterstützte Implementation zurück liefern, und diese dann beim Flushen entsprechend rendern. Sollte eigentlich mit der vorhandenen Infrastruktur machbar sein... *kopfkratz*


    Zitat von louis

    Ich hab mir eben mal deine Änderungen angesehen...kann es sein, dass du nur Bitmaps per GPU unterstützt? "Moderne" Skins bzw. Plugins, die selbst zeichnen, benutzen keine Bitmaps mehr, sondern Pixmaps. Aber ich denke, das hast das ja schon selbst gesehen.

    Nein, Bitmaps werden nach wie vor bloss kopiert. Das Plugin unterstützt aber nun die Zeichnen-Funktionen von cOsd.


    Gruss
    Thomas

    Zitat von seahawk1986

    Beim Bauen ist mir diese Warnung aufgefallen:

    Code
    g++ -march=armv6 -mfloat-abi=hard -mfpu=vfp -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -g -fvar-tracking-assignments -O3 -fPIC 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -c 
-DPLUGIN_NAME_I18N='"rpihddevice"' -DHAVE_LIBOPENMAX=2 -DOMX -DOMX_SKIP64BIT -DUSE_EXTERNAL_OMX -DHAVE_LIBBCM_HOST -DUSE_EXTERNAL_LIBBCM_HOST -DUSE_VCHIQ_ARM -Wno-psabi -Wno-write-strings -fpermissive -DHAVE_LIBSWRESAMPLE -Iilclient -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads  -I/opt/vc/include/interface/vmcs_host/linux    -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz  -o display.o display.c
display.c: In statischer Elementfunktion »static cRpiDisplay* cRpiDisplay::GetInstance()«:
display.c:47:11: Warnung: »false« wird in Zeigertyp »cRpiDisplay*« umgewandelt [-Wconversion-null]
    return false;
           ^

    Danke für den Hinweis!


    Zitat von seahawk1986

    Hallo, ist das normal, dass er die Fonts ständig neu lädt, wenn man sich durch das Menü bewegt? Er ist dadurch mit aktiver GPU-Unterstützung recht langsam und scheint dann nach einiger Zeit in ein Ressourcen-Limit zu laufen. Mein Raspberry Pi B mit 256/256 Memory Split läuft unter Arch Linux mit dem STTNG-Skin des VDR an einem Monitor mit 1280x1024

    Das kommt vor, wenn OpenVG der Speicher ausgeht - dann löscht das Plugin die bereits geladenen Fonst und konvertiert den gewünschten neu. Wie viele verschiedene Fonts braucht denn dein Skin?


    Gruss
    Thomas

    Zitat von reufer

    Wie viele verschiedene Fonts braucht denn dein Skin?

    STTNG unterstützt soweit ich weiß maximal drei Fonts, bei mir ist die Voreinstellung des VDR aktiv:

    Code
    FontFix = Courier:Bold
FontFixSize = 31
FontFixSizeP = 0.030000
FontOsd = Sans Serif:Bold
FontOsdSize = 32
FontOsdSizeP = 0.031000
FontSml = Sans Serif
FontSmlSize = 29
FontSmlSizeP = 0.028000

    Kann man sich die freien Ressourcen von OpenVG irgendwie anzeigen lassen?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von reufer

    Das Plugin unterstützt aber nun die Zeichnen-Funktionen von cOsd.


    Soweit ich das aus der Erinnerung sagen kann sind die Zeichenfunktionen von cOsd und cPixmap fast gleich. Das soll nicht heißen das du keinen Aufwand hast aber ich denke der sollte sich in grenzen halten mit viel copy&paste :) Zumindest stell ich mir das gerade so vor.


    Grüße
    Martin

    Zitat von _Martin_

    Soweit ich das aus der Erinnerung sagen kann sind die Zeichenfunktionen von cOsd und cPixmap fast gleich. Das soll nicht heißen das du keinen Aufwand hast aber ich denke der sollte sich in grenzen halten mit viel copy&paste :) Zumindest stell ich mir das gerade so vor.

    Wenn man nur Truecolor-OSDs abdecken würde, wäre es sogar nur ein Verschieben... die Funktionen von cOsd im VDR rufen ja auch nur die entsprechenden Pixmap-Funktionen auf.


    Gruss
    Thomas

    Naja soweit ich das weiß nutzen die VDR-Core-Skins keine Pixmaps sondern die cOsd-Funktionen und es gibt ja auch noch genug "alte" Skins die keine Pixmaps verwenden. Die "neuen" Skins wie nopacity, flatPlus, skindesigner nutzen aber ausschließlich Pixmaps.


    Grüße
    Martin

    Zitat von _Martin_

    Naja soweit ich das weiß nutzen die VDR-Core-Skins keine Pixmaps sondern die cOsd-Funktionen


    Das ist richtig. Wobei cOsd in diesem Fall einfach implizit eine einzelne cPixmap benutzt. Wenn ein Device cPixmap implementiert, dann sollten automatisch auch die direkten cOsd-Zeichenfunktionen funktionieren.
    Die Standard-Skins benötigen nicht mehrere cPixmaps, daher benutzen sie einfach direkt die cOsd-Zeichenfunktionen.


    Klaus

    Zitat von kls

    Wenn ein Device cPixmap implementiert, dann sollten automatisch auch die direkten cOsd-Zeichenfunktionen funktionieren.


    Was aber dann nur für Truecolor-Skins funktioniert. So wie ich das verstehe, muss ich entweder auch die Funktionen in cOsd neu schreiben, oder eine eigene cBitmap implementieren, wenn mein lieb gewonnener EnigmaNG funktionieren soll... oder übersehe ich da was?


    Gruss
    Thomas

    Zitat von reufer


    Was aber dann nur für Truecolor-Skins funktioniert. So wie ich das verstehe, muss ich entweder auch die Funktionen in cOsd neu schreiben, oder eine eigene cBitmap implementieren, wenn mein lieb gewonnener EnigmaNG funktionieren soll... oder übersehe ich da was?


    Wenn du die Funktionen von cOsd überschreibst, dann musst du dich da wohl selber drum kümmern.
    Du kannst aber natürlich im "low level" Fall einfach die jeweilige Funktion der cOsd-Basisklasse aufrufen.
    Ich habe mir deinen neuen Code aus Zeitgründen noch nicht anschauen können, daher kann ich im Detail leider noch nichts dazu sagen. Ich finde es aber toll, daß du das anpackst.


    Klaus

    Zitat von kls

    Wenn du die Funktionen von cOsd überschreibst, dann musst du dich da wohl selber drum kümmern.
    Du kannst aber natürlich im "low level" Fall einfach die jeweilige Funktion der cOsd-Basisklasse aufrufen.

    Ich weiss nicht, ob ich dich richtig verstehe. Ich werde nun als nächstes meine Zeichenroutinen vom OSD in eine eigene Pixmap-Klasse verschieben. Damit sollten dann alle neuen Skins, inklusive LCARS, von der GPU profitieren können. Alte Skins werden davon nichts mitkriegen, da für diese statt einer Pixmap ein Bitmap erstellt und vom VDR gerendert wird.


    Die Frage ist nun, wie kann ich alte Skins (wie z.B. EnigmaNG) beschleunigen. Meine Idee war - analog der Pixmap - die Bitmaps neu zu implementieren und die OSD-Methoden lassen wie sie sind. Allerdings habe ich nun gesehen, dass beispielsweise EnigmaNG via cOsd::GetBitmap() direkt auf die Pixel zugreift, was sich natürlich mit meiner GPU-Lösung beisst.


    Alles in allem habe ich nun den Eindruck, dass ein High-Level-OSD nur für True-Color-OSDs mit vernünftigem Aufwand realisierbar ist. Teilt jemand diese Auffassung?


    Zitat von kls

    Ich habe mir deinen neuen Code aus Zeitgründen noch nicht anschauen können, daher kann ich im Detail leider noch nichts dazu sagen.

    Kein Problem - ich bin auch später noch dankbar für dein Feedback! ;)


    Ich habe gestern Abend übrigens noch zwei Probleme entdeckt:
    - Save/RestoreRegion funktioniert nicht - obwohl ich das mal erfolgreich getestet habe...
    - Bei LCARS ist beim erstmaligen Anzeigen der Kanalinfo der Hintergrund nicht komplett eingefärbt. Da ich meistens ohne Video teste, ist mir das bisher nicht aufgefallen…


    Gruss
    Thomas

    Zitat von reufer

    Ich werde nun als nächstes meine Zeichenroutinen vom OSD in eine eigene Pixmap-Klasse verschieben. Damit sollten dann alle neuen Skins, inklusive LCARS, von der GPU profitieren können. Alte Skins werden davon nichts mitkriegen, da für diese statt einer Pixmap ein Bitmap erstellt und vom VDR gerendert wird.


    Das ist auf jeden Fall mal der richtige Ansatz.
    cPixmap ist so konzipiert, daß davon nichts "zurückgelesen" werden kann und es auf schneller Hardware beliebig implementiert werden kann.
    Falls jemand auf Pixelebene arbeiten möchte, ist dafür cImage vorgesehen. Auch dafür sind Mechanismen vorgesehen, mit denen ein mehrfach verwendetes cImage nur einmal auf die Hardware übertragen werden muß und dann beliebig verwendet werden kann.


    Zitat


    Die Frage ist nun, wie kann ich alte Skins (wie z.B. EnigmaNG) beschleunigen.


    Dafür bliebe nur der Weg, die cOsd-Funktionen zu überschreiben und im Falle von "low level OSD" eigene Funktionen aufzurufen, die mit cBitmaps arbeiten.


    Zitat


    Meine Idee war - analog der Pixmap - die Bitmaps neu zu implementieren und die OSD-Methoden lassen wie sie sind. Allerdings habe ich nun gesehen, dass beispielsweise EnigmaNG via cOsd::GetBitmap() direkt auf die Pixel zugreift, was sich natürlich mit meiner GPU-Lösung beisst.


    Die cBitmap ist nicht so ausgelegt, daß sie von einem Plugin neu implementiert werden kann.


    Zitat


    Alles in allem habe ich nun den Eindruck, dass ein High-Level-OSD nur für True-Color-OSDs mit vernünftigem Aufwand realisierbar ist. Teilt jemand diese Auffassung?


    Nun, das dvbhddevice implementiert das High-Level-OSD für "normale" Auflösungen bis 8bpp (leider nicht für 32bpp - das kam in VDR ja erst später).
    Es sollte also durchaus möglich sein, wenn du die cOsd-Funktionen entsprechend überschreibst. Lediglich cOsd::GetBitmap() dürfte damit nicht funktionieren, da du damit ja das gleiche Problem hättest wie mit cPixmap, nämlich die Daten, die irgendwo in der "schnellen Hardware" liegen, wieder zurücklesen zu müssen. Ich würde sogar soweit gehen zu sagen, daß cOsd::GetBitmap() "obsolete" ist und nicht mehr verwendet werden sollte. Skins, die diese Funktion unbedingt brauchen laufen dann halt nur im "VDR-Low-Level-Mode", für den das Device-OSD nur die aller notwendigsten Funktionen wie cOsd::Flush() zu implementieren braucht. Solche Skins sollten langfristig so umgebaut werden, daß sie eben cOsd::GetBitmap() nicht mehr benötigen.


    Klaus

    Hallo Thomas,


    ich hab den GPU Support mal mit dem LCARS-Skinn ausprobiert und bin sowas von begeistert, dass ich die Version gleich produktiv gesetzt habe, auch wenn es noch Refresh-Probleme gibt. Das Scrollen im Aufnahme-Menu (Extrec-Plugin) beispielsweise, ist sowas von pfeilschnell, cool.


    Thx für dieses neue tolle Feature. :tup

    SAT Hardware: Gibertini SE75 | DuraSat Dur-Line UK-24 | DD OctopusNET V2 Rack (Firmware 1.1.6) mit MaxS8
    Server: Asus M5A78L-M/USB3 | Sempron 145@2Cores | 8GB ECC RAM | PicoPSU | Debian Stretch 64Bit | VDR 2.4.5 mit SAT>IP, epgsearch, live, markad
    Clients: RaspberryPI 2/3 | Yocto Poky Linux (Openembedded) 3.2+git | Linux Kernel 5.4.72 | VDR 2.4.5 mit SAT>IP, RpiHDDevice, SkinDesigner, Remote, Extrecmenu, Femon, Mlist


    R.I.P: Gigaset M740 mit VDR von open7x0.org

    Zitat von seahawk1986

    STTNG unterstützt soweit ich weiß maximal drei Fonts, bei mir ist die Voreinstellung des VDR aktiv:

    Ich hab's extra noch mal getestet, aber STTNG funktioniert bei mir problemlos. Die entsprechenden Fonts werden übrigens erst geladen, wenn sie auch angezeigt werden sollen - fürs normale Menü sollte also einer reichen.


    Zitat von seahawk1986

    Kann man sich die freien Ressourcen von OpenVG irgendwie anzeigen lassen?

    Nicht das ich wüsste. Aber hast du mal versucht, der GPU mehr Speicher zuzuweisen? Oder hast du noch XBMC/omxplayer aktiv?


    Gruss
    Thomas

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden