Quoting Chris Wilson (2020-12-01 09:33:20)
> Quoting Tvrtko Ursulin (2020-12-01 09:26:05)
> > Now second copy comes and calls emit_pte which again writes to [0,
> > CHUNK_SZ) virtual range. How does that end up in the PTE backing store
> > and not previous object backing store?
>
> It all boils down to the PD being offset.
/*
* We construct a very special VM for use by all migration contexts,
* it is kept pinned so that it can be used at any time. As we need
* to pre-allocate the page directories for the migration VM, this
* limits us to only using a small number of prepared vma.
*
* To be able to pipeline and reschedule migration operations while
* avoiding unnecessary contention on the vm itself, the PTE updates
* are inline with the blits. All the blits use the same fixed
* addresses, with the backing store redirection being updated on the
* fly. Only 2 implicit vma are used for all migration operations.
*
* We lay the ppGTT out as:
*
* [0, CHUNK_SZ) -> first object
* [CHUNK_SZ, 2 * CHUNK_SZ) -> second object
* [2 * CHUNK_SZ, 2 * CHUNK_SZ + 2 * CHUNK_SZ >> 9] -> PTE
*
* By exposing the dma addresses of the page directories themselves
* within the ppGTT, we are then able to rewrite the PTE prior to use.
*/
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
