DirectX 12 - info a vše okolo

[Ache]

Je to krávovina mixovat AMD a Nvidii, když mají odlišnou kvalitu obrazu (hlavně AF filtr). Tuhle "DX12 feature" využijí jen BFU řídící se heslem čím víc fps tím víc adidas.

[Krteq]

„SLI“ Radeonu s GeForce pod DirectX 12? Použijte Radeon jako primární

Asi nejzajímavějším poznatkem celého testu je zjištění, že není úplně jedno, kterou ze dvou karet svěříte vedoucí úlohu, tedy která bude vyrenderované obrazy z obou GPU skládat ve výsledný obraz a posílat jej monitoru. Zkrátka a dobře: Pokud jako primární poslouží Radeon (Fury X), bude FPS skoro o 20 % vyšší než když tuto úlohu převezme GeForce (GTX 980 Ti) Dokonce je v takovém případě výsledek i lepší, než když přes DX12 explicit multiadapter spárujete dvojici GeForce (GTX 980 Ti a Titan X).

[havli]

Dokud se bude pouzivat AFR, je tohle stejne k nicemu. Ono teda i bez nej, protoze kdo bude kupovat do PC AMD + nvidia grafiku a hrat vyhradne DX12 hry?... nikdo, prinejmensim pristich 5 let.

Minimalne teda ale pada zazity blabol, ze AMD a nv ovladace nemuzou byt v PC zaroven.

[oneb1t]

tohle se hodi maximalne pro notebooky ze se nebude integrovana karta flakat a tam se kazdy procento vykonu navic hodi

[Krteq]

Však takový je taky smysl téhle funkce, tj. přesunout postprocess a další míň náročné úlohy na iGPU.

[Ache]

Však takový je taky smysl téhle funkce, tj. přesunout postprocess a další míň náročné úlohy na iGPU.

Já myslel že na tyhle nenáročné věci jsou ty asynchroní shadery.

[Krteq]

Ne, async-compute slouží ke zpracování jak graphics, tak i compute queues/command listů zároveň na jednom GPU.

To tu opravdu jsou lidi co nechápou smysl a princip A/C po všem tom vysvětlování?

[webwalker]

OK, vezmu to od začátku a ve zkratce. Jen upozorňuju, že je v tom spoustu spekulací a nepotvrzených věcí!

V DX12 může každé jádro CPU samostatně vytvářet příkazy pro GPU (Draw calls, Dispatch calls a DMA copy). Podle typu příkazu je pak UMD přeloží a nahází do příslušné fronty (3D queue, Compute queue a Copy queue). Tady začíná první story u Nvidia, která využívá software sheduling a musí si ještě příkazy správně poskládat - vyšší CPU overhead. Na druhou stranu zase ušetřili spoustu tranzistorů na GPU a citelně snížili spotřebu!

Jdeme dále. Všechny fronty vedou do GPU a o každou z nich se stará na GPU jiný engine. Odtud název Multi Engine, což je oficiální název pro Asynchronní shadery v DX12.

multi-engine.jpg

U GCN se o 3D queue stará GCP (Graphics Command Processor) o DMA queue DMA engine a o Compute queue pak až 8 ACE. GCN tedy může zpracovat až 8 Compute queue. GCP, ACE a work distributor se pak starají o plánování výpočtů na CU a tedy o řádný chod simultánního multi-threadingu. Protože jsou enginy samostatné, Žádný context switch na frontendu se nekoná. Může se však konat na CU (při změně úlohy na CU), ale GCN prý umí provést context switch v jednom cyklu GPU!

GCN.jpg

U Kepleru/Maxwellu je to tak, že nikdo vlastně neví!!!
To, co napsali na Anadtech o HyperQ a 32 queue je s největší pravděpodobností naprostý blábol. HyperQ a jeho 32 front se týká pouze CUDA a s DX12 je to nekompatibilní. Nvidia pro 3D a Compute queue využívá tedy zřejmě pouze jediný engine - GCP. 3D a Compute se tedy musí zřejmě přepínat, což způsobuje context switch na frontendu (a pipeline flush). Další context switch pak následuje na SMM/X (podobně jako u GCN).

