AMD Mantle: Low-level Graphics API

[webwalker]

sam_217: nekde sem cetl, ze od nejakyho vyvojare na APU13 padlo, ze DX overhead je 40% a mantle 8% ... ale taky si to nekdo moh vycucat z prstu...

To řekl Jurjen Katsman z Nixxes (portace Thief na PC).

[sam_217]

sam_217: nekde sem cetl, ze od nejakyho vyvojare na APU13 padlo, ze DX overhead je 40% a mantle 8% ... ale taky si to nekdo moh vycucat z prstu...

To řekl Jurjen Katsman z Nixxes (portace Thief na PC).

Jo, jaks to připomněl taky sem si vzpomněl...jenže v čem je ten overhead? V konzumaci více CPU výkonu, než by bylo třeba, nebo GPU?...já z toho nepochycuju, zda je to myšleno jako overhead celkově díky náročnosti na všechen HW, nebo se to týká jen GPU...

Tohle vypadá zajímavě http://www.bit-tech.net/hardware/graphi ... -directx/2 a zdá se že píšou tam právě o tom, co vlastně DirectX brzdí.

[Krteq]

same, ty v tom máš pořád pěknej guláš

Tím byla imho myšlena celková režie, tj. HW (CPU,GPU) i SW (Driver, OS/abstr. layers atd.).

Jinak dobře že jsi tenhle článek vytáhnul, protože už mi chvíli vrtá hlavou, jestli Mantle náhodou není z části právě Huddyho dítě

[ttxman]

Ja si myslim, ze jde o dobu kterou stravi CPU volanim API funkci.
Takze to bude 60% casu v kodu enginu a 40%v DX funkcich vs 92% casu v enginu a 8% v mantle API funkcich.

S mantle se cast funkci API presunula do enginu, takze to nemusi nic znamenat. A na druhou stranu tam klidne muzou byt 10x vetsi FPS, je to jenom pomer mezi dobou v driveru a v enginu a ten muze bejt stejnej pri 1fps i 1000fps

[webwalker]

Tak, dle mého, je prakticky vše o cpu. Už v DX11 bylo převážně vše o cpu - jako teselace, multithreaded rendering.
Ještě připomenu Civ5, kde nVidia představila jako první podporu multithreaded renderingu.

S původním ovladačem:


a s novým ovladačem a MTR


Stačí kouknout o kolik poskočil výkon GTX580 u téhle cpu limited hry

Řešilo se to pak v tomto vlákně (Ryan Smith) >>

No a víme, že MTR uměl "udělat" až dvojnásobné draw call, zatímco u Mantle se spekuluje o desetinásobném draw call. To ale neznamená, že nárůst výkonu bude lineární!!!

[sam_217]

same, ty v tom máš pořád pěknej guláš

Tím byla imho myšlena celková režie, tj. HW (CPU,GPU) i SW (Driver, OS/abstr. layers atd.).

Jinak dobře že jsi tenhle článek vytáhnul, protože už mi chvíli vrtá hlavou, jestli Mantle náhodou není z části právě Huddyho dítě

Jo, mám...nic nezapírám nejsem v tomhle žádnej znalec a rád se o tom něco dozvim, jak to doopravdy je...a asi ani nejsem jedinej.

Pokud to je celková režie jak řikáš, kolik z tý 40% ztráty DirectXu tvoří ztráta GPU výkonu?
Ten Huddy sice řiká, že výkon PC grafik je tak 10x lepší jak starejch konzol...jako důvod se uvádí i directX, ale jak vědět, jestli ten důvod je v omezenosti CPU, což neumožňuje dělat tak pěkný hry aby běžely rozumně, nebo to je proto, že hry se hlavně portujou z konzolí...ztráta výkonu GPU jak to chápu já je dána i výkonem CPU = brzdí ho a nebo snad díky DirectX desktopový GPU počítaj věci, který by normálně počítalo CPU (fyzika a jiný věci který asi DirectX cpe na GPU místo CPU), právě proto, že CPU je moc pomalý? a proto je hodně her méně závislých na CPU ale na GPU? kdežto na konzolích sou grafiky slabý, ale k tomu konečnýmu výsledku např hodně ulehčuje IBM Cell CPU v PS3 např?...

