Split Barrier Question

Started by
5 comments, last by MJP 6 years, 7 months ago

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. 

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.

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?

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.)

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.

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.

This topic is closed to new replies.

Advertisement