DirectX 12 - info a vše okolo

[killerek]

Zaprve ses s Vulkanem ve spatnem vlakne. Za druhe neni Vulkan ani DX12 o koktretnim vyrobci HW, ale obe API maji obecne snizovat naroky na CPU a umoznit lepsi vyuzizi vice jader. Navic, kdyz koukam na ostatni hry, tak bych videl spise chybu v Doomu, protoze jinde je to cca stejny propad.

[oneb1t]

ono kdovi jak to bylo zatim to nikdo jinej takhle nenameril a na druhejch strankach pro slabsi karty jako RX480 nenamerili vubec zadnej posun mezi i3-4360 a i7-5960

navic dle zkusenosti co mam z ostatnich her se prave presne tohle vubec nedeje a na rychlosti procesoru zalezi daleko min nez pod DX11

taky to nemusi bejt vubec dany vykonem CPU ale treba nepodporou SSE4.2

[Krteq]

DX12 zřejmě dostane novou abstraktní vrstvu pro Multi-GPU
...

Yes, the layer will be available in this repo. We will also be publishing two mGPU sample projects along with it - one using the layer and one not using the layer. We're making some final tweaks and doing additional testing and plan to post it all soon.

Tak M$ na GitHubu v tichosti vydal 2 verze multi-GPU vrstvy - linked adapters (standardní AFR pro CFX/SLI) a unlinked adapters (Explicit Multi-Adapter).

[Eddward]

Dava to zmysel

The main reason Async Compute shows massive gains for AMD is mainly because their DX11 drivers have horrendous amounts of overhead that Nvidia's drivers do not. Thus, when Async is enabled, AMD's hardware eliminates the overhead and utilizes the GPU more efficiently. Nvidia hasn't had this problem as their overhead is very small, so enabling Async doesn't provide massive gains as it's already being utilized rather efficiently.

The fan boys seem to think its unlocking some magical performance and people using Nvidia are missing out. We've had that performance all along you fools.

repost z Guru3D fora

takze je to asi tak, ze sa netreba pozerat kolko Nvidia ziskava pod DX12, ale skor kolko AMD straca pod DX11

[webwalker]

Pokud se ten člověk bavil pouze o výkonnostních ziscích z Async shaders, pak to pravda moc není. Lepší utilizaci GCN přináší přímo DX12, zisky z AS přicházejí až díky vyššímu počtu výpočetních jednotek u AMD karet a samozřejmě také lepší podpory Multi-engine.

[del42sa]

Navíc je to nesmysl už jen z toho důvodu, že Async Compute rozhodně nesnižuje overhead, ten jak správně podotknul Webwalker řeší samotné DX12 API.
Async Compute spíše funguje jako hyperthreading u CPU, pomáhá plynulému krmení pipeline bez zbytečných stalls a čekání na různé typy úloh, které může pipeline zpracovávat paralelně a bez čekání. Plus celý je podtrženo schopností architektury GCN plynule přepínat mezi různými úlohami, což je pro fungovaní AS klíčový prvek. To video s těmi vláčky je trefným popisem.

[Krteq]

Celý ten post je krapet mimo, ten kdo to psal zřejmě nepochopil jak pipeline v DX12 vlastně funguje

[Eddward]

Asi potom spravnejsie to vysvetluje Anandtech v rozbore
http://www.anandtech.com/show/10325/the ... n-review/9

Getting back to Pascal then, Pascal finally fixes the resource allocation issue. For Pascal, NVIDIA has implemented a dynamic load balancing system to replace Maxwell 2’s static partitions. Now if the queues end up unbalanced and one of the queues runs out of work early, the driver and work schedulers can step in and fill up the remaining time with work from the other queues.

In concept it sounds simple, and in practice it should make a large difference to how beneficial async compute can be on NVIDIA’s architectures. Adding more work to create concurrency to fill execution bubbles only works if the queue scheduling itself doesn’t create bubbles, and this was Maxwell 2’s Achilles’ heel that Pascal has addressed.

At the same time however I feel it’s important to note that the scheduling change alone won’t (and can’t) guarantee that Pascal will see significant gains from async compute across the board. Async compute itself is a catch-all term – there are lots of things you can do with asynchronous work submission/execution – so async doesn’t mean that a game is making significant use of concurrency. Furthermore the concurrency is still based on filling execution bubbles, and that means that there needs to be bubbles to fill in the first place. In other words, the greatest gains from async will come from scenarios where for whatever reason, the graphics queue and its synchronous shaders can’t completely saturate the GPU on its own.

