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.
Pokud tam budou stále stejný shadery, ale vypínatelný (taktovatelný), tak je to asi lepší nápad než dělat "široký shadery" a "úzký shadery". Ale je to teda těžká fyzika - docílit, aby se ty transistory na konci spolu potkaly ve stejný čas. Otázka je, kolik % dat má takovou povahu, že by bývalo bylo rychlejší je počítat na širším SP. Asi málo (tj. i ty nejširší 512bit jdou zgranulovat), takže hype o "různé šířce shaderů" se nekoná. V tomto ohledu by mě zajímalo, jestli SP je "spíš integer" nebo spíš "float" stroj, resp. do jaké (malé) míry je integer, myslím kolik křemíku navíc stojí "integer provoz". Na Voltě V100 mastodontu je vidět, že rozhodně zadarmo to není. Zajímavý bude, co na to nVidia - nápad je to dobrej a neumím si představit, jak patent obejít, aby dosáhla podobné funkce. Škoda, že je to nenapadlo dřív, protože při 5000 shaderech současné generace ten přínos "mikroturba" odhaduju tak na 10 %, spotřeby nebo výkonu, to je jedno.
na tom měli pracovat dávno - už od doby kdy věděli že aplikace využívají jen část té spousty výpočetních jednotek. Proto NV vystačila s méně ale silnějšími než s mraky slabých. Ale to už se táhne od HD3XXX, času měli dost, jenže všechny ty organizace a zpětné reorganizace narušovaly vývoj, takže jediné kde opravdu excelují je výpočetní oblast, zbytek je šedivý průměr.
„Proto NV vystačila s méně ale silnějšími než s mraky slabých.“
Teď by mě ještě zajímalo, kde se vzala informace, že výpočetní jednotky Nvidie jsou „silnější“.
záleží jak se to vezme, ale podle marketingu AMD bylo 320SP proti 128SP Nvidia - a dostávalo to na kokos. Vím že to bylo 64 s pěti minijednotkami, jenže ty byly softem využívány jen max dvě-tři z pěti. A marketingově to bylo nešťastné, zrovna tak jako stavění jednoho BD modulu na úroveň klasického dvoujádra. Že by 64 posílených "multi jednotek" dostalo na prdel od 128 normálních nvidie by zákazníci vzali mnohem líp než házení hausnumer z maxima možných výpočetních možností, tedy 320. Pak to bylo pro smích že 320SP dostává nářez od pouhých 128 jednoduchých konkurence. Ale v praxi se to bere tak že myriády malých jednotek soupeří s mnohem menším množstvím "klasických" nv. V principu se tyhle jednotky berou samostatně a jestliže velká část leží ladem, pak jde efektivita do kopru. Na výpočty je taková architektura fajn, ale na konzervativnější herní enginy už o hodně méně.
Co píšeš, má zádrhel a ne jeden.
1. Posuzuješ výkon výpočetních(!) jednotek na základě FPS v grafických(!) úlohách. Na grafických úlohách se podílejí mimo jiné texturovací jednotky, ROP, geometrické procesory a řada dalších obvodů. I výpočetní jednotky, ale jen jako jeden z mnoha prvků.
2. Srovnáváš počet výpočetních jednotek, ale zapomínáš na jejich frekvenci, která bývá u Nvidie o polovinu vyšší.
3. „AMD bylo 320SP proti 128SP Nvidia“ - zároveň to bylo 16 texturovacích jednotek na straně AMD proti 32-64 texturovacím jednotkám na straně Nvidie.
Nemůžeš si z čipu vybrat jednu část a považovat ji za zodpovědnou za veškeré jeho vlastnosti.
ano, vzal jsem to hodně zjednodušeně ale princip odpovídá. Multi vlákno vs posílený výkon jednoho na maximální efektivitu, která byla daná programy které mnohem víc využily singl výkon než bohaté větvení. A pro laika to při výběru působilo hodně negativně - mají mraky jednotek a přesto dostanou napráskáno. Proto v téhle oblasti spolehlivě platí ono okřídlené "více proužků, více addidas". Ostatně jako dnes, ani 2300SP spolehlivě nevydrtí pouhých 1280SP NV. Rozdíl frekvence tam je, ale ne tak dramatický aby ospravedlnil potupnou remízu s o tisíc sp slabším čipem.
Ne, princip právě vůbec neodpovídá. Tedy stručně: Pokud chceš měřit výpočetní výkon a výpočetní efektivitu, měř to ve výpočetních úlohách. Pokud chceš měřit grafický výkon a grafickou efektivitu, měř to v grafických úlohách. Nemůžeš ale na základě výkonu v grafických úlohách dělat závěry o výpočetním výkonu. Protože pak jsou ty závěry nesmyslné.
Ne. Nechci exaktně měřit výkon. Od počátku šlo o prosté srovnání jak se aplikace staví k daným hw prostředkům čipů amd a nv. A výsledek je ten že hw nvidie je využit lépe a jen velmi málo toho "lelkuje", díky jednodušší konstrukci kde se programy nemusí draze a složitě optimalizovat. To je zásadní nevýhoda překombinované architektury AMD. Mysleli si že dodají hw a výrobci sw budou celí nadšení investovat tisíce člověkohodin do vytváření aplikací na jejich složitý čip. No a když zjistili že ne tak konečně došli k tomu že sami musí udělat řádný management na úrovni hw, jinak část jednotek bude neustále ležet ladem. Málokdo si dá tu práci detailně optimalizovat sw specielně na jejich čipy když jde o firmu která je na trhu číslo dvě a to dlouhodobě.
https://www.youtube.com/watch?v=6eNVv2yhDVE
nie som finewine teoretik, ale je naozaj otazne co povazovat za lepsie.. ja v tom tak jasno nemam ako ty
Mňa tak isto
GV100 21 mld. tr. 815 mm² 28,1 TFLOPS
http://diit.cz/clanek/nvidia-na-isc-predstavila-teslu-v100
a proti tomu VEGA
Radeon Instinct MI25 525 mm² (odhad) 24,6 TFLOPS
http://diit.cz/clanek/amd-uvadi-instinct-miseries
výkon na mm² :
Volta: 28,1/815 = 0.0344785276 TFLOPS/mm²
Vega: 24,6/525 = 0.04685714285 TFLOPS/mm²
Ja viem reálne treba porovnávať
TFLOPS/mm²/W/USD .. :)
Zakladni myslenka tohoto konceptu urcite nekoho napadla uz pred vetsi dobou, ale problem je v realizaci. Podobne hratky potrebuji uplne novy pristup k regulaci napajeni, ohromne mnozstvi senzoru na chipu a firmware, ktery to vsechno bude ridit.
Myslim, ze ted vsichni docela kuli oci na to co AMD zvladlo se Zenem a co vsechno umi power management Epycu. Tohle je v podstate aplikace dalsiho vyvojoveho stupne stejne technologie, ale na GPU misto CPU.
Něco podobného dělá Intel s AVX2 jednotkami, ne?
„I observed an interesting phenomenon when executing 256-bit vector instructions on the Skylake. There is a warm-up period of approximately 14 µs before it can execute 256-bit vector instructions at full speed. Apparently, the upper 128-bit half of the execution units and data buses is turned off in order to save power when it is not used. As soon as the processor sees a 256-bit instruction it starts to power up the upper half. It can still execute 256-bit instructions during the warm-up period, but it does so by using the lower 128-bit units twice for every 256-bit vector. The result is that the throughput for 256-bit vectors is 4-5 times slower during this warm-up period. If you know in advance that you will need to use 256-bit instructions soon, then you can start the warm-up process by placing a dummy 256-bit instruction at a strategic place in the code. My measurements showed that the upper half of the units is shut down again after 675 µs of inactivity.“
http://www.agner.org/optimize/blog/read.php?i=415#415
No a pak vyskakujou grafický dropy, když se má vykreslovat kabát ve větru. A on se jen Skylake zahřívá :D
Tak pokud jde o časování, tak tam je zajímavá spíš ta informace o dočasném podtaktovávání, kdykoli procesor narazí na instrukci ze sady AVX.
Urcite se v AVX zatezi podtaktovavaji Xeony Broadwell-EP. Desktopova CPU to myslim nedelaji a jak to maji ostatni Xeony nevim.
Desktopový Skylaky se, pokud je mi známo, nepodtaktovávají při užití AVX. A AVX jednotka je pěkná mrška při OC. Sám mám OC CPU a myslel jsem si, jak snadný to bylo přetaktovat. Ale pak jsem si pustil střihací studio, který při renderingu AVX používá a nebylo schopno práci dokončit, uprostřed renderování se zastavilo s chybovou hláškou. Zajímavý je, že studio ani systém nezamrzl, prostě jen přestal renderovat a po odkliknutí chybový hlášky šlo pracovat dál, jako by se nechumelilo. Nakonec jsem tedy zvýšil napětí CPU na 1,37 V a takt vyhnal na 4,5GHz. Vždycky, když čtu články o OC, zajímalo by mě, zda autor práve AVX řádně potrápil.
Technická: odkdy patent z USA potvrzuje, že to co je v něm popsáno je k něčemu dobré nebo snad i realizovatelné?
Seznam nesmyslných patentů si můžete prohlédnout na https://www.lhup.edu/~dsimanek/museum/patents.htm
Vzhledem k tomu, že to popisuje řešení vyvinuté prakticky na míru GCN, zároveň to řeší aspekt, ve kterém nejvíce zaostává za konkurencí a zároveň to technologicky navazuje na předchozí patent, je prakticky jisté, že to bude použité. Otázka spíš je, jak dlouho potrvá něco takového implementovat.
Super!
[přečte si článek]
Ach jo. A já už myslel, že tím titulkem je myšlena plně asynchronní logika typu AMULET, F21 apod. Tak na to si asi ještě počkáme. :-)
Tak i Ryzen a EPYC maju samostatny regulator napatia a riadenie frekvencie pre kazde jadro.
Ale ak hovorime o roznej frekvencii, tak u GPU to je problem. Sice nie az tak hardwarovy. Nezavisle taktovanie je len mala zmena, lebo uz i prve GCN (napr. 7970) maju samostatny Program Counter pre kazdu wavefront (co je 64 threadov, ktore su vykonavane na 1 SIMD v 4 cykloch) a kazda SIMD moze fungovat asynchronne.
To sa prave vyuziva pri asynchronnych shaderoch, kde sa vykonava viac shaderov (programov) naraz a predpoklada sa ze kazdy pouziva ine data. Tu hovorime o malom pocte roznych shaderov, vacsinou su to len 2 shadery, co ale uplne postacuje na ten 20-40% boost vykonu.
A teraz ten problem, ktory sa tyka pristupu do pamate. Citanie/zapis do pamate je ta najpomalejsia operacia a trva 500-1000 clock cycles. GPU funguje najefektivnejsie ak cita velky spojity kus pamate naraz. A to je dosiahnute tym ze vsetky wavefronty su synchronizovane. Teda tie wavefronty ktore pocitaju spolocny shader program. Pri 2 shaderoch su to 2 skupiny wavefrontov ktore musia fungovat synchronne. Az by mali ine takty, tak by jednotlive wavefronty pristupovali do pamate v roznom case, co by vyrazne zhorsilo cache hit-rate a tym by to znizilo i vykon.
Ten pokles vykonu by bol vyssi nez zisk z niektorych vyssie taktovanych SIMD.
Preto sa podla mna asynchronne takty konat nebudu.
Nic ve zlém, ale tohle není drbání se levou rukou za pravým uchem. Předkládáš tu poněkud překomplikovaný způsob, jakým by bylo možné popsanou technologii implementovat a pak na základě toho, že je tvoje teorie příliš komplikovaná, vyneseš verdikt, že tato technologie nebude implementovaná.
Přitom existují naprosto jednoduché způsoby, které takový problém nemají. Prostá deaktivace nebo podtaktování (částí) některých SIMD ušetří energii, tím klesne spotřeba, automatické řízení spotřeby situaci ihned vyhodnotí a nastaví vyšší výchozí takt. Zvýšením výchozího taktu ke snížení hit-rate nedochází, vypnuté (části) SIMD žádné přístupy k paměti nevyžadují a případné podtaktované SIMD mají z principu věci nižší potřebu k přístupu do paměti, nikoli vyšší.
Ja nic komplikovane nepredkladam. Ty v clanku tvrdis ze niektore casti cipu budu mat vyssiu frekvenciu, cim sa ale podla mna rozbije synchronizacia.
Ale ak bude cely CU blok, alebo dokonca cele GPU fungovat na rovnakych zvysenych taktoch (co tvrdis teraz) a len niektore SIMD budu mat znizene takty, a GPU dokaze menit frekvenciu podtaktovanych SIMD s presnostou az na 4 cykly (tj. na 4 cykly znizim takty jedneho SIMD lebo nie je plne vytazeny), ktore su potrebne na vykonanie 1 wavefrontu aby to nenarusilo synchronizaciu,
tak s tym problem nemam.
„Ty v clanku tvrdis ze niektore casti cipu budu mat vyssiu frekvenciu, cim sa ale podla mna rozbije synchronizacia. Ale ak bude cely CU blok, alebo dokonca cele GPU fungovat na rovnakych zvysenych taktoch (co tvrdis teraz)“
Tato dvě tvrzení se ale nijak nevylučují. Druhé tvrzení je jen příkladem nejjednodušší implementace prvního příkladu.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.