On Thu, Jan 21, 2010 at 3:44 PM, Francisco Jerez <curroje...@riseup.net> wrote: > Luca Barbieri <l...@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. > _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau