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.
Možná jsem vedle jak ta jedle, ale ty výpočty s hitratem a průměrné zvýšení propustnosti mi přijdou mimo. Podle popisu to vypadá jako by to jednoduše zvedlo celkovou propustnost, ale jak chápu cache já, tak ve chvíli kdy to tam data nenajde a šahá si to pro ně do pomalejší RAM, tak se hra na tu danou chvíli zpomalí, což by mělo znamenat znatelné sekání obrazu. S hitratem kolem 60% by to sekalo prakticky pořád (cca každý třetí snímek). Nebo jsou tam další technologie které tohle řeší? Obraz přece musí být vyrenderovaný a zobrazený co nejrychleji kvůli latencím, takže nějaké další bufferování obrazu asi moc nepřipadá v úvahu. Nebo mi něco uniká?
Nejde se do RAM, ale do VRAM/GDDR.
Pro srovnani u starsich karet takova cache neni k dispozici a nebo je L2 typu (pro zjednoduseni zanedbam). V ten okamzik je hitrate 0% a do VRAM/GDDR se jde vzdy. Veskera data jsou nalezena tam. Rozhodne to neni o tom, ze by se sekal kazdy 3. snimek. Takovych dat se nahravaji stovky na snimek. Tzn. neohrozi to plynulost, ale spise naopak a ani stuttering nema zvysenou pravdepodobnost (rozdil se bude pohybovat okolo 0% a bude zavisly na konkretnim scenari)
Do RAM se jde az v okamziku, kdy nestaci VRAM, ale ta staci vesmes vzdy. Jde spise o to, kolik dat se prednahraje do VRAM aby se v probehu renderovani nemuselo casto dohravat VRAM z RAM, pripadne SSD/HDD.
Ikdyz jdes spravnym smerem, uplne pravdu taky nemas, protoze ty data nemusi vzhledem k 256 bit sbernici vzdycky byt.
Takze ano, to co popisujes je pravda, pokud data ve VRAM jsou, ale 256bit neni zrovna super siroka sbernice, aby se nikdy nestalo, ze tam data nebudou. Akorat tenhle pripad, ktery jiste take nastane, vubec prezentace neresi, takze nevime, jak casto se tohle stane.
„Ikdyz jdes spravnym smerem, uplne pravdu taky nemas, protoze ty data nemusi vzhledem k 256 bit sbernici vzdycky byt.“
Promiň, ale to je nesmysl. Jestli se data v jakékoli paměti nacházejí nebo nenacházejí nijak nesouvisí s šířkou sběrnice. Nebo chceš říct, že když třeba pevný disk odpojím od SATA sběrnice, tak mi z něj zmizí všechna data, protože v tu chvíli je připojen 0bit sběrnicí?
Samozrejme, pokud uz tam ty data jsou nahrana, tak se to chova presne tak, jak popisuje Andreas. Ja mluvim o pripade, kdy se tam ty data jeste nenahrala.
V takovém případě je ale limitem velikost VRAM, nikoli IC...
A 16GB je IMHO naprosto postačujících minimálně na 3-4 roky, i s ohledem na zkriplenou konkurenci.
Pokud mluvíš o přesunech dat z RAM do VRAM, tak tam je samozřejmě limitujícím prvkem propustnost PCIe (32 GB/s), nikoli paměťové sběrnice (~512 GB/s).
mejla: AndreasCZ to popisuje velmi přesně. Zkus si uvědomit, že grafická karta má například 8 GB paměti, ale datová propustnost této paměti je třeba 512 GB/s, takže - teoreticky - může obsah celé této paměti 32× za sekundu celý přečíst a 32× za sekundu celý přepsat. Takto se to samozřejmě neděje, načítá a přepisuje se menší část, ale o to intenzivněji. Během vykreslování každého snímků dochází k myriádám přístupů - ať už čtení nebo zápisů. Více než polovinu lze s použitím Infinity Cache eliminovat.
.. tohle, plus bych jeste dodal:
CPU jadro, kdyz nenajde data v L1/L2/L3, tak da pozadavek do RAM a ceka. CPU ale maji obvykle >1 jadro; zatimco to prvni jadro ceka na RAM, jine jadra muzou pracovat s jinymi cacheline z L3 cache.
GPU jsou *extremne* paralelni. Radeon 6800 pokud ma 60 CU a 3840 "stream procesoru", tak to je trochu podobne 60 jadrovemu CPU s 64 hyperthready / jadro. Navic kazdej z tech "hyperthreadu" - stream procesoru - muze mit rozpracovanych vicero pixelu. Data pro nektere muzou byt v IC, pro nektere ve VRAM.
Co chci rict je: GPU muze velmi efektivne vyuzivat *soucasne* cache i VRAM, pokud to ma AMD vyreseno. Nejenze jsou pristupy do IC rychlejsi, ale ta propustnost se do jiste miry opravdu scitava. Vicejadrove CPU umi taky pouzivat L3 a RAM soucasne, ale zdaleka to nema takovej efekt (protoze tech hardwarovych vlaken je radove min).
Jo a taky k puvodnimu komentaru: latence pameti jsou u GPU absolutne nepodstatny parameter. GDDR jsou obzvlast spatne v latencich (uz si presne nepamatuji, ale kolem 500ns). Latence IC jsou sice mensi, ale taky vcelku nepodstatne. Dulezita byla u GPU vzdy propustnost.
VRAM nemá takové latence, aby to vyústilo ve stutering.
V AMD přišli na to, že 58% dat, které scéna potřebuje se vejde do 128MB, tudíž z VRAM je potřeba tahat jen 42% dat oproti konfigurace bez IC. Vyjádřit to v teoretické propustnosti dává smysl. Závěr je takový, že by mohli sběrnici do VRAM zúžit na polovinu a nemělo by to být poznat.
mě ten výpočet (součet šířky pásem) taky na začátku zarazil, ale pak jsem našel stejná čísla i jinde, takže to jsou zřejmě oficiální hodnoty, které prezentuje samo AMD:
https://www.pcgamer.com/amd-infinity-cache-rx-6800-xt-rx-6800-rdna-2/
Znamená to asi, že IC je sideband cache, takže Navi může zároveň sosat data z cache i standardní VRAM.
edit: v tomto ohledu mi IC připadá jako chytrá evoluce eDRAM z XB360.
Ten součet je samozřejmě blbě. Má to být vážený průměr - 0,58*2TB/s+0,42*0,5TB/s, protože při 100TB dat čteš 58TB z Cache 29sec a 42TB z VRAM 84sec. 100TB je tedy přečteno za 84 sec = 1,19TB/sec.
Pak tedy rozumíte hardwaru AMD lépe než lidé, kteří ho navrhli a jejichž čísla v případě Navi 21 ve článku cituji.
Ne, jen odděluji zjevný marketing :-) Co kromě toho je na mé úvaze špatně ?
„Co kromě toho je na mé úvaze špatně ?“
Kupříkladu to, že staví na nepodloženém předpokladu o chování hardwaru, ale vůbec se nezabývá tím, zda je tento předpoklad správný, tedy zda odpovídá reálnému chování hardwaru. Což je obzvlášť na pováženou v situaci, kdy výrobce popisuje jiné chování.
Řekněme, že se ta úvaha ani nepokusila nevypořádat s myšlenkou, proč by během přístupu k Infinity Cache neměla být přístupná paměťová sběrnice.
Z údajů od AMD je zjevné, že paměťová sběrnice je přístupná stále (100 %) a IC má hit-rate 58 %, tedy v 58 % případů zvýší datovou propustnost. Tedy 1,00 × propustnost sběrnice + 0,58 × teoretická propustnost cache = 512 GB/s + 0,58 × 1987 GB/s = propustnost sběrnice + obvyklá propustnost cache = 512 GB/s + 1152 GB/s = 1664 GB/s.
Tohle scitani funguje pouze tehdy, pokud si mohu vybrat co pujde kudy. To se v soucasne dobe neda ocekavat. Mozna v budoucnu az hry vezmou v potaz cache hierarchy a budou urcovat co je kde ulozene toho mozna bude dosahnout, ale ty statistiky jsou pro soucasne hry co tuto prioritizaci nedelaji.
Vzhledem k tomu, ze se bavime o sanci, ze data bud v cache jsou nebo ne, tak se typicky bavime o tom jak dlouho musime cekat na data (cehoz je propustnost dobre meritko). Tedy: 1 GiB jde z cache 0.5 ms, kdyz je ve VRAM tak to trva 2 ms. Je 58% sance ze budu cekat jen 0.5 ms a 42% sance ze budu cekat 2 ms. V prumeru cekam 1.13 ms a tedy efektivni propustnost je zhruba 880 GiB/s. Je to porad pekne zrychleni ale rozhodne to neni soucet.
„Tohle scitani funguje pouze tehdy, pokud si mohu vybrat co pujde kudy. To se v soucasne dobe neda ocekavat. Mozna v budoucnu az hry vezmou v potaz cache hierarchy a budou urcovat co je kde ulozene toho mozna bude dosahnout, ale ty statistiky jsou pro soucasne hry co tuto prioritizaci nedelaji.“
To je ale další chybný předpoklad. Proč bychom měli předpokládat, že jediným prvkem, který vůbec teoreticky může určit, jaký obsah se nachází v cache, měla být právě a jen hra?
Protoze, data o tom jak dobre to samotna GK data prerozdeluje mezi cache a VRAM uz mame - 58% hit rate.
Hit rate ale nijak nesouvisí s tím, jestli hardware ví nebo neví, v jaké části paměti má uložená jaká data. Hit rate vypovídá o efektivitě využití cache, tedy jakou část datové propustnosti je cache schopna obsloužit z celkových nároků systému na datovou propustnost.
Ta data v cache prostě jsou nebo nejsou a systém ví, která data má kde uložená. Cache a v ní obsažená data nejsou krabice a Scrödingerova kočka.
no-Xi já obdivuju že se s těma nýmandama bavíš. Všechno si v článku napsal správně a jasně, že to nepochopí jen idiot a tady hned kecy typu že když něco není v cache, tak prej "zpomalení". Pak je pomalá i 3090 protože ta žádnou takhle velkou cache nemá. Další nesmyslný předpoklad v diskuzi co jsem postřehl, že snad šířka sběrnice souvisí s latencí. No a nakonec tu lidem nedochází že to co se najde v cache (teda v těch 58% případů) tak už se nemusí hledat ve VRAM a tedy karta toho nemusí přes VRAM tlačit tolik, což mě mj. napadá že může vést teoreticky i k lepší energetické efektivitě
To, že no-X v diskuzích odpovídá a vysvětluje je naopak obrovské plus diitu (minimálně pro mě). Lidé se mílí, a dokud po sobě nezačnou kydat "nýmandama", tak může diskuze dělat článek ještě lepší.
Zatim tady vidim spoustu uvah pracujici s cache jako s RAM a definovanym adresnim prostorem namisto pracovani jako s cache.
Cache z principu neni dalsi RAM/VRAM. Chip testuje, jestli se pozadavek na data nenachazi v cache. Pokud ano, pouzije data s cache (ty by meli byt jen ozrcadelnim dat z VRAM). Adresa dat je zachovana (ve sve podstate se testuji spise adresy/pointry nez data samotna).
Data se tedy u cache nacitaji paralelne s daty z VRAM a ridi si to chip sam. Interni sbernice (infinity fabric ???) je schopna dodat data primo jednotlivym CU. Data z VRAM jsou vyrazne pomalejsi a prenosovou kapacitu interni sbernice vytizi minimalne.
Zobecneni v duchu, ze jsou data nacitana paralelne neni chybne. Efektivni rychlost nicmene opet bude zalezet na aplikaci/renderu, charakteru dat atd. Do hry dale vstoupi latence, ktere efektivni rychlost dale snizuji (nekde na to byla i prezentace od AMD). To pak dale jeste zvysuje vyhody Infinity cache a realna relativni prenosova rychlost z toho bude tezit jeste vic.
Ale prdlajs, název cache je dost obecný a vúbec nic neříká o tom, jak jsou data rozdělená mezi cache a zbytek RAM. Možností je mnoho a sama AMD zatím mnoho nesdělila. Jsou klidně možné rúzné kombinace, např. některé datové struktury jsou celé jenom a pouze v cache, zatímco jiné se standartně kešují podle toho, kdy byly naposledy potřeba.
Souhlasím. Jen s výjimkou - data nebudou rozdělená mezi cache a VRAM. Obsah cache je podmnožinou toho, co je ve VRAM - to je v podstatě definice cache.
Těch možností může být skutečně mnoho, včetně té, že IC "není tak úplně" cache :-). Nicméně, pak by údaj hit rate byl "ne tak úplně" vypovídající.
Cache je cache a RAM je RAM. Je mozne, ze se do hry pustil marketing, ale z principu jsou data cachovana, kdyz jsou pouzita, pripadne kdyz si data prediktor vyzada dopredu.
Vzdy je to duplicita. Pokud neni, tak to neni cache.
To, co napsal Milan Bacik, neni spravne.
Napsal jsem totéž. Jen jinými slovy :-)
Moje úvaha staví na tom, že 58% dat se čte z IC a 42% z VRAM - zároveň. Proto časy nesčítám, ale beru jen max. Vizte můj příklad 100TB výše.
Samozřejmě je IC i VRAM dostupná celou dobu a je možné z obou číst. Pak ale se zachováním logiky vzhledem k VRAM (512GB/s pořád dostupné) mi vyjde 2,5TB/s.
Protože během přístupu k paměťové sběrnici je samozřejmě dostupná i IC (2TB/s), tak proč ji krátit o 42% (hit rate 58%) ?
Navíc hit rate mi říká, kolik z celkového množství dat jsem přečetl z cache. Ne jakou rychlostí - ta je víceméně stálá. Nebo není ?
Váš původní výpočet ale popisuje jinou situaci, než o které hovoříte. To, co zde popisujete, vyjadřuje, za jakou dobu se načte konkrétní blok dat. Jenže způsob, jakým to vyjadřujete, popisuje situaci, kdy měříme čas, za který bude od začátku do konce přečten jeden konkrétní datový blok - 58 % z něj je v IC, 42 % z něj je ve VRAM a vy vyjadřujete čas, kdy budou celá data načtená. Což je naprosto chybný postup:
Proč: No protože IC je mnohem rychlejší, vydá svých 58 % dat rychleji než VRAM svých 42 %. Pak už IC nic nedělá a čeká, až VRAM vydá svůj díl. V praxi se ale na nic nečeká, existuje fronta a jakmile je přístup k IC volný, čtou se paralelně další data.
Nemůžeme tudíž propustnost počítat z hlediska načtení jednoho bloku dat, ale z hlediska toho, jaký objem dat lze daným paměťovým subsystémem protáhnout za jednotku času.
512 GB/s máme k dispozici stále. Zde není důvod řešit buď/nebo.
V 58 % případů ale můžeme číst (či zapisovat) navíc k tomu i z IC o 1987 GB/s. To znamená, že za onu sekundu lze v průměru využít 58 % z těchto 1987 GB, tedy 1152 GB/s.
512 + 1152 = 1664 GB/s.
S čím jiným než s bloky dat pracuje grafická karta ?
"V praxi se ale na nic nečeká, existuje fronta a jakmile je přístup k IC volný, čtou se paralelně další data."
To není nesmysl, pouze pokud uvažuji jen v jednotlivých pages/blocích. A ty se čtou buď 2TB/s nebo 512GB/s, žádný hit rate se neuplatní. Pokud ale jedou všechny paralelní streamy, tak operace vyžadují ucelené bloky dat. Pokud výpočetní část nemá 42% dat k výpočtu, tak čeká a nečte dokud nedostane ucelený blok. V případě cache je to statisticky vyjádřeno hit ratem 58%.
"Nemůžeme tudíž propustnost počítat z hlediska načtení jednoho bloku dat, ale z hlediska toho, jaký objem dat lze daným paměťovým subsystémem protáhnout za jednotku času."
Pak tedy 2,5TB/s :-) Máme k dispozici stále jak 512GB/sec, tak i 2TB/sec :-). Jak se používá 58% sběrnice? :-) Hit rate nemá spojitost s časem, ale s počtem čtení. Počet čtení se tak nějak blbě vztahuje k času, ale dá se docela dobře vztáhnout k objemu čtených dat (čte se po definovaných stránkách/blocích).
1987 × 0,58 + 0,42 × 512 = 1 367,5
asi tak ;)
Jo, to je chyba, kterou jsem nejdříve udělal taky :-) Respektive, byl to můj první myšlenkový pochod.
Jenže platí, co píšu výše - nepoužíváš část sběrnice, to prostě nejde. Používáš počet čtení (= datový blok/ paměťový blok).
Zjednodušeně pro ilustraci - CU potřebuje 1MB dat, z paměti se čte po 10kB blocích, takže musíš udělat celkem 100 čtení. 58 z nich jde do IC a 42 z nich jde do paměti. To je to, co mi říká hit rate. Žádná sekunda v tom nehraje roli :-)
Ta přijde na řadu, až budu zjišťovat jak rychle tyhle data dostanu k CU. 580kB za 292us a 420kB za 820us. Z pohledu CU dostanu potřebný 1MB za 820us. Pak tedy mohu říct, že při 58% hitrate je efektivní rychlost sběrnice 1,219TB.
edited: us = mikrosekunda :-)
Ne, ne, ne. Prostě je to efektivní rychlost čtení (z nějakého složeného systému), vážený průměr vážený "typickým umístěním" dat. Dat a přístupů k nim je jakoby nekonečno a nesouvisí spolu. Žádné sběrnice, mikrosekundy ani bloky do toho netřeba plést.
Bohužel tento článek se moc nepovedl, abych to řekl na plnou hubu ;)
Mate odkaz na technicke materialy udavajici tu celkovou propustnost, kde se scita propustnost GDDR6 a cache? Ono je taky docela dobre mozne, ze to je jen marketingovy blabol.
V pripade blokujicich operaci by se mel skutecne pouzit vazeny harmonicky prumer (nikoliv prosty vazeny prumer, jak pise kolega, aneb cislo vychazejici z udaje jak dlouho v prumeru musim cekat na 1 GiB dat) a nikoliv soucet propustnosti a v pripade sideloadingu, jak kolega spravne popisuje, pak ten delsi interval tj. propustnost GDDR6 delena miss rate cache.
„V pripade blokujicich operaci…“
To je ono. Dovolím si prostou otázku: Jaký smysl má rozebírat hypotetickou situaci, která nenastává a pokoušet se tímto rozborem snažit vyvracet cokoli na reálném chování hardwaru? Nemohu v tom najít elementární logiku.
... a pokud nejsou blokujici tak je efektivni propustnost 500 GiB/s (VRAM) / 0.42 coz je miss rate tj. 1190 GiB/s. Opet zadne scitani, aneb cekate na ta data ktera k vam dojdou pozdeji.
Spravne poukazujete na predpoklady. Problem je to, ze ono scitani propustnosti ma taky predpoklady, ktere opomijite. Jmenovite:
Aplikace nepotrebuje cekat na data z VRAM ke zpracovani dat z cache, zpracovani dat trva presne tak dlouho nez doputuji data z VRAM. Jinak bud musite cekat na data (memory bound) nebo na dokonceni vypoctu (GPU bound, a v tom pripade vyssi propustnost je k nicemu a bavit se o ni nema smysl). Tohle chovani se u realisticky napsane aplikace neda ocekavat, nehlede k tomu, ze dane rozdeleni pravdepodobnosti je pro soucasne aplikace o kterych vime, ze tohle rozhodne nedelaji.
Prosím Vás, nechci být neslušný, ale zjistěte si něco o fungování grafických jader. GPU jsou masivně paralelní systémy, kde se rozhodně nečeká. Platí můj předchozí příspěvek „kolegovi“ výše (prosím, zkuste si jej přečíst).
V okamžiku, kdy by - podle Vašeho názoru - IC začala čekat na realizaci přenosu z VRAM - bude ve skutečnosti zahájen další přenos z IC. Proto nelze propustnost hodnotit z hlediska jednoho izolovaného přenosu, do kterého započítáváte bublinu, která v praxi neexistuje.
Musíte uvažovat objem přenosů, kterých je systém schopen dosáhnout v čase - jak vyjadřujeme nejčastěji - jedné sekundy. 512 GB/s je konstantních, 1987 GB/s v 58 %, tedy 1152 GB průměrně za sekundu. 1664 GB/s celkem.
Nadherne cteni. Dekuji :)
takže radeony "nemůžou" "zrát jak víno", protože díky zvyšující se paměťové náročnosti v čase se bude hit rate snižovat, ale už chápu proč jim to fullhd jde tak dobře, díky
To právě není tak úplně jisté, pokud programátoři postaví hru tak, aby počítala s efektem oněch ultrarychlých 128MB IC, tak naopak ten výkon do budoucna může ještě růst. A opět platí - má-li IC i PS5 a XBox, pak by se dalo uvažovat o synergiích.
já bych to teda viděl spíše opačně, že dnešní hry s IC nepočítají vůbec a do budoucna budou Radeony spíše zrát. :-)
pekne napisane :)
128MB neni zrovna nic moc velkyho, ted to jiste staci, ale pokud se technologie uchyti, tak se da pocitat s tim, ze pristi generace AMD grafik prinese treba 256 nebo 512MB, tudiz bude prvni generace dozrala a zacne starnout.
Určitě ano, je to zcela jistě způsob, jakým lze škálovat výkon do budoucna - za předpokladu, že se taková IC rozumně "vejde" na čip - 256MB si třeba na 7nm moc představit nedokážu, i těch 128MB zabírá docela hodně místa.
Pokud se naplní to, že výkon s novými hrami ve vyšším rozlišení (4K) bude růst, tak to ale jako moc velký problém nevidím.
osobne si 256MB cache nedokazu predstavit ani na 5nm .. ty SRAM bunky aby byly rychly hrozne blbe skalujou dolu, treba se dockame na 3nm ale i na 5nm pochybuju ze by to zdvojnasobily, to fakt jedine kdyby to byl zakladni kamen chipletove architektury a 128MB proste neslo pouzit
ono tam jde spíše o "uvolnění místa," které zabírají jiné, lépe škálující, části čipu, takže by IC nezabírala na čipu třeba 20%, ale 30% při stejné ploše. A ano, chiplety+IC by mohly taky docela změnit paradigma konstrukce GPU, obzvláště pokud by se zajistila koherence dat v IC oproti VRAM - pak by totiž asi nebylo nutno zdvojovat adresní prostor ve VRAM (každý čip má vlastní paměti), jak tomu bylo u dvoučipových karet.
No a IC muze cipletovemu reseni napomoct, tudiz na 5nm nevidim duvod, aby to nezdvojnasobili.
...vy nevidíte důvod. Ovšem ty grafiky navrhuje někdo jiný.
Při chipletovém řešení by bylo nejrozumnější udělat cetrální I/O čip s integrovanou cache na starším výrobním procesu (jako to maji Ryzeny) a k němu připojit na jedné straně VRAM, na druhé výpočetní jednotky (ideálně přes nějakou variatu EMIB). Uvidíme, s čím přijde RDNA 3, ale podobný design by mě nepřekvapil. Dokonce si myslím, že v pozadí odchodu Koduriho do Intelu byl přesun patentů opačným směrem, a to právě na EMIB. Protože ten přechod byl až překvapivě hladký, bylo by divné, kdyby za to AMD nic nezískalo.
Ten Koduriho odchod byl divnej, je kolem toho more spekulaci a tezko rici kde je pravda. Ja se priklanim k tem mene optimistickym, ze se ho AMD fakt chtelo zbavit, protoze je dost lakoval a Vega pak nebyla softwarove kompatibilni, takze jestli jim tam porad dokola tocil jak se vsechno vyresi a je indicky zuzovy, jak nejsou zadne problemy a pak se ukazalo, ze se vyresi kulovy tak asi vedeni nebylo zrovna happy ... viz ty Primitive shaders ... stezejni funkce pro vykon ve hrach ktera mela umet zaprahnout vypocetni jadra i pro geometrii co je funkcni az od RDNA. Vegu jsem mel, vyborna karta ktera ale ve hrach lezela z pulky ladem. Navi jsou super karty, zas uz ale nejsou takovy vypocetni brutky jako byla Vega. Na druhou stranu kdo mel rad tento typ karet tak ma moznost novych nVidia, to jsou vypocetni bestie, takze zakaznik si porad muze vybrat jestli mu zvysena spotreba vykompenzuje vypocetni pouziti, skoda jen 8nm protoze takovych 50W dolu by se u 3080+ hodilo jako sul.
Řekl bych že velikost se nijak závratně zvyšovat nebude. Spíše dojde k vylepšení jak s touto pamětí nakládat.
Není náhodou že to vychází z L3 cache, hlavní využití bude na velmi často používaná data a data která se spočtou a hned zahodí. Smysl je v tom že se to nemusí posílat do VRAM a o chvilinku později zase načítat zpět.
je to možný, ale dnes většině her stačí na 4K 8GB takže, takže nyní je využívána efektivněji, než budou v budoucnu, kdy budeš potřebovat té ram víc třeba 16GB, tzn. bude zapotřebý tyhle optimalizace dělat, aby sis udržel efektivitu tohohle řešení jako je dnes, je pak otázka, jak ty optimalizace budou velké a obecně nutné a jestli to půjde do plusu nebo do mínusu nad stávající stav
moc bych nespoléhal na konzole, stačí se podívat v jakém stavu lezou exkluzivky od sony, MS se ani nezmohl udělat MS Flight simulator pro DX12
Souhlasím, že předpovědět reálný vývoj není moc spolehlivé.
Já počítám s tím, že pro PS5 i XBX se programátoři budou muset nejdřív "zaškolit", což bylo vidět třeba i na dožívající generaci konzolí, kdy první hry bývaly jen trochu lepší než to co bylo na PS3. Ty nejlíp optimalizované a načančané hry vyšly až na konci životnost PS4, tudíž se dá čekat, že totéž nastane i u nové generace - tj. první opravdu "rozdílové" hry bych čekal třeba až po roce nebo dvou. Pak se taky projeví věci jako větší textury apod., a to i na PC. Vždyť to není až tak dávno, kdy tu byli lidé, co tvrdili, že jim bohatě stačí 3GB na GTX1060... a jak to vypadá dnes? 8GB je v nových hrách tak na střední třídu.
Jenze uz dnes jsou i hry, ktere si reknou o 10-12GB pri 4K, takze ta situace bude takovahle i nadale. 16GB je overkill, to nema realne vyuziti, ale zase pri 256bit lepsi 16GB nez 8GB, ktere jsou nedostacujici!
MS Flight simulator neni pro konzole, az bude, tak se DX12 verze ocekava i v PC
@ TyNyT: PS5 má něco jako IC, mark Czerny významně pokrčil obočí, když to komentoval. Ale vzhledem k mnohem dřívějšímu uzavření specs to nebude totožné s tím co je NAVI. XSX nemá IC vůbec, má širokou sběrnici.
P.S. přesto MS tvrdí, že jejich SoC je plně RDNA2, takže je tu zjevný prostor prostor pro to, co RDNA2 znamená a zahrnuje. Z pohled SW vývojářů je to asi HW podpora DX12 Ultimate. Sony to zase skrývá pod označení Geometry Engine, kam se vejde všechno, ale víceméně půjde o něco podobného DX12U v jejich provedení.
„takže radeony "nemůžou" "zrát jak víno", protože díky zvyšující se paměťové náročnosti v čase se bude hit rate snižovat“
1. Uvědom si, oproti jakému hardwaru definuješ „zrát jak víno“.
2. Uvědom si, jaké parametry má hardware, oproti kterému jsi to nadefinoval.
3. Zkus si představit, jak se bude dařit hardwaru s těmito parametry při „zvyšující se paměťové náročnosti“.
;-)
AMD už rastie "ako víno"
o 7,6% (RX6800XT) resp 26% (RX6800) v GNU/Linux
https://www.phoronix.com/scan.php?page=article&item=rx6800-more-performa...
ale máte pravdu, v hraní v rozlíšení 1440p je 6800XT o 3% rýchlejšia ako RTX3080
https://www.phoronix.com/scan.php?page=news_item&px=Radeon-RX-6800-1440p...
aj vďaka Infinity cache.
Tak Geforce 3070 a 3080 s 8GB a 10GB VRAM jsou na zrání ještě horší.
hlavne pokud se snizi pri 16GB hitrate a klesne prenoska z 900GB treba na 700GB tak to snizi FPS o par cisel, kdezto kdyz dojde pamet a resi se to pameti v pocitaci tak to je defakto automaticky nehratelny, proto je lepsi mit vic pameti s nizsim hitrate nez min pameti s nulovou sanci to pak zahrat .. neresim ted, ze proste stahne rozliseni textur aby to hratelny bylo, coz samozrejme je reseni pro ty co si poridi 8GB a 10GB karty, ten vykon tam je, jen uz nebudou mit ultra ale jen high textury napriklad
ono dneska ty propady u moderních her nejsou tak obrovské, jako dřív, kdy se to na hulváta muselo tahat z ramky, díky optimalizacím třeba právě i ořezání těch textur nebo použitím dlss, který má větší nároky na vram, ale obecně se ti zvýší fps, tak se to o dost hůř poznává, kdy dojde vram a jaký to má dopad, ale vydávat v roce 2021 :) produkty se stejnou velikostí paměti jako 4 roky starý pascali je prasečina
> ten vykon tam je, jen uz nebudou mit ultra ale jen high textury napriklad
S novými konzolemi nám poskočil baseline, takže se přejmenují nastavení rozlišení textur apod. Správně bude:
"ten vykon tam je, jen uz nebudou mit high ale jen medium textury napriklad"
Něco podobného jsme už zažili, jen si to teď firmy prohodily. Dřív mělo AMD 512 bit sběrnici a Nvidia jen 256 bit, ale měla zvětšenou a chytře udělanou cache v GPU - výkony byly srovnatelné, nvidia méně žrala. U CPU je stejné směřování a proto už nechci kupovat Intely s malou cache, i když to dnes díky malým latencím té malé cache vůbec nevadí.
Kdyz uz to APU tak hodne prekovapavaj, stalo by za to, aby to umelo rezim CAR - Cache as RAM, aby se to dalo pouzivat jako mikrokontroler bez nutnosti pridavat jakoukoliv pamet, ta by v pripade potreby mohla sedet az za PCIe :)
Myslíš jako ve win vypnout swapák? Pro 2D by to nemusel být problém :-)
"* kapacita grafické paměti, respektive objem paměti, který hra svými daty obsadí"
Nebyla by vhodnější formulace ".. objem paměti k němuž GPU v rámci úlohy přistupuje"?
Čekal bych, že pokud bude mít hra obsazeno 2G a GPU aktivně využívat 64MB z toho je šance na vyšší cache-hit ratio než v případě že bude obsazeno 1GB a pracovat s 256MB.
Možná by to byla korektnější formulace, ale v praxi už to budou nuance. Infinity Cache zjevně obsluhuje primárně pracovní buffery, které mají nejvyšší požadavky na datovou propustnost, takže „assets“ se do IC podle mě budou dostávat v minimální míře. Spíš to bude tak, že pokud se na Navi 21 spustí nějaká stará hra v nižším rozlišení, kdy operační buffery ani kapacitu IC nezaberou a zbude prostor i pro další data, tak bude mít vliv na případný výkon (který už tak bude v řádu stovek FPS), zda se přistupuje k desítkám nebo stovkám MB těchto dat (a tedy zda je jejich podstatná část v IC nebo ne). Podle mě je to ale spíš zajímavost, okrajová záležitost. Neumím si moc dobře představit, že by k takové situaci mohlo dojít u novějších her ve vyšších rozlišeních.
Nemusí jít nutně jen o hry, z IC se patrně bude značně profitovat i v rámci GPGPU. Pokud se bude intenzivně pracovat nad středně velkým datasetem, měl by být vliv IC znát. Patrně by v tomto šel udělat experiment s postupným zpomalováním GDDR6 a sledováním dopadu na výsledný GPGPU výkon (srovnání téhož na předchozí generaci GK by asi bylo zatíženo mnoha neznámými/proměnnými).
Já čekal že rok 2021 bude ve znamení HBM2 a oni vymyslí takovouhle cipovinu. Leda že by do budoucna byla společná cache pro CPU a GPU.
Nedá se říct, že to je cipovina, na CPU už to funguje a je to obrovský přínos.
HBM2 je sice připojena široce (např. 4096bit), ale na relativně nízkých taktech. Samotný hrubý bandwidth ještě nemusí zvítězit nad nejspíš nižší latencí GDDR. Záleží asi dost na charakteru úlohy.
Latence neřeší ani AMD ve výpočtu. Počítají pouze propustnost. Nicméně těch HBM2 chipů by tam na propustnost 2TB/s muselo být asi 8 a to by potom vycházela kapacita šíleně velká.
AMD jen zkopírovalo to, co Nvidia už dávno měla, ale obráceně - na GTX970 použila dokonce 512MB "cache" a zbytek běžel na normální sběrnici :o)
Jen těch 512MB zapoměla připojit tak širokou sběrnicí :oD
No prostě chyby se stávají :oDDD
vtip dobry :)
Ted sucharsky popisu GTX970. Tam bylo tech 512 MB pripojeno pres 32b sbernici. Byl to normalne adresovatelny prostor a nebyl duplicitni. Proto se nejedna o cache. // konec sucharskeho komentu :)
nekaž mi ho :o), proto jsem taky dal "cache" do uvozovek
Přesně tak, nebyla to cache byl to pravý opak. Anti-cache, technické opatření snižující v důsledku rychlost přístupu k části pamětí. Slabou útěchou bylo 100% cache-hit-ratio této invisible anti-cache, hledaná data v ní byla vždy přítomna ale četlo se z ní rychlostí přistupu do pamětí a vždy znovu. ;-)
+1 :-D
Jj, taky jsem to sem chtel napsat, ze GTX970 mela "cache" uz davno. :-) Akorat jsem si netroufl, to by byly minusy, ze zase jenom trolim.
Zaujimal by ma prinos v minovackach. Najprv velky osial na NH, ze 120MH/s Ethash dnes uz je to len 60MH/s. Samozrejme ako vzdy plati pravidlo z praxe vsetko nove ma nejake "ale" a casom sa to zlepsi alebo strati do zabudnutia. Kazdopadne zaujimavy tah od AMD. Tesim sa ked Vitalik uzavrie PoW cast na Ethereu kolko minerov bude tieto karty predavat vratane RTX.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.