[DOC_ZENITH]

Máš pravdu v obouch bodech.

Jednak porty z konzolí jsou tragické. Když se ani neobtěžujou vyladit ovládání tak jak je na tom asi engine. Ty porty se dělaj tak že to proženou jinym compilerem aby to bylo x86 win32 a API bylo directX a tim to hasne. Optimalizace je pak logicky tragická.


A co se týče PS3 a Cellu, tak u těch hi-tech chce co to fakt ždímou typu Killzone, Uncharted, The last of us, atd. Tak tam se GPU používá opravdu jen na to co je nutné a s čím CPU nemůže pomoci, jako třeba práce rops a texture filtering. Jinak je ale ve tlačeno na cell. Kdysi jsem viděl ňáké dev video s dev verzí killzone a měli tam tunu subprocesů, paměť spočítanou do posledního MB (na těch starejch konzolích je to inu třeba eghm). Ono prograovat na cell je noční můra a jen málo vývojářů to zvládlo a ti co ano tak těm to trvalo x let než se na to naučili optimalizovat. On Cell je totiž singlecore CPU s dalšími výpočetními jednotkami uvnitř na které se musí přímo volat instrukcema, nejde na ně poslat separé thready či to project jinym compilerem. Proto na Cellu nabootoval standardní powerPC OS, ten CPU byl powerPC compatible ale jen tim 1 hlavnim jádrem o výkonu +- jak Pentium III. Aby se z toho stal trhač asfaltu musely se použít instrukce co použily ty další jednotky uvnitř a navíc to nesmělo bejt FPU heavy protože cell prní generace (ten v PS3) má docela slabej výkon v FPU, to vyřešili až u toho druhýho co nepoužíval XDR paměti.

Mantle je jiné ale zároveň v něčem stejné. Zezačátku to opravdu vidim jen jako odlehčovač CPU a odbourávač CPU limitace. Ano bude to brána přímo k železu GPU, ale dnes téměř žádnej programátor neumí programovat na železo GPU, takže to bude trvat x let než se oběví první enginy kde o to budou vůbec pokusy.

Edit: To ale může být i problém protože pokud jim potrvá roky než na to budou optimalizovat, tak to tu fakt bude stejná GCN? Nebo další verze GCN zpětně kompatibilní s tou první aby ty optimalizace furt fungovaly? A co Nvidia či jiná konkurence? Kdyby to nedali tak monopol = průser pro všechny. A kdyby ano což pravděpodobně ano, ačkoliv NV má herní grafiky spíš jen pro marketing propagandu a předvádění se, ne jako citelnzj zdroj příjmů, tak se určitě vytlačit nenechaj. Buďto joino mantle nebo nabídnou vlastní alternativu. A co potom? I kdyby to bylo mantle jejich železo je komplet jiné než to od AMD? A co pak vývojáři? Jen 3 studia po x letech optimalizovala perfektně pro cell a to je 1 HW, v PC by jich mělo bejt více? Co s tim pak.

To bude jak za dob Glide kdy byly hry co uměly jen glide. A nebo ty co uměly hodně API ale Glide bylo jednaznačně dominantní ala pod těma ostatníma to jelo pomaleji, nebo to hůře vypadalo nebo oboje. Zkus si třeba na prastarym Pentiu II 400Mhz zahrát UT na Voodoo2 pod Glide, pojede to docela fajn. A pak to zkus na stejné sestavě s jakoukoliv kartou přes D3D či OGL... pojede to strašně, 2x hůře. K obdobnému výkonu tam pak potřebuješ 2x tak rychlé CPU. Tehdy se nad tim mávlo protože po 2 letech jsme měli více jak 2x tak rychlá CPU a ty hry pak šly hrát na všem. ale dnes těžko toto nastane když Nehalem 2008 vs Haswell 2013 = +- 35-40% výkonu navíc a je to 5 let. Takže zde jsou mé obavy. Zatim se uspokojim s variantou že to bude odstraňovat CPU limity protože to je dle mého názoru klíčová věc.

