[Intel-gfx] [PATCH v3 3/3] drm/doc/rfc: VM_BIND uapi definition
Lionel Landwerlin
lionel.g.landwerlin at intel.com
Thu Jun 23 12:41:30 UTC 2022
On 23/06/2022 14:05, Tvrtko Ursulin wrote:
>
> On 23/06/2022 09:57, Lionel Landwerlin wrote:
>> On 23/06/2022 11:27, Tvrtko Ursulin wrote:
>>>>
>>>> After a vm_unbind, UMD can re-bind to same VA range against an
>>>> active VM.
>>>> Though I am not sue with Mesa usecase if that new mapping is
>>>> required for
>>>> running GPU job or it will be for the next submission. But ensuring
>>>> the
>>>> tlb flush upon unbind, KMD can ensure correctness.
>>>
>>> Isn't that their problem? If they re-bind for submitting _new_ work
>>> then they get the flush as part of batch buffer pre-amble.
>>
>> In the non sparse case, if a VA range is unbound, it is invalid to
>> use that range for anything until it has been rebound by something else.
>>
>> We'll take the fence provided by vm_bind and put it as a wait fence
>> on the next execbuffer.
>>
>> It might be safer in case of memory over fetching?
>>
>>
>> TLB flush will have to happen at some point right?
>>
>> What's the alternative to do it in unbind?
>
> Currently TLB flush happens from the ring before every BB_START and
> also when i915 returns the backing store pages to the system.
>
> For the former, I haven't seen any mention that for execbuf3 there are
> plans to stop doing it? Anyway, as long as this is kept and sequence
> of bind[1..N]+execbuf is safe and correctly sees all the preceding binds.
> Hence about the alternative to doing it in unbind - first I think lets
> state the problem that is trying to solve.
>
> For instance is it just for the compute "append work to the running
> batch" use case? I honestly don't remember how was that supposed to
> work so maybe the tlb flush on bind was supposed to deal with that
> scenario?
>
> Or you see a problem even for Mesa with the current model?
>
> Regards,
>
> Tvrtko
As far as I can tell, all the binds should have completed before execbuf
starts if you follow the vulkan sparse binding rules.
For non-sparse, the UMD will take care of it.
I think we're fine.
-Lionel
More information about the Intel-gfx
mailing list