AMD Mantle: Low-level Graphics API

[webwalker]

Mna by skor zaujimalo, co mantle a hyperthreading

Johan Andersson ‏@repi 10 hod.
@Covenant_R @JuppiO we always run with HT on. the patch today also contained a bunch of tweaks & fixes so try it out with HT

Vyzkoušet pak ale musíš sám

[DOC_ZENITH]

Jo jo mě ulítly včely a tobě zdravej rozum Docente. Takže odteď už ani tolik protěžovaná i3 nenakrmí HD7870 ? no to jsou mi novinky. Co bude příště ? i5 co nenakrmí ani HD7730 ? Trochu soudnosti by neškodilo... Hlavně doufám, že nakonec nepřijde tvůj oblíbený argument v podobě nějaké (zprasené) MMO co umí běžet na jednom vlákně a z které budeš generalizovat ty svoje ujeté závěry

repost toho co jsem už jednou postoval:

Note that these drivers Catalyst 14.1 beta provide, finally, the support frame pacing (rate of regular displays multi-GPU) for higher resolutions to 1600p for all graphs and maps for Kaveri APU coupled with Radeon R7 250. These drivers also include support for HSA Kaveri.

Ten driver na Kaveri umožňuje použít HSA. Umožňuje použí HSA =/= mantle jej používá, či jakjkoliv rendering. Po x měsících těžení GPU ti na 100% potvrdim že GCN opravdu neumí něco jako multithread na GPU či opravdu dobrej content-switching.Ala jakmile výpočetně zatížíš GPU, musíš mít sakra dobře nastavené priority aby se to netrhalo i 2D UI ve win, natož jakejkoliv 3D. A těmito prioritami ztratíš tak 20% výpočetního výkonu GPU. Pokud jej chceš tahat naplno nepustíš si během takovýho výpočtu ani film. Plynulej 3D rendering v hrách je komplet vyloučen jakmile se GPU používá na něco jiného. Takže nepleť HSA do mantle.

Co se té CPU limitace týče. Tak zdravé kombo je dle mého názoru zhruba toto: Mainstream karta typu 7870, haswell I3 minimálně nebo přetočené FXko. Katy nad tim, třeba 7970 OC, tak tam I5. Třída GTX780 atd, I7. Třída GTX780TI + Oc, přetočaná I5. SLI či jiné hovadiny = přetočená I7. Šestijádrovou jsem nezmínil protože ty thready až na vyjímky obvykle moc nepomáhaj, doufejme že s mantle se to změní.

[nou]

ale nic nebrani aby Mantle HSA pouzivalo. HSA prinasa HUMA takze to napriklad moze odburat kopyrovanie z CPU casti RAM do GPU casti ako to bolo doteraz. samozrejme to je aplikovatelne iba na APU. HSA ale prinasa omnoho efektivnejsie prepinanie medzi CPU a GPU vypoctavmi tym ze odstranuje nutnost kopyrovania/uzamykania pamete. HSA moze hrat rolu aj pri klasickom renderingu. jediny rozdiel medzi renderingom a GPGPU je v tom ze sa pouzivaju ROP. HUMA urychly nacitavanie dat aby ich mohlo GPU pouzit na rendering. ak sa HSA/HUMA v Mantle nepouziva teraz tak v buducnosti urcite.

to ze ti seka GUI pri miningu je pravda. ale to je tym ze ta uloha bezi sekundu-dve kedy sa nemoze prerusit. rendering vypocet ale bezi len 10-20ms kedze sa musi prekreslovat X krat za sekundu.

[del42sa]

Docente nemám čas se tu s tebou dohadovat o nesmyslech. Poslední poznámka: sdílený paměťový prostor. Už jsem se tady o tom dřívě bavili a o kopírování dat z paměti karty do paměti CPU a naopak. Tohle u Kaveri odpadá a to je jedna ze stěžejních vlastností Mantle, zcela nová režije práce s touto unifikovanou pamětí.

[DOC_ZENITH]

Vim co je to HUMA, ale taky vim že to neni něco co by se používalo při 3D renderingu v hrách. Huma je super věc protože paměť pak nemusí bejt striktně odělená na CPU a GPu část a dokonce mohou obě výpočetní jednotky pracovat na 1 úloze přímo v paměti. Ano v tom je budoucnost. Ale při 3D renderingu jak jej známe nám to troufám si tvrdit nic nepřinese, protože jakmile piužiješ SP v GPU na cokoliv jiného během redenrigu budeš mít děsivé pády výkonu a stuter. GCN nemá něco jako HT či efektivní content switching. Alespoň v OpenCL jej nemá, a myslim si že je to věc HW ne API. Ani mantle tam necílí, cílí jako cesta k železu GPU s GCN architekturou. Tečka, je to API. Api se ti nebude chovat jinak dle typu GPU, to by to pak bylo higher level API což mantle bejt nemá. Leda že by vývojáři her napsali spešl optimalizace pro APU. Dream on about that.

