Re: Nouveau fences?

[Thomas Hellstrom <thomas@shipmail.org>]

On 11/28/2010 10:55 PM, Francisco Jerez wrote:
> Thomas Hellstrom<thomas@shipmail.org>  writes:
>
>    
>> On 11/28/2010 05:11 PM, Francisco Jerez wrote:
>>      
>>> Francisco Jerez<currojerez@riseup.net>   writes:
>>>
>>>
>>>        
>>>> Thomas Hellstrom<thomas@shipmail.org>   writes:
>>>>
>>>>
>>>>          
>>>>> Ben,
>>>>>
>>>>> I'm looking at a way to make TTM memory management asynchronous with
>>>>> the CPU. The idea is that you should basically be able to DMA data to
>>>>> and from memory regions without waiting for idle, as long as the GPU
>>>>> has a means to provide operation ordering.
>>>>>
>>>>>
>>>>>            
>>>> Sounds good. I guess you're mainly dealing with BO eviction
>>>> synchronization? The only problem I see on our side is that calls to our
>>>> move() hook aren't guaranteed to be carried out in order (because of the
>>>> multiple hardware channels). I'm thinking that move() could be extended
>>>> with an optional sync_obj argument, that way move() would be able to
>>>> make sure that evictions are strictly ordered with respect to the fence
>>>> specified.
>>>>
>>>>          
>> The way evictions will work is that they appear to take place
>> "instantly", but are scheduled on a channel, and there will be a data
>> structure that keeps track about what fences need to be signaled
>> before a managed area can be reused.
>>
>> The driver will need to provide a function that, given a list of
>> fences, returns a fence that when it signals, guarantees that all
>> other fences in the list have signaled.
>>      
> Ah, so, evictions made in response to ttm_bo_mem_force_space() are still
> going to be synchronous after the changes you have in mind (because in
> that case you need to reuse the freed memory immediately), right?
>    
No and yes. Evictions will be asynchronous, but the new user of the 
memory area needs to
take appropriate action to make sure it doesn't overwrite old contents. 
If it's a CPU upload, it needs to wait on a fence. Single-channel GPU 
with dma uploads needs to do nothing.
Multi-channel GPU needs to insert a barrier before uploading, that waits 
on the eviction DMA.

So you're right in that we need to give the new move function 
information on what to wait on / insert barriers for. I was initially 
thinking of a single fence object (and that's why the order function is 
needed).

> In other cases (e.g. evictions triggered by BO validation), what exactly
> would we gain from this function? I mean, why can't we just push waiting
> down to ttm_bo_move_ttm/memcpy?
>    

That's essentially what's going to happen, but those functions also need 
to know what exactly to wait on.

>    
>> Single-channel hardware will just return the fence with the highest
>> sequence. Multi-channel hardware may need to insert command stream
>> barriers if available and create a new sync object to return or resort
>> to simply waiting to determine which fence signals last.
>>
>> I guess Nouveau can do command stream barriers, (waiting for other
>> channels to reach a certain command before progressing?)
>>
>>      
> Yep, that's what nouveau_fence_sync() does.
>    

OK, thanks.

/Thomas