Takže Nvidia karty umí pracovat najednou s 3D a Compute shadery, ale pouze v CUDA (viz. PhysX). V DX12 NE! Možná tedy případná oprava driveru pro DX12 bude spočívat právě v tom, že si bude softwareově převádět Compute queue na CUDA (a HyperQ).

Jinak Compute shadery nemusejí být výhradně na post procesy, ale můžeš s nimi i vykreslovat a obcházet tak rasterizaci na GPU. Dokonce bys tak i šetřil bandwidth VRAM (méně přístupů do VRAM než u klasické 3D pipeline).

[HafanPetr]

Však takový je taky smysl téhle funkce, tj. přesunout postprocess a další míň náročné úlohy na iGPU.

Takže DX12 bude tuto funkci využívat např. u platformy FM2 v kombinaci APU+GPU?

[Krteq]

Pokud bude implementovaná podpora ve hře/enginu, tak ano.

[webwalker]

U AotS je ještě zajímavá metoda renderingu, kde díky DX12 mohou používat namísto Deferred renderingu Object Space Rendering (OSR). Má tady někdo nějaké bližší info nebo zkušenost s OSR?

[nou]

https://cseweb.ucsd.edu/~ravir/papers/s ... owslrs.pdf

Our coherence based sampling technique is designed to work with object-space rendering algorithms that shade and render the scene surface by surface. We have implemented our algorithm within the shading pass of Pixar’s PhotoRealistic Renderman which is based on the REYES [4] object-space rendering algorithm. In the REYES algorithm, geometric primitives are split into micropolygons that are shaded and then scan converted to create the final image. Micropolygons are shaded in a coherent manner, in groups that lie close to one another both in screen space and on the geometric primitive. Thus, lighting tends to change slowly from micropolygon to micropolygon. Since the micropolygons are shaded before computing their visibility, we compute soft shadows for every surface in the viewing frustum regardless of whether it is visible or not.
In contrast, standard raytracing renderers and the post-shading approach used with layered attenuation maps only perform the soft shadow computation on visible points. Therefore, direct comparisons between the running times of our coherence-based approach and other methods is difficult.

Da sa povedat ze vyuzivaju fakt ze jednotlive pixely v obrazemaju podobne osvetlenie co im umoznuje vykonat nejake optimalizacie pri ray-tracingu? Ono to dava zmysel pretoze aj vyvojari spominali ze OSR bol pouzity pri CGI vo filmoch.

[DOC_ZENITH]

Ray-tracing je defakto SW rendering přes GPU. S DX 12 nemá nic společného. A v hrách se to nebude používat snad nikdy.

[Vlastik80]

Kdysi se někde na netu psalo v článku, že RT patří budoucnost, ale že stávající grafiky (tehdy tuším GTX 400 řada) na to nemá ani zdaleka výkon, sice byla nějaká prezentace nVidie kde ukazovali jak krásně jim RT funguje na top modelu GTX 480, ale i tak to renderovalo asi tak 2 fps... Dnes jsme sice dál, ale tipuji že na render celé scény realtime při ideálně 60 fps to asi nebude... A to asi ani u další generace grafik...

Mimochodem souvislost s DX 12 to asi opravdu moc nemá, leda že jsou v DX 12 jisté fce, které RT podporují, ale otázkou pak je jak hodně pokročile a také zda a kdy budou využity... (pak bychom se asi dostali na úroveň CGI renderu ale realtime, což by bylo super a jednou asi bude)

[rbclass]

tento artefaktovany RT uz funguje aj dnes
https://www.youtube.com/watch?v=BpT6MkCeP7Y

[DOC_ZENITH]

