DirectX 12 - info a vše okolo

[del42sa]

So far, Microsoft has mentioned only two DX12 features that will need new hardware: new blend modes and something called conservative rasterization, which can apparently help with object culling and hit detection. Neither of those additions sounds hugely groundbreaking, but as Tamasi hinted, they may just be the tip of the iceberg. We'll probably have to wait for another announcement from Microsoft to find out more.

Uh. The lovely Pixel Ordered UAV is not supported on today's Nvidia and AMD GPUs it seems? So is that DirectX 12 will have a legacy cap for today's GPU, and a modern cap for GPUs due this or next year? It would be really glad to know if any of these can be supported by today's hardware.



Quote:
Originally Posted by pTmd View Post
Just found an interesting piece of information that DirectX 12 comes with Pixel Ordered UAV the standardized PixelSync. [...]

http://techreport.com/news/26210/direct ... t-gen-gpus

[Krteq]

Jak jsem slíbil, sesumarizoval jsem popisy základních resp. klíčových principů fungování obou API z níže uvedených článků.

MSDN blog - http://blogs.msdn.com/b/directx/archive ... tx-12.aspx
TechReport - http://techreport.com/review/25683/delv ... ntle-api/2

Zkusim to vzít popořadě, jak je to uvedené v tom MSDN článku

Pipeline state objects (PSO) - DX12 = Monolithic pipelines - Mantle

• PSO

  Direct3D 11 allows pipeline state manipulation through a large set of orthogonal objects. For example, input assembler state, pixel shader state, rasterizer state, and output merger state are all independently modifiable. This provides a convenient, relatively high-level representation of the graphics pipeline, however it doesn’t map very well to modern hardware. This is primarily because there are often interdependencies between the various states. For example, many GPUs combine pixel shader and output merger state into a single hardware representation, but because the Direct3D 11 API allows these to be set separately, the driver cannot resolve things until it knows the state is finalized, which isn’t until draw time. This delays hardware state setup, which means extra overhead, and fewer maximum draw calls per frame.
  
  Direct3D 12 addresses this issue by unifying much of the pipeline state into immutable pipeline state objects (PSOs), which are finalized on creation. This allows hardware and drivers to immediately convert the PSO into whatever hardware native instructions and state are required to execute GPU work. Which PSO is in use can still be changed dynamically, but to do so the hardware only needs to copy the minimal amount of pre-computed state directly to the hardware registers, rather than computing the hardware state on the fly. This means significantly reduced draw call overhead, and many more draw calls per frame.

• Monolithic Pipelines
  

  That brings us to monolithic pipelines. To paraphrase Johan Andersson, Mantle rolls all of the various shader stages that make up the graphics pipeline into a single object. Above, I've added the slide from Andersson's keynote, since it's somewhat more enlightening than the one used by Riguer and Bennett in their presentation.
  
  In short, monolithic pipelines help avoid draw-time shader compilation—a problem that, as I mentioned earlier, can make games stutter. Here's how Bennett sums it up:
  In the current implementations, draw-time validation that the driver does is super expensive. Since you can vary all your shaders in state independently, we spend a lot of time at draw deciding what hardware commands we should write. By compiling the pipeline up front, binding the pipeline is lightning fast in comparison.
  
  Second, by compiling this up front, you give us the opportunity to spend some cycles to improve the GPU performance. If we know everything you're doing in the whole pipeline, we can optimize that. And . . . with the draw-time validation models, sometimes you'll bind a new state, call draw, and that draw will have an inexplicably high CPU cost. Maybe the driver had to kick off a shader compile in the background, and that's going to impact you. [There are] no surprises with Mantle.

Command lists and bundles - DX12 = Queues - Mantle Execution Model

• Command lists and bundles

  In Direct3D 11, all work submission is done via the immediate context, which represents a single stream of commands that go to the GPU. To achieve multithreaded scaling, games also have deferred contexts available to them, but like PSOs, deferred contexts also do not map perfectly to hardware, and so relatively little work can be done in them.
  
  Direct3D 12 introduces a new model for work submission based on command lists that contain the entirety of information needed to execute a particular workload on the GPU. Each new command list contains information such as which PSO to use, what texture and buffer resources are needed, and the arguments to all draw calls. Because each command list is self-contained and inherits no state, the driver can pre-compute all necessary GPU commands up-front and in a free-threaded manner. The only serial process necessary is the final submission of command lists to the GPU via the command queue, which is a highly efficient process.
  
  In addition to command lists, Direct3D 12 also introduces a second level of work pre-computation, bundles. Unlike command lists which are completely self-contained and typically constructed, submitted once, and discarded, bundles provide a form of state inheritance which permits reuse. For example, if a game wants to draw two character models with different textures, one approach is to record a command list with two sets of identical draw calls. But another approach is to “record” one bundle that draws a single character model, then “play back” the bundle twice on the command list using different resources. In the latter case, the driver only has to compute the appropriate instructions once, and creating the command list essentially amounts to two low-cost function calls.

