[rpihddevice] OSD mit GPU-Unterstützung und Pixmap-Support

  • Das Problem mit der beschränkten Größe von Pixmaps bei GPU-Beschleunigung ist halt nunmal eben erst jetzt zutage getreten, da kann doch keiner was dafür!


    Und diese Beschränkung gibt es ja auch nur, wenn die GPU-Unterstützung im Setup des rpihddevice eingeschaltet wird (zumindest verstehe ich das so). Wenn sie ausgeschaltet ist und somit die Default-implementierung im cOsd verwendet wird, dann liefert zwar cOsd::MaxPixmapSize() auch 2048x2048 zurück, wer das aber ignoriert kann weiterhin beliebig große Pixmaps anfordern - und bekommt sie auch, wenn genügend Speicher vorhanden ist. Sein Plugin wird dann halt nicht von der GPU-Beschleunigung profitieren können, denn Fakt ist nunmal, daß die GPU nur Pixmaps bis maximal 2048x2048 Pixeln hardware-beschleunigt handhaben kann. Alles, was darüber hinaus ginge und vom Ausgabedevice auf irgend eine dubiose Weise "gekachelt" würde, könnte von der Beschleunigung nicht profitieren. Dann kann man aber die GPU auch gleich ganz abschalten und wieder mit der normalen, halt langsameren Variante arbeiten.


    Klaus

  • Alles, was darüber hinaus ginge und vom Ausgabedevice auf irgend eine dubiose Weise "gekachelt" würde, könnte von der Beschleunigung nicht profitieren. Dann kann man aber die GPU auch gleich ganz abschalten und wieder mit der normalen, halt langsameren Variante arbeiten.


    Sorry, aber das stimmt doch nicht. Wenn das Ausgabeplugin selbst nur Pixmaps kleiner 2048 * 2048 benutzt, warum soll dann die GPU Beschleunigung nicht genutzt werden können?


    Übrigens: wenn dieses "dubiose Kacheln" vom Skin oder sonstigen Plugins gemacht werden würde (was ja genau dein Vorschlag war), wäre das weniger dubios? :D


    Ciao Louis

  • Ja, finde ich schon. Denn diese Lösung wird *immer* funktionieren, auch wenn die virtuelle Zeichenfläche beliebig groß wäre (größer als der vorhandene Speicher).


    Aber ich werde mich da jetzt raushalten und mich sinnvollerer Beschäftigung widmen. Wenn Ihr Thomas davon überzeugen könnt, sich das anzutun und es in seinen GPU-Code einzubauen, soll's mir recht sein. Auf den Core-VDR hat das ja keinerlei Auswirkungen. Die einzige Frage in dem Zusammenhang, die mich betrifft ist, welchen Wert die Default-Implementierung von cOsd::MaxPixmapSize() liefern soll. Ich habe jetzt mal 2048x2048 eingebaut, kann es aber auch auf INT_MAXxINT_MAX setzen, da die Default-Implementierung ja keine Größenbeschränkung hat. Allerdings würde ich es durchaus für sinnvoll halten, auch im Default-Fall nicht davon auszugehen, daß Pixmaps beliebig groß sein können.
    Wobei, streng genommen ist INT_MAXxINT_MAX nicht wirklich sinnvoll, denn eine so große Pixmap *kann* es nicht geben, soviel Speicher hat keiner.


    Klaus

  • Sorry, aber das stimmt doch nicht. Wenn das Ausgabeplugin selbst nur Pixmaps kleiner 2048 * 2048 benutzt, warum soll dann die GPU Beschleunigung nicht genutzt werden können?

    Sinn der GPU-Beschleunigung ist, dass ich die GPU zeichnen lasse. Und dass kann sie nun mal nur auf sog. Surfaces, also Speicherbereiche im RAM der GPU, und die sind auf 2048x2048px beschränkt. Eine solche Surface ist entweder eine Window Surface, also ein Bereich der dem Framebuffer überlagert und angezeigt wird (so wie es das rpihddevice bis anhin gemacht hat) oder aber ein Pixelbuffer, was nichts anderes ist als ein OpenVG-Image, welches ich der GPU als Zeichenfläche unterjuble. Letzteres entspricht genau dem, was das VDR-OSD-API als Pixmap vorsieht, wodurch ich die Zeichenfunktionen in cPixmap praktisch 1:1 anwenden kann. Entweder hat sich Klaus vor dem Entwurf des APIs das OpenVG-Manual gut durchgelesen, oder es entspricht einfach dem üblichen Weg, ein OSD (oder andere 2D-Grafiken) zu abstrahieren...


    Übrigens: wenn dieses "dubiose Kacheln" vom Skin oder sonstigen Plugins gemacht werden würde (was ja genau dein Vorschlag war), wäre das weniger dubios? :D

    Ich verstehe ehrlich gesagt die Aufregung nicht. Das API ist klar definiert, ein OSD erzeugt eine Pixmap nur, wenn es dazu in der Lage ist. Mit der Möglichkeit zur Abfrage der maximal möglichen Dimensionen ist es nun sogar einfacher, das gezielt zu umgehen. Klar ist es einfacher, einen überlangen Text auf eine überlange Pixmap zu zeichnen. Aber wer sich das API genau angeschaut und die Funktionsweise von osddemo begriffen hat, der weiss, wie Klaus das Scrolling vorgesehen hat.


    Und louis, so enorm kompliziert ist es nun auch nicht, scrollbaren Text so zu implementieren, wie es Klaus im osddemo-Plugin vormacht. Jedenfalls wäre es ein vielfaches aufwändiger, in rpihddevice virtuelle, übergrosse Pixmaps zu implementieren, und diese dann auf reale, dynamisch zu allozierende, HW-Pixmaps zu mappen. Und das hat nichts mir "keine Lust" zu tun, sondern mit dem effizienten Umgang von begrenzten Hardware-Ressourcen.


    Und ja, der GPU-Support lässt sich natürlich abschalten, womit auch Pixmaps jenseits von 2048x2048px wie gewohnt funktionieren. Aber halt unbeschleunigt.


    Gruss
    Thomas

  • reufer: beim schnellen Drüberschauen über den entsprechenden Code in rpihddevice glaube ich gesehen zu haben, daß dort kein Fallback für zu große cImages drin ist. Kannst du das bitte verifizieren? Wenn die StoreImageData()-Funktion eines Ausgabedevices ein cImage nicht handhaben kann, dann müsste es das StoreImageData der Basisklasse aufrufen (siehe die entsprechenden Beschreibungen in osd.h).

    Das ist korrekt, ich werde das noch anpassen. Allerdings wird das den Aufruf von StoreImageData() etwas verzögern, da ich erst auf die Antwort vom OVG-Thread warten muss, ob die Allozierung des Speicherbereichs erfolgreich war. Sollte aber an dem Punkt nicht so kritisch sein.


    Ich würde auch vorschlagen, daß CreatePixmap() im rpihddevice für "APIVERSNUM >= 20301" NULL zurückliefert, wenn eine zu große (oder aus sonstigen Gründen nicht realisierbare) Pixmap angefordert wird.

    Werde ich so einbauen. Aber auch hier wird es einen kleinen Moment dauern, bis ich vom OVG-Thread definitiv weiss, ob die gewünschte Pixmap in den verbleibenden GPU-Speicher passt - aber auch hier sollte eine kleine Verzögerung zu verschmerzen sein, das eigentliche Zeichnen erfolgt dann wieder nach dem Prinzip "fire and forget".


    Gruss
    Thomas

  • Was geht hier denn ab?


    Mir ist es eigentlich egal wie das ganze programmiert ist. Ich bin nur Anwender des VDR und seinen Plugins, hauptsächlich gucke ich damit TV und das nicht erst seit gestern!
    Für mich ist wichtig das alles funktioniert. Und mit dem Skinsoppalusikka-plugin ohne GPU-Unterstüzung funzt das Mailbox-plugin und das OSD-Teletext-plugin in für mich akzeptabler Geschwindigkeit.


    Bei diesem Skin erinnere ich mich gern an meine Anfänge mit dem VDR zurück! Komplettpatch 1.2.6_E.diff.bz2 von Andreas Kool.


    Auch damals hieß es immer wieder mal, dies und das geht nicht. Ich bin mir sicher Ihr werdet eine Lösung finden.


    Weiter so!

    FSC Primergy TX 300 S4 | 2 x Intel(R) Xeon(R) CPU X5460 @ 3.16GHz | RAM 16GB | VDR-SERVER | Centos 7 Kernel-4.19.0 | DVBSky S952 v3 & DVBSKy S950 v3 | VDR-2.2.0 | iptv, dummydevice, dvbhddevice, svdrposd, streamdev-server.
    Raspbery Pi 1 Model B + | Debian wheezy Kernel-4.4.50+ | VDR-2.2.0 | epgsearch, remotetimers, skinsoppalusikka, svdrpservice, mailbox, rpihddevice, sleeptimer, osdteletext, streamdev-client
    Raspbery Pi 2 - Model B | Debian jessie Kernel-4.4.50-v7+ | VDR-2.2.0 | epgsearch, remotetimers, skinsoppalusikka, svdrpservice, mailbox, rpihddevice, sleeptimer, osdteletext, streamdev-client


  • Wie von Thomas vorgeschlagen, habe ich mal den Patch für das OSDTeletextplugin überarbeitet. Alle Zeichenoperationen laufen jetzt auf einer (nicht OSD) cBitmap und werden nach Fertigstellen der Teletextseite in einem Schritt per DrawBitmap in die OSD Pixmap geschrieben. Ich hoffe, damit funktioniert es jetzt auf dem Raspi.


    Gruss, kanadakruemel

  • Guten Morgen kanadakruemel

    Wie von Thomas vorgeschlagen, habe ich mal den Patch für das OSDTeletextplugin überarbeitet. Alle Zeichenoperationen laufen jetzt auf einer (nicht OSD) cBitmap und werden nach Fertigstellen der Teletextseite in einem Schritt per DrawBitmap in die OSD Pixmap geschrieben. Ich hoffe, damit funktioniert es jetzt auf dem Raspi.


    Danke für den Patch - funktioniert bei mir, auch auf dem Raspi. Trotzdem zwei Anmerkungen:


    - Den Umweg über die Pixmap kannst du dir sparen und stattdessen das Bitmap mit cOsd::DrawBitmap() direkt aufs OSD zeichnen.
    - Das Plugin würde auf dem Raspi deutlich schneller funktionieren, wenn das OSD das Skalieren übernimmt. Seit vdr-2.1.7 gibt es die Funktion cOsd::DrawScaledBitmap(), womit man diese Aufgabe an die OSD-Implementation delegieren kann. Beim Raspi übernimmt das die GPU, was nicht nur schön ausschaut, sonder auch die CPU entlastet. Ausserdem bräuchte das osdteletext-Plugin so auch keine 2 Millionen Pixel (bei einem Full-HD-OSD) einzeln auf ein Bitmap zu zeichnen, sondern nur die originalen 480x250px (wenn ich richtig gerechnet habe) des Teletexts.


    Gruss
    Thomas

  • Mit 256MB funktionieren aber die mitgelieferten Skins von skindesigner zuverlässig und dank GPU-Beschleunigung selbst auf dem alten Raspberry Pi recht flott.


    Ich hab meinen RasPi-B sogar aktuell immernoch auf 128MB RAM stehen und mit skinnopacity läufts absolut rund und Fehlerfrei :)

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;) *


    vectra --- glasslike ---

  • Hi,


    ich habe das Plugin nun auch mal auf dem RPI2 installiert. Mein Setup:
    - Raspbian
    - neuestes rpihddevice Plugin aus dem git
    - neuestes skindesigner Plugin aus dem git
    - neueste RPI2 Firmware mittels rpi-update ist installiert
    - In /boot/config.txt habe ich gpu_mem = 256 eingetragen.


    Leider bekomme ich bei mir die Hardwarebeschleunigung nicht zum Laufen. Wenn ich die Setup-Option aktiviere stürzt VDR ab, startet neu und stürzt direkt nach dem Start wieder ab. Im Log kann ich nichts Auffälliges sehen. :(
    Mit deaktivierter Hardwarebeschleunigung läuft VDR auch mit skindesigner-Skin stabil.
    EDIT: Die VDR-Standardskins laufen allerdings mit der Hardwarebeschleunigung.


    Gruß maz


    P.S.: Vielen Dank für die großartige Arbeit.

    Meine VDRs:
    >>>Mac mini 2010 mit 2x Sundtek SkyTV Ultimate III, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>ZOTAC D2550 ITX-WIFI Supreme mit DD Cine S2, Gehäuse OrigenAE M10, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>Raspberry Pi
    2 mit Sundtek SkyTV Ultimate IV, raspbian, rpihddevice-Plugin, Logitech Harmony 200<<<

    2 Mal editiert, zuletzt von maz ()

  • Hi maz

    Wenn ich die Setup-Option aktiviere stürzt VDR ab, startet neu und stürzt direkt nach dem Start wieder ab. Im Log kann ich nichts Auffälliges sehen.

    Wenn im Log nichts steht, wäre ein backtrace natürlich enorm hilfreich.


    Bis auf den Unterschied, dass ich skidesigner-0.2.2 und Gentoo nutze, läuft bei mir das selbe und das eigentlich ohne Probleme.


    Gruss
    Thomas

  • Hallo,


    bei mir läuft unter Raspian die OSD-Beschleunigung auch überhaupt nicht. Zuvor ging mit Aktivierung der GPU-Beschleunigung einfach kein OSD mehr bei etwas umfangreicheren Skins. Mit der Version von heute stürzt VDR komplett ohne weitere Meldung ab (auch bei default skin und zusätzlich lediglich geladenem streamdev-client).


    syslog:

    Code
    Mar 14 19:49:28 rpi vdr: [2550] rpihddevice: video stream started 1280x720@50p
    Mar 14 19:49:38 rpi vdr: [2540] skinflatplus: create osd SUCCESS left: 63 top: 37 width: 1774 height: 994
    Mar 14 19:49:39 rpi vdr: [2553] rpihddevice: [EGL] failed to create pixel buffer surface: bad alloc!
    Mar 14 19:49:39 rpi vdr: [2540] rpihddevice: [OpenVG] failed to allocate pixmap buffer!
    Mar 14 19:49:39 rpi lircd-0.9.0-pre1[385]: removed client


    Kann es an einer anderen - oder gar falsch kompilierten - OpenVG Version von Raspbian liegen?



    Was nämlich seltsam ist: hier steht rpi1 - bei Raspbian für den rpi2!

    yaVDR 0.5 Server: Satix S2 Dual, Technisat DVB-T
    yaVDR 0.5 Client: POV ION-MB330
    yaVDR 0.3 Client: S100 mit Scart-Out
    Raspberry 2 Clients

  • bei mir läuft unter Raspian die OSD-Beschleunigung auch überhaupt nicht. Zuvor ging mit Aktivierung der GPU-Beschleunigung einfach kein OSD mehr bei etwas umfangreicheren Skins. Mit der Version von heute stürzt VDR komplett ohne weitere Meldung ab (auch bei default skin und zusätzlich lediglich geladenem streamdev-client).

    Dem Plugin geht aus irgend einem Grund der GPU-Speicher aus und liefert beim Kreieren einer Pixmap wahrscheinlich einen NULL-Pointer zurück, der vom Skin nicht abgefangen wird.


    Kann es an einer anderen - oder gar falsch kompilierten - OpenVG Version von Raspbian liegen?

    Die brauchst du nicht, die benötigten Bibliotheken werden von den Userland-Libs des Raspberry Pi's unter /opt/vc zur Verfügung gestellt. Jene libs die du meinst, werden wahrscheinlich GPU-Beschleunigung für das ganze X-Zeugs beinhalten.


    Gruss
    Thomas

  • Danke Thomas.


    Das mit dem fehlenden GPU-Speicher stimmt wohl. Interessant ist nämlich auch, dass ich, nachdem es bei umfangreicheren Skins nicht ging und ich auf default skin stelle, folgende Meldung (mit Absturz von VDR) gibt:


    Code
    Mar 14 20:31:44 rpi vdr: [2737] rpihddevice: OmxError(InsufficientResources)
    Mar 14 20:31:44 rpi vdr: [2737] rpihddevice: OmxError(InsufficientResources)
    Mar 14 20:31:44 rpi vdr: [2737] rpihddevice: OmxError(InsufficientResources)
    Mar 14 20:31:44 rpi rsyslogd-2177: imuxsock begins to drop messages from pid 2728 due to rate-limiting
    Mar 14 20:31:47 rpi lircd-0.9.0-pre1[385]: removed client


    Nach einem Neustart funktioniert es aber wenigstens ohne diese Fehlermeldung mit dem default skin. Offenbar wird also der GPU Speicher nicht mehr freigegeben?


    [edit]]


    Was auch noch interessant ist: es reicht, dass irgend ein skin-plugin mit geladen wird, um VDR zum Absturz zu bringen, selbst wenn nur der default skin ausgewählt ist!

    yaVDR 0.5 Server: Satix S2 Dual, Technisat DVB-T
    yaVDR 0.5 Client: POV ION-MB330
    yaVDR 0.3 Client: S100 mit Scart-Out
    Raspberry 2 Clients

    Einmal editiert, zuletzt von scovery ()

  • Nach einem Neustart funktioniert es aber wenigstens ohne diese Fehlermeldung mit dem default skin. Offenbar wird also der GPU Speicher nicht mehr freigegeben?

    Ja, wenn der VDR crasht, hat das rpihddevice-Plugin keine Gelegenheit mehr, den GPU-Speicher freizugeben und dieser bleibt reserviert...


    Was auch noch interessant ist: es reicht, dass irgend ein skin-plugin mit geladen wird, um VDR zum Absturz zu bringen, selbst wenn nur der default skin ausgewählt ist!

    Das kann ich so nicht bestätigen. Ich lade (und benutze) nebst den Standardskins auch skinenigmang und skindesigner (0.2.2).


    Gruss
    Thomas

  • Die Komplett-Abstürze kamen erst mit dem letzten Patch.


    Eigentlich war ich mir sicher, dass ich in der config.txt gpu_mem=256 hatte, irgendwie waren dort wieder 128 MB rein geraten. Mit 256 MB sieht's jetzt etwas besser aus, VDR läuft jetzt mit GPU-Beschleunigung zumindest eine Weile, dann aber wieder der gleiche Fehler.


    An fehlendem GPU-Speicher liegt es nicht! Siehe folgendes Tool:


    https://github.com/MilhouseVH/bcmstat


    Mit Option f bzw. g bekomme ich mit laufendem VDR nicht unter 135MB freien GPU Speicher angezeigt!


    Nach einem Absturz von VDR geht wieder nichts mehr (freier GPU-Speicher 196MB), VDR Neustart scheitert (freier GPU-Speicher nur noch 169MB), erneuter Neustart-Versuch (freier GPU-Speicher 139MB, eine Sekunde später 172MB - VDR läuft wieder!)


    HIer mal ein Schnippsel vom Moment, an dem sich der VDR wieder mal beim OSD verabschiedet hat (nach Absturz freier GPU Speicher rauf auf 201MB):


    yaVDR 0.5 Server: Satix S2 Dual, Technisat DVB-T
    yaVDR 0.5 Client: POV ION-MB330
    yaVDR 0.3 Client: S100 mit Scart-Out
    Raspberry 2 Clients

  • Mit 256 MB sieht's jetzt etwas besser aus, VDR läuft jetzt mit GPU-Beschleunigung zumindest eine Weile, dann aber wieder der gleiche Fehler.

    Kannst du etwas konkreter werden? Wann genau passiert der Absturz und mit welchem Skin? Und ohne Logs bzw. Backtrace läuft das alles auf heiteres Rätselraten raus…


    Nach einem Absturz von VDR geht wieder nichts mehr (freier GPU-Speicher 196MB), VDR Neustart scheitert (freier GPU-Speicher nur noch 169MB), erneuter Neustart-Versuch (freier GPU-Speicher 139MB, eine Sekunde später 172MB - VDR läuft wieder!)

    Wie schon geschrieben, nach einem Absturz ist der GPU-Speicher vom rpihddevice nicht freigegeben, da hilft nur ein Reboot. Alles andere kann, muss aber nicht funktionieren.


    Gruss
    Thomas

  • Immerhin bin ich beruhigt, dass ich nicht der Einzige mit dem Problem bin. Im Moment habe ich wieder auf das alte nopacity-Skin umgestellt, was aber doch etwas zäh läuft.
    Ich versuche mal VDR nach einem frischen reboot mit GPU-Beschleunigung zu starten.


    Gruß maz

    Meine VDRs:
    >>>Mac mini 2010 mit 2x Sundtek SkyTV Ultimate III, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>ZOTAC D2550 ITX-WIFI Supreme mit DD Cine S2, Gehäuse OrigenAE M10, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>Raspberry Pi
    2 mit Sundtek SkyTV Ultimate IV, raspbian, rpihddevice-Plugin, Logitech Harmony 200<<<

  • Hallo Reufer,


    Ja, wenn der VDR crasht, hat das rpihddevice-Plugin keine Gelegenheit mehr, den GPU-Speicher freizugeben und dieser bleibt reserviert...


    Könnte man da ein Tool schreiben, was generell allozierten Speicher von bspw. rpihddevice in der GPU frei gibt, oder kommt man da nach dem Beenden des VDR nicht mehr dran? Das wäre viel angenehmer als nach einem Absturz booten zu müssen. Man könnte das dann sogar im Start-Skript des vdr zur Sicherheit hinter den VDR-Aufruf schreiben. Damit wäre beim Beenden des VDR sichergestellt, dass die GPU den Speicher wieder frei hat.


    Viele Grüße


    Tim

Jetzt mitmachen!

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