ansible@focal und softhddrm

  • Braucht man denn jetzt noch das ppa von oibaf?

    Das müsstest du selber ausprobieren. Für die Haswell-IGP war es nicht nötig.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • rkp

    oibaf ist (hier) nicht mehr erforderlich - alles zurück auf Standard und funktioniert wieder bestens...

  • Hallo allerseits,

    ich habe jetzt versucht, softhdrm auch unter X zum laufen zu bringen. (als softhdvaapi natürlich).

    Mein System ist ein AMD Ryzen 5650GE (mit AMD Renoir GPU).

    5.15 Kernel und die mesa treiber von oibaf


    Ich habe dazu libplacebo175 von Seahawk installiert.

    im Makefile von softhddrm habe ich:


    VAAPI=1

    LIBPLACEBO=1



    Leider bekomme ich jetzt folgende Fehlermeldungen wenn ich das Plugin innerhalb einer X Session starte:


    vdr[9365]: Fehler beim export VAAPI Handle

    vdr[9365]: error: Validation failed: (image->planes[i]).texture (../src/renderer.c:2170)

    vdr[9365]: error: #0 /lib/x86_64-linux-gnu/libplacebo.so.175(+0x3dda1) [0x7fcb493c1da1

    vdr[9365]: error: #1 /lib/x86_64-linux-gnu/libplacebo.so.175(+0x407f9) [0x7fcb493c47f9]

    vdr[9365]: error: #2 /lib/x86_64-linux-gnu/libplacebo.so.175(pl_render_image+0xa0) [0x7fcb493caf80]

    vdr[9365]: error: #3 /usr/lib/vdr/plugins/libvdr-softhdvaapi.so.2.5.6(+0x2f25b) [0x7fcb497af25b]

    vdr[9365]: error: #4 /usr/lib/vdr/plugins/libvdr-softhdvaapi.so.2.5.6(+0x3611f) [0x7fcb497b611f]

    vdr[9365]: error: #5 /lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7fcb4aff5609]

    vdr[9365]: error: #6 /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7fcb4aa0a293]


    jojo61 Der Fehler schein mir ähnlich zu sein, wie in der DRM Variante. Hast Du eine Idee, ob man das auch fixen könnte?

    Das wäre super, da ich meine Kiste schon gerne mit X betreiben möchte.

  • Hi jojo61 gab leider keine Besserung.


    Ich habe mal das printf statement wieder aktiv gesetzt. Evtl hilft das beim Fehler finden.


    Dabei habe im syslog gesehen, dass fd immer hochgezählt wird.

    Import size und offset ist immer 0



  • Wenn das fd immer hochgezählt wird dann wird es nicht mehr freigegeben. Nur sollte das eigentlich die libplacebo in dem Fall tun. Zumindest bin ich davon ausgegangen.

    Du kannst ja mal zum testen ein close hinter die schleife machen. Auch wenn das wohl zu früh ist.

  • Hi, das habe ich gemacht (sorry für die edits).


    Nach:

    decoder->pl_frames[index].planes[n].texture = pl_tex_create(p->gpu, &tex_params);

    das eingesetzt:

    for (int n = 0; n < Planes; n++)

    close(desc.objects[n].fd);


    "Fehler beim export VAAPI Handle" ist jetz weg.

    Das ist ja schon mal super!



    Nov 29 15:16:02 amd vdr[10156]: vor create Object 0 with fd 14 import size 0 offset 0 1280x720

    Nov 29 15:16:02 amd vdr[10156]: vor create Object 1 with fd 42 import size 0 offset 921600 640x360


    d.h. fd wird nicht mehr hochgezählt.

    Warum ist eigentlich size immer 0?


    Es bleibt der Placebo Fehler bei:

    decoder->pl_frames[index].planes[n].texture = pl_tex_create(p->gpu, &tex_params);





  • error: Validation failed: (image->planes[i]).texture (../src/renderer.c:2170)

    Da ist mir wohl eine Änderung der libplacebo durch die Lappen gegangen. Die Zeile 2170 stimt wohl im aktuellen commit der Lib nicht mehr. Hast du placebo selber übersetzt ? Dann poste doch bitte mal die stelle um die Zeile 2170 um zu sehen was ihm da fehlt. Ist wohl nur ein Feld was noch zu füllen ist. Mangels AMD Karte kann ich hier wenig testen.

  • Da ist mir wohl eine Änderung der libplacebo durch die Lappen gegangen. Die Zeile 2170 stimt wohl im aktuellen commit der Lib nicht mehr. Hast du placebo selber übersetzt ? Dann poste doch bitte mal die stelle um die Zeile 2170 um zu sehen was ihm da fehlt. Ist wohl nur ein Feld was noch zu füllen ist. Mangels AMD Karte kann ich hier wenig testen.

    Noe, ich habe die Version von Seahawk genommen.

    dpkg -l | grep placebo"*"

    ii libplacebo-dev:amd64 7:4.175.0+git20211113-146-72cd260-1yavdr0~focal amd64 GPU-accelerated video/image rendering primitives (development files)

    ii libplacebo175:amd64 7:4.175.0+git20211113-146-72cd260-1yavdr0~focal amd64 GPU-accelerated video/image rendering primitives (shared library)


    Ich habe jetzt apt-get source gemacht. In der Datei steht:


    // Rendering to/from a frame with no planes is technically allowed, but so

    // pointless that it's more likely to be a user error worth catching.

    require(image->num_planes > 0 && image->num_planes <= PL_MAX_PLANES);

    require(target->num_planes > 0 && target->num_planes <= PL_MAX_PLANES);

    for (int i = 0; i < image->num_planes; i++)

    validate_plane(image->planes[i], sampleable);


    Das ist die Definition:


    #define validate_plane(plane, param) \

    do { \

    require((plane).texture); \

    require((plane).texture->params.param); \

    require((plane).components > 0 && (plane).components <= 4); \

    for (int c = 0; c < (plane).components; c++) { \

    require((plane).component_mapping[c] >= PL_CHANNEL_NONE && \

    (plane).component_mapping[c] <= PL_CHANNEL_A); \

    } \

    } while (0)


    Update:

    Vermutlich ist bei der Übergabe was schiefgelaufen?


    jojo61: Ich habe das Plugin mal auf einem computer mit Intel Graphik übersetzt und das printf Statement wieder aktiviert.


    Auffällig ist, dass size hier einen vernünftigen Wert hat:


    Nov 30 12:40:35 multi-lin vdr[4401]: vor create Object 0 with fd 16 import size 1433600 offset 0 1280x720

    Nov 30 12:40:35 multi-lin vdr[4401]: vor create Object 0 with fd 16 import size 1433600 offset 942080 640x360







  • Komisch, ich setze aber sampleable auf true wie man ein paar Zeilen vorher sieht.

    Ich denke du musst dir mal die ganze structur desc anschauen was da denn wo drin steht. Das scheint bei AMD wohl doch etwas anders gefüllt zu sein. Zumindest bei Intel ist da nicht alles am richtigen Platz. Wie man ja an den fd schon sieht.

  • Wir haben es hier ja mit 2 Planes zu tun. Das erste Plane I=0 ist das Y Plane und hat die Size height * width. Das zweite Plane i=1 hat ist das UV Plane und hat die Size Height * width / 2 Man kann also die Size durchaus auch so setzen.

  • Habe ich probiert.

    leider bekomme ich die zweite Ebene nicht gebacken:


    Dec 3 19:09:32 amd vdr[12101]: vor create Object 0 with fd 39 import size 921600 offset 0 1280x720

    Dec 3 19:09:32 amd vdr[12101]: vor create Object 1 with fd 41 import size 230400 offset 921600 640x360


    Der erste Aufruf geht noch gut, der zweite bringt den bekannten Fehler:

    Dec 3 19:09:34 amd vdr[12101]: error: Validation failed: (image->planes[i]).texture (../src/renderer.c:2170)



    ist da was mit memory tiling los?


    ich checke es leider nicht.

    Ich habe mal das selfcompiling example laufen lassen, das ging ohne probleme


    Dort wird auch in der zweiten Ebene einfach durch 4 geteilt.

    Bin etwas ratlos? Was kann ich noch tun, um das einzukreisen?

  • ok wir machen mal eine debug session:

    Dazu musst du erstmal die Zeilennummer in video.c finden wo das va SyncSurface steht. Bei mir ist das die Zeile 2420.

    Dann startest du den vdr mit dem gdb:

    Code
    gdb -args vdr -P softhdvaapi 
    (gdb) b video.c:2420
    hier musst du noch ja sagen weil das file noch nicht da ist
    (gdb) r
    Nun sollte er an der Stelle breaken die du gesetzt hast.
    (gdb) print desc
    Den output von desc solltest du dann hier posten

    Ich hoffe du schaffst das :)

  • ok, habe ich gemacht. Ich habe dazu nochmal aus Deinem Repository das original ausgecheckt.


    Das habe ich zu bieten (ich habe dann einmal weitergemacht, um einen zweiten Wert zubekommen.)



  • Ok das hat geholfen. So wie ich das sehe fehlen die drm_format_modifier und die size. Ich habe dir mal ein Version im Anhang gemacht die die Size nachberechnet.

    Ich hoffe das die fehlenden drm_format_modifier kein Problem für placebo sind.


    Und aktualisiere mal deine libpacebo auf den GIT stand. Sonden finde ich die Zeilennummern nicht aus den error log. Oder hänge mal das src/renderer.c das du verwendest hier an wenn das einfacher für dich ist.

  • Hi, das sieht sehr gut aus!


    Ich denke, dass kannst Du einfach in Deiner Source einchecken.
    Ich habe im Syslog auch nichtsmehr verdächtiges finden können. Die Audio Delays (ohne placebo, analog Intel HW) sind jetzt auch verschwunden.

    Herzlichen Dank für Deinen Einsatz und Deine Geduld mit mir!

    Vielleicht macht das ja die AMD Ryzen Platform (5650G z.B.) attraktiver für den VDR.

Jetzt mitmachen!

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