DirectX12 | Various DirectX12 examples | Runtime Evironment library

Generally speaking, "intermediate resources" (such as depth stencils and intermediate render targets) are not presented on the screen.

So when one swapchain is ready to present (and you start recording next frame commands), those resources can be safely overridden, since the content is ready within the swap chain.

The only exception for those resources are generally buffers that are uploaded from cpu, for them it is needed to have one per frame (since you will start to copy data while another command list is still executing).

Updated Answer:

The Win32 API allows you to modify parameters of the window one at a time. When a parameter is modified, the API may or may not update the window and trigger a WM_SIZE that will be the size of the window given the current parameters.

Since to have a complete full screen window you need to make at least 2 calls, one to update GWL_STYLE and another to update GWL_EXSTYLE, you have a big chance of getting 2 WM_SIZE calls. One of them will give you the window size without the menu, and the other the full screen window size. It depends in which order you call SetWindowLongPtr, but you'll probably get 2 WM_SIZE and only the second one is "correct", i.e. the one you want in the end.

The more reliable solution to your problem is to use a variable at the top of Main.cpp:

int isTogglingFullScreen = false;

Then inside your full screen toggle code (note where isTogglingFullScreen is being set):

#directxtk does it with a single fence, and a fence value for each frame.

I believe you need fence values for each frame, because you want to know when the next frame is ready, not when the previous frame is completely finished (which would let you use a single global fence value). The call to a fence's GetCompletedValue() will tell you if the fence reached the fence value necessary to consider the next frame ready to be rendered.

Since the frames rotate with the back buffers, you want as many fence values as back buffers. But you don't necessarily need multiple fences. You can make it work with a single fence for a given command allocator.

Any time you need something fenced, you get the current fence value which you'd previously stored for the current back buffer in m_fenceValues[m_backBufferIndex]. Then you increment by 1, and tell the GPU via Signal() to please set the fence to this fence value when all current commands are executed. When you want to check that they've been executed, you compare to this fence value. If it's gone to the new number, then the GPU has done what it needed. Store that new fence value back in m_fenceValues[m_backBufferIndex] and you're done.

This can be done at any time, within a frame or for moving to the next frame. When you want to move to the next frame, you do the same thing, except that you store the (fence value +1) in the fence value of the current back buffer which, by now, has become the new back buffer.

Here's the relevant code for moving to the next frame:

Assuming your shader actually doesn't use the sampler when its image is bound to it, the validation layer is incorrect (not that it can know). The Vulkan standard only requires that the attached image subresources are not used:

Image subresources used as attachments in the current render pass must not be accessed in any way other than as an attachment by [a rendering command], ...

"Access" is defined by the Vulkan memory model, which for a bound image, involves invoking an image access command. So long as you don't do that to the descriptor, it is not "accessed", and thus does not violate this rule.

That being said, ping-ponging between images without using input attachments requires stopping and starting a render pass, not to mention the execution barriers between each pass. The cost of VkBindDescriptorSet will be a rounding error in your GPU profiling data next to all of that.

So you should just change descriptor sets and shut the validation layer up.

Based on the webstie-Windows 10 SDK, there is a note: Windows 10, version 21H1 is a scoped set of features for select performance improvements and quality enhancements. Developers should be aware of this release, but no action is necessary at this time.

A new Windows SDK will not be issued to accompany this version of Windows because this release doesn’t introduce new APIs. That means there’s no need to modify your project files or target a new version of Windows, and you should continue to use the Windows 10 SDK for Windows 10, version 2004. When setting the target version for your Windows app, Windows 10 build 19041 is still the most recent target version.

That's why you still need to select the build 19041 as the newest target version.

If you need to switch between buffers of the same type, dynamic indexing is indeed useful, but as you mention you need to declare resources of the same type (that said, it is the same with textures, I have common use cases for things like Texture2d for example, so it is not limited to StructuredBuffer).

So yeah, you will have to declare a different array for each typed buffer, which is not super convenient.

If you want to have full dynamic access to your resource (no matter the type), Shader Model 6.6 introduces direct access to heap (code name: ultimate bindless ;)

So you have a global variable called ResourceDescriptorHeap (which represents the currently bound resource Heap)

and SamplerDescriptorHeap (same but for samplers).

Now from there you can do (for example):

Well after you provided some more source code, I am pretty sure the mistake is here:

You can pass D3D12_RECT to ClearRenderTargetView to specify what portion of a render target to clear. So set your viewport of smaller size, clear only that part and you should be good to go.

Hardware video decoding comes from DXVA (DXVA2) API. It's DirectX 11 evolution is D3D11 Video Device part of D3D11 API. Microsoft provides wrappers over hardware accelerated decoders in the format of Media Foundation API primitives, such as H.264 Video Decoder. This decoder is offering use of hardware decoding capabilities as well as fallback to software decoding scenario.

Note that even though Media Foundation is available for UWP development, your options are limited and you are not offered primitives like mentioned transform directly. However if you use higher level APIs (Media Foundation Source Reader API in particular) you can leverage hardware accelerated video decoding in your UWP application.

Media Foundation implementation offers interoperability with Direct3D 11, in the part of video encoding/decoding in particular, but not Direct3D 12. You will not be able to use Media Foundation and DirectX 12 together out of the box. You will either have to implement Direct3D 11/12 interop to transfer the data between the APIs (or, where applicable, use shared access to the same GPU data).

Or alternatively you will have to step down to underlying ID3D12VideoDevice::CreateVideoDecoder which is further evolution of mentioned DXVA2 and Direct3D 11 video decoding APIs with similar usage.

Unfortunately if Media Foundation is notoriously known for poor documentation and hard-to-start development, Direct3D 12 video decoding has zero information and you will have to enjoy a feeling of a pioneer.

Either way all the mentioned are relatively thin wrappers over hardware assisted video decoding implementation with the same great performance. I would recommend taking Media Foundation path and implement 11/12 interop if/when it becomes necessary.