Am 02.04.2018 um 20:49 schrieb Eric Anholt:
[SNIP]
This call will pick a VMID and remember that the process of the job is
now the owner of this VMID. If the VMID previously didn't belonged to
the process of the current job all fences of the old process are added
to the job->sync object again.
This makes some sense when you have many VMIDs and reuse won't happen
very often. I'm concerned that when I effectively have one VMID that I
need to keep swapping, then we're creating a specific serialization of
the jobs at the time they're submitted to the kernel (dependency()
callback) rather than when the scheduler decides it would like to submit
to the HW (run_job() callback after deciding on a job based on
priority).
We have the same problem, e.g. a currently active process on a VMID
would get an unfair advantage because you don't need to switch between
page tables for its submissions.
That is avoided by remembering the submission as user of a VMID as soon
as it asks for it and not when the job is actually run. This way the
current submission will be guaranteed to get a chance with the MMU.
Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
