DirectX 12 - info a vše okolo

[Hladis]

.....odtud pramení ta nízká spotřeba Kepler......

Ehm to koliduje s realitou Kepler nejakou extra nizkou spotřebu tedy nemá, zvlaste s rostouci frekvenci a voltazi zere vic jak Hawaii.

[Krteq]

U radeonů to bylo dokonce tak zlý (i u GCN) že vysokej load GPGPU kartu udělal nepoužitelnou i na 2D. Zkuste si na GCN spustit litecoin miner nebo něco obdobného a i desktop budete mít tak cca 3-5fps protože karta je overloaded. GPGPU je prostě problém a AS je novinka co nám trošku té GPGPU během renderingu dovolé použít. Ale jen trošku, musí sae to vše stihnout než do SP púřijde další frame co bude potřebovat jjich výkon, protože kdyby stále počítali tu GPGPu úlohu už by tam byl zátruh a čekání na další cykl a to by dělalo stutter, a toto se bude blbě progrtamovat pro GPU všech výkonnostních tříd. Protože použíju třeba jeden post processing efekt, ale pro jeho výpočet bude Fury potřebovat méně času než třeba 7850 tka, tak jak to udělat. Dnes se všude měří Fury Hawaii a GM200/204, ale to neni celej trh, co v budoucnu, jak zajistíš aby ten kód jel dobře na všech GPU, a ne že GPU co je o 20% pomalejší už to na 1 průchod v době kdy je SP idle nedá a bum musí to dělat na 2 tzn obrovskej performance hit? Nebo jako NV že to tam prostě neni a musí na chvíli zastavit rendering provést tu GPGPU operaci a pak pokračovat? Já chci vědět odpovědi na tyto otázky před tim než se to globálně nasadí.

Pleteš 2 věci dohromady.

xCoin mining není úplně to samé jako DirectCompute tasky, které se pro výpočet postprocessing efektů používal už v DX11. V DX11 nebylo možné poslat ke zpracování command listy obsahující oba typy úloh, prostě se nejprve zpracovaly grafické tasky, pak následovalo pre-emption, přepnul se context a pak teprve se zpracovali compute tasky (příp. naopak, záleží na složitosti tasku).

To teď v DX12 a Async-Compute padá, protože se mohou oba typy úloh zpracovávat naráz. Bohužel u nV karet to z nějakého důvodu nefunguje (zřejmě driver ovlivňující SW scheduling) a stále dochází k pre-emption a hrozně to prodlužuje context switching, tím pádem nárůstá čas na zpracování snímku a FPS jde zákonitě dolů.

[Hladis]

K DC starsi test http://www.tomshardware.com/reviews/dir ... ,3146.html DC je uz starsi a pouzivana zalezitost, ve hrach aktivni. Od DX9 se toho v DX11 opravdu dost zmenilo.

[Hladis]

Pridam klidne další od nV https://developer.nvidia.com/dx11-samples

The second major addition to DirectX 11 is DirectCompute -- an extension of the API that allows DirectX programs direct access to the tremendous parallel processing performance Nvidia's GPUs can provide. Applications can use this power for a variety of purposes, from Physical Simulation to AI to advanced rendering techniques that might not fit perfectly into the traditional graphics pipeline. SDK 11 includes a few samples that show the basics of how such systems could be written, as well as some techniques which are useful on their own. N-Body Interaction demonstrates how to efficiently access memory and run calculations on a large number of independant objects, like you might find in a physical simulation. Constant Time Gaussian Blur takes some of those same techniques and applies them to 2D image processing, showing how to quickly blur an image efficiently and independant of kernel width. Horizon-Based Ambient Occlusion using Compute shaders provides an example of a Screen-Space Ambient Occlusion effect done using Direct Compute. Finally, Hair takes advantage of both DirectCompute and tessellation to render convincing, physically interactive hair, while FFT Ocean shows how you can perform complex data transforms efficiently on the GPU to generate realistic ocean waves.

Tim bych kauzu pouzivani/nepouzivani/ucelu DC uzavrel.

[hnizdo]

A/C ulevuje CPU už jen tím, že se nemusí řešit preemption a "náročný" context switching