[nou]

DOC: HUMA odstranuje kopirovanie RAM<-->VRAM. ked sa renderuje nejaka geometria tak sa nastavuje nejaky buffer kde su ulozene pozicie kde sa kreslit. engine hry ten buffer musi teraz namapovat zapisat aktualizovane data odmapovat a tie sa potom poslu cez PCIe do grafiky. HUMA umozni aby to mohlo CPU prepisat priamo na mieste bez akehokolvek kopirovania. HUMA rapidne zlepsi komunikaciu GPU<-->CPU kedze sa takmer nic nemusi kopirovat.

[ttxman]

HUMA, jenom rika, ze shodna adresa (ukazatel) na GPU a GPU ukazujou na stejny pametovy misto, a CPU i GPU tak maji vicemene primy pristup k obema RAM bez kopirovani.
Pro diskretni grafiku to porad znamena alokace a kopirovani textur a jinyho rendering balastu do pameti na graficky karte, protoze je to proste rychlejsi. Tahat to z pameti CPU je sice mozny, ale pomalejsi, jenze asi ne ve 100% pripadu...

Mantle jako API by si muze kontrolovat "na jak moc HUMA PC bezi" a v zavislosti na tom eliminovat nektery kopirovani bufferu. V pripade APU, ktery ma jenom 1 RAM by to znamenalo, ze mnozstvi kopirovani se da snizit na absolutni minumum. Otazkou je, kolik je to minimum? (jak v mantle funguji ruzne buffery a jejich pushovani na grafickou kartu z nas tu pravdepodobne nikdo nevi)

Takze podle me zisk vykonu na APU diky HUMA je podle me realny diky snizeni pametovych prenosu. A vzhledem k tomu, ze GPU v APU ted ma bottleneck prave pristupy do pameti tak by to mohlo byt znatelne zrychleni...

[DOC_ZENITH]

Hmm, mantle by mohlo teoreticky něco v tomhle vybojovat. Standardní API, ala OGL a D3D totiž maj veškerej obsah textur ve Vram uloženej i v RAM. Až na to že jsou to komplet jiná data, v ram jsou textury original a v GPU paměti jsou komprimované DXTC/S3TC. V ram jsou aby ve win fungovalo plynulé a rychlé switchování a efektivní multitasking. Třeba Glide neměl textury v RAM, proto taky hry když běžely pdo Glide žraly méně ram než třeba pod D3D. Ukázka třeba staré UT + win98, čistej OS, 128MB ram, pod glide max detialy OK, pod D3D max detaily = swapování.

Mantle by teoreticky rovněž nemuselo mít textury i v ram. Rozhodně nemůžou bejt jednotný s těmi ve Vram protože jak už jsem řekl, komprese. To samé nevim jak při real-time renderingu se bude zasahovat do geometrie. Ta se skládá v Z-bufferu, kterej má od R300 rovněž interní kompresní algoritmy by GPU tak jak do jeho dat chceš zasahnout aniž by jsi přerušil render. Ughm, příliš mnoho nejasností.

Podle mě o tomhle Huma vůbec neni. Ta je o tom že výpočetní schopnosti GPu půjdou použít pro 1 úlohu. Bude v 1 paměti a budou na jejích threadech moci pracovat jak CPU tak GPU jádra. KOmplet se odstraní posílání dat to DPU a čekání na to co se vrátí, atd. Výpočty, atd. Na to. Celej HSA koncept je o tomhle. Na real-time 3D rendering, tak velké přínosy nečekám.

[ttxman]

Komprese nevadi, proste to lezi nekde v ramce a zabira nejaky misto, to je tak vsechno. Problem je, ze kdyz aplikace jde ve D3D fulscreen rezimu a vypadne z nej, tak prijdete o graphic device (mimo jine) http://msdn.microsoft.com/en-us/library ... s.85).aspx:"A lost device must re-create resources (including video memory resources) after it has been reset." Ty resource nemusi byt v ramce, ale pak je alt+tab zpatky pomalej = proste loading levelu znova.

