- #D3dx9.lib how to
- #D3dx9.lib driver
- #D3dx9.lib free
If a command list or all command lists in the call executes faster than that, there will be a bubble in the HW queue
The OS takes 50-80 microseconds to schedule command lists after the previous ExecuteCommandLists call. This can result in wasted idle GPU cycles. Small command lists can sometimes complete faster than the OS scheduler on the CPU can submit new ones. Don't submit extremely small command lists. Switch compute workload to graphics workloads in this case if possible. This may lead to bubbles in the asynchronous compute queue. Don’t overlap compute work on the 3D queue with compute work on a dedicated asynchronous compute queue. Otherwise you typically limit the reusability of the bundle. Don’t use bundles to record more than a few draw calls (e.g.~12 draw calls is fine). Make sure to use just one CBV/SRV/UAV/descriptor heap as a ring-buffer for all frames if you want to aim at running parallel asynchronous compute and graphics workloads. Be conscious of which asynchronous compute and graphics workloads can be scheduled together - use fences to pair up the right workloads. Even for compute tasks that can in theory run in parallel with graphics tasks, the actual scheduling details of the parallel work on the GPU may not generate the results you hope for. Check carefully if the use of a separate compute command queues really is advantageous. This allows bundles to be reused with less overhead as it facilitates more thoroughly cooked bundles. Use bundle resource binding inheritance sparsely. Reuse fragments recorded in bundles if you can. Try to bundle those CLs into 5-10 ExecuteCommandLists() calls per frame. Try to aim at a reasonable number of command lists in the range of 15-30 or below. Fences force the splitting of command lists for various reasons ( multiple command queues, picking up the results of queries). 
You still need a reasonable number of command lists for efficient parallel work submission.Be aware of the fact that there is a cost associated with setup and reset of a command list.
#D3dx9.lib free
Command lists are not free threaded so parallel work submission means submitting to multiple command lists. #D3dx9.lib driver
Recording commands is a CPU intensive operation and no driver threads come to the rescue.Submit work in parallel and evenly across several threads/cores to multiple command lists.Calls to ExecuteCommadList() finally do start work on the GPU.Submitting work to command lists doesn’t start any work on the GPU.Accept the fact that you are responsible for achieving and controlling GPU/CPU parallelism.Work Submission – Command Lists & Bundles The more efficiently one can use parallel hardware cores of the CPU to submit work in parallel, the more benefit in terms of draw call submission performance can be expected. While the total cost of work submission in DX12 has been reduced, the amount of work measured on the application’s thread may be larger due to the loss of driver threading.On DX11 the driver does farm off asynchronous tasks to driver worker threads where possible – this doesn’t happen anymore under DX12.Don’t rely on the driver to parallelize any Direct3D12 works in driver threads.
#D3dx9.lib how to
The app has to replace driver reasoning about how to most efficiently drive the underlying hardware. Expect to maintain separate render paths for each IHV minimum. The idea is to get the worker threads generate command lists and for the master thread to pick those up and submit them. Consider a ‘Master Render Thread’ for work submission with a couple of ‘Worker Threads’ for command list recording, resource creation and PSO ‘Pipeline Stata Object’ (PSO) compilation. This way you may achieve sufficient parallelism in terms of draw submission whilst making sure that resource and command queue dependencies get respected. Prefer a tasks graph architecture for parallel draw submission. NVIDIA DirectX12 Hardware Features table. DirectX12 Hardware Features and other Maxwell Features. Work Submission – Command Lists & Bundles. Also make sure to be thoroughly familiar with the DX12 feature specifications. In order to stay on top of things the developer needs to strongly leverage the debug runtime and pay close attention to any errors that get reported. Likewise illegal API usage won’t be caught or corrected by the DX-runtime or the driver. 
This starts with resource state barriers and continues with the use of fences to synchronize command queues. The DX12 API places more responsibilities on the programmer than any former DirectX™ API.
0 kommentar(er)