Ach tak. Takze AC pomaha resit overhead vznikajici pri pouziti AC. Tak to je argument

Zbytek citaci nijak s nesouvisi s overheadem, tedy rezii, API/driveru, notabene resitelne pres AC. Tyka se jen a pouze vyuziti volnych prostredku GPU.

[Krteq]

Ach tak. Takze AC pomaha resit overhead vznikajici pri pouziti AC. Tak to je argument

Při použití A/C snad vzniká nějaký další overhead? Snad právě naopak. Při A/C se neřeší preemption a context-switching s A/C není tak náročný, protože už nemusí být tak častý, takže tím CPU ulevíš.

Co na tom zas nechápeš?

[Hladis]

AS proste vytezuje GPU efektivněji. V compute shaderech uz není potřeba cekat ve fronte na zpracovani mezi grafikou a vypocty...... latence, nefektivita a nižší vykon, nez když ty ulohy zpracuje najednou. Je to vcelku simple. Ale proc to nV nejde, to je stale v radu spekulaci. Ja tipuju, ze ten cip proste není s DX12 v tomhle kompatibilni. Při navrhu tohle nebylo ze strany nV brano v potaz a v ty době se jim o nejakym DX 12 ani nesnilo. nV karty stavela tak maximalne na CUDA a DX11/OGL. Nejaky AS mezi jejich priority vůbec nepatrily.

[del42sa]

IMHO AC funguje u GPU stejně/podobně jako SMT u CPU.


//edit Wilik - promaz OT, neresi se zde spotreba konkretnich grafik

[hnizdo]

Ach tak. Takze AC pomaha resit overhead vznikajici pri pouziti AC. Tak to je argument

Při použití A/C snad vzniká nějaký další overhead? Snad právě naopak. Při A/C se neřeší preemption a context-switching s A/C není tak náročný, protože už nemusí být tak častý, takže tím CPU ulevíš.

Co na tom zas nechápeš?

Od kdy context switching souvisi s CPU? To je zalezitost GPU. Nehlede k tomu, ze context switch se resi jen ve spojeni s AC, tedy asynchro vypocty.

[Krteq]

Od kdy context switching souvisi s CPU? To je zalezitost GPU. Nehlede k tomu, ze context switch se resi jen ve spojeni s AC, tedy asynchro vypocty.

Jestli tohle myslíš vážně, tak jsi mě opravdu pobavil

1. Od té doby co aplikace skrze driver submitne draw call/frontu ke zpracování a od té doby co je context switching řešen driverem, resp. WDDM (tedy přes CPU), GPU už si na HW levelu řeší jen sheduling command listů a jejich rozsekání a dispatching ke kokrétním CUs.
2. Context switching pro GPU se řeší už od dob 3D akcelerovaného prostředí ve Win (XP) když přepínáš mezi prostředím Win a 3D aplikací a přímo ve hrách/enginech pokaždé když přepínáš context z graphics na compute a naopak.

Zkus si nejprve přečíst něco o WDM/WDDM

[hnizdo]

1. Jak je tedy mozne, ze rezije context switchingu zavisi na GPU architekture, kdyz ji provadi CPU? Tedy cela ta afera ohledne AS?
Protoze tu mame tvrzeni, ze urcite architektury maji vysokou rezii prepinani kontextu, a nektere architektury nizkou. Nikde se nehovorilo o CPU overheadu.

2. Jak s tim souvisi AC?

Zaver, kde tedy vznika ten tvuj overhead, ktery resi asynchronni shadery?


//edit Wilik - upraveno

[Krteq]

Šmarjá, přečetl jsi si vůbec něco o WDM/WDDM jak jsem ti doporučoval a četl jsi vůbec předchozí posty?

Závisí na více faktorech, ne jen na architektuře GPU, resp. sheduleru. DX12 API je vázáno na WDDM 2.0, stejně jako driver. Chování preemption a context switchingu je definováno ve WDDM. V DX12 máš ale možnost zpracovávat pomocí Async-Compute oba typy front naráz, čímž odpadá preemption a časté přepínání kontextu, čímž se zákonitě sníží i CPU overhead.

