Windows 10: D3D12 Debug Object Auto-Naming option now available

Brink · Oct 16, 2020

Great. The D3D12 Debug Layer has just helpfully reported, âAn ID3D12Resource object (âUnnamed ID3D12Resourceâ&#153 referenced in a command list (âUnnamed ID3D12GraphicsCommandListâ&#153 was deleted prior to executing the command listâ¦â. Getting past the fact that the application never called ID3D12Object::SetName to provide useful names for the resource and command list (no judgement, it happens), you are now left to figure out which objects these were with very limited data. If only there was something more to go on than just, âUnnamed ID3D12Resourceâ.

As of Windows 10 Release Preview 20236 (the latest available Insider Fast build as of this writing), there is now an option to enable automatic naming of D3D12 objects. Debug Object Auto-Names are unique, and descriptive, and are easy to enable programmatically or using d3dconfig. The related APIâs also require Windows Insider Preview SDK 20236.

With Debug Object Auto-Naming enabled, the previously mentioned message would be something more like, âAn ID3D12Resource object (âUnnamed Committed ID3D12Resource: Format=R32_FLOAT, Dimension=Texture1D, Width=128, MipLevels=1, ArraySize=1, UniqueId=0x0000000000567231â ) referenced in a command list (âUnnamed ID3D12GraphicsCommandList: Type=Direct, UniqueId=0x0000000000566145â&#153 was deleted prior to executing the command listâ¦â. Not only is this telling us more about the offending resource and command list, this is also reporting a âUniqueIdâ.

So, hidden in this new feature is another new feature: D3D12 assigns a locally-unique id (LUID) to every D3D12 DeviceChild object at create time. This id can be retrieved using GetPrivateData with the REFGUID value WKPDID_D3D12UniqueObjectId. Note, these IDâs are going to be unique from one run to the next, even for the exact same object. Still, if you happen to have this ID in your execution log then it can be easily cross-referenced from the auto-name.

Due to memory and performance overhead, Debug Object Auto-Naming is disabled by default. It can be enabled programmatically using the new interface method:

void ID3D12Debug5::SetEnableAutoDebugName(BOOL bEnable)

Alternatively, Debug Object Auto-Naming can be enabled using d3dconfig:

c:\users\bad_with_names>d3dconfig device auto-debug-name=forced-on

To avoid application compatibility issues, Debug Object Auto-Names are not retrievable using public ID3D12Object::GetPrivateData(). Debug Object Auto-names will only appear in DRED output and Debug Layer messages, and only when an object has not been assigned a debug object name. Note that the Debug Object Auto-Name feature is not intended to replace developer-assigned names. In most cases, the app developer can provide a much more meaningful name, and there is nothing in the Auto-Name that cannot be replicated by app developers.

Bill Kristiansen
Principal Developer, DirectX
Click to expand...

Source: https://devblogs.microsoft.com/direc...t-auto-naming/

:)

Brink · Oct 16, 2020

D3D12 Translation Layer and D3D11On12 are now open source

If you’re a developer looking to port your game to DX12, we have good news: There’s a helper library available to get you there more easily!

We’re excited to announce that the D3D12 Translation Layer is now open source. The D3D12 Translation Layer is a helper library for translating graphics concepts and commands from a D3D11-style domain to a D3D12-style domain. As an example of how to use the library, we have also opened sourced D3D11On12, a mapping layer that maps graphics commands from D3D11 to D3D12.

Check out the source on GitHub:

D3D12 Translation Layer

D3D11On12

Read on to learn more about what this means for you.

A bit of history: Why mapping layers?

The first mapping layer project was started during the development of Windows 10 and D3D12. The Windows graphics team has a large set of D3D11 content which was heavily utilized during design and bring-up of the D3D12 runtime and driver models. In order to use that content, a mapping layer named D3D11On12 was developed.

This mapping layer proved successful and useful, to the point that a second mapping layer was developed, named D3D9On12. As the name implies, this maps from D3D9 to D3D12, and it has to solve a lot of the same problems as D3D11On12. D3D11On12 was thus refactored into two pieces: a part that implements the D3D11-specific concepts, and a more general part that translates more traditional graphics constructs into a modern low-level D3D12 API consumer. This more general part is what became the D3D12 Translation Layer. The translation layer code is currently being used by two mapping layers that ship as part of Windows: D3D11On12 and D3D9On12.

We realize that the D3D12 Translation Layer solves problems that are not unique 11On12 and 9On12, and we’re sharing the source with the graphics development community so others can reuse and benefit from our work. Both the D3D12 Translation Layer and D3D11On12 are available on GitHub today. If you have questions as you play with the code, feel free to reach out to us on Discord.

What can you do with the code?

Make the move to D3D12 more quickly. Leverage the D3D12 Translation Layer library as-is in your game to port your existing work to D3D12 faster.

Build a mapping layer from your favorite graphics or compute API to D3D12. Take advantage of a tested and conformant IHV DirectX 12 driver via your own D3D12 wrapper.

Contribute back to Windows. We welcome community contributions to both the D3D12 Translation Layer and D3D11On12. Improvements will be pulled back into the Windows codebase and eventually ship in future versions of Windows 10.

Learn more

D3D12 Translation Layer GitHub readme

D3D11On12 GitHub readme

D3D11On12 conceptual documentation

D3D11On12 reference documentation

D3D11On12 blog posts: First and second

Questions? Reach out on Discord

Angela Jiang
Click to expand...

Source: https://devblogs.microsoft.com/direc...w-open-source/

Johan45 · Oct 16, 2020

AMD FX OC'ers Club

That's what the auto setting will do since you're over the 1333 mark it jumps to the next step which isn't listed or officially supported I assume by that ram.

At this point though I would suggest dropping the multi one step or .5 so that we can get something stable and possibly take the heat issue out of the picture for now.

Brink · Oct 16, 2020

New in D3D12 - GPU-Based Validation now available for Shader Model 6.x
In the next update to Windows, codenamed 19H1, the DirectX12 debug layer adds support for GPU-based validation (GBV) of shader model 6.x (DXIL) as well as the previously supported shader model 5.x (DXBC).

GBV is a GPU timeline validation that modifies and injects validation instructions directly into application shaders. It can provide more detailed validation than is possible using CPU validation alone. In previous Windows releases, GBV modified DXBC shaders to provide validations such as resource state tracking, out-of-bound buffer accesses, uninitialized resource and descriptor bindings, and resource promotion/decay validation. With the 19H1 release, the debug layer provides all these validations for DXIL based shaders as well.

This support is available today in the latest 19H1 builds accessible through the Windows Insider Program.

How to enable GPU-based validation for applications using DXIL shaders

No additional step is needed to enable DXIL GBV. The traditional method is extended to support DXIL based shader patching as well as DXBC:

Code:
Code:
void EnableShaderBasedValidation()  {      CComPtr<ID3D12Debug> spDebugController0;      CComPtr<ID3D12Debug1> spDebugController1;         VERIFY(D3D12GetDebugInterface(IID_PPV_ARGS(&spDebugController0)));      VERIFY(spDebugController0->QueryInterface(IID_PPV_ARGS(&spDebugController1)));      spDebugController1->SetEnableGPUBasedValidation(true);  }
Click to expand...
Source: New in D3D12 - GPU-Based Validation (GBV) is now available for Shader Model 6.x | DirectX Developer Blog

Windows 10: D3D12 Debug Object Auto-Naming option now available

D3D12 Debug Object Auto-Naming option now available

D3D12 Debug Object Auto-Naming option now available

D3D12 Debug Object Auto-Naming option now available

D3D12 Debug Object Auto-Naming option now available - Similar Threads - D3D12 Debug Object

Physical device object name

D3D12 Debug Layer Message Callback feature is now available

D3D12 Translation Layer and D3D11On12 are now open source

Folder Object Name desynchronized with displayed name

Folder Object Name desynchronized with displayed name

New in D3D12 - GPU-Based Validation now available for Shader Model 6.x

Circular Objects Are Now Rhombuses?

Name not available

Time Travel Debugging is now available in WinDbg Preview