[del42sa]

Já bych tochu zasáhl do té vaší diskuze. Nevím proč se tu bavíte o nějakém hypotetickém čísle, které se navíc vztahuje ke konkrétní hře ? Já si osobně myslím že s těmi procenty to vůbec nelze paušalizovat, protože máme několik verzí DX a drtivá většina her je navíc v DX9 a nikoliv DX11. Jedna věc je limitace CPU a jiná limitace samotným API bez ohledu na CPU. To že Mantle umožňuje takový násobek draw calls je dáno IMHO tím jak to API samo o sobě funguje nikoliv samotným CPU overheadem. Stačí se podívat na přiložený slajd. Takový násobek nelze dosáhnout pouhým odstraněním CPU limitace.


Spíše jde o způsob, jakým Mantle vnitřně funguje. Právě ta "monolitická pipeline" umožňuje provádět paralelně "rendering command list" zatímco co DX zpracovává příkazy "sériově" jeden po druhém.



Závislosti na CPU se nezbavíme nikdy, protože pořád bude CPU k určitým výpočtům potřeba, ale Mantle bude umožňovat (pokud to bude třeba) efektivně přiřazovat CPU až 8 vláken. To by sice teoreticky měl umět i MTR u DX11, ale realita zdaleka není tak růžová jako na papíře a násobek draw calls neodpovídá náročnosti programování MTR. Proto se do toho nikdo nehrne...

[sam_217]

...

Díky za ujasnění.
Podle toho co bylo k vidění ze slajdů atd to ale spíš nevypadá, že to AMD sváže jen na GCN, měli slajd kde bylo jasně řečeno "not tied to GCN architecture"...mohli by jinak získat takovou podporu od tolika vývojářskejch studií jak to tak vypadá z těch dosavadních zpráv? proč by se přece měli otravovat s optimalizací na AMD hardware, když už tak se jim nechce z konzolí na PC portovat nějak pečlivějc...jinak mi fakt nedává smysl, proč by Star Citizen měl běhat na Mantle API jen proto, že na AMD GCN radeonech bude podávat R9 290X o 30% lepší výkon jak titan, to by je AMD snad muselo fakt uplatit aby je k tomuto donutilo.

@del42sa
Asi tě moc nechápu...Co je pro tebe "odstranění CPU limitace"?...není náhodou ta "monoltická pipeline" právě jedním z elementů, který odstraňuje CPU limitaci? Nemyslel si to náhodou tak, že CPU limit je dán díky API? jestli jo tak to je přece jasný, že tak mantle funguje...Mantle přece nečaruje výkon z ničeho, on jen lépe "doluje" ten výkon, co už tam je... jestli sem tě pochopil správně, tak samotná CPU limitace by pro nás byla konečná, protože žádný API by ten výkon nezachránilo, zachránil by to akorát další přídavnej HW, nějaká akcelerační jednotka a nebo změna architektury, sázka na ohromnej počet jader a tim i předělání celýho dosavadního SW pro multithreading, v tom je přece jasný, že se závislosti na HW jako CPU nikdy nezbavíme...Vždyť celá podstata Mantle je na tom, že bere výkon kterej v tom CPU už dávno je, asi jakože Mantle je trubka (téměř)bez děr, kterou proteče voda až do bazénu beze ztrát, DX je děrává trubka, kterou při stejnym proudu do bazénu doteče o 32% míň vody.

[DOC_ZENITH]

Ano not tied ale když chceš optimalizovat na železo GCN je jedno železo. Non GCN bude jiné železo a tam budou takové optimalizace k *****, to je právě má obava z do budoucna že se z mantle použije jen to co neni vázané na jednotlivé GPU architektury a tudiž se z nich zase nebude ždímat maximum. Či jednotlivé hry dle toho kdo si je zasponzoruje budou ždímat jen z toho čo onoho výrobce a bude v tom ještě větší koruptční bitva než jakou vedla Nvidia v jejich nej letech....

