softhdcuvid/softhdvaapi/softhddrm with hevc and UHD

Zitat von jojo61

Nein die shader werden nicht gecached. Der Absturz ist beim erstellen der Swapchain. Und da wird nur die XCB Surface benutzt. Sieht eigentlich alles gut aus und dennoch geht es nicht. Da der Absturz in den NVIDIA Libs ist könnte es mit dem NVIDIA Treiber zu tun haben. Oder schau mal ob es einen update der XCB Libs gibt.

Entschuldigung, unsere Postings haben sich überschnitten, s. oben, es tut!

Zitat von avak

BTW: habe versucht für SD auf "bicubic" umzustellen, er ist eine Verbesserung da, aber Frames werden immer noch gedropped auch in SD.

Framedrops sind gefühlt "heftiger" wenn diagnostic-OSD von softhdcuvid eingeblendet ist.

Habe versucht heute ein Bisschen zu experimentieren. Mit den zurückgehen auf ältere Treiber bin ich gescheitert: bereits 418 kompiliert nicht bei mir, vermutlich wegen dem 5.3.x kernel. mit 430 und 435 ist das Verhalten gleich.

OSD erzeugt ordentlich Last, für SD-Kanäle steigt GPU-Utilization von ca. 20% auf ca. 30% und das scheint schon "zu viel" zu sein -> framedrops in diagnostic-OSD

Ich habe ebenfalls softhdcuvid aktualisiert.

Frame Duration, die ohne libplacebo bei 2,5ms liegt, steigt mit libplacebo auf 20ms für SD und 25ms für UHD

War es auch früher so, dass OSD so viel Last erzeugt?

Zitat von jojo61

Ich habe nochmal ein paar kleine Optimierungen zum OSD eingecheckt. Die Angzeigte Frame Duration bei Placebo ist leider nicht ganz richtig. Es werden 20ms angezeigt wenn die Duration kleiner/gleich 20ms sind und es werden mehr als 20ms angezeigt wenn es länger dauert. D.h. bei einer Anzeige von 25ms schafft es die karte nicht das Frame schnell genug anzuzeigen. Das liegt dann an placebo und der eingestellten Skalierung und der nötigen Farbkonvertierung. Mir ist immer noch nicht klar warum das nun so langsam ist.

Danke schön. Ich habe es ausprobiert, es hat eventuell minimal etwas verbessert, aber nicht grundlegend. Ich orientiere mich eher daran, ob (und wie viele) dropped Frames es in diagnostic-OSD gibt. Bei SD sind es jetzt ca. 2 pro Sekunde, ich glaube davor waren es eher 3. Bei HD sind jetzt ca. 4, bei UHD ca. 6. BTW: als Scalierung ist bicubic eingestellt, scheint minimalen Ressourcenverbrauch zu haben.

Ohne OSD sieht es so aus, als ob SD und evtl HD flüssig laufen, UHD definitiv nicht mehr.

Frame Duration ist immer bei über 20ms: SD 20,4, UHD ca. 25ms

Ohne libplacebo läuft es ganz OK, so werde ich das auch erstmals lassen.

Zitat von jojo61

So ich glaube ich habe das Problem mit PLACEBO gefunden. Wenn du Lust hast probiere es doch nochmal aus.

Ja, in der Tat! Es ist viel, viel besser geworden mit libplacebo. Ohne OSD scheint es flüssig zu laufen. Mit diagnose-OSD gibt es sporadische dropped Frames, ca. 1 Frame pro Sekunde, in allen Auflösungen (SD, HD, UHD). Ich würde sagen, in SD und HD wird es richtig brauchbar. Ich UHD bei "normalen" Kanälen wie Fashion 4k ist es auf den ersten Blick auch akzeptabel, SES UHD ist problematisch. Gratuliere, super!

Jetzt kommen ein Paar sonstige Beobachtungen: Ich vermute, dass im Decoding (H265, MPEg4 etc.) noch ein Wurm steckt. Starten wir mit SD-Kanälen: wenn ich diagnostic-OSD einblende, treten dropped Frames hauptsächlich bei schnellen großflächigen Bewegungen auf. Solange im Bild nur kleinere Veränderungen passieren, werden keine Frames verloren. Wenn ich parallel dazu GPU-Utilization in nvidia-smi beobachte, sehe ich keine nennenswerte Schwankungen, Utilization ist mit libplacebo bei SD ohne OSD bei ca. 23%, mit diagnostic-OSD bei 30%, d.h. es sollte noch jede menge Lüft nach oben sein. Konnte ich bei mehreren Kanälen beobachten. Bei HD und UHD ist das weniger offensichtlich, der Effekt ist der gleiche: Dropped Frames beim eingeblendeten diagnistic-OSD korellieren mit Bewegungen im Bild.

Bei SES-UHD treten in manchen Szenen reproduzierbar Rückler (dropped Frames) auf. In allen Konstellationen: mit oder ohne OSD, mit oder ohne libplacebo. Insbesondede shuttle-start ist so eine Szene.

Fazit: ich glaube, da ist noch etwas unsauber beim dekodieren bzw. es gibt komische Wechselwirkungen mit dem Rest der Anzeigelogik.

BTW: GPU-Utilization (ohne diagnostic-OSD, mit libplacebo) steigt bei "normalen" UHD-Kanälen auf 40%, bei SES-UHD auf 80%

Aber trotzdem, geile Arbeit! Danke!

Zitat von jojo61

Wenn du dir den checkin anschaust sieht du das ich nur den usleep zwischen den Frames verkürzt habe. Zum Testen kannst du das auch mal von 5000 auf 1000 reduzieren. Im Prinzip bracht man das gar nicht. Aber wenn ich es rausnehme dann habe ich hier ein langsames Reagieren auf Eingaben. Wenn du mit lircd arbeitest dann kannst du es evtl. auch ganz rausnehmen.

Ich habe es probeweise auf 1000 reduziert, das hat aber nichts mehr geändert. Ich habe mir den Code angeschaut, stelle aber fest, dass ich mit den ganzen #ifdefs nur schwer durchblicken kann, was da abgeht. Eventuell schaue ich mir das bei Gelegenheit "genauer" an.

Zitat von Murry

Hallo jojo61,

beim aktuellen git ist das Hauptmenü nur ein 1/4 der normalen Größe.

nvidia 430 / cuvid / opengl / ohne libplacebo / skindesigner mit opengl patch

git checkout fae0d3a funktioniert

Gruß

Murry

Alles anzeigen

Moin jojo61,

dieser Fehler ist im aktuellen git wieder enthalten 146b826 funktionierte.

Gruß

moz

Hallo moz,

bei mir läuft es normal.

Gruß

Murry

Zitat von Murry

Hallo moz,

bei mir läuft es normal.

Gruß

Murry

Hmm,

X läuft bei mir in UHD, OSD ist auf HD eingestellt.

EIgentlich richtig wenn das OSD dann auf 1/4 des Screen dargestellt wird.

Bis dato wurde das OSD aber immer richtig skaliert. Mit der neuen Version nicht mehr.

Stelle ich das OSD auf Custom und 3840x2160 wird skindesigner nicht mehr richtig dargestellt und es kommt zum Absturz.

Hi,

if I fast open and close the menu "m", I can trigger a visible issue. (1920x1080 lcars no placebo)

and another strange log on exit

CU

9000h

Hi,

Zitat

Und ausserdem habe ich versucht das OSD bei schnellem an und aus zu beheben

it is still there, but only without placebo.

CU

9000h