[Nouveau] Questions on syncing mechanisms

[Ilia Mirkin]

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 <fsahmkow27 at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau