Here's what I know, which may or may not be accurate, and may or may not be complete. You've been warned.
GRAPH.SERIALIZE (0x0110) This is a method available on all GRAPH-engine classes (at least 3d and 2d). What this does is that it tells the GRAPH engine (not FIFO!) to wait until all previous draws are done before taking action on commands that go after the SERIALIZE. This may be done if you want to e.g. query something about a draw, and you want to make sure that draw completes first. However note that this does not stop processing at the FIFO level - it keeps reading and filling the GRAPH queue. We also do this if we're about to render to a texture that a previous draw is reading from. We could wait for everything to clear out first, but just sticking in a SERIALIZE means less GPU <-> CPU synchronization. FIFO.YIELD (0x0080) This is is a FIFO command (available on any subchan) to indicate that the FIFO should switch to another channel without waiting for its timeslice to be over. FIFO.SEMAPHORE_TRIGGER (0x001c) This tells the FIFO to wait before processing any additional commands until the condition in the ACTION field is met. Usually done to ensure that some incrementing sequence number is hit at some memory address. (This incrementing sequence number is usually known as a "fence".) This is done for inter-engine sync, where you can't just rely on GRAPH to process commands sequentially. For example let's say you want to copy from a rendered surface somewhere using the FIFO-based copy engine, you have to wait for that draw to finish first, and you might use SEMAPHORE_TRIGGER to do that. There's more on some of this here: https://envytools.readthedocs.io/en/latest/hw/fifo/puller.html#puller-builtin-methods On Sun, Jun 9, 2019 at 12:11 PM Fernando Sahmkow <fsahmko...@gmail.com> wrote: > > So I have been implementing syncing mechanisms to yuzu's switch emulator, aka > Tegra X1 emulation and I already have: Semaphores, Syncpoints and Queries to > some extent. I'm missing the barriers (GPU waits for CPU): > I got this from RE: > Barrier mode has priority (from highest to lowest): 1) 0x08 sets needsWfi=0 > -> highest priority, does puller refcnt + split(0,0) + 0x100 NoOperation + > rest of cmds + split(1,1) 2) 0x01 sets needsWfi=0 -> uses 0x0110 > Serialize/"WaitForIdle" 3) 0x02 sets needsWfi=1 -> uses 0xDE0 (??) 4) 0x04 > sets needsWfi=1 -> uses 0xF7C (??) <-- tile related? Used by > nvnQueue_ctrlTiledDownsample 5) nothing; sets needsWfi=0 > Do you guys know any info on this and how the GPU must behave in each > situation. For instance, on Serialize, what should the GPU be waiting for? I > do know you guys use that one not sure on the rest. > _______________________________________________ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
