keine Hardwarebeschleunigung mehr

Hallo,
mir ist plötzlich aufgefallen, dass ich keine HW Beschleunigung mehr in Emby habe.
Das hat definitiv mal funktioninert.
Der Container hat /dev/dri durchgereicht, die Tipps von SkyBird sind auch drin: CHMOD 777 Befehle.

Wenn ich in Emby bei Hardwarebeschleuninung "Erweitert" einstellt, ist da einfach nichts. Wird also nicht erkannt.

Ich bin auf unRAID 6.9.1 und Emby die neuste Beta 4.6.0.35

Gerade wollte ich mal überprüfen, ob es die Pfade überhaupt gibt:

root@unraid-27:/dev# ls
aer_inject       dm-2      [definition='1','0']log[/definition]=          md1        ppp     sde1  sg7      tty15  tty27  tty39  tty50  tty62    vcs6   vcsu5
block/           dm-3      loop-control  md2        ptmx    sdf   shm/     tty16  tty28  tty4   tty51  tty63    vcsa   vcsu6
bsg/             dm-4      loop0         md3        pts/    sdf1  stderr@  tty17  tty29  tty40  tty52  tty7     vcsa1  vfio/
btrfs-control    fd@       loop1         md4        random  sdg   stdin@   tty18  tty3   tty41  tty53  tty8     vcsa2  vga_arbiter
bus/             full      loop2         md5        rtc@    sdg1  stdout@  tty19  tty30  tty42  tty54  tty9     vcsa3  vhci
char/            fuse      loop3         mem        rtc0    sdh   tty      tty2   tty31  tty43  tty55  ttyS0    vcsa4  vhost-net
console          hpet      loop4         mouse@     sda     sdh1  tty0     tty20  tty32  tty44  tty56  urandom  vcsa5  vsock
core@            hwrng     loop5         net/       sda1    sg0   tty1     tty21  tty33  tty45  tty57  vcs      vcsa6  xconsole|
cpu/             initctl|  loop6         null       sdc     sg2   tty10    tty22  tty34  tty46  tty58  vcs1     vcsu   zero
cpu_dma_latency  input/    loop7         nvme0      sdc1    sg3   tty11    tty23  tty35  tty47  tty59  vcs2     vcsu1
disk/            kmem      lp0           nvme0n1    sdd     sg4   tty12    tty24  tty36  tty48  tty6   vcs3     vcsu2
dm-0             kmsg      mapper/       nvme0n1p1  sdd1    sg5   tty13    tty25  tty37  tty49  tty60  vcs4     vcsu3
dm-1             kvm       mcelog        port       sde     sg6   tty14    tty26  tty38  tty5   tty61  vcs5     vcsu4

Ich kenne mich nicht aus, aber müsste da nicht dev/dri vorhanden sein?

Mache ich gleich, kämpfe gerade noch mal mit dem "runterfahren".

Warum Beta? Weil Emby so vor ca. einem Jahr mal in rasanter Geschwindigkeit richtig geile Features gebracht hat, das war für mich stets stabil - wenn auch ein gewisses Risiko.
Seit dem bin ich auf der Beta und bereue das nicht.

Jo, alles klar.
Ich benutze seit über nem Jahr die Beta, aber wenn ich Probleme mit Unraid habe ist es wieder die Beta. Darauf hätte ich vorher ne Wette abschließen sollen.

Aber gut, verstehen kann ich den Tipp irgendwie.

Zitat von hi2hello

Na ja. Du schreibst, dass Deine Hardwarebeschleunigung in Emby nicht läuft, also von einem Problem in oder mit Emby.
Da liegt ein Verdacht bzgl. einer Beta jetzt ja nicht sooooo weit weg, oder?!

Bis später

Du übersiehst weiter oben, dass ich das Problem schon ein bisschen eingegrenzt habe.
Scheinbar werden die Linux / Unraid Treiber für die GPU nicht (mehr) korrekt geladen, denn ich habe den Ordner /dev/dri schon gar nicht zur Verfügung.
Es geht übrigens auch keine Hardware-Beschleunigung in TVheadend.

Ich habe dieses Tool / Plugin installiert:
https://forums.unraid.net/topic/92865-su…builder-docker/
[infobox]
This plugin adds the tool 'intel_gpu_top' to your unRAID server and also enables your Intel iGPU from the installation of this plugin on, so no editis to the 'go' file or creation of other files are necessary.To see the usage of your iGPU open up the unRAID Terminal and type in 'intel_gpu_top' (without quotes).This plugin satisfies installation prerequisites of the GPU Statistics plugin from Community Apps. With both plugins installed you can display Intel GPU utilization on the unRAID Dashboard.
[/infobox]

Und ich habe natürlich die go Datei nach den einschlägigen Empfehlungen modifiziert:
(Obwohl das nach der Beschreibung des o. g. Plugins nicht mehr nötig ist)

#Emby Hardware Transcoding
modprobe i915
chown -R nobody:users /dev/dri
chown -R 777 /dev/dri

Ok, "Problem" gefunden.
Ich nutze bei meiner VM auch die iGPU. Wahrscheinlich hatte ich bei meinen ersten Tests einfach nur Glück dass das nicht gleichzeitig lief.
Auf jeden Fall scheint das nicht zu gehen.
Mehrere Docker können sich die GPU teilen, aber mit der VM geht das nicht.

Schade!

Hallo,
falls das jemand noch nicht kennt, ich habe es gerade beim "reparieren" meiner unRAID Installation gefunden:

https://forums.unraid.net/topic/108650-plugin-intel-gvt-g/

Ungetestet, aber wenn es funktioniert, ist das Ding rund. Echte GPU Virtualisierung für das ganz System!

Ich teste das gerade.

So absolut perfekt ist es nicht, denn es knallt auch die CPU Last ziemlich hoch, aber im Grundatz klappt es.
GPU Transcoding sowohl in der VM (Handbrake > TV Aufnahmen) als auch im Docker (Emby und TVH) - und zwar gleichzeitig!

Ja, die Frage stelle ich mir auch immer mal wieder. Was kostet nen GB?
Aber h265 10 Bit und Opus 5.1 bringen schon was.

Avidemux zum schneiden und dann Handbrake zum encoden... ist bei mir so drin.

Back to topic. Nicht so geil, gestern Abend ist mir die VM im laufenden Betrieb 2 x einfach ausgegangen. Ob das jetzt an dem gvt-g liegt?

Nochmal testen

Wir sind zwar off Topic, aber das interessiert mich jetzt.

Beispiel einer Serienepisode die als Full HD ausgetrahlt wird, AC3 + Stereo Tonspur die ich jeweils nur durchpasse.

Also wenn ich die Aufnahme geschnitten habe, ist sie als MKV (Standard Matroska Profil vom TVH) 1.6 GB groß.
Als H265 10 Bit mit QF 22 (QSV) kann ich optisch absolut keine Einbußen feststellen und die Datei ist 650 MB groß.
Als H264 8 Bit mit QF 22 (QSV) ist die Aufnahme sichtbar matschiger und die Datei ist 1.3 GB groß.

Da muss ich nicht viel überlegen, und ich glaube auch du bist einem gewissen Irrtum aufgesessen.
Denn 10 Bit hat natürlich was mit der Farbtiefe zu tun, und damit auch in gewissen Weise mit HDR, dafür macht 10 bit ausschließlich Sinn.
Aber auch 8 bit Material profitiert von einem besseren Verhältnis von Kompression zu Qualität, bzw. am Ende sind dann halt die Dateien kleiner.

Besser kann ich es nicht erklären, aber meine Augen sind da mein Messgerät.