Question about strictness of resource states

[Yoshusa]

Dear Microsoft Team,

I attached two files, which contain a modified version of the HelloTexture sample.

The major change is, that I create an unordered access view to the texture in addition to the shader resource view in the LoadAssets method of the sample:

D3D12_UNORDERED_ACCESS_VIEW_DESC uavDesc = {};
uavDesc.Format = textureDesc.Format;
uavDesc.ViewDimension = D3D12_UAV_DIMENSION_TEXTURE2D;
uavDesc.Texture2D.MipSlice = 0;
uavDesc.Texture2D.PlaneSlice = 0;

handle.ptr += m_srvDescriptorSize;

m_device->CreateUnorderedAccessView(m_texture.Get(), nullptr, &uavDesc, handle);

Also I change the resource state of the texture from COPY_DEST to UNORDERED_ACCESS instead to PIXEL_SHADER_RESOURCE:

m_commandList->ResourceBarrier(1, &CD3DX12_RESOURCE_BARRIER::Transition(m_texture.Get(), D3D12_RESOURCE_STATE_COPY_DEST, D3D12_RESOURCE_STATE_UNORDERED_ACCESS));

I did not change anything in the rendering method, so the texture is still used there as a pixel shader resource. Now my question: Why is this working? Why can the texture be used as a pixel shader resource so its resource state is UNORDERED_ACCESS?

Is it because UNORDERED_ACCESS is a read/write state and the set read flag automatically includes read-only states? On the other hand, changing the state to or-combined UNORDERED_ACCESS | PIXEL_SHADER_RESOURCE is not allowed, cause read/write states cannot or-combined with read-only states. So to be honest, I am a bit confused.

I did not find an option in the Visual Studio Graphics Debugger (and neither in NSight) to check the current state of a resource. Did I have overseen something?

Kind regards,

Joerg Sahm

D3D12HelloTexture.zip

[bobbrow]

Hi @Yoshusa,

Thanks for the question. I'll start off by saying that just because this scenario appears to work on the driver you tested, you should not expect this to work universally. The SDK layers currently do not have extensive validation for resource states right now, but it is something we are working on.

Some drivers will interpret resource state more coarsely than others. It is not terribly surprising that what you've coded up works since you only ever transition this resource once and then never touch the state again or modify the resource. Transition barriers are generally used by the driver to stall the pipeline when necessary to ensure writes are committed before reads, necessary caches have been flushed, and perhaps perform compression/decompression. Putting resources in the correct state will ensure that your application will work across all GPU vendors.

For the graphics debugging tools, when you open up a texture resource, it will open up two tabs: one with a visualization of the contents of that texture, and another one with information about the texture itself (essentially the stuff in D3D12_RESOURCE_DESC). The first tab will be made visible by default so you will have to manually switch to the second tab to see the information. Unfortunately though, there is a bug where the state displayed in the second tab is not always correct and the fix did not make it into the 10586 build.

[stanard]

To add to Bob's comments, resource transition barriers are commands unto themselves. The resources themselves don't actually need to track what state they are in. You, the expert graphics programmer, are trusted to provide the right barriers at the right time. The debug validation layer can help you detect when you make a mistake, but resources don't know what barriers will come before or after. Remember that DX12 is a (mostly) stateless API. You can't, for instance, query the state of a resource.

Side note: I mean no offense by the "expert graphics programmer" comment. I am not being ironic or condescending. I'm saying that DX12 is a low-level API designed for experts who want to explicitly take control of the hardware and understand the implications and responsibility. DX11 managed resource barriers for you automatically, but you can do a much better job of it yourself, so we made it possible to do so with DX12. You might not be an expert when you come to DX12, but once you understand the design decisions of DX12, you will be considered a GPU expert by your peers.

[Yoshusa]

Hi All,

thanks for your replies.

I think, I've got it and after working with DirectX 12 for already 8 weeks now, I feel kinda stupid. Let's assume, I have a buffer resource, which can be viewed as a non-pixel-shader-resource and an unordered-access in some compute shaders. Now I run the following scenario once per frame:

1. Use resource as unordered-access
2. Dispatch some thread groups with compute shader A and write to the resource
3. Use resource as shader-resource
4. Dispatch some thread groups with compute shader B and read from the resource

Since I did not add a barrier between the two dispatch calls, it can happen that some thread groups are still not finished with step 2, while some other thread groups already work on step 4. So I end up in a classical read-writer conflict which can be solved with a barrier (all threads groups scheduled in step 2 have to be finished, before the barrier unlocks). I really did alot of multithreading programming and I always asked myself, why the heck of all the things they use barriers to synchronize access to the resources :)

Sorry, after all these years with DirectX 9..11, I could not get my head wrapped around that draw and dispatch calls are not longer "atomic" operations (from the sight of my application).

So, am I correct with these thoughts?

Greetings,

Joerg

[stanard]

You've got it. :-) Draws/dispatches can overlap, and a barrier is needed between two dependent draws/dispatches. As you put it, it's for the classic read/write data hazard. Transition barriers can also be used to tell the driver it's time to decompress a buffer (e.g. a depth buffer). And UAV barriers can be used when you write to a UAV and plan to read from it (or vice versa), since there is no transition but you still need a barrier. All of this falls under the banner of thread synchronization.

[Yoshusa]

Hi stanard

Thank you, I will close the issue.

Greetings,

Joerg

[pengliu916]

@stanard Just want to verify: Do we need to insert fence between step2 and step4 to ensure the producer finished writing before consumer begins reading? or the resource barrier implicitly did that?

[Yoshusa]

Hi pengliu916,

