[softhddevice-drm]

  • Bitte nicht zu früh freuen. Noch ist es nicht alltagstauglich und mit der Performance bin ich auch noch nicht zufrieden.

    Gruß Andreas

  • zillerbaer Wenn du nichts dagegen hast, würde ich mit https://github.com/rellla/soft…nglosd/tree/drm-atomic-v2 einen MR auf dein Repo stellen.

    Ich habe drm-seitig ein paar Dinge umgeschrieben, die es mir leichter machen das GL-OSD einzubauen. Außerdem habe ich drmModeSetPlane entfernt und in den atomic commit eingeschlossen.

    Ich kann den MR auch gleich stellen und bekomm danach mein Feedback ;)


    Hier auf meinem H3 kann ich keine Probleme festellen - nachdem ich den Deinterlacer abgestellt habe, Aber dessen Probleme liegen glaub ich daran, dass Kernel und FFMpeg nicht zusammenpassen ... Bin da grad am werkeln. Vielleicht kannst du es ja mal testen.


    Als nächstes würde ich dann das OpenGL OSD einbauen.


    Gruß

    Andreas

  • https://lists.freedesktop.org/…/2021-January/293185.html


    Der LE Patch für zpos scheint darauf zu warten, in den Kernel zu wandern. Ich denke, da musst du dir erstmal keine Gedanken machen.

  • Das verstehe ich nicht! Erst wird es aus allen Treibern rausgeschmissen und jetzt will sunxi das wieder einführen?


    Was Deinen Code betrifft, neuer Code sollte sich in den bestehenden einpassen. Nicht den bestehenden funktionierenden Code so grossflächig umschreiben. Ist das notwendig? Ohne alles verstanden zu haben würde ich das so nicht akzeptieren. Welcher branch funktioniert jetzt?

  • Das verstehe ich nicht! Erst wird es aus allen Treibern rausgeschmissen und jetzt will sunxi das wieder einführen?

    Frag mich nicht, ich habe es nur so gefunden und für mich sieht es so aus, als sollte das in den Kernel wandern. Hast du ein Beispiel, wo es herausgenommen wurde?

    Was Deinen Code betrifft, neuer Code sollte sich in den bestehenden einpassen. Nicht den bestehenden funktionierenden Code so grossflächig umschreiben. Ist das notwendig?

    Naja, 2a9cb04 habe ich voran gestellt, damit ich das nicht immer erst später mitziehen muss. openglosd.cpp benötigt später das VideoRender, daher habe ich es in die Header-Datei geschoben, wo es m.E. dann auch hingehört, wenn 2 darauf zugreifen.

    a363191, c164f4d, 734ff7f und 3f3c759 schreiben die bestehenden SetPropertyRequest Wrapper etwas um bzw. es werden neue hinzugefügt. Ich finds lesbarer, die brauchts aber nicht.

    528725b wandelt drmModeSetPlane() in einen drmModeAtomicCommit() um, in frame2display() und VideoInit() nutzt du ja auch bereits die atomic Variante, daher ist das nur konsequent. Laut dri-devel irc sollte man auch nach Möglichkeit auf drmModeSetPlane verzichten und auf atomic übergehen.

    47b80ad trennt ChangePlanes auf, und extrahiert quasi die SetPropertyRequest Befehle, da im letzten Commit in frame2display nur die properties gesetzt werden und der eigentliche Commit zusammen mit dem für das Videoframe stattfindet.


    VideoOsdDrawARGB und VideoOscClear schreiben nur auf den Buffer und schalten render->OsdShown entweder aus oder ein. So sollte es eigentlich auch sein, das Darstellen sollte wer anderes übernehmen. Der eigentliche (und einzige) drmCommit findet dann nämlich in frame2display statt - was m.E. durchaus Sinn macht.

    Ohne alles verstanden zu haben würde ich das so nicht akzeptieren.

    Ist ja dein gutes Recht, ist ja auch dein Branch und dein Code. Freuen würds mich trotzdem, wenn du auch einen Sinn in den Änderungen siehst, zumindest in den wesentlichen. Ich brauche eine Basis für das GL OSD, ohne dass ich bei den Rebases ständig die Konflikte auflösen muss.

    Welcher branch funktioniert jetzt?

    https://github.com/rellla/soft…nglosd/tree/drm-atomic-v2


    Zumindest bei mir auf H3 ohne Deinterlacer. Aber der sollte ein anderes Problem haben (kernel/ffmpeg)


    Gruß

    Andreas

    The post was edited 1 time, last by rell ().

  • Kommando zurück... da hab ich noch was vergessen zu pushen. Kompiliert nicht...


    EDIT: Jetzt sollts gehen.

    The post was edited 1 time, last by rell ().

  • zillerbaer  Hier wäre ein erster Versuch, das OSD mit OpenGL einzubinden, allerdings muss ich es noch in Live testen. Kompiliert bisher und scheint zu laufen, ob es korrekt angezeigt wird, muss ich prüfen.

    Das setzt auf den anderen Commits auf, hat aber ein paar angepasste Pfade im Makefile, damit es zu meiner Umgebung passt. Das Makefile muss noch aufgeräumt werden, das ist ziemlich wild. Nimms als Zwischeninfo und für den Fall, dass du es testen möchstest (mit etwas Bastelei).


    Das Zusammenbauen des OSD selbst läuft hier gefühlt sehr langsam, da weiß ich noch nicht, woran das liegt. Ich vermute an der niedrigen Taktung der GPU...


    Gruß

    Andreas

  • Bring das erstmal richtig zum laufen! Du kannst dazu auf Deinem jetzigen Stand bleiben. Neu dazu gekommen ist nur Raspi4 Zeugs. AW H3 betrifft das nicht. Ich schreib softhddevice-drm jetzt nicht um oder integriere Patches ohne zu wissen das das auch Mehrwert hat. OSD GL sollte schon spürbar schneller sein als die aktuelle Implementierung.

  • zillerbaer

    Was ist der Hintergrund hinter use_zpos? Korrigier mich, wenn ich es falsch verstehe:


    use_zpos wird gesetzt, wenn das NV12 plane das OVERLAY_PLANE ist und das ARGB plane das PRIMARY_PLANE ist, also standardmäßig OSD unter VIDEO liegt.

    In VideoOsdDrawArgb wird das dann getauscht und in VideoOsdClear wieder zurückgetauscht.

    In OsdDrawArgb wird zusätzlich das plane mit memcpy beschrieben, in OsdClear mit memset auf 0 gesetzt.

    Warum ist das Löschen mit memset notwendig, wenn das OSD eh wieder unter das VIDEO gelegt wird und nicht sichtbar ist?


    Falls NV12 bereits unten liegt, wird use_zpos nicht gesetzt, ChangePlanes wird dann auch nicht ausgeführt. Beide Male (OsdDrawArgb und OsdClear) setzen mit drmModeSetPlane die Properties. Diese werden in OsdClear so gesetzt, dass die SRC* Properties auf 0 gesetzt werden. Bewirkt das, dass das Plane "geschlossen" wird und im Endeffekt nicht sichtbar ist, obwohl es oben liegt?


    Anders gefragt, könnte man nicht 1x die planes so einstellen, dass OSD über VIDEO liegt und dann "nur" den Puffer löschen oder hat das Performancegründe?

  • Es ist so wie Du es beschreibst. Doppelt gemoppelt. Warum ich das damals so gemacht habe weiss ich nicht mehr genau. Es gab das Problem das auf der Videoplane das Bild nicht wechselte. Noch jetzt ist es so das in dem Zyklus in dem das OSD wechselt die Videoplane nicht wechselt und hinterher ein Bild verworfen wird. Das fällt nur nicht auf. Da würde ich momentan aber erst einmal warten wie die DRM Treiber das Handhaben. Wie gesagt ist zpos aus dem mainline Kernel entfernt. Ob das wieder einzieht ist fraglich. Wahrscheinlich wird ein Umstieg auf fence notwendig werden. Du kannst auf die OSD Plane mit ARGB schreiben. Den Rest macht softhddevice-drm.

  • Danke für die Antwort. Ich habe deshalb gefragt, weil das mit dem GL Osd zwar funktioniert, aber die zpos immer falsch gesetzt war. In der GL-Osd-Klasse gibt es SetActive nicht in der Form wie bei deiner. Und wenn man dann am Anfang mit den falschen zpos startet, stimmt natürlich ChangePlanes nicht. Ich habe es jetzt so gelöst, dass ich nicht "tausche", sondern bei OsdDraw VIDEO auf render->zpos_primary und OSD auf render->zpos_overlay setze und beim Clear genau anders herum.

    Ich glaube auch den Flaschenhals für das GL-Osd gefunden zu haben. Ich habe eine alte Diskussion mit louis ausgegraben. DrawText zeichnet jeden Buchstaben mit eigener Textur und eigenem GL-Befehl und das dauert ziemlich lange. Ich versuche jetzt, das ganze mit einem Texture-Atlas zu machen, damit nur mehr 1 GL-Aufruf pro DrawText durchgeführt werden muss. Mal sehen, was das bringt. Außerdem dauern die Ellipsen relativ lang ...


    EDIT: Hast du den Commit oder sonst einen Link zur Diskussion über die Herausnahme von zpos aus dem Kernel?

  • Wenn ich nach "zpos" suche, kann auf linux-media und dri-devel nichts finden, das den Anschein macht, dass zpos entfernt würde/wurde. Andere Treiber sind dabei, das anders zu integrieren, aber herausgenommen werden soll da nichts. Zumindest weiß der Patch-Ersteller von oben nichts davon. Also erstmal kein Handlungsbedarf.

  • Wie weit ist dein Ausgabe Plugin schon fortgeschritten? Macht es schon Sinn es zu testen? Welche OSDs werden dann später unterstützt?

    Viele Grüße

  • Nimm zille's Original.

    Ich habe hier zwar eine Version, die mit GL funktioniert, aber die baut das OSD (zumindest LCars) merklich langsamer als mit CPU memcpy.

    Ich brauch noch etwas, das zu optimieren. Ein “testen“ macht also noch keinen Sinn, außer du willst dich mit dem Quellcode beschäftigen ;)

  • Mit Quellcode komme ich nicht so zurecht =O Nachvollziehen geht so einigermaßen aber selber produzieren da hapert es. Ich setz das Thema mal auf Beobachten ;) Viele Grüße

  • Kann mir jemand sagen welche skins von zillerbaers softhddevice-drm unterstützt werden außer die Standart Themes. Aktuell habe ich das Lcars Blueglass in Verwendung welches ich hier im Forum gefunden habe. Was würde den noch funktionieren? Wenn man vom Skindesigner verwöhnt ist muss man sich schon an das spartanische OSD gewöhnen :D

  • Hi,

    Ich vermute mal die klassischen Skins wie Elchi, soppalusikka, evtl auch text2skin...

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de