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.
AMD jde s kůží na trh. Pokud to nebude perfektně vyladěné tak si spíš uškodí. Rozhodně tomu fandím, jenže je otázkou kvalita výsledné implementace.
Pokud to nebude perfektně vyladěné, tak se to postupně doladí. Dnes naprosto běžná praxe, které se nikdo nediví.
no jasně, jenže pokud to začne blbnout byť jen v několika hrách tak to bude jednak ostuda a jednak snížení prodejů. Snad ví co dělají. Ale třeba jen sýčkuji a bude to dobré. Nicméně po předchozích velkých prohlášeních AMD a mnohem skromnější a problémovější realizací vize jsem poměrně skeptický. Viz jak třeba skončila Hydra. Dnes po té technologii neštěkne pes a jaké vzrušení v té době vzbudila.
L3 cache u procesoru taky funguje jen v nekterejch hrach nebo jak? (.
to je dávno součást cpu, žádná novinka oproti tomu je tahle novinka proprietální snaha AMD....
ty me bavis (: co je na cache proprietarniho? a kdyz to pouziva nVidie tak to proprietarni neni? (:
ty jsi ten text jak to má fungovat nečetl, že? Tady jde o to že má nová AMD technologie nějak ohýbat aplikaci (hru) jak předpokládá že skutečně potřebuje paměť - a když to přestřelí tak hra spadne na nedostatek paměti.
nic takovyho sem ve clanku necet, protoze tam nic takovyho neni (. trochu min fantazie a vic faktu by neskodilo.. ve clanku je popsanej normalni princip cache.. nevim proc by neco melo padat ((: kdyz delas s 20mb souborem a mas v cpu 10mb cache tak ti taky procak pada na nedostatek pameti? (;
podle článku jde o to že karta by si nějak měla řídit a zjišťovat skutečnou potřebu paměti - a ta rezerva daná aplikací tam není pro legraci, nikde není řečeno že na 100% alokovanou kapacitu nikdy nevyužije. A jelikož aplikace počítá s tím že má vyhrazený určitý prostor, ale amd technologie ji část zabaví a vykáže jako volnou, tak může snadno dojít k fatálnímu problému. Proto to bude dost závislé na optimalizaci a zřejmě i spolupráci s grafickým ovladačem s patřičným profilem pro daný engine.
P.S: a mimochodem, neznamená to že se nároky na paměť sníží komplexně, ale část potřeb se přesune do normální RAM - tak sice postačí menší VRAM ale o to větší bude třeba klasická RAM.
Nejsem si vědom, že bych něco takového do článku napsal. Zkusím to vysvětlit ještě jednodušeji:
V současnosti si alokaci paměti řídí aplikace, která ovšem nemá informaci, kolik paměti bude skutečně potřeba. Z toho důvodu si alokuje mnohem více, aby vznikla dostatečná rezerva.
Pokud se ovšem správa paměti přesune na GPU, tak to v každém libovolném okamžiku přesně ví, kolik paměti má fyzicky obsazené, takže nemusí vytvářet rezervu, která slouží k řešení problému, který v této situaci ani neexistuje.
jasně, jenže jde o vyladění firmware GPU aby stihl včas reagovat na vyšší zátěž, řízení bude muset být hoodně optimalizované, protože když to nestihne včas tak bude následovat chyba a pád. A tuším že pro lepší predikci bude třeba i druhá část v ovladači. Každý engine má jiné požadavky - některý drží alokaci víceméně konstantně a jiný často zasahuje i do špiček.
Jaký pád? Jak už bylo řečeno, tento přístup je stejný jako u cache, tzn. zcela opačný, než se pro grafickou paměť používal doposud.
Zkusím to popsat ještě jinak. Máš k dispozici hrnec, který plníš vodou a bábu, která ti pro tu vodu bude chodit.
V prvním případě posíláš bábu s kýblem pro vodu, ona vždycky něco nabere a kolik nabere, tolik ti přinese a naleje do hrnce. Pokud si nepořídíš dostatečně velký hrnec, hrozí, že přeteče. Pokud si pořídíš velký hrnec, bude většinou poloprázdný.
Ve druhém případě pořídíš bábě místo kýble odměrku a posíláš jí pro přesný objem vody. Díky tomu si můžeš pořídit menší hrnec, protože je ti předem jasné, že s odměrkou, která je menší než hrnec, ti nikdy nepřinese tolik vody, aby mohl hrnec přetéct.
nj, jenže pak ten novátorský přístup bude muset podporovat engine hry, ne? Podle toho co je napsáno to vypadá, jak už jsem psal níže jako alternativní hw postup vůči sw postupu MS který to realizuje podobně ale má to ošetřený přímo v OS že samotná hra nepozná kde končí VRAM a začíná RAM.
Přece ta alokace aplikace je tam daná nějaký výpočtem pro mezní hranici spotřeby - to že v praxi se téhle hranice dosahuje málo neznamená že se jí nedosahuje vůbec, to by žádný soudný vývojář o 50% jen tak z legrace nenadhodnotil když by na její využití vůbec nedošlo. Ad princip cache napovídá že VRAM jako cache - a každá "keš" potřebuje hlavní paměť kterou bude klasická RAM. Proto to přirovnávám k postupu MS, byť to třeba řešení AMD ještě trochu "sesekne".
Jestli bude třeba podpora ze strany hry, zatím není jasné. Pokud ano, pak to ale neznamená, že by autor hry musel vyvíjet něco navíc, spíš že nějakým standardizovaným způsobem umožní ovladači GPU předat řízení správy paměti. Tohle je ale zatím na úrovni spekulací, takže to nemá smysl řešit.
Já jsem hlavně zvědavej jestli to v praxi fakt něco bude a nebo je to celé jen blud marketingu. Už teď jsou běžné situace, že když máte v systému třeba 8GB grafiku tak některé hry sežerou 7GB Vram, ale když tam dáte 4GB grafiku tak sežerou 3,8GB Vram a jedo ustejně plynule, stutter a velké přenosy přes PCI-E nastávaj až kolem 3GB. Je rozdíl mezi tim co se alokuje a co se použije, ano, ale to už funguje i dnes, vše se primárně tlačí do Vram a ta když dojde tak pak do RAM, ne že se celá Vram alokuje na něco co by "mohlo přijít" a pak když přijde něco jiného tak to půjde rovnou do RAM když neni místo? EE, půjde do Vram, reálnou Vram si rozeberou data co do ní fyzicky tečou, ne to co je alokováno a ve skutečnosti tam je třeba polovina dat.
AMD by taky mohlo mazazt jen med kolem pusy, u GPU jsme na to u nich už zvyklí, viz jak tvrdili že Radeony 39xx jsou nová GPU, nebo jakej superhype mělo HBM u Fiji a nakonec to jsou normální 4GB Vram i se tak chovaj nic extra navíc. Jo a ještě jak říkali že je to Overclockers dream, a vyklubalo se z toho GPU s nejhoršim OC poslední dekády. To co celej tenhle marketing materiál popisuje se ihmo v praxi už děje, takže co chtěj přinýst?
Ihmo fair by bylo, kdyby se to ostestovalo v praxi, ala v situaci kdy proti sobě budo ustát dvě 8GB karty v situaci která si vyžaduje 10GB a prostě by to nestačilo, a na Vega 8GB by to stačilo, pak smeknu, do té doby hrozí že je to jen marketingová kachna. Doufejme že aspoň Vega bude obecně velkej pokrok v architektuře, ne jen další die-shrink GCN s drobnejma vylepšeníma jak Polaris. Potřebujou use už někam pohnout.
„Já jsem hlavně zvědavej jestli to v praxi fakt něco bude“
AMD už ukázala na vzorku Vegy omezeném na 2GB paměti, jak hra běží s a bez využití HBCC. Že to funguje, je zjevné, jinak by neměli důvod to používat. Otázkou je spíš to, jak to bude uvedené do praxe.
jenze takle to nefunguje.. ty si michas nevyhody dvou ruznejch pristupu ktery nemuzou zaroven nastat (:
nemícham. Tohle je až podezřele podobné tomu co dělá MS ve WDDM v rámci DX12 kdy ve Windows 10 také klesla potřeba video paměti díky dotahování přes pcie z hlavní paměti. ALe AMD to chce realizovat víceméně hardwarově. Jistě je to zajímavý počin, ale co bude lepší jestli cesta AMD nebo MS ukáže až čas.
WDDM je API, takze aplikace efektivne predava kontrolu nad pameti driveru GPU. Ten proste bude u Vegy predavat cast prace primo na GPU, ktere je nejspis schopne pomoci virtualnich kanalu u HBM pretahovat data mezi RAM a VRAM s nizsi latenci a bez vlivu na vypocty bezeci na GPU. Asi by se to dalo popsat jako rozdil mezi emulaci virtualni VRAM a skutecnou HW akcelerovanou virtualizaci VRAM.
nvidia je aj tak nejlepsia :)
V ojebávaní áno.
nj, zda se ze optimalizace SW je pro vyvojare jiz delsi dobou "spanelskou vesnici"...., holt neni cas...
Hm.
To mi připomíná situace v obecném programování před cca 20-ti lety, kdy se běsnilo proti "C-éčkové" alokaci paměti programátorem, ve prospěch nových konceptů v C++ a především Javě, která se "o to stará sama". A výsledkem jsou pochopitelně zcela neoptimalizované aplikace, kde na spotřebu paměti každý programátor úplně kašle, "protože se to obsluhuje samo".
Proto bych se docela bál, že to naprosto podobně dopadne i v oblasti vývoje her. Dnes si při vývoji každý alokuje co nejvíce, aby v případě větších dat nemusel přialokovávat více nebo to pořád měnit, a nakonec tam z důvodu kašlání na optimalizaci původní vysoká hodnota zůstane. Proč přemýšlet nad úsporou paměti, když herní karty mají 16GB? Nakonec "jsou všichni rádi", protože výrobce karet prodá nové karty s velkou pamětí, programátoři nemusí "ztrácet čas" s optimalizacemi, které jim zaměstnavatel nerad platí... Problém s paměťovou náročností dnešních her je umělý, jelikož hry prostě využívají tolik paměti, kolik jim výrobce karet dá k dispozici. Dtto to probíhá v ostatních oblastech IT. Takže máme už mobily s větší RAMkou, než "potřebuje" desktop...
Zkrátka pochybuji, že právě tímto postupem se paměťová náročnost her sníží. Ze zkušenosti v ostatních oblastech je spíše zřejmé, že tímto způsobem paměťová náročnost stoupne nade všechny meze, protože to bude každému programátorovi úplně jedno.
"To mi připomíná situace v obecném programování před cca 20-ti lety, kdy se běsnilo proti "C-éčkové" alokaci paměti programátorem, ve prospěch nových konceptů v C++ a především Javě, která se "o to stará sama". A výsledkem jsou pochopitelně zcela neoptimalizované aplikace, kde na spotřebu paměti každý programátor úplně kašle, "protože se to obsluhuje samo""
Spotřeba paměti operační i jiné (cache!) v Javě je spíš dána především tím, že ten jazyk vůbec nemá "embeddovatelné" hodnotové typy a že každá pitomost tam má svoji hlavičku. Go má automatickou správu paměti také a paměťová situace v něm je přesto podstatně lepší.
nutno dodat, že takovej fallout 4 se 4k texture packem dokáže ve 4k hravě sežrat všechny 4GB HBM mojí Fury a klidně dalších 8GB ram. Díky W10 hra sice běží, ale při rozhlížení se kolem dokola dochází k viditelným propadům snímkové frekvence, jak se natahují nové textury z ramky. Při pohybu jedním směrem nejsou propady necvičenému oku tak znatelné a hra drží 60fps, ale při rozhlížení se klesá framerate na 15-21fps (ve městě, otevřená krajina, kde není tolik unikátních textur, jede celkem v pohodě) a frametimes jsem radši ani nezkoušel.
Funkci, o které se zde bavíme, teda přinese navíc co? Teď jsou ramky v podstatě cache vramkám, ale jen sw řízená a proto dochází k těm propadům? HW to bude lepší? Nebo je to tak, že nějaký balík textur má tolik a tolik MB, ale hra řekne grafice "vyčleň si pro to 100-300% víc místa, protože co kdyby", ale Vega pozná, že je to zbytečně moc? Proč se to teda "řeže" (dochází k propadům framtimes a díky tomu ke stutteringu)?
Nějak mi není jasné, co se stane v případě, že grafika má fyzicky 8GB HBM2 a hra má 57GB textur (případ FO4 4k texture packu), hra si teda řekne v nějaký lokaci grafice o cca 12GB místa a pak se stane co? Vega vytáhne křišťálovou kouli a řekne si, že bude po kompresi stačit 6GB?
Ten texture pack obsahuje textury pro různá rozlišení, hra tedy nepoužívá všechny.
> hra si teda řekne
Rekl bych, ze hra si nerekne nic :) Leda ze je napsana v DX12 / Vulkan. Pokud je napsana v necem jako DX11/OpenGL, tak alokaci textur ridi to API, a v tom API je kristalova koule, ktera odhaduje ktere textury bude pro pristi frame potreba. Hadam ze nejjednodussi odhadovani je stylem "nacpem tam vse co se vejde, a pak se uvidi". No a misto kristalove koule ted bude v hardwaru "ja si natahnu co zrovna potrebuji". Pokud mate scenu ktera vyzaduje vic textur nez ma vase grafika RAM, pak vam to nepomuze.
(teda alespon ja si to takhle predstavuju, klidne me nekdo znalejsi opravte)
Tak existuje něco jako MIP mapping, tak už jenom na tom principu by se dalo ušetřit - grafika bude mít ve 4k jen nejbližší textury v perimetru třeba 30 metrů, zbytek tak nějak osere a teprve až se pohneš z místa tak dotáhne zase ten správnej perimetr (s tím, že v reálu uvidíš full texturu až např. z 15 metrů). To je jen jeden princip, kterej už existuje, ale vývojáři (možná častokrát) natáhnou vždy textury celé lokace a proti tomu AMD "bojuje". Sama grafika si např. připraví vlastní velikosti=rozlišení textur, podle toho, jak detailní jsou reálně potřeba. A můžeš se dokonce točit na místě a rozhlížet... Opravdu nepotřebuješ 2 kilometry vzdálenou texturu ve 4k v paměti...
Ano, může se stát, že se ti přímo do xichtu teleportuje kilometr velikej lítající talíř a jeho povrch holt bude chvilku "mázlej", než tě rozmačká na sračku ))) Ten efekt vidíš v mnoha "dobře" optimalizovaných hrách, používá se dost i na konzolích, myslím že u Watch Dogs jedničky si recenzent stěžoval, že když jede moc rychle autem, je to sice plynulý, ale nestíhají se mu vykreslovat protijedoucí vozidla... Tomu já říkám jet rychle )))
Jsou i jiný přístupy, který k tomu můžou zvolit, ale spíš na úrovni ovladačů, než že by to drátovali natvrdo (nějaký frekvenční analýzy, jak často je nějaká textura potřeba atak). Ale taky se na to dívám jako na další (lepší?) HW verzi WDDM 2.0 (pro Vulkan?).
Já bych si tipnu, že to bude mít přínos pro VR. Přeci jen vyvíjet technologii která bude ve vlhkých snech marketerů dostupná v zimě pro současné hry nemá moc význam. Navíc když Vega s námi bude minimálně 2 generace GK možná spíše 4.
Toto je typicky krasozvast pro marketingove odeleni na propagaci neceho pro masy ...
pokud budete mit aplikaci ci hru, co do VRAM nahrava realnych 10GB textur
tak 8GB vam jaksi nepomuze ...
vyreseni deficitu starych API je krasa, ale proste realnych 16GB tech cool-8GB nenahradi
„pokud budete mit aplikaci ci hru, co do VRAM nahrava realnych 10GB textur“
Tahle věta nedává smysl, respektive myšlenka v ní obsažená je důsledkem celkového nepochopení situace. Kontrolu nad grafickou pamětí nebude mít hra, takže logicky ani do paměti nebude nahrávat žádné textury. O tom, jaká data budou nahraná do grafické paměti, si rozhodne GPU.
Procetl jsem zbezne komentare a priznam se, ze take nejsem moudry z jedne veci, snad se to de nejak polopaticky laikovi vysvetlit?
Tedy: Dneska si hra alokuje rekneme 4GB pameti na grafice, protoze cas od casu do ni skutecne potrebuje 4GB nahrat. Sice ne casto, ale obcas jo. Jinak je to obvykle 2GB, ale cas od casu vice.
Tato technologie udela to, ze na takovou hru pouzijeme 2GB grafiku, hra si bude nahravat ta sva obvykla data o velikosti 2GB...a kdyz bude chtit nahrat 4GB, tak se stane CO PRESNE? :-O
Fakt jsem laik a netusim. Predpokladam, ze v tu chvili se nejak pouzije nejaka napriklad RAM, do ktere se to nahraje misto do graficke karty, a z te RAM se to nejak operativne presume do te grafiky?
Neumim si predstavit jiny postup...
Kam by se ty data jinam daly?
A pokud to tak je, tak co kdyz ta hra v tu chvili skutecne VYZADUJE praci s 4GB datama najednou? Co se jako stane?:-O Nebo nejake ovladace te hre v tu chvili reknou, ze proste vice dat nedostane a nejak to "snizi detaily" ci tak neco?
Ja si to fakt neumim predstavit, da se to nejak vysvetlit fakt "jak pro blbce"?
Dik predem :-)
Nech to na ně, oni tě neojebou, funguje to dobře...
https://www.youtube.com/watch?v=mNOC5ZLA4sI
https://www.youtube.com/watch?v=O90zrOS18t4
TLDR; Hra si myslí, že pracuje s VRAM, ale skutečně pracuje pouze s RAM. GPU si natáhne do VRAM co potřebuje. Může to slušně fungovat i pod DX11 a bez úprav engine.
Aktuální situace:
Karta má 4 GB VRAM
Hra si alokuje 4 GB a nahraje tam 4 GB dat (modely, textury, atd)
Během renderování framu se použije cca 2 GB dat
- některé modely nejsou ve scéně nebo nejsou vidět
- některé textury se nepoužijí, z jiných je vidět pouze část
- z dalších textur se použijí pouze méně detailní mipmapy protože jsou v dálce
Nová situace:
Karta má 2 GB VRAM
Hra si alokuje 4 GB a nahraje tam 4 GB dat (modely, textury)
Hra si "myslí" že pracuje s VRAM, ale data jsou skutečně uložena v RAM
Během renderování framu se natáhnou pouze potřebné 2 GB dat (z RAM do VRAM)
- může to fungovat podobně jako virtuální pamět a stránkování
Co se stane pokud hra potřebuje během jednoho framu víc než 2 GB?
- trashing, GPU natáhne do VRAM data, použije je při renderování a rázem je zahodí a natáhne jiná data
- stejné řešení jako se používá běžně jinde
Často se renderuje následující framy velmi podobná scéna, takže přesuny dat mezi RAM a VRAM budou minimální. Data, která nejsou použita většinou nezáleží ani na natočení kamery, je to například:
- detailní mipmapy textur pro objekty, které jsou daleko
- detailní verze modelů pro objekty, které jsou daleko
- modely a textury, které nejsou zrovna ve scéně (ale hra je má nahrané "na GPU", aby je mohla rychle vložit)
Je možné, že AMD využije nějakou HW technologii na urychlení přenosů mezi RAM a VRAM.
Také je pravděpodobné, že když CPU submituje batche, driver na základě toho může určit jaká data budou potřeba a začít je tahat na GPU.
Na to je dost času, protože GPU nezačne zpracovávat batch ihned, ale se zpožděním (když se submituje aktuální frame, je typické, že na GPU se stále ještě renderuje předchozí frame).
Jo, to dava logiku - no neverim, ze presuny dat mezi RAM a VRAM budou tak rychle.
Imho tohle bude fungovat v situaci, kdy skutecne hra sice bude chtit 4GB grafickou kartu,ale ve skutecnosti 99,99% casu bude vyuzivat jen 2GB
Pokud by potrebovala realne vyuzivat 4GB v napriklad 10-20% casu, tak to uz bude imho dost zasadne brzdit.
Coz je imho docela logicka uvaha I z toho duvodu, ze kdyby tomu tak nebylo, mohly by se grafiky delat vsechny skoro bez pameti a vsechno by se mohlo tahat z RAM, coz se nedela.
Buď se z toho stane nový standard , nebo to bude featura co ještě stropí AMD hodně problémů. Aktuálně je možný scénář obého ....Pamatuji původní Furry Max a ovladače které deaktivovány celé jedno jádro jen kvůli tomu aby karta podávala výkony srovnatelné s tehdejší konkurencí . A 8GB mi připadá , že se AMD jistí , pokud automatická správa paměti nebude fungovat tak optimálně , jak se na prezentačních slidech jeví . ( Pokud to půjde bez zádrhelů , čekejte v budoucnu opět 2GB karty a snad i s rychlými čipy ...)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.