Co se Star citizen týče, tak AMD tam muselo zareagovat. Je to vůbec první Cry engine 3 hra kde bylo slíbeno mantle. Ještě se ani neví jak to chtěj udělat. Ta hra zatím ve své současné fázi běží na NV kartách citelně rychleji takže AMD něco udělat muselo protože kdyby to takhle zůstalo byl by to průser. Mantle ve Star citizen je spíš snaha vyrovat stav.

Pokud AMD chce skutečně masově uspět, musí představit své vlastní vývojářské nástroje. Dnes se vše dělá na NV. NV má dev toolsy, AMD je nemá, a ti lidé co dělaj ty 3D modely a animace maj pod stolem Quadro a dělaj to v softu ve kterym má prsty NV. I ten star citizen. Ta akce na hawaii byla první zmínka o AMD, do té doby sám Chris roberts když ukazoval své PC an i v jednom neměl CPU nebo GPU od AMD. Dokud toto bude realita tak se NV nemusí bát.

AMD musí nabídnout své vlatní alternativy těm nástrojům co má NV a taky nabídnout stejně kvalitní support. A ty jejich nástroje musej pracovat v mantle a pro mantle. A výsledky musej stát za to aby se studiím vyplatilo na toto API přejít jako na primární API, ne jen jako třešničku na dortu kterou tam dodaj stylem "hra je hotová hoďte tam mantle ať AMD nebrečí".

Co se týče portů z konzolí, po CPU stránce nás čeká zlepšení. Bude to optimalizovanj x86 kód, takže na našich CPU pojede velice dobře. Je klidně možné že ty next-gen hry budou běžet lépe jak ty staré. A to mluvim obecně. Jaguar je jinej jak FX či Intely, takže se ani nedá říci že by z toho ňák AMD těžilo v desktopu, budou z toho těžit všichni společně.

Jediná škoda je že Jaguar je takové vícejádrová K6 na stereoidech. V moderních instrukcích je slow. Umí třeba FMA ale potřebuje na 1 cyklus 2 průchody takže s 50% výkonem, takže se pro hry nedočkáme optimalizací na AVX, FMA a podobně.

[sam_217]

To mě taky napadlo... že vlastně z Mantle by se využila hlavně ta část, která by lépe využívala CPU, takže jen na odstranění CPU limitu a běh na GPU obou výrobců stejnej/podobnej, přičemž mantle může mít další funkce low level funkční jen pro AMD GCN atd - asi ve stylu jako OpenGL extensions pro Nvidii, který se asi ale budou využívat fakt jen na AMD sponzorovaných hrách...
Což skoro vypadá jak když si AMD radši vyrobilo "svoje vlastní OpenGL" místo toho, aby si udělalo vlastní extensions a to díky konzolím.
Takže by to bylo vlastně celý o tom, že Mantle díky svý příbuznosti z konzolovejch API přenese na PC tu konzolovou optimalizaci na x86 - což vlastně mě docvakává ještě víc , proč asi se v Mantle zdůrazňuje ta monolitická pipeline/multi rendering -> protože AMD jaguar má 8jader a jedinej způsob jak ty pomalý HD7750/HD7850 nebo co je v těch nextgen, moc nezatížit je využít těch 8jader co nejlíp, aby na tom běhala top skvělá grafika na úrovni dnešních top grafických her -> pojede to i na intelu obdobně a na GPU by byly minimální optimalizace...a Mantle v tomhle asi šíleně usnadní portaci, kdy se to jen projede kompilerem z Mantle, optimalizace na x86/víc jader tam všechny zůstanou a všichni budou jásat, jaká to paráda, přičemž 8mi jádrový AMD konečně předběhnou ve všech takovejch hrách 4jádrový intely, díky většímu počtu jader...

[arach]

zenith: kdyz je engine naprogramovanej treba v c++ tak jakej na to ma vliv hw na kterym v c++ programujou ?

[DOC_ZENITH]