• Queues - Mantle Execution Model
  

  These days, a modern GPU typically has a number of engines that execute commands in parallel to do work for you. You have a graphics or compute engine, DMA, multimedia . . . whatever. The basic building block for work for those engines is a command buffer. In [the diagram above], a command buffer is a colored rectangle. A driver builds commands targeting one of the engines; it puts the command buffer into an execution queue, and the engine, when it's ready to do some work, goes to the execution queue, grabs the work, and performs it.
  
  [That's] as opposed to a context-based execution model, where it's up to the driver to choose which engine we want to target; it's up to the driver to figure out where we break command buffers apart, and manage the synchronization between those engines. Mantle exposes all that, abstracted, to you. So, you have the ability to build a command buffer, insert commands into it, submit it to the queue, and then synchronize the work between it. This lets you take full advantage of the entire GPU.
  
  More fundamentally to Mantle's goals is the fact that you can create these command buffers from multiple application threads in parallel. . . . That is the key to opening up the potential of our multi-core CPUs these days. There is no synchronization at the API level in Mantle; there is no state that persists between command buffers. It is up to you to do the synchronization of your command building and of your command submission; and if you want to do work on multiple engines, we give you constructs to synchronize work between those engines. You have all the power.

Descriptor heaps and tables - DX12 = Mantle's binding model

• Descriptor heaps and tables

  Direct3D 12 changes the binding model to match modern hardware and significantly improve performance. Instead of requiring standalone resource views and explicit mapping to slots, Direct3D 12 provides a descriptor heap into which games create their various resource views. This provides a mechanism for the GPU to directly write the hardware-native resource description (descriptor) to memory up-front. To declare which resources are to be used by the pipeline for a particular draw call, games specify one or more descriptor tables which represent sub-ranges of the full descriptor heap. As the descriptor heap has already been populated with the appropriate hardware-specific descriptor data, changing descriptor tables is an extremely low-cost operation.

• Mantle's binding model
  
  

  Mantle introduces a new way to bind resources to the graphics pipeline, as well. According to Bennett, the traditional binding technique is a "pretty big performance hog," and the currently popular alternative, which he calls "bindless," has downsides of its own, including higher shader complexity, reduced stability, and being "less GPU cache friendly."
  
  Mantle's binding model involves simplified resource semantics compared to Direct3D, and it works like so:
  In Mantle, when you create your pipeline, you define a layout for how the resources will be accessed from the pipeline, and you bind that descriptor set. The descriptor set is an array of slots that you bind resources to. Notably, you can bind another descriptor set to a slot—and this lets you set hierarchical descriptions of your resources.
  
  If your eyes just glazed over, that's okay—mine did a little, too. In any event, Bennett said that the ability to build descriptor sets and to generate command buffers in parallel is "very good for CPU performance." During his presentation, Johan Andersson brought up a descriptor set use case that reduced both CPU overhead and memory usage.

Ve světle těchto informací se domnívám, že DirectX 12 skutečně vychází z Mantle (zřejmě tedy výsledek té úzké spolupráce s AMD) a z části i z původního feature setu DX11. Jak už tu bylo linkováno, MS doplní další funkce a features, které Mantle nepodporuje (vzhledem k vývojovému stádiu Mantle se ale mohou objevit i v něm)

[Krteq]

Perfektní článek o DirectX 12 na AnandTechu (ostatně jako vždy )

Microsoft Announces DirectX 12: Low Level Graphics Programming Comes To DirectX

A z tohoto článku jeden políček pro ty, co tu neustále omýlají potřebu podpory Command Lists v ovladačích

Meanwhile it’s interesting to note that with this change Microsoft has admitted that Direct3D 11 style immediate/deferred command lists haven’t lived up to their goals, stating “deferred contexts also do not map perfectly to hardware, and so relatively little work can be done in them.” To our knowledge the only game able to make significant use of the feature was Civilization V, and even then we’ve seen AMD video cards perform very well without supporting the feature.

Huddy měl ohledně té dvojsečné zbraně prostě pravdu - proto AMD tuhle podporu do ovladačů taky nikdy nezahrnula

[Hladis]

No prave ze AMD je vykonostne pozadu při pouziti MTR, takze nevim co tam pise. Zvlastne v ty Civilizaci.

[Krteq]

A kde přesně? Je tam rozdíl v řádu jednotek procent, někde jen v řádu chyby měření

Když už i M$ uznal že tudy cesta nevedla, tak na tom asi něco bude nemyslíš?

[DOC_ZENITH]

Chyby měření. Jo, já ti dám. Inu samotné mantle testy v BF4 (jedna z her co DX11 MT render používá) nám ukázaly jak špatně je na tom AMD s jeho implementací, což se nejvíce odráží paradoxně při použití AMD CPU. Zde máš CPU limited cituaci na FXku....



Civilizace je na tom obdobně, já ti dám chyby měření. DX11 MT render nezmenšuje overhead ale přidává MT do renderu geometrie, bodeť by se prosadil když jeden z výrobců GPU s jeho implementací 2 roky otálel a i pak jí má ať už úmysně nebo ne, mizernou.

[del42sa]

a jsi si jistý Docente, že ten rozdíl souvisí zrovna s MTR ? Pokud vím tak jediná hra kde to opravdu funguje je Civilization V a hra byla pro využití této feature optimalizovaná Ubisoftem a Nvidií. To ale neznamená, že to když to funguje v CV, tak to automaticky funguje v každé DX11 hře.

[quote]Basically, DirectX 11 Multithreading doesn’t work with AMD GPUs and drivers, instead of improving performance (creating more than one “rendering thread”) it kills it. You can’t penalize Ubisoft for this because this option is hidden in the xml config file (only available for nVidia GPUs in-game). If you look at Civ 5 performance difference between two AMD and nVidia Cards (similar in performance) you’ll see a huge FPS difference (100% improvement in some cases) in favor of nVidia, that’s what DX11 Multithreading does…[/quote]

Not all of you know that Far Cry 3 supports DirectX 11 Multithreading (more info). Unlike nVidia, AMD’s Catalyst Drivers don’t exactly support this feature (maybe because it’s not being used so often by devs, Civ 5 is one of the VERY few games that make use of it) but I still decided to give it a shot, see how “things” work with and without DirectX 11 Multithreading, the results are disappointing…

http://benchmark3d.com/far-cry-3-benchmark

[CageJ]

Doc,

ten polsky web je dost o nicom.. AMD friendly web ...

[Krteq]

DX11 MT render nezmenšuje overhead ale přidává MT do renderu geometrie

Woot? To nemyslíš vážně, že ne

Jinak ten test na PClab je dost pochybný, výsledky se řádově liší od zbytku světa.

@CageJ: Nemyslím, že PClab je zrovna "AMD friendly web".

[Krteq]

Vypadá to na nový WDDM

Tak potvrzeno

Budou DirectX 12 stačit Windows 8?

[del42sa]

to by hrálo do karet Mantle

[havli]

Vsak taky neni duvod cpat dx12 na win7. Za ty dva roky uz to bude dost zastaralej system...

[CageJ]

este bude tento rok Windows 8.2, nevidim dovod to nezakomponovat tam

[del42sa]

[quote="CageJ"]este bude tento rok Windows 8.2, nevidim dovod to nezakomponovat tam[/quote]

kdyby to bylo tak jednoduché (WDDM 2.0)... já ten důvod naopak vidím velice zřetelně , co nejrycleji přejít z nepovedených win8 na nové win9 a budou z toho mít i pěknou PR kampaň :o)