nV má scheduling a dispatching z části řešen SW cestou v driveru. Při submitnutí dvou typů front (graphics i compute) tam z nějakého důvodu vzniká další CPU overhead a preemption a context switching je se zvyšující se komplexností těžkopádnější a pomalejší, zřejmě právě kvůli SW schedulingu.

Jinak už jsem to tu jednou vysvětloval:

V DX11 nebylo možné poslat ke zpracování command listy obsahující oba typy úloh, prostě se nejprve zpracovaly grafické tasky, pak následovalo pre-emption, přepnul se context a pak teprve se zpracovali compute tasky (příp. naopak, záleží na složitosti tasku).

To teď v DX12 a Async-Compute padá, protože se mohou oba typy úloh zpracovávat naráz. Bohužel u nV karet to z nějakého důvodu nefunguje (zřejmě driver ovlivňující SW scheduling) a stále dochází k pre-emption a hrozně to prodlužuje context switching, tím pádem nárůstá čas na zpracování snímku a FPS jde zákonitě dolů.

The additional queues give you additional pools of threads to pick from, and if the GPU is presented with a situation where it absolutely can’t hide latency from the graphics queue and must stall, the compute queues could be used to fill that execution bubble. Similarly, if there flat-out aren’t enough threads from the graphics queue to fill out the GPU, then this presents another opportunistic scenario to execute threads from a compute task to keep the GPU better occupied. Compared to a purely serial system this also helps to mitigate some of the overhead that comes from context switching.

Graphics has been referred to as an “embarrassingly parallel” problem, since it involves processing millions of polygons and pixels to create moving images. The faster these elements can be processed, the higher the quality of the resulting output. This characteristic is very amenable to specialized hardware that can handle many operations in parallel, which is why GPUs have becomeso critical in modern computing.

However, submitting all of that work to the GPU and scheduling it efficiently on the available processing resources is still a complex problem. GPUs rely heavily on pipelining to achieve their performance, and bottlenecks at any stage of the pipeline can leave other stages under-utilized. These stages include command processing, geometry processing, rasterization, shading, and raster operations. Each stage can make extensive use of parallel processing, but the throughput of each stage is also dependent on other stages that come before and/or after it.

Applications submit work to the GPU in the form of command buffers or command lists, which consist of a series of commands that execute on a set of data in parallel. Each command buffer is associated with a particular rendering task (shadow mapping, lighting, physics simulation, etc.).

Ideally we want the GPU to be able to handle multiple tasks simultaneously, so they can share the available resources and improve utilization. Accomplishing this means frame rates can be improved and latency reduced without requiring more processing power.

Tím se vysvětluje i bod 2

Jinak se mi donesla informace že se o problematice shedulingu, A/C a DX12 chystá článek. Tam to snad bude všechno dopodrobna vysvětleno

[hnizdo]

Ja se ptam, jakou rezii a ceho async compute / asynchronni shadery resi. Opakuji rezii, overhead. Ze AS umoznuji lepe vyuzit GPU, tvrdim od zacatku, k tomu jsou urcene, tedy citace 3.

Citace 2 se zabyva tim, ze vetsi davka AS umoznuje mene caste prepinani kontextu, jeji zaver "compared to a purely serial system this also helps to mitigate some of the overhead that comes from context switching." vsak citujes mimo relevanci a vecny kontext, protoze oproti zpracovani graphics q a compute q, napriklad s direct compute v DX11, paralelni zpracovani neslouzi k odstraneni overheadu vznikleho prepinanim kontextu mezi frontami, at uz se delaji seriove nebo paralelne, ale k samotnemu lepsimu vyuziti prostredku cipu, viz citace 3.

Overhead tam bude nadale, v zavislosti na gpu implementaci, a aplikace ACompute jako takoveho s tim NEMUZE NIC UDELAT. Overhead nezavisi na pouziti nebo nepouziti AC, ale na jeho implementaci do hw. Viz citace 1.

Zaver - tvam na tom, ze AC/AS nema s zadnym overheadem co delat. Jak jsi sam napsal, je to vec implementace AC do gpu. S tim bez vyhrad souhlasim, pokud je zaroven kod AC prizpusoben dane architekture, a neni umyslne nebo z nedbalosti napsan nevhodne.

