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

[Maarten Maathuis]

On Thu, Jan 21, 2010 at 4:56 PM, Luca Barbieri <luca at luca-barbieri.com> wrote:
>> 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.
>
> Why would it need a semaphore in CPU domain?
> Couldn't it work this way:
> 1. Allocate a BO in the kernel

Who will set the initial "not-done" value?

> 2. Emit on one channel a "notify" request on that BO
> 3. Emit on the other channel a "wait" request on that BO
> 4. Emit a fence on the wait channel
> 5. Use the existing delayed-destroy mechanism to get rid of the BO
> once the wait channel fence expires
>
> Then the GPU would presumably switch away from the "waiting" context
> and not reexecute it until the notify happens, or something similar.
>
> The problem is, of course, whether the GPU supports the "wait" request.
>