[Hladis]

Doprcic uz zase a porad dokola. MTR maji i Crysis 3 nebo Battlefield 4. Ne jen Civilizace. Ta byla první full DX11 hrou, kde se vse demonstrovalo. A ty rozdily nejsou v chybe mereni. Tech grafu tu bylo naskladanych uz tuna. Samotnej Anand promeril zrovna nedavno prave Civcku http://www.anandtech.com/show/7189/choo ... ber-2013/8 A to pomeruje GTX 580 proti HD7970. Crysis 3, stejny Battlefield 4 pod Dx..... Jakykoliv srovnani v tehle hrach a hlavne u minimalek kde e narazi na CPU limit, ukazujou stejne cca 4-5 fps rozdilu mezi AMD a nV. Jo mozna to není 50%, ale meritelny to je. Zvlaste u FX to je pak často ještě vic. To není chyba mereni. At je to tou chybejici funkci nebo vysokou rezii a horsima driverama obecne, AMD proste pod Dx s pouzitim MTR ztraci v posledních DX11 a DX11.1 hrach. Pod DX9 nebo DX10 jsou výsledky vždy vyrovnany. Zrovna Crysis 3 tu bylo propirany horem dolem. Ono tech grafu na netu, kde porovnavaj minimalky na dvou konkurencnich kartách moc není. Vetsinou se jen prdne jedna karta na test ruznych CPU a pak ostatní karty na test GPU s jednim vykonym CPU. Když se to ale zkombinuje tak ejhle.... Ale to uz se tu resilo fakt hodnekrat a nevim proc se to porad vraci. Znova ty všechny grafy hledat a vytahovat nebudu.

