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.
Polaris, Vega, Navi - je to jedno, pocitat to umi skvele.
Uz Polaris je ve vypocetnich operacich uplne nekde jinde nez konkurence, proste chcete levne vypocetni kartu, mate jasnou volbu.
Herni stranku veci tu radeji zminovat nebudeme, o tom clanek neni.
Teď ještě kdyby zvládli i tu softwarovou stránku a udělali co nejlepší implementaci OpenCL 2.x se SPIR-V. To je poněkud bolavé místo. O Linuxu nemluvě...
ano, to je pravda.
No nevim, ale pro to "nakladackove" schema je to naprosty nesmysl. Pokud nemam data pro zaplneni celeho simd bloku, snizeni frekvence bude pouze znamenat, zpomaleni vypoctu, tj ze simd bude delsi dobu blokovan neuplnym vyuzitim.
To snižování taktů nedává smysl... Pokud vycházím z toho, že SIMD funguje tak že za stejnou dobu dokáže provést stejnou operaci na 1-16 "datech", pak snížením frekvence ten "kamion" nezkrátím, ale zpomalím. Sice spotřebuje polovinu energie, ale na provedení operace bude potřebovat dvojnásobek času.
já to chápu tak, že na těch nepoužívaných (bílých jednotkách) SIMD dojde k redukci taktů nebo k jejich úplnému gatování, což znamená, že výpočty poběží pouze na červených jednotkách. Nicméně pochybuji, že Polaris nebo jakékoliv ostatní GCN čipy něco takového umí, protože to vyžaduje zásah do hardwaru.
Stavající čipy jako Polaris umí pouze gating celého CU.
Já se přiznám, že jsem nepochopil, jak dotyčný přišel s teorií o dosažení daného efektu saháním na takty celé SIMD. Vždyť vše, z čeho vycházel, říká cosi o proměnné "šířce" SIMD!
Z toho by mi vyplynulo, že každá z 16 cest pro data má samostatný on/off stav.
no taky je tam rec jak o celejch simd tak o ruznejch taktech pro jeden simd.. takze muzes zabrzdit celej simd kdyz neni treba na vysledek chvatat nebo muzez zabrzdit jen kus co je ''prazdnej '' (: me to prijde docela zajimavy..
Snížením frekvence (je-li současně implementováno i synchronní snižování napětí) se až do jistého bodu spotřeba snižuje rychleji než výkon. To sice nebude platit u velmi nízkých frekvencí, ale určitě to bude platit třeba při snížení z provozního maxima na dejme tomu 60% maxima.
To tak prave nie je
spotreba CMOS je
P=nCU^2f
n pocet tranzistorov
C parazitna kapacita
U napajacie napatie
f frekvencia
aby pracovala stabilne
U=kf
teda
P=nCk^2f^3
a celkova energia za cas spracovania
Pt=nCk^2f^3t
ale t=1/f
Pt=nCk^2f^3/f = nCk^2f^2
Teda ak znizim frekvenciu na 1/2, predlzim cas operacie na dvojnasobok, ale spotrebovanu en3rgiu znizim na 1/4 =(1/2)^2, a jednotkova spotreba bude dokonca 1/8 =(1/2)^3
Teda ak znizim frekvenciu na 1/4, predlzim cas operacie na dvojnasobok, ale spotrebovanu energiu znizim na 1/16 =(1/4)^2, a jednotkova spotreba bude dokonca 1/64 =(1/4)^3
Ak nadimenzujem chladic na na max, spotru, tak sa mi znici termodynamicka teplota
a ono plati
C=kT+C0
tym padom sa znizenim teploty znizi spotreba, co znizi teplotu, ak nezvysim frekvenciu...
ak mam standarny odber karty a dost velke kondenzatory, viem docasne zvysit odber pomocou nich a tym padom zvysit frekvenciu v pripade potreby...
http://pctforum.tyden.cz/viewtopic.php?p=9053253#p9053253
http://pctforum.tyden.cz/viewtopic.php?p=9056263#p9056263
dynamicky gating SIMD16 na uzsi, posilena skalarni ALU,.... jeste jemnejsi granualita - ne cele CU, ale jednotlive SIMDs, nebo dokonce jednotlive ALU (lines) v SIMD jednotkach.
Tzn. ze v ramci CU by bylo mozne ridit rychlost/gating ruzne sirokysch SIMDs (SIMD2, SIMD4, SIMD8, SIMD16) a nebo ridit rychlost/gating sirky dnesnich SIMD16 v nasobcich 2.
Kdyz ma karta/akcelerator k prikladu TDP 250 wattu pochopim ze rizenim pracovni frekvence na urovni jednotlivych SIMD bloku muze skutecne dojit ke snizeni odberu energie, ale necht mi prosim autor clanku vysvetli ze kdyz vytizim vsechny pritomne SIMD bloky GPU na plnou uroven jak tim dosahnu skrze tuto technologii "rizeni frekvence skrz SIMD" snizeni celkoveho TDP, kdyz proste jde GPU na plny vykon?
nebude to tim ze je rec o realny zatezi a ne o teoreticky situaci co muze nastat max nekde v syntetice? ;) tam proste seriznou spotrebu pres tdp power limit a dal se neresi..
Reálná zátěž je taková jakou ji člověk naloží. TDP musí být počítána na maximální zátěž jak jinak pak karta nebude moci max. výkonu dosáhnout protože ho típne power limit. Tzn. dojde ke snížení výkonu, pokud se sníží TDP.
Leda by to bylo jen číslo do placu, zrovna AMD se s TDP v poslední době moc nepárala a psali na karty menší TDP než byla jejich spotřeba. Aspoň u těch nových karet co teď vyšly uvádí reálné čísla.
1. odstavec: částečná pravda, pokud neberu kartu na výpočty, tak ve hrách téměř nikdy karta maxima nedosáhne, takže "co ji člověk naloži" neplatí obecně.
2. odstavec: To spíš mluvíš o nVidii, ne? Ta je známá, že nikdy neudávala maximální TPD, ale nějaký průměr z měření. Kdosi tady i dával odkazy na 180W TPD kartu nVidia a i ve hrách byla hodně přes 200W - a hry grafiku nevytěžují na max (jako třeba Furmark), takže maximální TPD bude tak o 50W vyšší... hlavně že 180W karta
Intel už od Conroe používá TDP jako typical thermal design power...zatímco AMD uváděla až do příchodu APU maximal TDP - tehdy spíš teoretické maximum. Dnes oba používají něco co bych onačil jako designed TDP a je to celkem reálná hodnota.
nVidia uvádí jako TDP nějaký průměr - přesnou definici jsem nenašel.
např. GF 1080 FE má TDP 180W, ale průměrná spotřeba se pohybuje okolo 200-220W a maximální špičky okolo 300W.
Když se dneska porovnává GPU podle TDP a ne podle reálné (naměřené) průměrné či max. spotřeby, nemůžete se divit, že AMD, stejně jako nVidia dělá "optimalizace" TDP.
Obecně u grafik (obou výrobců) platí, že TDP je něco jako průměrná spotřeba udávaná výrobcem automobilu. Snad se brzy dočkáme porovnatelné a reálné TDP jako nastala u CPU Intelu vs. AMD.
---
I kdyby jste zatížil GPU na 100% to neznamená, že všechny části GPU jedou na 100% (vnitřní části GPU na sebe čekají než se provede výpočet scény, než se provede texturace, pixel/vertex shader atd.). A to nemluvím o tom, že reálně nejde zatížit GPU na 100% - pomineme krátké špičky kdy může jet opravdu na 100%, ale obecně se vždy na něco čeká (než přitečou data z RAM, než CPU připraví a comitne frame, než se přepne contex, než se spočítá AI atd.). Velmi záleží na hře jak kterou část zatěžuje.
viz Tom Buri. Kartu málokdy dostaneš na 100%, já mám třeba průměrný odběr karty (ve hře) okolo 85W, přitom TDP je 150W (a to se ta karta z pohledu hraní nefláká)
asi záleží jakou kartu a jakou zátěž ji hraním člověk dává. Umím s přehledem dostat kartu za 100% kdy ji začne brzdit 120% power limit při 100% zátěži stejně tak ji umím naložit těch 100% zátěže při třeba 70% TDP. Není zátěž jako zátěž... Zvláště takový MSAA dává energeticky kartě pěkně pohulit.
To není o indikátoru zatížení ovladačů nebo utilitek. Ten opravdu neřekne, jak jsou vytížené jednotlivé stream-procesory, to je skutečně jen orientační hodnota (může indikovat spíš energetické hledisko, kdy 100 % je využití 100 % TDP). Neexistuje architektura, kterou by reálné hry dokázaly vytížit skutečně na 100 %. To lze dokázat i prostým selským rozumem bez potřeby technologických vědomostí: Pokud by hry vytěžovaly stávající architekturu na 100 %, pak další vývoj architektury ztrácí smysl, protože vyšší než 100 % efektivity už není možné dosáhnout :-).
Pokud by hry vytěžovaly stávající architekturu na 100 %, pak další vývoj architektury ztrácí smysl, protože vyšší než 100 % efektivity už není možné dosáhnout :-).
Ne, ne, třikrát ne.
a) 100 % efektivní architektura je taková, která nejde "vytížit" nikdy na 100 %, jinými slovy, můžeš ji vytížit donekonečna a ona je tak efektivní, že zvládne i nekonečnou zátěž.
b) Z toho plyne, že "stávající architektura" nebo jakákoliv bleděfialová vytížená na 100 % nemá 100 % efektivitu.
c) Nebude a neexistuje 100 % efektivní architektura, (ano správně ani 101 % efektivní architektura.)
d) Co je to vlastně efektivnost architektury? )))
e) Asi jsem to neměl hulit ))))
Asi ne, protože si už od bodu a) pleteš pojmy „efektivita architektury“ a „nekonečný výkon“.
viz d) ty architekturo ;)
"Bloky SIMD nemusejí mít fyzicky různou šířku, ani není třeba řešit jejich variabilní šířku na úrovni hardwaru. Mohou být hardwarově prakticky stejné jako nyní. Zúžení jednoho SIMD ze 16 na kupříkladu 8 lze velmi snadno realizovat úpravou taktovací frekvence určitých linek tohoto SIMD oproti ostatním. "
Já mám ale pocit, že tenhle přístup neřeší zásadní problém GCN spočívající v tom, že část velkého křemíku je fyzicky nevyužitá a ne vždy se podaří "naplánovat" výpočet přes celou výpočetní jednotku (kdyby to šlo, SSE a AVX kód by touhle dobou v CPU již kraloval ve většině aplikací, ale to se zjevně neděje).
"Zúžení jednoho SIMD ze 16 na kupříkladu 8" snížením frekvence na polovinu by totiž znamenalo, že jste stále schopen jedntku plně využít (abyste nižší počet průchodů dat jednou jednotkou vykompenzoval větším objemem odvedené práce za jeden průchod dat touto jednotkou). Jenže kdybyste to přeuspořádání dat dokázal, tak nemusíte snižovat takt a celý výpočet prostě dokončíte za polovinu času a pak jednotku vypnete, nebo ji rovnou zaměstnáte něčím jiným.
Jak jsem pochopil řešení v NCU, to prostě obsahuje jednotky různé fyzické délky a potom plánovač instrukcí, který bere tyhle délky v úvahu a "matchuje" délky vektorů dat s délkami vektorů výpočetních jednotek, případně občas delší operaci poskládá z kratších. Využítí jak plochy křemíku, tak spotřebované energie je pak optimální. To, co článek naznačuje, podle mě žádné takové výhody nepřináší.
„Já mám ale pocit, že tenhle přístup neřeší zásadní problém GCN spočívající v tom, že část velkého křemíku je fyzicky nevyužitá a ne vždy se podaří "naplánovat" výpočet přes celou výpočetní jednotku.“
1. Máš pravdu, že tento problém to neřeší.
2. Ovšem neřeší ho právě proto, že to není zásadní problém GCN.
Pokud se podíváme na testy reálného výpočetního výkonu GCN ve srovnání s čipy konkurence, je zřejmé, že GCN je stále o něco efektivnější. Pokud zohledníme rozdíl v taktech a srovnáme ± stejně velká GPU nastavená na stejné takty, bude rozdíl ve prospěch ještě větší. Problém v tuto chvílí je energetická stránka, což je jeden z důvodů, pro který čip nemůže běžet na vyšších taktech.
Při úvahách o efektivitě je třeba brát v potaz i to, že samotné výpočetní jednotky nejsou to jediné, co ovlivňuje efektivitu využití křemíku a energetickou stránku. Čím složitější konfigurace, tím více dalšího křemíku je třeba na řízení a registry. Snadno může nastat situace, kdy efektivita na úrovni výpočetní jednotky sice stoupne o 10 %, ale na úkor 15% nárůstu plochy křemíku a o 20 % vyšší spotřeby. Další věc je, že současná GCN má z hlediska vývojáře velice dobře vyřešené registry, není třeba řešit žádné výjimky, není problém s konflikty, chování je očekávatelné. Ve výpočetní sféře může jít o jednu z konkurenčních výhod a je otázka, nakolik je pro AMD cenná na to, aby zaváděla takové změny architektury, které ji o tuto výhodu připraví.
> Jak jsem pochopil řešení v NCU, to prostě obsahuje jednotky různé fyzické délky a potom plánovač instrukcí, který bere tyhle délky v úvahu a "matchuje" délky vektorů dat s délkami vektorů výpočetních jednotek,
NCU je novej CU AMD Vega ? pak v tom pripade netusim kde si vzal tyhle informace, ale prijdou mi 100% spatne. To co popisujes by si vyzadovalo 1) vicero IP (instruction pointer) registru na jedno CU (momentalne jenom jeden), 2) odpovidajici pocet Scalar unitu (protoze ty delaji branching, opet momentalne jeden / CU).
Jedine co jsem se docetl o Vega, ze to umi kombinovat "kompatibilni" instrukce.
> Já mám ale pocit, že tenhle přístup neřeší zásadní problém GCN spočívající v tom, že část velkého křemíku je fyzicky nevyužitá
Rekl bych ze kdyby sis trochu precetl o tom jak funguje branching na GPU (BTW Nvidia to ma stejne), a trochu popremyslel jak to lze udelat jinak, tak bys zjistil ze o moc lepe to udelat nelze... kupodivu ty GPUcka nedelaji uplni idioti ;) jak pise no-X, tohle neni zasadni problem Nvidie ani AMD.
"NCU je novej CU AMD Vega ? pak v tom pripade netusim kde si vzal tyhle informace, ale prijdou mi 100% spatne. To co popisujes by si vyzadovalo 1) vicero IP (instruction pointer) registru na jedno CU (momentalne jenom jeden), 2) odpovidajici pocet Scalar unitu (protoze ty delaji branching, opet momentalne jeden / CU)."
To nedává smysl, proč byste to potřeboval? Všechny potřebné (pod)problémy k implementaci tohoto schématu jsou již řešeny v superskalárních procesorech s mikroinstrukcemi. Rozšíření plánování instrukcí tímto způsobem NEmění control flow! (A v nejhorším případě se o plánování může starat ovladač, ale mám pocit, že od toho se AMD právě nedávno odklonilo.)
"Rekl bych ze kdyby sis trochu precetl o tom jak funguje branching na GPU "
Opět - to, co popisuji, nemá s větvením nic společného. Proto způsob implementace větvení nemůže ovlivnit způsob plánování basic blocků.
GCN CU nie je superskalarny procesor, je to jednoduchy in-order SIMD ktory dokaze spracovat 2560 threadov paralelne na 1 CU a pritom je na plochu cca 4-8x mensi nez 1 super zlozite superskalarne jadro Kaby Lake ktore spracuje len 2 thready.
To co hovoris je sice teoreticky mozne, ale mega neefektivne na implementaciu u GPU.
To co píše tady Gath je to, o čem to je a žádný fabulace o zpomalování. Tento závěr v článku je bohužel kravina, sry kámo. Prostě proto, že zpomalení nemá s šířkou dat absolutně nic společnýho a tak jak jsi to popsal, je to nesmysl. Je to pouze o tom, aby byl čip efektivnější (podal nějaký výkon za čas při stejné energetické náročnosti) - situace, kdy (I) malý kusy spěchají víc, než velký kusy dat, a (II) vyskytují se příliš často malý kusy dat. Proto tam dají různý šířky stream procesorů, aby podtaktovali plně vytížené (a široké) SP, zároveň zvedli voltáž a frekvenci celýho čipu a tím dosáhli dočasně superrychlých malých SP při zachování určité obálky. Takže je to vlastně granulované superturbo. Do nějaké míry to asi jde nebo taky nejde už dnes, to řešit nechci. Stále je to ovšem limitovaný výrobním procesem, ale už né tolik - čip se lokálně nepřehřeje (to teplo prostě chvíli putuje pryč i při superchladiči) a snese větší taktáž. Chytrý.
"podíváme na testy reálného výpočetního výkonu GCN ve srovnání s čipy konkurence"
Me prijde, ze Tesla je dost uznavana a teda, ze NVidia kartu na vypocty opravdu umi. To by mohl byt namet na clanek, srovnani obou pristupu.
Jinak i za tento clanek diky, skoda ze tady neni moc nikdo, kdo by se podobne venoval NVidii (myslim na cz webu, moje anglictina je omezena a do cteni odbornych clanku se moc poustet nemohu).
Přístup Nvidie: Osekáme herní grafiky až na kost a pro výpočetní použití vyvineme něco jiného.
Přístup AMD: Budeme mít jeden koncept GPU, který bude dostatečně variabilní.
Přístup Intelu: Na GPU se programuje pořád blbě. Výpočty zkusíme přes haldu malých CPU, vzhledem k nikdy nekončícím problémům s ovladači pro klasická GPU by to časem mohlo vyjít i pro hry.
Problém je spíš v tom, že Nvidia v posledních letech drží vše pod pokličkou a s každou další generací toho o architektuře nového hardwaru zveřejňuje méně a méně. Vezmi si jen to, že vydala Pascal a nezveřejnila ani slovo o tom, že podporuje delta-kompresi nebo že má tile-based rasterizér. Domnívám se, že marketingové oddělení usoudilo, že je lepší, pokud nastoupí WOW efekt a na uživatele to bude působit jako… http://www.reactiongifs.com/r/mgc.gif …, než když zveřejní, že implementovali delta-kompresi a tile-based rasterizér, a pak jim uživatelé budou pod recenze psát, že s použitím takových technologií čekali větší posun ve výkonu. To se ještě kombinuje s faktem, že dlouhodobě ubývá čtenářů, kteří by měli zájem o technologické články, proto jich i ve světě tolik ubylo - nemá to čtenost, nezaplatí se, konec.
OK, dik.
"dlouhodobě ubývá čtenářů, kteří by měli zájem o technologické články"
Vazne? O tom bych pochyboval. Neubyva spis novinaru schopnych psat technologicke clanky? Spis bude jednodusi zvatlat jako OBR nebo DD a lidi co zvladnou vic (nebudu toho jednoho z diit jmenovat aby nezpychnul) je proste malo. ;-)
Nikomu nebráním pochybovat, ale je to tak. Z mnohých webů vymizely zcela v souladu s tím, jak vidím pokles čtenosti technologických článků tady. Sepsání 10-12+ stránkového technologického rozboru mělo z hlediska čtenosti význam naposledy někdy v době vydání Radeonu HD 7970, pak už to šlo strmě dolů. Generace, která o to měla zájem, má dnes z většiny jiné starosti a generaci stávající už to příliš nezajímá. Není to pro ni nic fascinujícího, protože se do světa s počítači a grafickými kartami už narodila. Dnešní přístup většiny uživatelů je pragmatičtější - funguje / nefunguje, cena nízká / vysoká, výkon nízký / vysoký a konec.
Njn,není nadto psát o zpocené pí..
https://www.super.cz/497051-vendulu-pizingerovou-potkal-stejny-problem-j...
Ja mam trochu divoku ideu, potom by tie jednotlive ALU mohli pocitat v DP(FP60) alebo EP (FP80). Totiz to skladanie/rozkladanie vobec nie je zla idea..
Diane v SUSE totiz moze nieco naznacit
Platinum sponsor of openSUSE
The combined forces of you, AMD and openSUSE are helping lead the Linux operating system community in 64-bit innovation.
https://en.opensuse.org/Sponsors
a to ide nejakou cestou
An Early Port Of GCC To AMD's GCN Architecture
on 22 September 2016 at 11:40 AM EDT.
While still in its early stages, there's a port in the works of the GNU Compiler Collection for AMD's GCN (Graphics Core Next) instruction set architecture.
https://www.phoronix.com/scan.php?page=news_item&px=GCC-For-AMD-GCN-Early
Porting GCC to AMD GCN microarchitecture
Honza Hubička
SuSE ČR s.r.o
Prague
Joint work with Martin Jambor
GNU Cauldron 2016
AMD Graphics Core Next
New and clean instruction set used by AMD GPUs
First specification released in 2011, Generation 3 in 2015
Primarily designed for graphic cards, but with parallel
computation in mind
GCN code generator is needed to complete HSA
infrastructure (currently we rely on a proprietary finalizer)
!!!Similar to traditional CPUs (unlike the predecessors)!!!!
https://gcc.gnu.org/wiki/cauldron2016?action=AttachFile&do=view&target=P...
SUSE Developers Publish Radeon GCN Backend Code For GCC Compiler
Written by Michael Larabel in Radeon on 16 March 2017
This GCN back-end for GCC is primarily focused on compute capabilities rather than compiling graphics shaders.
Martin Jambor and Jan Hubicka are among the developers working on the GCN back-end for GCC that's now been made public.
https://www.phoronix.com/scan.php?page=news_item&px=GCN-For-GCC-Branch
Ak by to totiz bolo tak, ze sa daju jednotky skladat/rozkladat na mensie, a to AMD vie
vdaka AMD 2900
http://datasheets.chipdb.org/AMD/290x/1979_AMD_2900family.pdf
The Itek Advanced Technology Airborne Computer (ATAC) used on the Galileo Attitude and Articulation Control Computer System and some Navy aircraft had a 16-register, 16-bit word width assembled from 4-bit-wide 2900 series processors
https://en.wikipedia.org/wiki/AMD_Am2900
Cize zo styroch 4-bitovych procesor, vedeli zlozit jeden 16-bitovy uz v roku 1975.
A tym padom by sa pri 80 bitoch ALU dala pouzit GCN ako CPU a pri 5x16bit ako GPU s Half precision alebo 2x32-SP +1x16 bit-HP, ako nejaka ina GPU, ci 1x64 bit -DP+1x16bit ako GPU a CPU sucasne..
V podstate by vznikol dynamicky hybrid GPU a CPU, kde cast cipu by bola CPU a cast GPU, pricom by sa urcenie menilo podla potreby v case..
Edit:
a nieco podobne, (kombinacia CPU a GPU) tu bolo
[RUMOR]AMD Volcanic Islands 20nm “Hawaii” GPU Architecture Leaked – 512-Bit Memory, 4096 Stream Processors
Author Photo
By Hassan Mujtaba
May 8, 2013
In addition to the main parallel compute module (PCM), the Hawaii chip would also feature 8 SPMs (Serial processing modules) which allows for parallel computing and could be a dedicated HSA module.
http://wccftech.com/rumoramd-volcanic-islands-20nm-hawaii-gpu-architectu...
A to uz bolo v ramci GCN -ta je z roku 2011.
Řezové procesory nejsou žádná novinka, ale ty obvody se používaly se v pevných zapojeních, která nebyla funkčně příliš odlišná od monolitických mikroprocesorů.
Trochu mi chybí sdělení základního faktu, který ukazuje, proč to celé dává smysl. Já znám lépe architekturu CUDA, nicméně princip spouštění instrukcí bude u GCN asi podobný: instrukční jednotka běží relativně pomalu oproti ALU procesorům, dokáže emitovat novou instrukci např. jednou za 4 takty. Proto když máme 16 SIMD ALU na instrukční jednotku, má wavefront 64 vláken -- musíme instrukcí nakrmit těch 16 ALU 4x, než dokážeme připravit instrukci novou.
Výkon GPU nám klesá, pokud z wavefrontu využijeme jen část vláken -- např. kvůli malému datovému paralelismu (zpracování malé struktury), nebo divergenci kódu (if-then-else větev vede k tomu, že je aktivní jen část vláken). V takovémto případě nám nutně část ALU běží alespoň některé cykly naprázdno (nedostane instrukci, protože ji instrukční jednotka ještě nepřipravila). Pokud máme např. aktivní pouze polovinu vláken ve wavefrontu, pak první polovinu času "zbytečně kvaltujeme" a druhou necháváme ALU zahálet. Fyzika čipu je pak taková, že je výhodnější raději zařadit poloviční rychlost a nechat ALU pracovat po celou dobu, než pro ně bude připravena další instrukce. Přitom zároveň podtaktováním neztrácíme vůbec žádný výkon (v analogii s dopravou: namísto půlhodinové jízdy rychlostí 120km/h a půlhodinového čekání na odbavení jedeme hodinu rychlostí 60km/h a jsme odbaveni inhned).
Ano to ma logiku a u GCN je to podobne. U GCN trva FP32 instrukcia 4 takty. Paralelne CU naraz spracuvava 4 wavefronty, tj. 256 FP32 operacii za 4 takty, cize realne je to tych 64 flops / takt.
Je to v tejto prezentacii, slajd 12 a 28:
https://www.slideshare.net/DevCentralAMD/gs4106-the-amd-gcn-architecture...
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.