On 20/11/2019 12:59, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-20 12:55:42)
On 20/11/2019 09:32, Chris Wilson wrote:
Bonded request submission is designed to allow requests to execute in
parallel as laid out by the user. If the master request is already
finished before its bonded pair is submitted, the pair were not destined
to run in parallel and we lose the information about the master engine
to dictate selection of the secondary. If the second request was
required to be run on a particular engine in a virtual set, that should
have been specified, rather than left to the whims of a random
unconnected requests!
In the selftest, I made the mistake of not ensuring the master would
overlap with its bonded pairs, meaning that it could indeed complete
before we submitted the bonds. Those bonds were then free to select any
available engine in their virtual set, and not the one expected by the
test.
There is a submit await which ensures master is not runnable before
bonded pairs are submitted. Why was that not enough? Are the sporadic
test failures?
One test is using the submit_await, the other does not. It takes the
background retire worker to run as we are submitting the secondaries...
But I have not noticed this failure before hooking up retirement to
process_csb. However, the issue is definitely present in the current
test.
So what happens? Is this another issue limited to selftests? Because I
don't see that uAPI itself can't be used in this way.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