Right now I think it’s going to prove significant that while NVIDIA introduced dynamic scheduling in Pascal, they also didn’t make the architecture significantly wider than Maxwell 2. As we discussed earlier in how Pascal has been optimized, it’s a slightly wider but mostly higher clocked successor to Maxwell 2. As a result there’s not too much additional parallelism needed to fill out GP104; relative to GM204, you only need 25% more threads, a relatively small jump for a generation. This means that while NVIDIA has made Pascal far more accommodating to asynchronous concurrent executeion, there’s still no guarantee that any specific game will find bubbles to fill. Thus far there’s little evidence to indicate that NVIDIA’s been struggling to fill out their GPUs with Maxwell 2, and with Pascal only being a bit wider, it may not behave much differently in that regard.

Meanwhile, because this is a question that I’m frequently asked, I will make a very high level comparison to AMD. Ever since the transition to unified shader architectures, AMD has always favored higher ALU counts; Fiji had more ALUs than GM200, mainstream Polaris 10 has nearly as many ALUs as high-end GP104, etc. All other things held equal, this means there are more chances for execution bubbles in AMD’s architectures, and consequently more opportunities to exploit concurrency via async compute. We’re still very early into the Pascal era – the first game supporting async on Pascal, Rise of the Tomb Raider, was just patched in last week – but on the whole I don’t expect NVIDIA to benefit from async by as much as we’ve seen AMD benefit. At least not with well-written code.

Otherwise, for the time being, the one good benchmark we have here is 3DMark Time Spy, which was released last week. The ground up DirectX 12 benchmark attempts to heavily overlap rendering passes to fill those aforementioned execution bubbles.

Taking a quick run of the benchmark, on a relative basis we see a 10.8% gain from using async compute plus concurrency for the RX 480, and a 5.4% gain for the GTX 1070. This is but one benchmark (and technically not even a game at that), but for what it’s worth this is the kind of trend I’m expecting to see in future games as they get better about exploiting workload concurrency via async compute

[del42sa]

In concept it sounds simple, and in practice it should make a large difference to how beneficial async compute can be on NVIDIA’s architectures. Adding more work to create concurrency to fill execution bubbles only works if the queue scheduling itself doesn’t create bubbles, and this was Maxwell 2’s Achilles’ heel that Pascal has addressed.


Right now I think it’s going to prove significant that while NVIDIA introduced dynamic scheduling in Pascal, they also didn’t make the architecture significantly wider than Maxwell 2. As we discussed earlier in how Pascal has been optimized, it’s a slightly wider but mostly higher clocked successor to Maxwell 2. As a result there’s not too much additional parallelism needed to fill out GP104; relative to GM204, you only need 25% more threads, a relatively small jump for a generation. This means that while NVIDIA has made Pascal far more accommodating to asynchronous concurrent executeion, there’s still no guarantee that any specific game will find bubbles to fill. Thus far there’s little evidence to indicate that NVIDIA’s been struggling to fill out their GPUs with Maxwell 2, and with Pascal only being a bit wider, it may not behave much differently in that regard.

To není úplně přesné, dokonce bych dovolil říct zcestné jak to tam je popsáno/vysvětlováno.
Ony totiž ty "bubliny" v pipeline se samozřejmě vyskytují i u Maxwellu a stejně tak i u Pascala a v podstatě u každé GPU architektury. U některé víc u některé míň, ale problém je v něčem úplně jiném. Je zřejmé že i Maxwell umí přepínat mezi úlohami, ale problém leží dostatečně rychlém přepnutí těch úloh mezi sebou.

U Maxwellu znamenalo přepnutí na compute úlohu a zpět buď :

a) dokončení předtím běžící úlohy ( velká prodleva - latence - pokles výkonu )
B) flush pipeline, to je "zrušení právě běžící úlohy a uvolnění pipeline pro jiný typ úlohy (ještě horší scénář - performance hit)

Druhý předpoklad, aby ono přepínání mezi úlohami fungovalo plynule je (preemptive) schedulling oněch úloh a preemption,tj. dočasné přerušení právě běžící úlohy. Karta tedy musí dopředu "předvídat" jiný typ úlohy a přepnout na jiný typ úlohy (context switching), případně rezervovat určitý počet exekučních jednotek pro daný typ úlohy aniž by to negativně ovlivnilo zpracování právě probíhající úlohy.
Tohle všechno GCN umí (GCN4 i compute unit reservation a dvojitý HWS) , zatímco Nvidia s použitelným řešením Nvidia přišla teprve nedávno a flexibilita onoho řešení zdaleka není taková jako u GCN. Tak či tak je to ale krok správným směrem.

