• 13
• 18
• 19
• 27
• 10
• ### Similar Content

• By Krypt0n
Finally the ray tracing geekyness starts:
https://blogs.msdn.microsoft.com/directx/2018/03/19/announcing-microsoft-directx-raytracing/

https://www.remedygames.com/experiments-with-directx-raytracing-in-remedys-northlight-engine/
• By lubbe75
What is the best practice when you want to draw a surface (for instance a triangle strip) with a uniform color?
At the moment I send vertices to the shader, where each vertice has both position and color information. Since all vertices for that triangle strip have the same color I thought I could reduce memory use by sending the color separate somehow. A vertex could then be represented by three floats instead of seven (xyz instead of xys + rgba).
Does it make sense? What's the best practice?

• Hey all,
I'm trying to understand implicit state promotion for directx 12 as well as its intended use case. https://msdn.microsoft.com/en-us/library/windows/desktop/dn899226(v=vs.85).aspx#implicit_state_transitions
I'm attempting to utilize copy queues and finding that there's a lot of book-keeping I need to do to first "pre-transition" from my Graphics / Compute Read-Only state (P-SRV | NP-SRV) to Common, Common to Copy Dest, perform the copy on the copy command list, transition back to common, and then find another graphics command list to do the final Common -> (P-SRV | NP-SRV) again.
With state promotion, it would seem that I can 'nix the Common -> Copy Dest, Copy Dest -> Common bits on the copy queue easily enough, but I'm curious whether I could just keep all of my "read-only" buffers and images in the common state and effectively not perform any barriers at all.
This seems to be encouraged by the docs, but I'm not sure I fully understand the implications. Does this sound right?
Thanks.
• By NikiTo
I need to share heap between RTV and Stencil. I need to render to a texture and without copying it(only changing the barriers, etc) to be able to use that texture as stencil. without copying nothing around. But the creating of the placed resource fails. I think it could be because of the D3D12_RESOURCE_DESC has 8_UINT format, but D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL enabled too, and MSDN says Stencil does not support that format. Is the format the problem? And if the format is the problem, what format I have to use?

For the texture of that resource I have the flags like: "D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET | D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL" and it fails, but when I remove the allow-stencil flag, it works.

• I know vertex buffer is just another GPU resource represented by ID3D12Resource, but why is it said that vertex buffer don’t need a descriptor heap??
Other resources like depth/stencil resource, swap chain’s buffer need to have descriptor heaps. How does these resources differ from vertex buffer.

# DX12 Split Barrier Question

## Recommended Posts

I am working on optimizing barriers in our engine but for some reason can't wrap my head around split barriers.

Lets say for example, I have a shadow pass followed by a deferred pass followed by the shading pass. From what I have read, we can put a begin only split barrier for the shadow map texture after the shadow pass and an end only barrier before the shading pass. Here is how the code will look like in that case.

DrawShadowMapPass();

DrawDeferredPass();

DrawShadingPass();

Now if I just put one barrier before the shading pass, here is how the code looks.

DrawShadowMapPass();

DrawDeferredPass();

DrawShadingPass();

Whats the difference between the two?

Also if I have to use the render target immediately after a pass. For example: Using the albedo, normal textures as shader resource in the shading pass which is right after the deferred pass. Would we benefit from a split barrier in this case?

Maybe I am completely missing the point so any info on this would really help. The MSDN doc doesn't really help. Also, I read another topic

but it didn't really help either.

##### Share on other sites

There's two things it does for you:

1. Think of the begin as inserting a signal at the end of the pipeline, and the end as inserting a wait at the beginning of the pipeline. If the signal has already passed by the time the wait is executing, then the wait is a no-op. If you don't use split barriers, then it requires completely (or at least partially) draining the GPU pipeline when you do a barrier that requires that kind of sync.

2. If there's actual work associated with the barrier (e.g. a decompression of some kind), then the driver is able to begin that work when the begin is issued, and wait for it when the end is issued. If you don't use split barriers, then there's no parallelism to be had between the work you know about and the work associated with the barrier.

##### Share on other sites

Thanks for the info. It clears up a lot of things. But I still don't understand what could be the advantage of the split barrier if we have a shadow-map pass and the shadow-map is used as shader resource in the next pass.

DrawShadowMapPass();

DrawShadingPass();

Wouldn't the code look like that in the above case?

##### Share on other sites
49 minutes ago, mark_braga said:

But I still don't understand what could be the advantage of the split barrier if we have a shadow-map pass and the shadow-map is used as shader resource in the next pass.

If there is no other work in between there schould be no advantage from using a split barrier.

(But i can't tell from experience. In Vulkan you can do this with events but i have not used it yet.)

##### Share on other sites
1 hour ago, JoeJ said:

If there is no other work in between there schould be no advantage from using a split barrier.

Yep, pretty much this. A full barrier is equivalent to a begin+end with nothing in between.

##### Share on other sites

Just an FYI on split barriers: so far (through experimentation) I have not seen any PC hardware/driver combination that actually overlaps work with a split barrier in the way that you would expect. All of the hardware that I tested on would treat either the BEGIN or the END as a full barrier and ignore the other one. I suspect that taking advantage of split barriers is tricky for drivers in their current state, since there's nothing to link the END barrier back to the initial BEGIN barrier. With Vulkan the driver might be able to do a better job of this, since you have to provide a persistent "event" object for both steps.