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. > While doing that I looked a bit at the Nouveau fencing. It appears > like waiting for fences is polling only (no irq to signal fences)? Is > that correct? > That's right, nvidia hardware has no nice way to schedule a fence-like interrupt we could selectively turn on and off around the sync_obj_wait hook. There's a bunch of (more or less) chipset-specific hacks that could be used to get an equivalent effect, but polling has seemed good enough so far (in the typical case we only take the "lazy" path so CPU usage is still OK). Unconditional PFIFO CACHE interrupts might be an option too, but, I'm a bit afraid of the PFIFO stalls and useless IRQ storms some applications could trigger. > /Thomas > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel
Attachment:
pgpw8kleoBpsJ.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
