[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.

Zitat von zillerbaer

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?

Zitat von zillerbaer

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.

Zitat von zillerbaer

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.

Zitat von zillerbaer

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

Zitat von rell

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

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

EDIT: Jetzt sollts gehen.

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

Macht Sinn, so mach ich das

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?

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.

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