Glide tyhle problemy mit nemusel, jelikoz 2D a 3D cast renderingu byla plne oddelena a nesdilela ani pamet, v ty dobe sem zadnej 3D akcelerator nemel, takze netusim jak se to chovalo i kdyz bych tipnul, ze proces si proste nemohl narokovat 3D akcelerator, pokud uz ho pouzival nejaky jiny proces, takze ramka byla v nebezpeci

Huma sice pro rendering neprinasi takove vyhody jako pro GPGPU. Ale jak sem psal predtim, minimalne muze eliminovat zbytecna kopirovani. A v pripade APU i kompletne eliminovat pamet vyhrazenou pro GPU, jenze s tim musi pocitat API.

Tezko muzes chtit nejake vyhody v D3D/OGL situaci, kdy vezmu buffer, zkopiruju ho do GPU a pak si do toho sameho bufferu pripravuju dalsi data, tam to kopirovani proste musi byt, jinak nebude fungovat nic. Mantle by mohlo fungovat stylem: Tady mas buffer s datama, dej ho do renderovaci fronty.... dej vedet az s nim skoncis. V tuhle chvili se diky Huma nemusi kopirovat nic. Na APU neni duvod ke kopirovani zadny, u diskretni grafiky s dedikovanou RAM se kopirovani vyplatit muze(to fakt neumim ohodnotit).

edit:typo

[del42sa]

Docente Mantle není jen o odstranění overheadu slabého cpu, je to mnohem více. Je to úplně nový způsob práce s daty a to zahrnuje i práci s pamětí, efektivní přidělování threadů, multi gpu konfigurace, asymetrický rendering,atd. Trochu si to prostuduj a přijdeš na spoustu zajímavých věcí.



http://beyond3d.com/showthread.php?t=64351&page=25

http://www.geeks3d.com/20131113/amd-man ... per-frame/

http://www.slideshare.net/DICEStudio/ma ... developers

[dexterav]

Však až vyjde driver, tak si pak přepni renderer z DX na Mantle a porovnej

//Aha, "Titanic", tak nic

stále to nič nedokazuje, proste na 15% zoptimalizujem aj ovládče tak ako sú to fakt neni až taký problém a netrebe k tomu mantle
samozrejme netvrdím žo to neni zásluha mantle ale proste na +15% v7konu ozaj netreba nejaké zázračné popr brutálne optimalizované api
to ovládače ukazujú dosť dlho

nj Titanic

[ArgCZ]

jo jenomže 15% v průměru může taky ukazovat 35% situaci kde šel výkon do kopru a 6% v situaci kde jsi měl stabilní FPS a co pak bude klepší? Nějakej průměr je na prdlačku.. a co to ostatní, asymetrickej CF? CF bez AFR etc...

58% se dvěma R9 290X je taky v pohodičce dosažitelné optimalizací ovladačů žejo

[ttxman]

Ano optimalizujeme ovladace, aby hra bezela klidne desitky procent lip. Ja v tom vidim dukaz slozitosti a problemovosti DX. Jak muzete implementaci API optimalizovat na konkretni hru? A jak se to muze dit porad dokola? To v podstate znamena, ze hra se chova nestandartnim zpusobem, zpusobem jakym se nechovala jeste zadna jina hra nechovala (a to mluvime o hrach za miliony dolaru). To se deje pokazdy znova, jak se na jednom API muze prakticky kazda hra chovat nestandartne?

No a jedna citace pro rozproudeni debaty z prezentace od DICE na zaver:

No driver threads - no overhead - no contention

[Hladis]

To není o slozitosti API. To je o tom, ze AMD i nV pouziva věci jinak a něco sedi dobře tomu a onomu. DX je univerzalni s nejakymi standarty a AMD a nV si to ohybaji podle sebe. Přes standartni compilator to u jednoho jede a u druhyho to vyhodi errory. K tomu, aby to běželo dobře je třeba optimalizovat driver. Ono taky optimalizace často primo u vyvojaru znamena jen vyflusnout něco v kompilatoru a je hotovo. To poslou nV a AMD a ti na to splacnou driver, aby to sedelo jejich HW, nebo vyvojarum jedna z firem stoji za zadkem.

Pokud je něco low-level, tak to je uzpusobeny rovnou na konkretni architekturu, ke který primo pristupuje. To samozrejme odboura nektery problémy v procesu.

[ttxman]

To není o slozitosti API.

