When to call FLUSH/SEMA/STALL

Wladimir J. van der Laan laanwj at gmail.com
Thu May 11 08:18:10 UTC 2017


On Thu, May 11, 2017 at 08:54:48AM +0200, Rolf Wöhrmann wrote:
> Hi
> 
> first thanks to all the responses to my previous post. The info was really helpful!
> 
> My question is when exactly to execute the FLUSH/SEMA/STALL sequence?

This is one of the things I never figured out properly.

Some synchronizations are obvious (like when transferring ownership of buffers
between GPU/CPU, or between different GPU cores), but usually it's just "add in
synchronization when you run into random crashes or corruption". Or "look what
the blob driver does for your hardware".

Even worse it seems to differ between models, even revisions. Some have bugs that necessitate
extra flushes/syncs/stalls between operations and state changes.

I'm happy that recent rendering APIs such as Vulkan have gone a lot further in
exposing various synchronization primitives explicitly to the application, and
documenting when they're to be used, but that won't help for older hardware.

> Let’s assume for simplicity we’ve a chain of lines & rect fills (aka clear) with changing color in between. This would result in a sequence of LOAD_STATE and START_DE ops.  

Yep, that would be the ideal.

> Looking into the code it seems that after START_DE and changing the state with LOAD_STATE again for the next START_DE a FLUSH/SEMA/STALL is performed.
> 
> Is this mandatory (like state is “global” to the DE pipe and you have to wait until PE is finished before changing it) ?

I don't think it's mandatory to go the whole way, on all hardware: in my
reverse engineering testing with the 2D engine back in the day I've executed
huge command buffers without any synchronization in between, but for the lowest
common denominator you need to sync after every little thing.

> I know that this is also of advantage like for fencing with using event/irqs and I also understood the use of WAIT/LINKs for a-synchronically managing the cmd ring buffer, but 
> my question relates to a situation where you have a long pre-known sequence of LOAD_STATEs and START_DEs and how to efficiently build up the related cmd sequence.

Just try it out!

Wladimir


More information about the etnaviv mailing list