Tud-e bárki valami hasonló toolt, mint
- radeontop - nyilván AMD GPU-kra
- intel-gpu-top - nyilván Intelre
- gpustat, nvtop, nvidia-smi - Nvidia cuccokra
de működik a Raspberry pi4-ben levő Videocore VI GPU-ra és meg tudja mondani, hogy mennyi a GPU kihasználtsága?
OS: Raspberry pi OS 64 bit, Debian bullseye release (gyakorlatilag a latest ami most elérhető)
Háttér: Chromium-ból kísérletezek youtube és hasonló video streamelő oldalakról lejátszani. h264ify extension fenn van, a debug nézet ellenőrizve, hogy a video codec tényleg h.264. Lejátszás közben a
vcgencmd measure_clock h264
mutatja az órajelet, leállított lejátszásnál 0-t mutat. Ez alapján szerintem eléggé jól bizonyított, hogy hardveres h.264 lejátszás működik. VLC-vel a letöltött video lejátszása teljesen folytonos teljes képernyőn 1080p 60fps-sel is. Böngészőből viszont használhatatlanul akad. Full screenben kicsit jobb a helyzet.
Azt vettem észre, hogy a lejátszás közben a CPU igazából nincs teljesen kihasználva, a 4 magból mindre jut terhelés, de egyik sincs kimaxolva. A CPU húzva van 2GHz-re, semmit nem segített rajta. A Pi egyébként egy Flirc házban lakik, ami teljes egészében hűtőborda, remekül teszi a dolgát, minden maxra terhelve se megy 61C fölé - vagyis nem throttling a probléma.
Megpróbáltam még a böngészős "UFO" tesztoldalon video nélkül megnézni, hogy mégis milyen sebességgel tud képet frissíteni, ez a szövegscrollozós teszt tűnt a leghasznosabbnak: https://www.testufo.com/framerates-text
Az eredmény, hogy a böngésző maximize-olt ablakban nem képes még szöveget sem 60fps-sel újrarajzolni, kb fél képernyőre kell az ablakot összehúzni, hogy a 60fps stabilan menjen. A CPU eközben nincs kimaxolva.
Az utolsó kisérlet volt a GPU overclock-olása. És valóban, ettől határozottan javul a helyzet. A doksi szerint a default 500 MHz-ről egészen 750 MHz-ig mehet. Mint kiderült ez nem hard limit, nekem egészen 830 MHz-ig sikerült húznom, mielőtt instabillá vált volna. Ennyi kellett is, hogy a szöveges scrollozása akadásmentesen vigye a 60 fps-t. Alapértelmezetten a
gpu_freq=830
paraméter mindent is 830MHz-re húz, ami nem ARM mag. Mint kiderült a h.264 engine ezt nem bírja, a video helyett csak memóriaszemetet látni.
h264_freq=750
sor hozzáadásával ezt vissza lehet venni 750MHz-re, de igazából bőven maradhatna 500 MHz-en is.
A videolejátszás böngészőben most ott tart, hogy 720p60 fullscreenben már egész folyamatosan megy, 1080p30 is, de 1080p60 továbbra is túl sok neki. Szerintem eléggé igazolt, hogy itt csakis a GPU lehet szűk keresztmetszet, viszont érdekes lenne tudni, hogy mit csinál a Chromium és valójában mekkora terhelést produkál a GPU-n.
Hozzászólások
Chromium media-internals oldalán láthatod, hogy mivel játsza le.
VLC-ből egy patchelt változat van pire tudtomma, amibe betették a hardveres gyorsítás és talán a hw megjelenítést is.
A linux desktop pi alatt nem hw gyorsított. A gpu dekódolja a rajta lévő patchelt chromium alatt a videót, de a pixeleket proci erőből rakosgatja ki a képernyőre, mert nincs rendes X gyorsítás. Az egy dolog, hogy nincs minden cpu mag kimaxolva, lehet egy szálon küzd a videó cpu-ból való pixelenkénti kirakásával a normális gépek hw renderelése helyett.
Ezen szerintem már túl vagyunk a latest verziókban. Nem kell az omx-es patchelt vlc-t használni. Az tény, hogy a net még mindig tele van 2020 vagy azelőtti outdated infókkal erről a témáról.
A media inspectort nem írtam le, de persze korábban azt is megnéztem (erről nagyon sok outdated, néha kifejezetten hibás javaslatot találtam):
Decoder name: VDAVideoDecoder
Hardware decoder: true
A desktop lehet, hogy nem gyorsított, de chromium-ban a chrome://gpu/ oldalon:
Graphics Feature Status
minden amit nem emeltem ki bolddal, az elvileg hardveresen gyorsított.
Én konkrétan a chrome://flags/ alatt 3 dolgot kapcsoltam be (különösen erre van rengeteg outdated javaslat):
A másik pedig, hogy ha igaz lenne amit írtál, akkor a CPU overclock-ra kéne reagálnia, nem pedig a GPU overclock-ra.
Régóta vágyok én, az androidok mezonkincsére már!
Az lehet, hogy már nem kell patchelni a vlc-t mert vagy bekerült a hivatalosba a támogatás, vagy szabványos api-t csináltak a video dekódoláshoz bullseye-ban. (meg lehet opengl outputra van állítva, ezért nem törik, szaggat)
Az hogy pixelenként rajzolgatja a videót, gondolom gpu szempontból sem hatékony. Hw desktop gyorsítással textúrába rendereléssel szokták szerintem csinálni, amikor a háttérben hatékonyabb módon a gpu kezeli teljesn a kirajzolást.
Régebben úgy gondoltam, hogy amíg wayland-ot nem támogatják pi-n addig esélytelen a desktop gyorsítás és mindig olyan lesz, mintha modern gépen s3trioval használnánk. Sokáig az volt az alapítványos álláspont, hogy nincs rá szükség. De jellemző rájuk, hogy titkolnak dolgokat, vagy szimplán üzleti érdekből hazudnak a hw/sw képességek szükségességéről.
Közben látom, hogy tán került be experimental wayland support a raspi os-be is:
https://www.phoronix.com/news/Raspberry-Pi-OS-Wayland
https://youtu.be/bBPDuIsUkDM?t=213
de még lehet bugos.
Más rendszereken már korábban is próbálkoztak waylanddel, pl ubuntu. Itt összehasonlítja x11 és wayland alatt a videojátszást
https://www.youtube.com/watch?v=a-Gfpc60cHU
Így elvileg külön pi specifikus teljes x11 megvalósítás helyett opengl(es) alapon bewrappelődhet és gyorsított lehet a desktop. Azzal lehet a nagyobb ramos változat jobb desktop élménnyel fut. Bár bullseye kapcsán variáltak a desktop kezelésen, pi4 ram mérettől függően anno már desktop effektetket is használtak. A pi kezdeteitől próbáltak fokozatosan egyre jobb teljesítményt kihozni, volt fbturbo, vc4-kms-v3d és vc4-fkms-v3d driver is használva.
Érdekességképpen az órajel módosítások kapcsán azt is érdemes tudni, hogy a pi valójában broadcom videocore zárt rendszeren fut alsó szinten. Azon emulál egy pécészerű dolgot, amihez az arm magok is kapcsolódnak, amit linux alól látsz. A különböző pi-ken más arm coprocesszorok vannak. Ezért tudják viszonylag könnyen up to date tartani a linux kernelt hozzá, mert úgy emulálják a pécét, hogy könnyű legyen linux oldalról használni. Ha a videocore belső órajeleit változtatod, az hatással lehet másra is. Valójában a videocore nem csak egy gpu, vannak olyan settopbox-ban használt soc változatai is, amiben egyáltalán nincs arm mag, hanem linux nélkül full a bare metal rendszer fut rajta. Régi videó, de a legújabb pi is hasonló.
https://www.youtube.com/watch?v=eZd0IYJ7J40
Ja és a 2d/3d is külön modul a vpu-któl. A pi4 tudtommal tartalmazza a p3-ig használt videocoreIV-ben is lévő vpu-t (lebutítva, mpeg2 és vc1 gyorsítás kikapcsolva, elődhöz hasonlóan csak max fhd, de csak h264-re) és a videocoreVI vpu-jából a h265 4k részt.
https://forums.raspberrypi.com/viewtopic.php?t=271632
Az igaz, hogy nem követem napi szinten már a pivel kapcsolatos híreket, mert nehezen beszerezhető és desktopnak még mindig gyenge, az affelé tolódott reklámjuk ellenére. Szal desktopnak továbbra is más való szerintem.
Célfeladatra, akár médiacenternek meg vannak célrendszerek rá, ahol nem fogja vissza a desktop mód a videólejátszást (libreelec és hasonlók)
Sokmindennel tisztában voltam én is, amit leírtál. A videocore-on fut igazából elég sokminden ami az arm magok inicializáláshoz kell, és azt is tudom, hogy a Broadcom - finoman szólva - nem arról híres, hogy elősegítené a hardvereik opensource támogatását. Ettől függetlenül reménykedtem benne, hogy van valami generikusabb módszer a GPU load mérésére, csak én nem találom meg.
Az jó hint volt, hogy a wayland már kipróbálható a raspi os-en is. Mondjuk a problémát sajnos nem oldotta meg, mert a video fullscreenbe rakása még bugos, az utolsó 2 frame-et ismételgeti.|
EDIT: amúgy az összteljesítmény wayland-el lényegesen rosszabb lett, a text scolling tesztben már csak 30-40 fps-t tud 830MHz-en. X11-en ennyire húzva már vitte a 60fps-t. A CPU load viszont nagyon alacsony közben, 10-13%.
Az órajelek viszonyát végigolvasgattam a doksiban. Nekem még a memória-sávszélesség volt a lehetséges gyanúsítottak között, de az sdram_clock opció nem támogatott Pi4-en, úgyhogy ez nem tesztelhető.
Egyébként a végcél tényleg valami media center szerűség lenne, úgyhogy tervben van Kodi vagy Libreelec kipróbálása is.
Régóta vágyok én, az androidok mezonkincsére már!
ja igen.. százalék értéket azért sem fogsz látni, mert az a gyártó saját logikája szerinti kalkulációból valami érték és a videocorenál nem adnak kifelé ilyet.
https://forums.raspberrypi.com/viewtopic.php?t=304453
https://forums.raspberrypi.com//viewtopic.php?f=29&t=195178&start=100
A vpu-ra talán van hasonló érték, de csak arra, ahogy írják (és lehet az sem teljes)
Emlékeim szerint a régi piken össz sávszélesség limit volt a videódkódolásra, de lehet az is csak teljesítmény limitként. Mivel valsz azt is a videokoce zárt rendszer dekódolja és nem feltétlen fixed elektronika, hanem az is szoftveresen a zárt blobban definiált módon. A régi pi1 zeroval is lehetett 4 sd videót egyszerre dekódolni, hang nélkül, mert utóbbit a proci magja kezelte. Magasabb vpu órajellel nagyobb sávszélességig bírta.
Jelfeldolgozásnál vettem észre azt, hogy összes magon NEON számolt ezerrel, toltam bele a digitalizált RF jelet és hőterhelés miatt leszavályoznak, nem bírják csak impulzus szerűen a fullos aritmetikázást. Ezen az órajel feljebb húzása egyáltalán nem segít, sőt.
Ezt valahogy mérhetővé lehet tenni? Nekem a vcgencmd measure_clock arm nem mutat semmi ingadozást, fixen a maxon áll, amíg a terhelés fennáll. A flirc case elég jól hűti a raspberry-t, a lehető legnagyobb húzásnál sem sikerült 62-63C fölé vinni.
Régóta vágyok én, az androidok mezonkincsére már!
Lesz egy kis időm, próbálok írni rá egy tesztet, ahol a hűtés meg sokminden szerepét is láthatjuk. Egyébként sok dologgal szívtam eddig. ARM Cortex A53 esetén például a RAM adatkiszolgálási tempó is akadályozott, amikor 4 szálon NEON számolt ezerrel.
Off: nvtop az nem csak Nvidia-ra jó de mutatja intel, nvidia vagy AMD GPU-k terhelését is.
Végignéztem a readme-jét, tényleg van támogatás bizonyos Intel és AMD cuccokra is. De ahogy nézem ezek mindegyike valami nagyon specifikus interfészt használ. Nem látom sok esélyét, hogy videocore-on menni fog. Este ha lesz rá időm megpróbálom leforgatni. Sajnos a repoban nincs.
Régóta vágyok én, az androidok mezonkincsére már!
Perf-et lenne érdemes megnézni, elvileg vannak GPU specifikus hardware counterek kivezetve VC4 esetében:
https://patchwork.kernel.org/project/dri-devel/patch/20180112090926.125…
Performance Counters fejezet:
https://docs.broadcom.com/doc/12358545
Ez egyebkent nem tunik rossznak. Ugyan nem pont az, amire gondoltam, de az eddigiek kozul ez a legkozelebbi, ami elarul valamit, hogy mit is csinal a GPU. Ugy nez ki, hogy a Pi4-ben levo VC6-ra (v3d) is van valamilyen szintu tamogatas: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/v3d/v3d_perfmon.c, illetve itt a patch: https://patchwork.freedesktop.org/patch/437710/
Az egyetlen baj vele, hogy ezt nagyobb lelegzetvetelu feladat beuzemelni. Mert - ahogy elnezem nem eloszor - raspberry pi os alatt hianyzik a linux-perf csomag megfelelo kernelhez valo verzioja. Egy sokkal regebbihez valo van a repoban (de minek). Ahogy elnezem teljes recompile kell hozza...
Régóta vágyok én, az androidok mezonkincsére már!
https://github.com/Alex313031/Thorium-Special/releases/tag/M111.0.5563…