Ja nemyslel slozitost API, ale slozitost implementace driveru..

To je o tom, ze AMD i nV pouziva věci jinak a něco sedi dobře tomu a onomu. DX je univerzalni s nejakymi standarty a AMD a nV si to ohybaji podle sebe. Přes standartni compilator to u jednoho jede a u druhyho to vyhodi errory. K tomu, aby to běželo dobře je třeba optimalizovat driver.

Tady nejde jenom o kod pro shadery (kde zadnej standardni kompilator neni, jelikoz ma vyrobce z principu svuj). Navic to nemeni nic na tom, ze pokud neco v driveru opravi, tak uz by to melo fungovat a ne se to opakovat s kazdou hrou.

Ono taky optimalizace často primo u vyvojaru znamena jen vyflusnout něco v kompilatoru a je hotovo.

Ale takhle by to fungovat pro zmenu melo, proto je to high-level API. Pokud dodrzim nejaky zakladni pravidla, tak bych se mel sakra priblizit maximalnimu vykonu (na danem api). Vyvojar nema k HW pristup proto by na nej ani nemel optimalizovat. Problem v tomhle pripade neni obecna pomalost nebo rychlost DX. Problem je nemoznost napsat optimalni kod pro DX a diky tomu stale se opakujici prostor pro optimalizace driveru.

edit:
Takze bud DX je uz na urovni, kdy uz se neda dal vyvijet a kazda optimalizace driveru je optimalizace na extremne konkretni pouziti (tam mi moc nedavaj smysl ty velky procenta narustu). Nebo je to tak problematicka uloha, ze se nekolika firmam a investicemi v miliardach dolaru nepodarilo priblizit se k optimalnimu reseni. Tak nebo tak je to problem, ktery je potreba nejak resit

[dexterav]

jo jenomže 15% v průměru může taky ukazovat 35% situaci kde šel výkon do kopru a 6% v situaci kde jsi měl stabilní FPS a co pak bude klepší? Nějakej průměr je na prdlačku.. a co to ostatní, asymetrickej CF? CF bez AFR etc...

58% se dvěma R9 290X je taky v pohodičce dosažitelné optimalizací ovladačů žejo

lenže ja spomínam iba tých 15%
a popravde pri CF/SLI neni problém ani 100% že

[del42sa]

lenže ja spomínam iba tých 15%
a popravde pri CF/SLI neni problém ani 100% že

při nefungujícím CF/SLI určitě

[Trovaricon]

Standardní API, ala OGL a D3D totiž maj veškerej obsah textur ve Vram uloženej i v RAM. Až na to že jsou to komplet jiná data, v ram jsou textury original a v GPU paměti jsou komprimované DXTC/S3TC.

To nie je pravda. Teraz neviem, ci ti to tu nikto nevie vyvratit, alebo na to vsetci kaslu.
Kde na toto chodis? Dofrasa skus raz zajst na MSDN namiesto napisania jedneho zavadzajuceho prispevku.
V D3D9 musis vytvorit resource v D3DPOOL MANAGED aby sa spraval tak ako popisujes (to, ze taky L2 vytvaral nanovo vsetky textury aj ked bolo 80% z nich v managed je ina tema).
V D3D 10+ je "hint" od D3DUSAGE flagu kam umiestnit resorce ale v konecnom dosledku je to v rezii OVLADACA.

AD nekoprimovana textura v RAM - nebolo by potom uplne jedno aky kvalitny kompresny algoritmus (bavime sa o kvalite, kedze kompresny pomer je konstantny) pouzijes ked ti to runtime dekomprimuje a pri prenasani z RAM do VRAM znova skomprimuje

K teme:
Ked vysla prva verzia C++ AMP, tak som si hovoril: skoda ze to ma taku biednu podporu textur, lebo z tohto by mohol byt zaujimavy "software renderer". S vydanim VS 2013 prisla nova verzia, ktora vylepsila podporu textur (napr podpora filtrovania).
Ked sa tak pozeram na Mantle z pohladu univerzalnosti zdrojov (textury / buffre - vychadzam z prezentacii), tak mi to pripada ako "C++ AMP 2.5"

[maltra]

Do hajzlu, som myslel ze to cez vikend otestujem. No, su to naozaj mant(l)áci v tom AMD, uviedli oni niekedy nieco vyznamne nacas?

TechPowerUp - Update on AMD Mantle driver delayed

[webwalker]

@Trovaricon: Takto nějak vypadají knihovny Mantle:
http://pastie.org/8682650