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.

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.