Jump to content
  • Advertisement
ZachBethel

DX12 Resource Aliasing Barriers

Recommended Posts

I'm reading through the Microsoft docs trying to understand how to properly utilize aliasing barriers to alias resources properly.

"Applications must activate a resource with an aliasing barrier on a command list, by passing the resource in D3D12_RESOURCE_ALIASING_BARRIER::pResourceAfter. pResourceBefore can be left NULL during an activation. All resources that share physical memory with the activated resource now become inactive or somewhat inactive, which includes overlapping placed and reserved resources."

If I understand correctly, it's not necessary to actually provide the pResourceBefore* for each overlapping resource, as the driver will iterate the pages and invalidate resources for you. This is the Simple Model.

The Advanced Model is different:

Advanced Model

The active/ inactive abstraction can be ignored and the following lower-level rules must be honored, instead:

  • An aliasing barrier must be between two different GPU resource accesses of the same physical memory, as long as those accesses are within the same ExecuteCommandLists call.
  • The first rendering operation to certain types of aliased resource must still be an initialization, just like the Simple Model.

I'm confused because it looks like, in the Advanced Model, I'm expected to declare pResourceBefore* for every resource which overlaps pResourceAfter* (so I'd have to submit N aliasing barriers). Is the idea here that the driver can either do it for you (null pResourceBefore) or you can do it yourself? (specify every overlapping resource instead)? That seems like the tradeoff here.

It would be nice if I can just "activate" resources with AliasingBarrier (NULL, activatingResource) and not worry about tracking deactivations.  Am I understanding the docs correctly?

Thanks.

Share this post


Link to post
Share on other sites
Advertisement

Passing non-null pResourceBefore and/or pResourceAfter simply allows the driver to optimize out the temporal overlap of the accesses to these resources. 

If you provide neither, the driver must assume an immediate transition and must ensure all reads/writes have completed before any reads/writes following the barrier can start.

If you provide pResourceBefore, the driver can determine that all references to pResourceBefore should have already been completed by the time the barrier is reached by the GPU, it may choose to not insert any additional synchronization. 

That's also why the "Advanced Model" says that the barrier is not necessary if the access occur in different invocations of ExecuteCommandLists - since there's an implicit barrier between each invocation.

But do ensure that you heed the second bullet point of the "Advanced Model" - for render/depth resources you must first initialize the data using either a full copy, clear or discard of the regions of overlap between the aliases.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • 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!