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

[Francisco Jerez]

Luca Barbieri <luca at luca-barbieri.com> writes:

>>> 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.
>
> The problem is that one needs to disable them *before* the one he cares about.
>
> Suppose the card is at fence 0 and we are interested in fence 1000 expiring.

That isn't the most common case. You typically don't expect the card to
get further than 3-4 pushbufs behind the CPU.

>
> If we just enable interrupts, then we are going to be interrupted
> uselessly 1000 times.
> Instead, we would like to tell the card "send me interrupts for
> fences, but only for fence number 1000 (or higher)".
>
> This way one could for instance render a whole scene, and then
> desiring to read it into the CPU, just ask for an interrupt once
> rendering is done (i.e. wait for the framebuffer fence) and get a
> single interrupt, while we cleanly sleep undisturbed in the meantime.
>
> Basically, it would just need some way of *conditionally* causing interrupts.
> If there is none, then maybe we could insert a call to a "fence
> mini-pushbuffer" filled with NOPs that could be overwritten with an
> interrupt request on demand?

The card also keeps some internal FIFO caches, so it seems to me that
getting that safe of races and efficient at the same time could be a bit
non-trivial.

> Or alternatively, construct such a pushbuffer with the 2D or 3D
> engines, starting from our "1000" input and the fence value generated
> by the 3D engine? (this is likely to be slow though).
> Or some hack like the DMA object resizing? (would it crash the GPU? or
> just not work due to it caching the previous size?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/nouveau/attachments/20100121/0d091a59/attachment.pgp