On 11/28/2010 10:55 PM, Francisco Jerez wrote:
Thomas Hellstrom<thomas@xxxxxxxxxxxx> writes:
On 11/28/2010 05:11 PM, Francisco Jerez wrote:
Francisco Jerez<currojerez@xxxxxxxxxx> writes:
Thomas Hellstrom<thomas@xxxxxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
