DirectX-Graphics-Samples | This repo contains the DirectX Graphics samples that demonstrate how to build graphics intensive app | Graphics library

The key issue is that you don't want to stall the GPU for best performance. Double-buffering is a minimal requirement, but typically triple-buffering is better for smoothing out frame-to-frame rendering spikes, etc.

FWIW, the default behavior of DXGI Present is to stall only after you have submitted THREE frames of work, not two.

Of course, there's a trade-off between triple-buffering and input responsiveness, but if you are maintaining 60 Hz or better than it's likely not noticeable.

With all that said, typically you don't need to double-buffered depth/stencil buffers for rendering, although if you wanted to make the initial write of the depth-buffer overlap with the read of the previous depth-buffer passes then you would want distinct buffers per frame for performance and correctness.

The 'writes' are all complete before the 'reads' in DX12 because of the injection of the 'Resource Barrier' into the command-list:

The project use package.config file to manage nuget packages.

So try to modify the Package Reference to Package.config

This is essentially the same build error reported under Issue #652 Error building D3D12MeshShaders (on VS 16.8.0 Preview 3.0) in the DirectX-Graphics-Samples repo.

I'm getting error C2102: '&' requires l-value on many of the lines. Usually it's when a CD3DX12 constructor is directly used with an &, for example [...]

The issue is still open, with an interim workaround given in a comment:

The use of an address of an r-value like this [...] is non-conforming code.

Visual C++ emits a warning C4238 here with /W4 warning level 4, but most VC projects default to level 3 including these samples. [...] Looks like the latest Visual C++ updates for /permissive- have upgraded this to an error.

You can work around this issue for now by disabling /permissive- by changing "Conformance Mode" to "No" in the C/C++ -> Language project settings.

You are using the 'latest' copy of D3DX12.H which requires you use the 'latest' version of the Windows 10 SDK (19041). If D3D12_RESOURCE_DESC1 is undefined, you are using an older Windows 10 SDK.

Note that there are three different options for fixing this mismatch:

1. Install the latest Windows 10 SDK (19041). For VS 2019, this is done by running Visual Studio Installer and selecting the new Windows 10 SDK as a component. For VS 2017, you need to run the standalone installer. VS 2015 and earlier are not supported.

2. Use a version of the D3DX12.H utility header that supports older SDKs. I maintain a version of the 'latest' D3DX12.H header that contains a bunch of preprocessor conditionals so that it will support Windows 10 SDK (14393) or later. That happens to be last version of the Windows 10 SDK to support VS 2015. Obtain it from GitHub: directx-vs-templates.

3. Use GitHub DirectX-Headers: A new option is to get the latest headers including D3DX12.H as a set from GitHub. You still need a Windows 10 SDK for the link libraries.

See this blog post for details on why D3DX12.H is not part of the Windows 10 SDK.

The samples on DirectX-Graphics-Samples in the main/master branch assume you are using the latest Windows 10 SDK (19041).

As you are new to DirectX 12, you may want to take a look at DirectX Tool Kit for DX12 as a more gentle introduction to the latest version of the API.

The *.inl extension is usually used to indicate that the file is an inline-definition of something defined in a header. Effectively, the *.inl file is generally treated as an inline-equivalent to a *.cpp file.

In the same way that *.cpp files can use symbols #included in the header for that *.cpp file, *.inl files usually have the same assumption.

In this specific example. it appears that Functions.inl is included after a bunch of other headers are included