O vyšších jazycích jako je C++ tu neni řeč... co má C++ společného s vývojem animací, modelů či programování shaderů GPU....

[arach]

no tak treba ue engine je v c++

[Krteq]

Jeden o voze a druhej o koze

[arach]

no tak ja tomu tak nerozumim tak se prave ptam :- ) sem si myslel ze kdyz renderuju nejakej model tak ho vyrenderuju stejne na cemkoli treba v 3d studiu, jen na necem me to bude trvat min : -) a game enginy jsou teda naprogramovany vcem, v cem me tam pomuze treba quatro proti firepru ?
je v tom kodu moje enginu bude nejaka optimalizace na konkretniho vyrobce grafik, tak v cem me pomuze quatro proti firepru, kdyz me ty optimalizace do kodu doda treba nvidia ?

[webwalker]

Tvorba 3D objektů na kartách nVidie je sice pěkná věc, ale nakonec si vývojář stejně bude muset sednout k mašině s kartou od AMD a optimalizovat minimálně shadery pro ni. Navíc, Mantle by se mohlo prosadit i do samotných 3D vývojových aplikací, což by byl samozřejmě pro nVidii celkem problém a pokud vím, AMD se netají tím, že by rádo.

[nou]

overhead DX 40% vs Mantle 8% bude pravdepodobne kolko casu stravy CPU vnutry volani jednolivych API. teda pri DX sa takmer polovica casu premrha v drivery.

za dalsie DX overhead prameni z neustaleho context switch medzi kernel a user space. totiz x86 CPU maju viacero modov kedy pricom v kazdom su dostupne ine instrukcie. v user mode je napriklad funkcny preklad pametovych adries takze funguje ochrana pamete. spomente si na Windows 98 ktory ochranu pamete nemal a spolu s programom casto zletel cely system. v kernel mode bezi samotny operacny system, ovladace obsluha preruseni ... kazdy takyto context switch vam zaberie 2-3 mikrosekundy.

teraz chcete renderovat 60FPS. to mate 16.6ms na jeden snimok. ak chcete spravit 5000 draw callov tak vam vychadza ze na jeden draw call mate 3.2mikrosekundy. tu mate ten overhead. toto ale platilo hlavne o DX9. novsie DX10/11 odstranily vela context switchov pri jednolivych draw calloch. dalsim problem ktory ale ostal je ze sa velmi casto moze stat ze niektory draw call sposoby flushnutie vsetkych cache a cakanie kym GPU dokonci aktualne vykonavanu ulohu. pipeline do GPU je ma ale vysoku latenciu takze kazde taketo zastavenie vas zdri drahocenne milisekundy.

mantle bude proste davat velmi presnu a deterministicky nastroj ktory bude vykonavat presne to co mu poviete. DX je prilis abstrahovane a vyvojar teda straca kontakt co sa vlastne na GPU deje.

[yuri.cs]

...

Jaguar nema FMA... absolutne by se nevyplatilo predelavat klasickou Bobcat FADD+FMUL FPU na obrovskou FMAC obdobu.

Cell, ze mel spatny FP vykon? Proto byl sveho casu takova revoluce v HPC? Proto mel 1x FPU + 8x 128b FMA SPE FPUs? Je pravda, ze novejsi revize prinesla super narust vykonu v DP, ale... kdo pouziva ve hrach DP...

Cell byl krok do neznama, pred GPGPU a dalsimi generacemi HPC exotiky. Proc ale skoncil v konzoli... 1 jedine in-order 2 SMT jadro, ktere bylo schopne prace s pameti, ktere melo pomerne slaby vykon v klasickem kodu, atd. atd. Ale 8 pridavnych FPUs...

[DOC_ZENITH]

AVX nebo FMA, jedno z toho umí ale sloooow. A o cellu jsem to nevěděl, tam jsem to stavěl na věcech co jsem zaslechl roky dozadu nevěděl jsem že byl tak FPU heavy. Hlavně mě zmátlo to že ten druhej byl prezentován jako FPU šampión oproti tomu prvnímu.