Osobně si myslím, že Asynchroní Shadery jsou teprve na začátku své cesty a do budoucna se s touto technikou bude potkávat v mnohem vyšším měřítku a i s výšším výkonovými benefity než je tomu nyní.

[ArgCZ]

http://gamegpu.com/action-/-fps-/-tps/d ... d-test-gpu

DeusEx: Mankind Divided test i pod DX12

hra bude extrémně náročná jak na GPU tak kupodivu na CPU kterým teda dává dost do těla

jak tohle chtěj rozchodit na konzolích teda netuším

[DOC_ZENITH]

Easy, méně efektů, menší doledost, počet polygonů, 30fps a možná ani ne 1080p a hned to jede na konzoli... ostatně jak to bejvalo vždy. Taky je tu šance že je to zprasenej PC port, protože samotnej engine je fajn a na konzoli to může běhat dobře.

[oneb1t]

vsak staci sundat o jeden stupen detaily a uz to bezi cca 3x lip

co me spis prekvapuje je ze hra bezi pod DX12 hur nez pod DX11 (ale psali ze realny vydani DX12 patche je az 5.9 takze jestli na tom jeste nic neudelali tak je to celkem jasny )

[DOC_ZENITH]

Taky je to tahle ruská stránka která snad nikdy nebyla věrohodná, vypustili tunu testů které byly mimo, obvzláště si pamatuji jejich 5960x bez OC drtící v některých hrách vysoko taktovaná 4 jádra, v hrách které nejdou nad 4 thready, atd. Spousta jejich grafů mi přijde jak střílená od boku stylem otestuju to na 1 sestavě a zbytek odhadnu, a tenhle test nevyjímaje.

[Krteq]

Vyšel DX12 patch pro Deus Ex: Mankind Devided - http://pctforum.tyden.cz/viewtopic.php? ... 1#p9143581

Ten "pre-release" test pod DX12 na GameGPU smrdí až to bolí

[ArgCZ]

R9 390X a OC edice RX 480 na úrovni GTX 1070? WTF?

[Hladis]

Je to AMD Evolved a engine z Hitmana, takze na tom není co k prekvapeni. Staci zabrouzdat do minulosti, tyhle tituly byly vždy AMD friendly.

[ArgCZ]

Crysis 3 je taky Gaming Evolved, AMD nemá schopný lidi který by dokázali dodat do hry nějaký věci co jim daj nějakou výhodu, v tomhle jsou neschopný dlouhodobě

[Krteq]

Je to AMD Evolved a engine z Hitmana, takze na tom není co k prekvapeni. Staci zabrouzdat do minulosti, tyhle tituly byly vždy AMD friendly.

Well... nope. Engine je úplně jiný (Dawn engine vs. Glacier 2 engine) a DX12 update vyvíjelo Nixxes studio - tj. stejné jako RotTR

Prostě jen hra bez GameWorks.

//Bavíme se snad v DX12 vlákně o DX12... upraveno aby to Hladisovi dávalo smysl

[Hladis]

Crysis 3 je taky Gaming Evolved, AMD nemá schopný lidi který by dokázali dodat do hry nějaký věci co jim daj nějakou výhodu, v tomhle jsou neschopný dlouhodobě

V Crysis 3 dost skrouhli tesselaci, ktera AMD zabijela ve dvojce a dost tam napraskali fyziku a boostlo to FX procesory. Uvedom si, ze do vydani toho "zazracnyho" nV driveru to tam bylo jinak. Dal tyhle hry jsou historicky v programu AMD, jako Total War, Deus Ex, Hitman, kdysi AvP, atd..... nV si vystřílela munici dlouhy obdobi do Fallouta 4 a Tomb Raidera. Zadna tradicni hra s nV logem ted není na poradu dne a naopak, ted prislo obdobi, kdy vychazeji zase klasiky z druhy staje. Nejak se to hezky rozdělilo. Opravdu není překvapující, ze hry jako Hitman a Deus Ex jedou na AMD lip, bylo to tak vždy.

Krtek:

Its technology is based on IO Interactive's proprietary Glacier 2 game engine, which was used in Hitman: Absolution

RoTTR je uplne na jinym enginu a dela ho uplne někdo jinej. Eidos opravdu není Crystal Dynamics.

[-Vladimir-]

Hladis, Krteq: že vás ty hádky ještě baví