Microsoft opravdu nemůže dat novy DX12 na Win 7. Není to charita. Mantle stejne nebude ve všech hrach a dle me nemůže aspirovat na standart. Takze stejne pro hrani vetsiny her se bude muset upgradovat. Nehlede k tomu, ze Win 7 zastaravaji. Ale nevim ted zda ty "Win 9" nemaji byt jen updatem na 8.1.

[DOC_ZENITH]

DX neni pevně vázanej na WDDM. navíc samotné grafiky nemusej vůbec podporovat WDDM aby fungovaly. S trochou snahy jsou rozchodit i historické grafiky na NT6 které WDDM neuměj a stejně fungujou.

Navíc třeba WDDM 1.0 měla vista, 1.1 7, a stejně vista dostala dodadtečně DX11.

To že MS schválně nedává DX na oblíbené OS je jen snaha protlačit jeho nejmodernější i když třeba méně povedený OS. Největší dojeb to byl v době visty proto DX10 skoro neexistuje. To samé se dějě nyní. MS to dělá od visty, kdy si musel začít vytvářet umělé důvody pro to aby lidi koupili OS. Před tím pro něj nebyl problém udělat DX 9.0C i pro win98....

MS je klidně schopenj dát DX12 (vzheldem k tomu že do roka tu nebude) až do win9 a ostatní máte smůlu. To opět hraje do karet mantle, protože to funguje na všech NT6.

Edit: Win9 by měly bejt win8 s tim že desktop primary metro jen přídavné feaurka, ne pořád "in your face! Metro or die.".Což mi klidně stačí. Projekt win8 a jeho ovládání selhal a MS to ví.

[Hladis]

Hele uvědomte si jednu věc. Microsoft nemůže zustat sedet na jednom systemu dlouhou dobu. To proste financne nejde. Nemuze se promenit v charitru a ztratove dotovat jeden stary systém, z kterého nemá uz ani floka. Microsoft nechce další Win XP. Musí se posouvat dal, jinak zacne mit velky problém. Takze politika s DX je vcelku logicka.

[DOC_ZENITH]

Koukni na Vistu. Lidi ti nepřejdou na horší OS. Většina Visty a win8 se prodala jen s OEM sestavami protože MS už neprodával jiné licence a kolik lidí i tehdy tam chtělo downgrade uuughm.

Proto jsem tu měli tak dlouho XP a DX9 friendly enginy a hry, protože tam byla kupa zákazníků. Vývojáři her nebudou dělat hru pro minoritní platformu, to prostě ne. Budou jí dělat pro to nejvíce majoritní platformu.

A MS musí přinášet lepší systémy, ne horší. Stačí aby se v něčem zlepšil a v niem nethoršil, o to jde. Ne že přijdou win8 budou trochu rychleji bootovat a mít DX11.1 a vše ostatní co se týče UI a ovládání a zpětné kompatibility a vůbec takového běžného komfortu a ne "reklama in your face hned po loginu a vše z našeho storu jinaj tahni" atd, atd. Tak prostě ne. Sorry ale začít tlačit prostředí kde nefunguje multitasking v tomhle roce je prostě úlet. V 80tých letech by to bylo cool.

Takže shrnuto, 90% her stále DX9. 5-8% DX10/11, zbylá top 2% se budo usnažit jít po top technologii a tyhle top hry budou umět i mantle. Takže asi tak.

[zumpar1234]

[quote="del42sa"][quote="CageJ"]este bude tento rok Windows 8.2, nevidim dovod to nezakomponovat tam[/quote]

kdyby to bylo tak jednoduché (WDDM 2.0)... já ten důvod naopak vidím velice zřetelně , co nejrycleji přejít z nepovedených win8 na nové win9 a budou z toho mít i pěknou PR kampaň :o)[/quote]


Tak DX11 prisiel spätne aj na nepodarene Visty...

Inak, no dufam ze z nepodarenych Win 8 sa prejde na podarene Win 9. lebo sa kludne moze stat že nepodarene win 8 vystriedaju nepodarene win9 :D nakolko MS uz pred prichodom Win8 proklamoval ze nam svoju novu viziu PC sveta napcha aj nasilu a ze si na to beru 4 roky kym vytvoria ten velkolepy jednotny ekosystem ktoreho synonymum je Win8.

[Hladis]

DOC: Hlavni problém u Vist nebyl systém jako takovy ale drivery. Lidi vždycky sirej plno legend. Win 7neni zase az tak super a rozdil proti Vistam je minimalni. Win 8.1 je taky dobrym systémem a jen konzervy na to nadavaji, nebo lidi kteří jen siri urban legendy. Fakt s tim systémem nemam zadnej problem. Spis vyhody. Drzeni Dx9 byla věc hlavne konzoli a ne systemu.