Co se tyce nejakeho clanku, pokud ho bude psat nezavisly programator se zkusenostmi s implementaci AS na soucasnych architekturach, pak to bude jiste prinos. Doufam, ze to nebude dalsi PR od Oxide nebo podobnych lharu, nebo dalsi redaktorska kompilace dojmologii z for.

[Krteq]

Whatever

[Hladis]

Tedy vy si nedate pokoj.

Overhead tam bude nadale

Overhead CPU se samozrejme při pouziti AS snizi zcela logicky z podstaty fungovani Nemá cenu kolem toho tady popsat berlínskou zed a hadat se o prdu. Da se spekulovat nakolik to overhead snizi, jelikož se to tyka jen nekterych efektu, kde se pouziji Comute shadery. Tedy prinos bude pramenit z použitého poctu prislusnych vypoctu. Pokud třeba do hry mrsknou jen HBAO, tak ten prinos by nemel byt tak velky, jako když tim spočítají i pozice svetel, kolize, AI....etc... dohromady. V realu to bude asi v jednotkách fps.

[hnizdo]

Hladisi, slovo overhead, cesky rezie, znamena v tomto kontextu vypocetni cas, ktery neni vyuzit na vypocet ulohy, ale na provoz nezbytne infrastruktury okolo. Je to cast vypocetni kapacity, ktera se pouzije neefektivne, nema zadny vliv na zadany vysledek vypoctu, a idealne efektivni kod ho ma limitne roven nule.
Jinymi slovy, AS nemuze overhead (API, driveru) snizit, muze ho zvysit, nebo v idealnim pripade ho muze NEzvysit.

[Hladis]

Samozrejme ho snizit muze. CPU nemusi porad prepinat mezi úlohami a posilat to tam rovnou bez zbytečný rezie navíc. Eh je to tu uz asi 5x postnuty. Stejne se hadate o vlivu na CPU v radu mozna az sotva meritelnem. Hlavni narust vykonu není v uleve CPU, ale v rychlejsim zpracovani uloh.

[hnizdo]

Hlavni narust vykonu není v uleve CPU, ale v rychlejsim zpracovani uloh.

Coz rikam od zacatku.

Samozrejme ho snizit muze. CPU nemusi porad prepinat mezi úlohami a posilat to tam rovnou bez zbytečný rezie navíc. Eh je to tu uz asi 5x postnuty. Stejne se hadate o vlivu na CPU v radu mozna az sotva meritelnem.

Je mi lito, nechapu tvuj myslenkovy pochod. Pokud je uloha paralelizovatelna, neni duvod ji posilat seriove, overhead nevznikne. Pokud to napisu schvalne seriove, nejedna se o overhead, ale o blbost.
AS jako takovy nema co delat s overheadem, period. Ze neco krteq postne desetkrat, neznamena, ze to je pravda, period.

[Krteq]

Pochop už konečně, že s předchozími verzemi DX API nešlo posílat oba typy úloh (graphics/compute) naráz. V DX12 to díky A/C jde a tím že není tak složitý a častý context switching snižuje se částečně i CPU overhead, který tam předtím byl.

Co je na tom tak těžké pochopit?

[hnizdo]

Pochop už konečně, že s předchozími verzemi DX API nešlo posílat oba typy úloh (graphics/compute) naráz

O tom nikdo nepochybuje.

V DX12 to díky A/C jde a tím že není tak složitý a častý context switching snižuje se částečně i CPU overhead, který tam předtím byl.

Nevim co je slozite pochopit na tom, ze A/C vubec neslouzi k nejakemu snizeni overheadu, ani neresi kontext switching, pokud to gpu neumoznuje - je to na gpu scheduleru, ne A/C. Ze tedy hovoris o jevu, ktery je k A/C zcela irelevantni.

Podivej, ja muzu klidne rict, ze conservative rasterization snizuje overhead (kdekoliv v render path), protoze se nemusi kolize elementu pocitat "rucne" a je tam mene iteraci. Muzu to rict v podstate o jakekoliv technologii, ktera neco sebere z prace cpu. Uz nevim jak to napsat, a uz ani nemam chut.