Ano a užití od NV vypadalo podobně, ala pro real-time se při pohybu snížilo rozlišení a počet paprsků aby to bylo plynulejší a když se scéna zastavila postupně se to dopočítávalo do plné kvality, ok pro práci v cadu a pod, useless pro hry. Ray-traycing se prostě pro to nehodí, tolik výkonu co by bylo potřeba k srovnatelné scéně přes klasickou rasterizaci nikdy nebude nazbyt.

[Hladis]

Na RT ve hrach zapomente a ani souvislost s DX12 tam nevidim. Na to není a ani nebude vykon v pristich několika letech, ne-li dekade. Momentalne budou pouzitelny jiny metody jako treba VXGI. RT zustane stale u filmu, videa a prezentaci.

[hnizdo]

Takže Nvidia karty umí pracovat najednou s 3D a Compute shadery, ale pouze v CUDA (viz. PhysX). V DX12 NE! Možná tedy případná oprava driveru pro DX12 bude spočívat právě v tom, že si bude softwareově převádět Compute queue na CUDA (a HyperQ).

V tom pripade je z hlediska AS kompatibilni uz Fermi, protoze uz Fermi ma asynchronni CUDA frontu urcenou pro PhysX. Coz neni, tedy tato tvoje domnenka je mylna. Je velmi pravdepodobne, ze maxwellv2 ma narozdil od predchozich architektur prave ten zminovany hw scheduler. Akorat se musi respektovat, ze nelze psat jeden kod pro GCN i Maxwell, protoze to dopadne jako AotS, a musi se to optimalizovat pro kazdou arch zvlast.

[webwalker]

Takže Nvidia karty umí pracovat najednou s 3D a Compute shadery, ale pouze v CUDA (viz. PhysX). V DX12 NE! Možná tedy případná oprava driveru pro DX12 bude spočívat právě v tom, že si bude softwareově převádět Compute queue na CUDA (a HyperQ).

V tom pripade je z hlediska AS kompatibilni uz Fermi, protoze uz Fermi ma asynchronni CUDA frontu urcenou pro PhysX. Coz neni, tedy tato tvoje domnenka je mylna. Je velmi pravdepodobne, ze maxwellv2 ma narozdil od predchozich architektur prave ten zminovany hw scheduler. Akorat se musi respektovat, ze nelze psat jeden kod pro GCN i Maxwell, protoze to dopadne jako AotS, a musi se to optimalizovat pro kazdou arch zvlast.

Samozřejmě, že by Fermi mělo umět pracovat najednou s 3D a Compute shadery, ale pouze v CUDA! Jinak by těžko asi mohlo vzniknou PhysX. Fermi ale na rozdíl od Kepler/Maxwell má pro CUDA compute shadery pouze jedinou frontu, kdežto Kepler/Maxwell jich má 32!

cuda.jpg

Naopak, HW sheduler byl přítomný na Fermi, ale od Kepleru je řešen softwareově a odtud pramení ta nízká spotřeba Kepler/Maxwell. Jediné, co u Keplera přibylo je Grid Management Unit s HyperQ, ale zase jen pro CUDA, s DX12 je zřejmě nekompatibilní.

Co se týká nutnosti optimalizací u DX12 her podle výrobce GPU, pak díky neschopnosti paralelní práce současných Nvidia grafických karet, bude evidentně nutná v každém AAA titulu! Protože kdyby se vývojáři řídili pouze specifikacemi DX12, pak by si 80% lidí danou hru nezahrálo

[ifkopifko]

Naopak, HW sheduler byl přítomný na Fermi, ale od Kepleru je řešen softwareově a odtud pramení ta nízká spotřeba Kepler/Maxwell.

Máš aj nejaké podklady k tomu tvrdeniu o príkone? Kepler pokiaľ viem nemá nejaký markantný náskok čo do príkonu oproti GCN (okrem Tahiti GPU boli dosť výsledky dosť vyrovnané).