Re: [Intel-gfx] [PATCH v3 3/3] drm/doc/rfc: VM_BIND uapi definition

[Lionel Landwerlin <lionel.g.landwerlin@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

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?


-Lionel


[-- Attachment #2: Type: text/html, Size: 1612 bytes --]