Názory k článku Threadripper byl hobby projekt, který AMD nemělo v plánu. Jméno je původní „codename“
-
No ale je to hrozne dlouhy. Hned jsem si rikal, ze je ten nazev dost blbej, takze ted je to osvetleno. Ja jsem ten procak interne prejmenoval na TRipper, to si myslim, ze je prijatelnejsi na zapamatovani. Jinak teda se dost divim uspechu, protoze to cileni se mi zda na velmi uzkou skupinu. Kolik lidi na svete potrebuje pracovni stanici s masivnim multithread vykonem? Zda se, ze o dost vic nez bych predpokladal, dost by me zajimali softwary, co to vyuziji. Kazdopadne ale teda urcite AMD uspech preju.
-
Gratulace! Tohle v korporátu utajit a dotáhnout až do konce, kdy produkt management uzná, že myšlenka, se kterou sám nepřišel je dobrá, prodejná a začne ji oficiálně podporovat, je husarský kousek. Bohužel to ale taky obvykle dopadne tak, že odměněni jsou ti, co k tomu přišli jak slepí k houslím a ty co to vymysleli, vydřeli a postarali se aby to fungovalo, může akorát hřát dobrý pocit.
-
Ladik (neregistrovaný)
Hele, mně zatěžuje, můj 4 Jádrový Desktopový procesor AMD Athlon II X4 615e, na FREKVENCi, asi tak 2,5 GHz, se spotřebou, jen asi tak 45 WATTů, na tak, Vysokou FREKVENCi, až asi tak 2,5 GHz, tak mi zatěžuje Antivir, od MICROSOFTu, ve Windows 10 Proffesional, asi ně-jaká 32-Bit. verze CZ, tak mi někdy zatěžuje, tenhle Antivir, ten Můj čtyřJádrový Procesor, až asi tak na 3,5 Jádra, takže se mi seká i ikonka, v té chvíli když přetahuju Ikonku Videa, na Přehrávač Media Player Classic: Home CINEMa, na Ploše, abych ho spustil, takže se VíceJádro, v pohodě, využije, takže, asi tak, celkem, do-cela, zase, tedy! :-)
-
Ladik (neregistrovaný)
To je trochu asi fakt, ale mám LISu Su, za Počítačovou PROFFESIONÁLKu, takže to bude, asi i trochu tím, a ten Její Zástupce, je taky dobrý Týpek, ne jako ty Experti co tam, byli od ROKu 2009 do ROKu 2013, v Pozicích ŘEDITELů AMD, a po roce, je vždycky, vyrazily, protože, tam, tomu, šéfovali, hůře, jak Děti, ze 4-Té Třídy Základní ŠKOLy, se Selským ROZUMem, i když oni kluci, ještě, nemněli přehled, takový jak psali o počítačích pro Celou ČESKou REPUBLIKu, hodně se zlepšily, třeba, konkrétně www.extrahardware.cz ,dříve to snad, byli Počítačový Amatéři, kteří by snad, mohli dělat, uklízeče, ve Firmě AMD, pomalu, a dneska, jsou to Počítačový PROFFESIONÁLOVé, takový že by, tomu AMD, mohli sami ŠÉFOVat, to je Velká Paráda, dříve, jste, kluci zmotali pomalu PC 386 s Pentium, jen v Modernějším provedení, tedy, a dneska, píšete, prakticky úplně skvěle, skvělý odkaz, na BandiZip, který v poslední verzi, jak jsem tak koukal, pěkně vylepšily, a Inspirovali se WinRARem, což je skvělé, jenže proti WinRARu, to ten Komfort, vůbec, nemá to už lepší PeaZip, pro mně, uvnitř, programu, i když WinRar, je uvnitř, programu, to jeho Ovládání je nejlepší, ani mi nebude, vadit, když mně zablokujete, vy už si téměř, beze mně poradíte, časem, snad, určitě, teď, je můj Úkol splněn, takže zaujmu své Místo, mezi LEGENDAMi MINULOSTi, a nebo, ne-vím, inu, kdo-ví, do-cela, celkem, zase, tedy! :-)
-
Na tenkym klientovi TRipper? To snad ne. Na to ti staci Celeron. Na servr strane budes mit AMD Epyc.
Enkodovani videa konci na nejakejch 16 vlaknech, treba H264 vic efektivne neumi.
Mozna nejaky renderovani, ale zase opravdu ty programy davaji efektivni vysledky na 16 vlaken RyZenu 1800X? (Ptam se, ja s tim zkusenost nemam.) -
Maor nejsise myslel, ze na TR muzes rozjet neco jako terminal server. Tudiz muzes naskalovat nekolik tenkych klientu, kteri pak na nej budou pristupovat. Jestli to udelas na 16C Epycu nebo 16C TR je jedno. TR ma vyhodu, ze bude nejspise levnejsi a jako Terminal server bude fungovat vyborne.
Krome toho, pro ruzne maximalisty, kteri napriklad pousteji 2 a vice narocnych paralelnich uloh, to muze byt taky vyborna volba. Tady pro legraci, co se stane kdyz takovy TR a 7900x namaxujes...
https://www.youtube.com/watch?v=IHVUBU-pJQc&t=50s -
Výkon rendrování (raytracing) škáluje s jádry takřka lineárně.
I encoding z více jader profituje. Například x265 bechmark při jednotlivém encodingu vytížil TR na cca 80% (výsledná rychlost encodingu ~60FPS), při paralelním běhu dvou encodingů je již vytížení CPU plné a dosažený výkon je 72FPS.
http://www.monitos.cz/tmp/x265_benchmark_1x_2x.png -
Encoding ma ten problem, ze nad 16 vlaken rapidne pada kvalita. Dokonce borci na Doom9 odzkouseli, ze nejlepsi ultrakvalita je jet to na singlethread. Takze RyZen R7 bohate staci a s TRipperem bych si moc nepomohl. Jak to je u raytracingu nevim, ale kdyz to rikas, ze to skaluje OK, tak to asi tak bude. Takze na graficke renderovaci stanice bude TRipper optimalni, parada.
-
Jan Olšan (neregistrovaný)
Není to tak, že nad 16 vláken - závisí to na rozlišení. Třeba u x264 se uvádí, že to chce tak 80 pixelů výšky (šířka nerozhoduje) na každé vlákno (ale x264 spawnuje 1.5x enkódovacího vlákna na jádro/vlákno CPU) aby to moc netrpělo, ale univerzální to taky úplně nebude. Teda ideálně 80, minimálně 40 bylo takové hrubé "rule of thumb", jestli si to dobře pamatuju.
Jinak ale není žádný problém rozsekat práci na víc kusů a enkódovat se sníženým počtem vláken paralelně. V extrémním případě třeba těch 32 instancí. Dokud teda stačí RAM, haha. -
Predavam, co jsem sam cetl. Uplne v tom zorientovany nejsem, vim ze maximum je 128 vlaken, teda staci na vsechny dnesni procaky. Ale prave to chapu tak, ze problem je ve zpracovani tech oblasti, ktere presahuji z jednoho vlakna do druheho, tam potom ma singlthread nejlepsi vysledek, protoze se cely obraz zpracovava v jednom kuse a teda cim vic je to rozsekany, tim vic problemovych oblasti. Ale nevim, jestli to chapu spravne.
-
Jan Olšan (neregistrovaný)
Jo, v víceméně to tak je (jen jestli má x264/x265 hard limit na 128 vláken, to nevím, nikdy jsem o tom neslyšel a už 2S broadwell-EP by na to narazil).
Ten threading ubírá na kvalitě kvůli tomu, že se nedá tak efektivně využít inter-predikce. Postih závisí na metodě - slice nebo tile-threading (libvpx) je hodně špatnej, WPP threading (x265) by měl být méně zatíženej a frame threads (x264,x265) také, AFAIK by mělo jít o nejlepší metodu. -
@Jan Olsan... muzu se zeptat.. kdyz mluvite o X264/265 vlaknech..tak to by melo byt otazka nastaveni nejakych parametru kodeku a vicemene tonema nic spolecneho s CPU jako takovym.
Druha vec co bych se rad zeptal... deli se zpracovavany rame na nejakou matici o XxY pixelech? V tom pripade, cim vetsi rozliseni, tim jemnejsi rastr muzu pouzit (pri velikosti matice rastru mezi 40->80px) a tim padem to muzu taky rozhodit na vice vlaken CPU.
Je to tak nebo mi neco unika? -
Neni to sice dotaz na me, ale mas v tech enkoderech parametr, kterym muzes nastavit, kolik vlaken bude enkodovani videa vyuzivat, defaultne je nula (automaticky).
Jinak jak tu Jan psal, tak mas moznost vyuzivat funkce predikce obrazu, ovsem pri multithread enkodovani je muzes pouzit jen na ctverec respektive spis radek kazdeho pouziteho vlakna, tudiz cim vic vlaken zpracovava obraz, tim bude predicke horsi. A na Doom9 foru jsem cetl, ze nad 16 vlaken je enkodovani spatne, tak z toho co Jan psal, jsem pochopil, ze v zavislosti na rozliseni bude maximalni pocet vlaken, kdy bude enkodovani jeste efektivni a pak pujde kvalita rapidne dolu. Asi to mozna bude souviset i s tim, proc je enkodovani o tolik lepsi na procesoru nez na grafice. -
Porad to vubec nechapes :)
Pokud jsi se na to video dival, tak oni sice maji SLI sestavu..ale soucasne jim tam bezi konverze 4K videa, streaming a tvrdi dokonce i ze jeste 3dmark (byt si neumim predstavit jak :D)
Takze to video neni o nejakem SLI (byt to je na jinem videu od te stejne skupiny), ale o tom, ze ta CPU brutalne zatizis. Neco, co by jsi na "beznych" desktopu nemel sanci vubec utahnout. Jinymi slovy, je to video, ktere muzes vzit jako pokus o extremni vyuziti desktopu (plus minus autobus) a hrani zaroven.
Uz tomu rozumis? -
Jan Olšan (neregistrovaný)
@tombomino, ne dlaždice ve smyslu matrice se (momentálně) nedělají.
"Slice" threading používá rozdělení obrazu na několik horizontálních pruhů (takže třeba u full HD by to mohlo být čtyřikrát 1920x270), které se kódují odděleně. To, co VP9 nazývá "tiles" je v podstatě totéž, ale vertikálně (takže sloupce 540x1080).
U tohohle typu threadingu není dobré, když je těch sekcí moc, takže teoreticky by šlo mít nějakou matrici z hodně kousků, ale bylo by to dost špatné pro efektivitu.
WPP je složitější, tam není ten frame striktně rozdělený, ale jednotlivá vlákna enkódují jednotlivé pásy macroblocků stejného "slice". Funguje to tak, že každý další thread začne enkódovat o něco později, když už má nad sebou hotových pár macroblocků. To je velká výhoda proti slice-threadingu, jelikož si z nich může brát data pro intra-predikci a tak, takže v tomhle režimu nejsou ztráty tak velké.
Viz https://www.parabolaresearch.com/blog/2013-12-01-hevc-wavefront-animation.html
No a frame threading funguje tak, že se enkóduje několik framů najednou, ale taky se chvíli počká. Když je už z prvního snímku hotových pár řad, může se začít kódovat následující, protože macroblocky v horní řadě už mají v předchozím snímku dost řad na to, aby z něj mohly být udělán motion search a nalezené bloky pro predikci (to proto, že motion vektory obvykle nejsou hodně dlouhé). Když už je i z druhého snímku hotovo celkem hodně, tak se může začít paralelně enkódovat třetí...
WPP a frame threading se v x265 používají zároveň. Enkóduje se pár snímků najednou a k tomu ještě v tolika WPP řádcích, kolik jich umožňuje rozlišení (výška obrazu / 64 nebo 32 ec pokud omezíte velikost CTU). WPP se dá i vypnout a používat jen frame threads, ale defaultně je zapnuté, protože se počítá i s tím, že ho používají k paralelizaci některé dekodéry.
Jinak ta efektivita není úplně o "maximálním počtu vláken". Každé rozdělení na vlákna něco ubere, ale je to křivka, takže ze začátku je to OK a postupně se to stává míň OK.
Návody a tipy
23. 10. 2024
| online
31. 7. 2024
| online
6. 7. 2024
| online
ČLÁNKY DO MAILU
