[Nouveau] [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete

[Maarten Maathuis]

On Thu, Jan 21, 2010 at 3:44 PM, Francisco Jerez <currojerez at riseup.net> wrote:
> Luca Barbieri <luca at luca-barbieri.com> writes:
>
>>> Nvidia cards have a synchronization primitive that could be used to
>>> synchronize several FIFOs in hardware (AKA semaphores, see [1] for an
>>> example).
>>
>> Does this operate wholly on the GPU on all nVidia cards?
>>
>> It seems that at least on some GPUs this will trigger "software
>> methods" that are basically a way for the GPU to trigger an interrupt
>> and stop the FIFO until the CPU handles the interrupt and restarts it.
>>

Yes this triggers a few software methods, nvidia hardware is a bit
lacking in this area.

> Yes, it could be handled without software methods, Maarten (CC'ed) was
> looking into this, IIRC.

Doing it without software methods means you need to have a semaphore
that "exists" in the cpu domain and therefore cannot be used again
until the cpu is sure it's done. So that will probably require a
rotating queue of several semaphores and a fallback to cpu waiting. It
should not be that hard to prototype in kernel, although we currently
assume notifiers (little chunks of memory that amongst other things
are used by semaphore) to be in channel private memory, so while in
kernel it's probably doable, there will need to be api changes for the
userspace side of it. Since the respective chunk of memory needs to
have a dma object on more than one channel. This should probably be
dealt with in combination with calims desire to be able to have dma
objects for random buffer objects for use with gpu queries. It doesn't
seem impossible, but it won't exactly be trivial either. The sanest
model would probably involve an ioctl that takes two channels and does
whatever is needed to make it synchronised. But given the recent
discussion/noise about doubts regarding our mixed userspace/kernel
model, we should consider this carefully. That said, i doubt it would
be sanely possible with a full userspace model like the one nvidia
uses.

>
>> Also, is there a way on nVidia cards to get interrupts on fences, but
>> only where the fence sequence number is higher than a dynamically set
>> value? (so that one could sleep for fence X without getting an
>> interrupt for every single fence before that)
>>
>> If not, it could possibly be hacked around by reading from a DMA
>> object at the address of the fence sequence number and then resizing
>> the DMA object so that addresses from a certain point on would trigger
>> a protection fault interrupt.
>
> I don't think you can safely modify a DMA object without stalling the
> card completely, but i think you could use e.g. PGRAPH NOTIFY interrupts
> and disable them by flipping a bit in PGRAPH when you stop caring about
> them.
>