Copyright © 1998-2025 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2025 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Dávalo by to velký smysl, takže se to neprosadí aneb podobně jako „to je blbé, to se bude líbit" jen přesně obráceně.
Od té doby co začala nvidia básnit o GPGPU (unifikované shadery od roku 2006) a AMD se přidalo, jsou praktické výsledky pro uživatele za očekáváním. Dostatečně silný CPU je pořád základ, naproti tomu mnozí se stále v pohodě obejdou bez silného GPU. Jednoznačně ten debakl většího rozšíření GPGPU dokazuje krach „future si fusion". Kdyby ta fůze nekrachla, tak má dnes každý CPU nějaký základní GPU obvod (bez neunifikovaných/specializovaných obvodů pro akceleraci multimédií), který je schopný se zapojit pro vhodné případy výpočtů (velká paralelizace).
Dělal jsem diplomku na GPGPU právě v době vzniku unifikované architektury. Je pravda, že v té době dobře optimalizovaný kód využívající SIMD a další pokročilé instrukce byl poměrně solidně srovnatelný s kódem běžícím na GPU. Tehdy to byla prostě nafouklá bublina a GPU se svými 128 jednotkami, navíc organizovanými po 16ti se stejným instruction pointerem nebyla žádná sláva.
Od té doby nastal určitý pokrok a nejvyýkonnější GPU již mají 10 000+ malých jader s paměťovou propustnost kolem 1TB/s. Opět ale platí stejná omezení - větvený kód zabije výkon, je nutná vhodná loktalita dat, ideálně to musí být výpočetně intenzivní. V GPU jsou tranzistory investovány do "hrubého výpočetního výkonu" ale logika spouštění kódu, větvení a spekulativního zpracování je brutálně osekaná. Takže víceméně "Čínská metoda, dělá milion lidí ale tupou práci".
Jinak řečeno pro GPU jsou vhodné úzce spefické problémy. Například v trénování neurnových sítí, renderingu formou raytracingu (s příslušnou hw akcelerací), výpočtech které nevyžadují double přesnost, interace N ku N u problému se vztahem k fyzickému světu, například kalkulace distribuce seismických vln v terénu atd. Speciálně vhodné jsou pak vhodně namapované užití neuronových sítí v 8bitech kde je hrubý výkon skutečně brutálně vysoký (atakující i 1 petaflop). U těchto úloh lze dosáhnout zrychlení pořád i v řádu desetinásobků, místy i stonásobků proti procesoru.
Na zbylé problému tu prostě stále máme CPU.
Dále tu máme nějaké zákony ohledně priorit - pokud programátoři čím dál víc kašlou na optimalizace SW na málo se měnící architektury CPU (důvody nechme stranou), tak převod programů na GPU nebo dokonce optimalizace na stále se hodně měnící GPU architektury vůbec nepřipadá v úvahu.
je to tak v čem projekt začne tak s tím taky skončí klidně i za 10, 15 let, proto furt existují poptávky po programátorech, kteří ovladají z dnešního pohledu staré jazyky typu fortran
a ohledně optimalizace, tam se balancuje nad tím, kdo může ten kód napsat vs náklady na něj a jak je důležitý, aby super senioři dělali optimalizace, je jasný, že web v assembleru by byl rychlej, ale opravdu potřebuju prosikulky.cz načíst o 2 sekundy rychleji na úkor toho, že tvorbu webu v assembleru by zvládla hrska lidí oproti všem co dělaj weby v php, takže by tenhle web možná ani neexistoval
Já jsem se díval po nějakém info ohledně VLIW. Přišlo mi, že to pro tu grafiku asi dává smysl. Pochopil jsem z popisu, že velmi hodně záleží na kvalitě kompilátoru. Teď, jak jsem si přečetl tento článek, tak to vypadá, že pro hry by VLIW mohl být výhodnější, oproti univerzálním výpočtům. To mi teď vrtá hlavou, kterým těm výpočtům to nesvědčí a kterým ano...
No, RDNA3 má vyjít teď v létě, nebo na podzim, jestli se nepletu. Takže uvidíme. Počítám, že testů se hnedle vyrojí mraky. Nejsem jediný zvědavec na světe. :)
https://community.amd.com/t5/archives-discussions/why-gcn-architecture-i...
Vybraná odpověď v té diskuzi opomíjí dvě zásadní skutečnosti:
1. Tahiti (GCN) oproti Caymanu (VLIW-4) navýšila počet tranzistorů o 60 %, ale počet ROP zůstal, taktovací frekvence téměř nestouply a počet aritmetických jednotek se zvýšil o 33 %. Takže i čistý aritmetický výkon stoupl podstatně méně než počet tranzistorů, který na implementaci této architektury padl. Když se člověk podívá na VLIW-5 GPU Barts, tak jeho hypotetický dvojnásobek (který by měl o ~10 % vyšší aritmetický a 2× vyšší rasterizační výkon oproti Tahiti) by stál o 14 % méně tranzistorů než Tahiti.
2. Popsané nevýhody jsou nevýhody z pohledu výpočetního (nikoli grafického) nasazení.
Zkrátka GCN lze ve výpočetním nasazení snáze a efektivněji využít, ale druhá strana mince je ta, že v rámci daného rozpočtu tranzistorů bude mít na ní postavené GPU nižší grafický výkon než stejně velké GPU s VLIW-5.
GCN je úkrok stranou, nakonec se to až tolik nevyplatilo, hlavně v profi segmentu, ale to mohli rozdělit vývoj na dvě větve. Vypadá to že to spěje k takovému scénáři. Osobně mě byl VLIW-4 alias Kajman nejsympatičtější.
GCN není úkrok stranou, byl to od AMD jediný možný a správný krok, pokud chtěli dosáhnout nějakého většího úspěchu v GPU byznisu (datacentra, HPC, AI). Co se čistě herních karet týček, tak má NO-X pravdu v tom, že VLIW karty byly efektivnější, ale moc nevěřím tomu, že by se AMD ke VLIW architektuře někdy vrátilo. Myslím, čistě VLIW.
Jirka má na mysli patent AMD, který se nazývá SUPER-SIMD a jde o kombinaci VLIW (very long inst word) a SIMD (GCN) https://patents.google.com/patent/US20180121386A1 GPU by bylo stále v základu SIMD/RISC, ale pro určité výpočty by využivalo VLIW instrukce. Jde o starší patent, jako spousta jiných které AMD publikovala, ale těžko říct, zda se někdy opravdu dostane do nějakého GPU.
Rozdělení GPU na dvě divize by tomu sice nahrávalo, ale jde o tak velkou architektonickou změnu, že k něčemu takovému zkrátka AMD nikdy nepřistoupí. Už teď se obě větvě , CDNA/RDNA docela zásadním způsobem liší, přesto že obě v základu vycházejí z původního GCN a v tom já osobně vidím další směr vývoje herních grafik.
„byl to od AMD jediný možný a správný krok, pokud chtěli dosáhnout nějakého většího úspěchu v GPU byznisu (datacentra, HPC, AI).“
Záleží na úhlu pohledu. Za celé éry GCN v segmentu HPC grafik nevydělali prakticky nic a zároveň ztratili obrovskou část podílu v herním segmentu. Ani jedno nelze dávat za vinu architektuře, obojí byla chyba managementu, ale tak to prostě dopadlo. Pokud by se tehdy na HPC vykašlali a cílili čistě na herní grafiku, tak by v HPC stejně o nic nepřišli a mohli mít vyšší podíl v desktopu.
Na druhou stranu z GCN dnes těží RDNA i CDNA.
Bez těch začátků by ale dnes HPC byznys neměli. Intel není ani v té první fázi.
Záleží, co považujeme za ty začátky. GCN byla vydána na přelomu 2011/2012. První verze ROCm byla vydána na přelomu 2016/2017, za éry Vegy, tedy poslední verze klasické GCN. Těch předchozích 5 let se nedě(la)lo nic, management nejspíš předpokládal, že pro úspěch ve výpočetním segmentu stačí vhodná architektura. Těchto pět let bylo zcela ztracených a pokud by AMD těchto pět let měla na trhu graficky orientovanou architekturu, pak by podle mě neztratila vůbec nic, protože těchto pět let v HPC segmentu nic neměla a prakticky se ani o nic nepokoušela.
Demers tvrdil, že po něm vedení chtělo výpočetní architekturu a proto GCN vznikla. Před vydáním GCN se ale vedení změnilo, nastoupil Rory Read a po vydání GCN rozhodl, že se grafická divize ořeže a jejím cílem budou APU a konzole. Tedy přesný opak toho, pro co byla GCN vyvinutá. Začátek využití toho, k čemu byla architektura určená, přišel až za éry Lisy Su a to teprve v době, co byla situace procesorové divize vyřešená dokončením Zenu a vedení se začalo věnovat grafické divizi. Pokud by něco na způsob GCN přišlo na trh právě v roce 2017, tak by to stačilo.
Tak chyby tehdejšího vedení si tu kritizoval několikrát i ty. Architektura GCN nemůže za to, že se pak změnily požadavky.
Ono na GPU stačí urobiť výpočet podľa všetkých vetiev programu a nakoniec vybrať platnú vetvu a tým výsledok.
Áno je to princíp 1,5 mld. číňanov s osvieteným vodcom, ale na GPGPU funguje. Ono by to "krásne fungovalo" aj pre CPU a neboli by potrebné prediktory.
Kdysi možná, ale dnes je hlavní limit výkonu spotřeba. A ta by šla brutálně nahoru.
Autodesk technologie se uplatňují v profi i v herním segmentu. Obávám se že rozdělení grafik na dvě vývojové větve bude špatný pro 3D programy (AutoCAD, Revit) a tedy celý stavební průmysl. Přechod na BIM (LOD 500) to vrátí o několik let zpátky.
Nakonec to bude směřovat k tomu že WS bude mít dvě grafiky. Jednu na zobrazení 3D a druhou na výpočty. Doufá že ne, protože to bude chtít optimalizace, to je u výrobců SW sprosté slovo.
Nebo to pojede ve VDI a žádné optimalizace nebudou potřeba :-). Jinak na spoustu CADovského softwaru stačí i Intel iGPU a na automatické testy ve VM dokonce i MesaGL. Aspoň tak to je u našeho software pro statiky, co s cenou začíná na 100 tis. Kč.
EDIT: Zobrazení můžeš mít lokálně a výpočty vzdáleně. Měly jsme kód, kde výpočet jel v Azure, ale autor pak vážně nemocněl a firma v tom nepokračovala.
intel iGPU by chodila dobře, kdyby měla vyladěné ovladače. AutoCAD 2018 na APU(Ryzen 4500U) chodí krásně. Ale novější verze přidali omalovánky a je to bída. (Původní AutoCAD R12 chodil na i386)
VDI zní hezky, v benchmarcích dosahuje slušné skóre. Srovnatelné s poctivým železem. Nějakých 10% výkonu bych jim odpustil. Ve vzdálené akceleraci GPU udělali velký pokrok. Funguje pěkně.
Ale pak se ukáže informace, jaký problém je pro M$ vykreslit blikající kurzor, nedej bože jednu číslici za jednu vteřinu: https://www.windowslatest.com/2022/04/17/microsoft-explains-why-it-wont-... a celý RD bych nejraději poslal k čertu.
U WS je nejdůležitější odezva systému. Takže VDI bych moc nevěřil. Ale rád se nechám přesvědčit o opaku...
Tak předpokládám, že by ten server byl v baráku té firmy. Tj. v práci připojím notebook k monitoru, klávesnici a myši, ale jede to na serveru o pár pater vedle. Např. u hraní přes Steam Remote Play (pro bráchu jediná možnost, jak na macbooku s M1 hrát většinu her - lokálně z jeho knihovny skoro nic neběží) to v LAN na server ve stejném domě má lag 20 ms (Steam ukazuje detailní grafy jako overlay), což je hodně slušný (většina lidí nepozná). U WiFi 50 ms, ale máme nějaké hodně staré a hodně levné routery, které mají výkonové problémy obecně. Takže předpokládám tohle lze mít lepší.
WiFi funguje dobře jen za ideálních podmínek:
Přímá viditelnost.
Žádné rušení.
Jen jeden uživatel.
K tomu VDI: Trochu to ztrácí smysl když je server v baráku. Serverovna je drahá sranda. Potřebuješ klimatizaci, konektivitu se slušným SLA, nějaký baterky....
Latencí na internetu bych se nebál. Za poslední roky se to dost zlepšilo. VDSL kolem 10ms, mobil kolem 30ms (4G stejně jak 5G).
Spíš mám obavu že to bude brzdit server.
Většinou je projekt největší těsně před odevzdáním, a to na něm dělá taky nejvíc lidí.
Když ti hoří termín, tak lagování nechceš řešit.
Tak to máme dobrý, že nám WiFi funguje. Jinak pokud se nebojíš latence do internetu, tak v cloudu si naklikáš server, jaký chceš (klidně silnější pro období většího využívání).
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.