• Content count

  • Joined

  • Last visited

Community Reputation

2212 Excellent

1 Follower

About SoldierOfLight

  • Rank

Personal Information

  • Interests
  1. DX12 WriteBufferImmediate use-cases

    Yep, that's right, and no it doesn't need to be unmapped.
  2. DX12 WriteBufferImmediate use-cases

    What you've implemented is the D3D11 equivalent of UpdateSubresource on a default constant buffer. WriteBufferImmediate would be roughly the same thing. In my experience, most people prefer to implement the D3D11 equivalent of Map(DISCARD) on a dynamic constant buffer, which would mean just binding your upload heap directly to the pixel shader.
  3. DX12 WriteBufferImmediate use-cases

    Right, to clarify, the barrier to COPY_DEST would cause the write to be serialized with the previous read operation. However, if you weren't previously reading from the resource in the command list, then yes, WriteBufferImmediate is an excellent replacement for CopyBufferRegion.
  4. There's no prescribed implementation for root parameters. It is possible that they may be implemented as a constant buffer on some hardware, but that's not really relevant to the application. D3D11 exposes 14 CBs, and D3D12 also exposes 14 for tier 1 and 2.
  5. Correct, the former. No, because the same root signature and the same descriptor tables can be used across multiple draw calls using different PSOs. Theoretically if the driver wanted to spend a lot of time searching and accumulating across all PSOs and draws that used a particular descriptor table, they could, but that goes against the spirit of D3D12, which is that the app knows what it's doing and is being explicit about the work it wants done, so that the driver doesn't need to waste time trying to be smarter than the app.
  6. DX12 WriteBufferImmediate use-cases

    At a high level, no that is not its intended use. Using MODE_DEFAULT would (probably) cause the graphics pipeline to stall/drain every time you issue one of these writes, which would kill performance. Using either of the other modes could cause the writes to happen too soon (affecting draws already in flight) or too late (after all previous draws in flight are fully finished, not necessarily in time for the next one). Its intended use is for checking progress of GPU execution, specifically when the GPU has faulted and the device has become removed. If you use WriteBufferImmediate to insert "breadcrumbs" at the top of pipe and bottom of pipe, and the GPU faults, you can inspect these breadcrumbs to see which workloads had started but not finished - i.e. which workloads could have possibly contributed to the fault.
  7. Oh, of course, I'd expect a shader to only have instructions to fetch (or prefetch) data that will be used within the shader. However for some hardware, a "SetDescriptorTable" operation turns into (e.g.) multiple "SetDescriptor" operations, and since descriptor table setting happens without knowledge of a particular PSO, it needs to respect the bound root signature instead. As for validation, again it depends on the tier and type of descriptor. On tier 3, nothing is required to be valid unless it's actually referenced in a shader (potentially even including conditional call flow, depending on compilation flags). But on tier 1, everything is required to be valid if it'd declared in the root signature, regardless of whether it's referenced in a shader. And tier 2 is a middle ground, where SRVs/samplers are "bindless"/unvalidated, but CBVs and UAVs need to be valid.
  8. No. The Xbox compiler goes from HLSL -> Xbox hardware instructions. The PC compiler goes from HLSL -> DXBC (bytecode), which the driver later translates into hardware instructions. By the time the driver sees the DXBC, they're guaranteed to have a root signature with it. Thanks for pointing this out, I didn't read close enough to see it was a single table with 3 ranges, I assumed it was 3 tables.
  9. DX12 VS2015 Dx12 Multi-Gpu Debugging

    D3D12 capture/playback development has moved to PIX. You can try PIX ( but I don't think that multi-GPU is something they've done yet.
  10. It's going to depend on the hardware. For binding tier 1 and 2, this will have some impact, as changing some descriptor tables devolves into a per-descriptor operation for them. For tier 1, this applies to all descriptors, and for tier 2, this applies to UAVs and CBVs. For everything else (tier 3, or tier 2 SRVs/samplers), changing a descriptor table is just a pointer swap. As for within the shader, I don't see what optimizations could occur. The root signature indicates where to grab the descriptor, but the descriptor table is populated without knowledge of the root signature that will consume it, and the root parameter is set without knowledge of which PSO will consume it.
  11. D3D12 devices are singleton-per-adapter. That means that calling D3D12CreateDevice while a device already exists will just return the same device. You can compare the pointers and confirm.
  12. DX12 Dx12 - timestamp queries

    Yep, you're totally on the right track. The ResolveQueryData takes data from the query heap, which can be in a hardware-dependent format, and puts it in a buffer, one which is probably CPU-accessible, in the canonical format. Once the resolve operation is complete, you can read the contents of the buffer to get your timestamps. Resolve can handle data from multiple query heap entries, and the output is one UINT64 per resolved timestamp, just like D3D11's GetData.
  13. For low-hanging fruit... you're building your project in 'release' mode, not 'debug' mode, right? That can yield surprising performance gains.
  14. How did you zero it out? Did you call ZeroMemory (or similar) on the CPU descriptor handle? That's... not the right way to do it. What you're looking for is a null view. You can call CreateUnorderedAccessView with a null resource, but you must pass a valid view desc. That'll set up the descriptor such that reads return 0 (or last-written data, depending on architecture) and writes are dropped.
  15. DX12 D3D12: CreateShaderResourceView crash

    Ah, I forgot about GetResourceAllocationInfo, you're totally right - I was thrown off that you called it GetMemoryFootprint. That provides the real memory footprint. That's what I get for trying to be helpful so early after getting back from vacation...