no, you do not need fences for that. DirectX fences are a technique to synchronize the CPU with the GPU. DirectX barriers are a technique to wait until a set of GPU threads have finished their tasks, so it is a way to synchronize Dispatch and Draw commands on the GPU. Please note that I write DirectX fences and DirectX barriers, because the combination of GPU and CPU is somewhat special in comparison to CPU-only multithreaded programming.

In your C++ application you can add a "Signal" command to the command queue in combination with a certain UInt64 value (CPU side). If the GPU has finished the command lists passed for execution before the Signal command, it processes the Signal command itself and notifies/updates the fence with your UInt64 value (GPU side). In your C++ application you can ask the fence for its current value, and if it contains your passed UInt64 value (or maybe a greater value from a later signal), you know on the CPU, that the GPU has finished the command lists executed before the Signal command.

When to use a fence? For example in our engine we use a triple-buffering swapchain. If the GPU is more than 2 frames behind the CPU, we get the problem, that the CPU wants to fill and run command lists for a frame buffer, which is still not finshed yet. In this case we use a fence in combination with the SetEventOnCompletion/WaitForSingleObject methods, to block the main graphics CPU thread until the GPU has finshed the frame. Let's assume, we would not use a CPU/GPU synchronization here and the GPU gets more and more behind the CPU. Then in each new frame the CPU would create and fill unexecuted command lists and therefore command allocators (which require GPU memory). After a while you will run out of CPU/GPU memory.

Long story short, a barrier between step 2 and 4 is enough, cause we only want to synchronize GPU side Dispatch/Draw commands.

Please note, that stanard's last comment contains a very important point. You also have to use a barrier between two Dispatch calls, if you use the same resource in both calls as an unordered-access-resource, but in one call the resource is written and in the other it is read (or in any other possible read-write conflict).

Please correct me, if I am incomplete or said something wrong.

Greetings,

Joerg

[stanard]

Fences are pretty heavy-weight constructs in D3D12. They are like semaphores except they usually only count up, not down. You can signal a fence from either the CPU or GPU, and you can wait for a fence on either. But when signaling from the GPU, the signal goes straight to the CommandQueue rather than onto a CommandList. This means you can only signal between command list executions. (This might change in the future.) But anyway, there is a bunch of overhead in closing a command list, signaling, and then executing a new command list, so try not to do it very often.

As Joerg said, fences let you monitor the progress of the GPU. Once it's finished with a command list, all resources used by that command list are now free to be reclaimed if you wish. All of your resource re-use and recycling must be guarded with fences. A good way to idle the GPU (flush everything out of the pipe) is to insert a signal command on the command queue and wait for it on the CPU.

One thing Joerg didn't mention is that signals and fences can be used to synchronize different command queues (such as Graphics and Compute) as well as different GPU adapters for SLI.

-James

[pengliu916]

Thanks @Yoshusa and @stanard for elaborating on that. I have hold on that thought for a few days, since I have a simple demo program and can be described as follow:

It's basically a dynamic volume renderer, and for each frame first I have a compute shader first update the volume buffer, and then a pixel shader render the volume. And the compute shader and pixel shader are in different commandlist and commandqueue (they can be in the same queue, but here we assume they need to be in different queue)

Originally, I added fence between these two commandlist to prevent read/write data hazard. But as you guys suggested, the fence is not necessary, since a resource barrier will be enough

Now, here I have a question, given the fact that closing commandlist have some overhead, and transition resource also take some time. So the following execution order

     1.ComputeCmdList->Dispatch
     2.ComputeCmdList->TransitionResource
     3.ComputeCmdList->Close
     4.GraphicsCmdList->Draw
     5.GraphicsCmdList->TransitionResource
     6.GraphicsCmdList->Close

should be a little faster than

     1.ComputeCmdList->TransitionResource
     2.ComputeCmdList->Dispatch
     3.ComputeCmdList->Close
     4.GraphicsCmdList->TransitionResource
     5.GraphicsCmdList->Draw
     6.GraphicsCmdList->Close

Since the first one kinda of overlap the the closing overhead with transitioning.

But my profiling result suggest otherwise: the first order is slight slower than the second one (14.7ms vs 14.4ms on my laptop) which didn't make sense to me.

So am I doing something wrong or my understanding of these are totally wrong?

[stanard]

Have you tried using split barriers? This might be a case where you are forcing a transition to happen before you actually need the results. Is VSYNC enabled? The extra 0.3 ms might be hidden in the VSYNC idle time.

-James

[pengliu916]

Yup, I have turn off VSYNC but didn't use split barrier. But I have tried this on other computer, and the perf delta is negligible. So I guess the 0.3ms maybe perf noise or different driver issue?

But does my assumption hold? that is theoretically the first order should run faster than the second one? (if we use split barrier)

Thanks in advance

Peng

[stanard]

I'm just not sure why it costs 0.3 ms extra. Why do you need two different command queues? Are you doing asynchronous compute? If you are synchronizing queues, you will need a fence object, not just resource barriers. Are you sure you are getting correct results? If you move the camera, do you notice visual artifacts that might be the result of non-deterministic write order?

[pengliu916]

I am not doing serious project, just crafting application to play around with DX12, so I decide to try put them into different queues to see what happens... But I see what you are saying.

(Correct me if I said something wrong) So if the GPU doesn't support async compute, then the job sequence is always draw,dispatch interleaved(one CPU rendering submitting thread), for this case I guess we don't need a fence object (or I am wrong?). While with async compute supported GPU, even we interleaved draw,dispatch job on CPU side, GPU may not see it interleaved. So we have to use fence to manually synchronize these two command queue.