Jump to content
  • Advertisement
mark_braga

DX12 Split Barrier Question

This topic is 431 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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();
ResourceBarrier(BEGIN_ONLY, pTextureShadowMap, SHADER_READ);

DrawDeferredPass();

ResourceBarrier(END_ONLY, pTextureShadowMap, SHADER_READ);

// Uses shadow map for shadow calculations
DrawShadingPass();

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

DrawShadowMapPass();

DrawDeferredPass();

ResourceBarrier(NORMAL, pTextureShadowMap, SHADER_READ);

// Uses shadow map for shadow calculations
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 this post


Link to post
Share on other sites
Advertisement

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 this post


Link to post
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();

ResourceBarrier(BEGIN_ONLY, pTexShadow);

ResourceBarrier(END_ONLY, pTexShadow);

DrawShadingPass();

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

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!