Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Vela odidencov z Intelu pochytal chujawej
No trochu mi to připomíná Intel. Tam si také někdo myslel, "máme už léta integrované GPU, tak přece na jeho základu navrhnout velké herní a nebo pracovní GPU nebude problém". No dnes už si to tam nikdo nemyslí. Navrhnout nové GPU je 30% práce a 70% jsou ovladače.
Zas na druhou stranu, pokud věří, že ty ovladače zvládnou, tak proč ne. U toho Intelu to byl stejně hlavně humbuk novinářů, aby měli kliky, protože jestli DX9 hra jede 100 nebo 600 fps je běžnému uživateli jedno. A napsat driver pro lowlevel API (DX12/Vulkan/Metal) je zlomek práce* a naprostou většinu optimalizací si dělá vývojář sám**. V ovladači tak není potřeba seznam quirků pro 1000 starých her.
*) první Vulkan driver byl za pár měsíců už v roce 2015: https://blog.imaginationtech.com/trying-out-the-new-vulkan-graphics-api-...
**) "When you fill in a struct describing some state using Vulkan, you know that there is no driver work going on; the code is all application code. The API is designed to fit as best as it can to all GPU vendor’s architectures so there are fewer opportunities for unknown performance hiccups."
EDIT: Intel pak napsal vlastní driver pro DX9, kde ty problémy vyřešil.
Ono nešlo ani tak o to, že to neběželo na 600 FPS, ale že distribuce snímků nebyla plynulá (microstuttering), že obraz často obsahoval artefakty a že ty hry padaly.
https://diit.cz/clanek/recenze-arc-a380-ovladace-jsou-jako-minove-pole-k...
Korunu tomu Intel nasadil, když oznámil, že nebude řešit situaci s cukáním obrazu na platformách nepodporujících resizable bar.
Nové grafiky vyjdou roky po problému s resizeable bar. Takže je to příklad něčeho, co i kdyby bylo znovu, tak už to nikdo řešit nebude.
A nikdo nebrání výrobcům GPU vylepšit wrapper pro staré DirectX. Microsoft ho dal na GitHub.
Tak nevím, jestli bych chtěl dělat novou grafiku s propuštěnými inženýry z Intelu 😁
Záleží, jak moc jim do práce kecali manažeři.
další příležitost pro Koduriho talent :-D
A není to málo Antone Pavloviči? Drivery grafické karty, to je takový rabbit hole, že 100 lidí by měl (alespoň na začátku, než se vyřeší kompatibilita s existujicimi hrami) mít samotný siftwarový tým.
Staré hry řeší emulační vrstva/y (přítomna ve Windows, macOS i Linuxu). I kdyby to jelo na 1/10 výkonu, tak je to furt 60+ fps. A nové hry za prvé používají lowlevel API, kde tvůrci driveru nemusí řešit quirky pro staré hry, a často jen 2 enginy (Unreal, Unity), což se dá pokrýt spoluprací s autory těch enginů.
To je dost naivní. Předně i hry v těch enginech mají quirky samy o sobě. A hlavně vůbec nepokryvaji majoritu her. Za poslední ~rok jsem hrál D4, POE, Starfield, BG3, ac Valhalla. Nic z toho není U/U engine...
To neodporuje tomu, co jsem psal. Ta třetina her, co má in-house engine, se bude řešit individuálně. I tak je to menší procento než kdy předtím.
Kdybychom uvažovali jen "to nejde", tak se nikam neposunem. Nové řešení nemusí vyhovovat 100 % uživatelů. Ale i kdyby stačilo "jen"* 25 % uživatelům, tak je to velký posun: budete mít levnější Nvidii ;-)
*) Z tak velkého koláče je to furt hodně $$$. Vemte si, že z GPGPU má AMD jen 10 %, a jak si čvachtá a ostatní firmy jí závidějí
Problém je v jedné věci - ti co dělají recenze a nezávislou publicitu na netu jsou zrovna ti samí co požadujou 100% funkčnost. A pokud tam jsou problémy tak je z toho negativní publicita co způsobí že si to nekoupí ani ti lidi co by jim to stačilo.
To je stejný jako s přechodem Applu na ARM a nově PC/Windows s Qualcommem. Recenzenti to zdrbou, ale ono to dál funguje a nabírá uživatele. I tak je firma "v balíku", protože pracují s menšími náklady, takže furt mají zisk.
Ladis - je dost rozdíl Apple, které komplet mění platformu a uživatelé nemají na výběr a alternativní možnost k něčemu, co funguje. Tam ta funkcionalita být musí, jinak nepřesvědčí stávající uživatele doposud fungující platformy k přechodu.
Uživatelé Apple mají na výběr switchnout na PC a naopak. A pak samozřejmě držet starý počítač, dokud funguje (Apple má dlouhou SW podporu, a pak nebrání i neoficiálně aktuální macOS).
Navíc ten Qualcomm se docela povedl (bodejť, inženýří přetáhnutí od Apple Silicon):
1. +50 % ST výkon oproti M1, kde porovnávaný kód na M1 je nativní a na Qulcommu *v emulaci* (na Windows nutné, protože ze začátku toho moc nativního není).
2. Strong memory model (není nutné vkládat do emulovaného kódu memory barriers).
3. Emulace x86 FPU (kvůli speciálním možným výsledkům není nutné obalovat každou FPU instrukci kontrolou různých situací).
4. Oproti x86 funkční uspání.
...
Zase se začínáš opakovat. V rámci ARM jde o výkonný CPU, to nepopírám, ale celkově existuje víc výkonných ARM jader, ale většina z nich je pro uživatele nedostupná a nebo není na trhu vůbec, protože si to firmy jako Google nebo MS udělaly pro sebe.
Tak za prvé, když nejsou ty ostatní procesory dostupné, tak proč je uvažovat? Za druhé, serverový procesor má hodně jader, ale ne single-thread výkon (ani ho nepotřebuje).
Já se bavím přímo o variantách ARM jader. Poměrně zajímavě pro neoptimalizovaný SW je Neoverse V2 to vychází z Cortex X3 a jako první umí ARMv9.0-A set. Má 4x 128 bit vektory. Do PC by klidně 12 jader stačilo, ale nic takového není. Jsou na něm jen NVIDIA Grace, AWS Graviton4 a Google Axion. Neovese V3 už má 2x 256 bit, tam už to chce upravený SW kód.
Nikdy jsme neviděli běh neoptimalizovaného SW na jádrech Neoverse. Ani nevíme, jestli podporují strong memory model a x86 FPU, nutné pro použití v PC. Jádra Oryon od Qualcommu, který koupil konkurenční Nuvii, to mají, a proto i v emulaci beží v ST o 50 % rychleji než M1 nativně (pozor, dnes už je M4).
Strong memory možná vyžaduje Win. Ale pod Linuxem to může klidně být jinak a tam i nějaký x87 FPU (x86 FPU je nesmysl) je nepodstatný. Ta výkonná jádra na serverech jedou na Linuxu nebo BSD.
Výkonná emulace x86 potřebuje strong memory model a x86 FPU (nejde jen o x87, +oo, -oo apod. jsou i v SSE/AVX). V každém OS. Proto je emulace na Linuxu ještě pomalejší než ve WIndows, protože tam ten kód je jen obecný pro Cortex, který to neumí.
Kdybych si pořizoval výkonnější ARM a Linux, tak mne nějaká Win emulace nebude zajímat. Protože budu chtít, aby všechen SW jel nativně. Už si rozumíme? A stejně kdyby to měl být jen úsprný desktop na Web, zase mne x86 emulace nezajímá. A na výkon a případné hraní bych k tomu měl x86/Win.
Pro "pár" lidí je "všechen SW" i komerční closed source věci. Na tomhle pohořel i x86 Linux.
Linux pohořel na více věcích. Je spousta SW částí, kde se nedohodli a je tam víc paralelních řešení. Kdyby se dohodli a dělali by ti programátoři společně, vypadal by Linux úplně jinak. A z hlediska uživatele, každý se přece může rozhodnut, zda pojede free only a nebo tam, kde to je výhodnější vezme komerci. Typicky třeba ovladače grafiky.
> 1. +50 % ST výkon oproti M1, kde porovnávaný kód na M1 je nativní a na Qulcommu *v emulaci* (na Windows nutné, protože ze začátku toho moc nativního není).
Too good to be true. Nie je ta emulacia nejaka tenka takym sposobom, ze dotycny kod velmi rychlo vola API widli, ktore uz bezi ako nativna ARM binarka?
Ano, stejně jako na macOS (bohužel zatím ne na Linuxu, ale pomalu se na tom dělá).
Na Linuxe je taka emulacia na dve veci, nie? Prelozim na ARM nativne a x86tkovu binarku mam u prdele.
A co třeba closed source aplikaci? Třeba komerční hra? Na macOS a na Windows on ARM na novém Qualcommu není problém.
Jak jsem psal, ARM by měl smysl pro Web, na Win / x86 je lepší PC.
Mě ty closed source x86 aplikace fungují dobře i na Apple a Qualcomm CPU.
Už s tím Apple přestaň otravovat.
A Qualcomm?
Zatím ho neřeším. Až bude Win on ARM trochu vyzrálá, tak se uvidí.
Už je. Mám ho doma.
Gratuluji.
Dík.
Ta CPU nejsou špatná, ale než osloví nějakou větší část uživatelů, to ještě potrvá.
To samé platilo pro Apple Silicon.
Tam je ten příběh trošku delší a složitější.
Na Windows on ARM bude taky.
Windows se zrodily na x86 a dominantně na něm fungují a zatím žádný pokus o Win na jiné platformě moc nefungoval. A že jich bylo. Alpha, MIPS, Itanium, ARM - píšu jen ty významnější. Možná se neměli rozhádat s IBM a jet ten společný vývoj. Už tehdy všichni říkali, že OS/2 byly lepší.
MS je softwarová firma, podporuje CPU, které jsou na trhu, a přestane, když se později ukáže, že zákazníci o ta CPU nemají zájem. Některé ty architektury byly lepší než x86, ale konkurence je zabila. Např. Alpha byla násilně nahrazena Itaniem. Levný MIPS zas výrobci sestav dávali jen do drahých workstationů, kde tento výkonný CPU nestál skoro nic. Samostatně byla snad jen jedna deska pro obyčejné lidi. A první pokus Win on ARM skončil na tom, že Intel jim zakázal tam dát x86 emulaci.
Alpha v té době už byla mrtvá. HP co ji tehdy vlastnila, pohřbila i své PA RISC. Proč by měli podporovat cizí CPU? Oni kopili DIGITAL i z jiných důvodů než jen kvůli CPU. Tedy mimo to, že vlastně převzali primárně Compaq.
Právě, jejich architektury zabili, protože Intel jim slíbil, že Itanium bude lepší.
Pokud vím, vývvoj Itania chtěl HP. Byl to společný projekt. Že se na to Intel pak upnul a chtěl tím nahradil x86, je jiná pohádka. Ale CPU silně závislý na SW kompilaci a optimalizaci, protože neuměl přeuspořádat a optimalizovat pořadí instrukcí... Speciálně s tím, jaké problémy Intel už v minulosti s kompilátory měl, viz Intel iAPX 432, i80860, 80960...
Tehdy byl dekodér instrukcí velká část die. Dnes by byl taky, kdyby chtěli v x86 dekódovat víc jak 4 instrukce za cykl - zatím to nahánějí frekvencí. Taky tehdy neměli moc zkušeností s možnostmi out-of-order.
Nepíšu o dekodéru, ale o out of order vykonávání. Byl to VLIW procesor, proto byl tak silně závislý na kompilátoru.
Právě že tehdejší idea byla přesunout práci dekodéru do kompilátoru.
Ta idea vznikla už dřív, ostatně 80860 byl taky VLIW. A taky se nejvíc uplatnil v TOP řešeních SGI grafik, přesněji u RealityEngine. Aplikací bylo víc, ale vždy dost specializované. Nicméně Intel si na tom vyzkoušel SIMD jednotky, které pak užil v Pentiu MMX.
Pro GPU fungovalo VLIW dlouho.
Ale GPU vykonává jen vysoce optimalizovaný kód. U CPU to ale nejde zaručit a pak výkon padá.
Proto Itanium skončilo jako slepá cesta.
Není EPYC jako EPIC (Explicitly Parallel Instruction Computing).
https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing
Pokud k tomu je zdroják. Což u komerční aplikace obvykle není.
To je zajímavé, že když vydal grafiku Intel a spousta věcí nejela, tak to byl velký fail. A teď prý stačí 20 %
U Intelu je jiný problém, grafik vyrábí/ěl málo a k lidem se dostávaly s velkým zpožděním. Pro lidi, co věděli, co chtějí (např. práce s videem, výpočty potřebující hodně VRAM nebo kdo hraje vybrané hry), to byl dobrý kup.
Ladis - Mělo by to vyhovovat aspoň 4/5 a je jedno, když 1/5 bude nadávat. Cílit na 1/4 je málo.
AMD třeba v GPGPU cílí na 10 % a ostatní by rádi její úspěch zkopírovali.
To je ale něco jiné, tady jde o specializovaný trh, kde se často dodávají HW i SW řešení na míru velkým odběratelům. Ale přesvědčit běžné uživatele, je něco jiné a speciálně, když nová alternativa má potíže a současně je dražší a jediná výhoda je, že proti stávajícímu úspornému řešení má být ještě úspornější. (Příklad ARM Windows)
Jim stačí přesvědčit uživatele AMD, protože těch je už dost a s výpočty na GPU furt bojují.
Nebojují, spíš jde o to, že programátoři GPU jsou zvyklí psát pro Nvidii a na AMD se ještě nenaučili. Právě proto si AMD teď pořídila SW tým.
Jak se mají naučit psát pro AMD GPU? AMD samo řeklo, že OpenCL byl krok vedle a ať jeho podporu odstraní z Blenderu (nikdy pořádně nefungoval kvůli bugům v driveru; navíc OpenCL skončilo, protože jeho autor - Apple - ho přestal nabízet na svých GPU). Jejich emulace CUDA není 100% bezproblémová a vyžaduje manuální úpravy kódu a projekt, který emuloval CUDA 100% na binární úrovni, jim NVidia nařídila smazat z GitHubu.
Open CL možná nebylo špatné, ale Nvidia prostě měla náskok a tak software vznikal jen s podporou CUDA. Tím pádem většina - spíš všichni programátoři jeli pro CUDA a Open CL téměř nikdo neuměl, tak ho AMD zařízla. Patrně by AMD CUDA podporovala dřív, jenže Nvidia se brání. Takže AMD má lepší HW, ale mimo velkých projektů a superpočítačů ho špatně prodá. Je to uzavřený kruh a jediné řešení, je násobně navýšit SW tým přímo u AMD, což udělali.
Intel to obchází svým oneAPI, do kterého se snaží zlanařit ostatní. Počítal, že NVidia chtít nebude, tak sám napsal wrapper oneAPI-->CUDA, takže na NVidii to funguje by default.
Ale to určitě má nějaký dopad na výkon.
Moc velký ne. Nezapomeň, že typické použití GPGPU je z Pythonu, takže wrapper v C/C++/Rust bude ta menší brzda.
Záleží jaká aplikace. Pochybuju, že na superpočítači je nějaká mezivrstva. Protože SW je u AMD problém, tak bych řekl, že menší věci jako běžné servery a pracovní stanice obsluhují spíš Nvidia GPU a větší instalace, kde se SW dělá na míru spíš AMD. A protože to AMD chce změnit, tak investovala do SW týmu.
Na druhou stranu, nemusí to být nutně a prvoplánově GPU pro "klasický" desktop s Windows. ARM se nasazuje na mnoha platformách a jedna široce rozšířená jsou mobily, potažmo tablety, případně VR headsety. Tam nějaká zpětná kompatibilita se světem x86 a chybami ve volání herních API nehraje roli.
Potom je tu svět takových těch "malých" počítačů na domácí "hraní si" jako třeba "různé ovoce" Pi, jako notebooků ve stylu chromebook. A tam ta kompatibilita s Windows hrama také nebude zásadní.
Teprve nakonec bych se díval někam do vod kolem Windows on ARM, protože něž ta fungl nová grafika dosáhne nějaké mainstreamové úrovně, aby byla považovaná za herní grafiku, tak to IMO docela potrvá. Teprve potom bych se obával, co provoz starých, více či méně, špatně odladěných her.
Tak i Qualcomm zvládl GPU pro Windows. Jeho Adreno (přesmyčka od Radeon, tým koupen od ATI) pro Windows on ARM umí konečně vedle DirectX i OpenGL, OpenCL a Vulkan. Brácha na tom zkoušel hry a jely tam lépe než na Apple Silicon + CrossOver. Situace podobná jako tehdy na Linuxu implementace DirectX 9 dokázala nahradit zbastlený překlad na OpenGL ve WINE (větší výkon, bez grafických glitchů). Spousta lidí má notebook jen na ten internet a méně náročné hry (nové indie, starší AAA). Nejnovější AAA hry stejně neběží ani na x86 laptopech kvůli chybějícímu výkonu GPU, tak je jedno, že ovladače jsou vyladěnější. Teda kromě Intelu, který je většina notebooků. U starých klasik bere člověk jako bonus, když z nich půlka funguje. Mimochodem spousta má opensource remake enginu, takže jede nativně třeba na Apple Silicon.
Je fajn, že je možné nahlédnout do diskuze i u takhle starých článků. Člověk se alespoň trochu zasměje. 🙂
Dík za tip :)
Adreno je určitě efektivnější než Radeon, tak se třeba vrátí pasivně chlazené karty. Expandovat z mobilů je určitě reálnější, než expandovat z PC do mobilů, protože v PC není zdravá konkurence už desítky let.
Kdyby nebyla v PC konkurence, to by teprve lidi nadávali...
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.