Y no me extraña, genial ese enlace con documentación oficial. Mirad esto:
https://msdn.microsoft.com/en-us/library/dn899217(v=vs.85).aspxD3D12 allows developers to avoid accidentally running into inefficiencies caused by unexpected synchronization delays. It also allows developers to introduce synchronization at a higher level where the required synchronization can be determined with greater certainty. A second issue that multi-engine addresses is to make expensive operations more explicit, which includes transitions between 3D and video that were traditionally costly because of synchronization between multiple kernel contexts.
In particular, the following scenarios can be addressed with D3D12:
•Asynchronous and low priority GPU work. This enables concurrent execution of low priority GPU work and atomic operations that enable one GPU thread to consume the results of another unsynchronized thread without blocking.
•High priority compute work. With background compute it is possible to interrupt 3D rendering to do a small amount of high priority compute work. The results of this work can be obtained early for additional processing on the CPU.
•Background compute work. A separate low priority queue for compute workloads allows an application to utilize spare GPU cycles to perform background computation without negative impact on the primary rendering (or other) tasks. Background tasks may include decompression of resources or updating simulations or acceleration structures. Background tasks should be synchronized on the CPU infrequently (approximately once per frame) to avoid stalling or slowing foreground work.
•Streaming and uploading data. A separate copy queue replaces the D3D11 concepts of initial data and updating resources. Although the application is responsible for more details in the D3D12 model, this responsibility comes with power. The application can control how much system memory is devoted to buffering upload data. The app can choose when and how (CPU vs GPU, blocking vs non-blocking) to synchronize, and can track progress and control the amount of queued work.
•Increased parallelism. Applications can use deeper queues for background workloads (e.g. video decode) when they have separate queues for foreground work.
Como decía, con una actualización del driver, por muy monolítico que sea, no es suficiente.
Podemos apreciar más la diferencia:
https://msdn.microsoft.com/en-us/library/dn913195(v=vs.85).aspxIn D3D12, there is no concept of a device context. The D3D11 immediate context was responsible for recording commands into a driver’s internal command buffer, and submitting them at arbitrary frequencies, with additional app-controlled flushes. In D3D12, this object is replaced with three objects: the command queue, the command list, and the command allocator.
Es decir, ese contexto del SDK de DX11 no tiene nada que ver con DX12, es que ya es parte de DX11 y no sólo para la consola. Y como se indica, no son lo mismo.
Edit:buf y esto tiene mucho más:
https://msdn.microsoft.com/en-us/library/dn903925(v=vs.85).aspxIndirect drawing enables some scene-traversal and culling to be moved from the CPU to the GPU, which can improve performance. The command buffer doesn’t necessarily need to be GPU-generated.
Eso está estupendo, si andas corto de CPU (según el juego) puedes repartir trabajo.
Tengo que seguir leyendo, pero sólo un par de cosas que he mirado, da mucho juego para evolucionar el software y sacarle partido. Como decía, es lo que va a permitir DX12 principalmente, y mirando a la anterior gen queda claro que es mucho más necesario (por lo menos yo lo veo así) que un boost mágico instantáneo y luego nada más.
![[facepalm]](/images/smilies/facepalm.gif "facepalm")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
In my experience, though, the driver.
