Re: [PATCH] drm/i915/guc: Disable preemption if it fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 31, 2018 at 10:20:54PM +0100, Chris Wilson wrote:
> Quoting Singh, Satyeshwar (2018-05-31 22:17:25)
> > Hi Chris,
> > Isn't this dependent upon the workload submitted to the GuC? Meaning we have one workload that refused to be preempted (really long shader for example) but it went away on its own. Other workloads that come in later are preemptible. However, if we turn off preemption permanently, then all future workloads will not be preempted either which may not be desirable.
> 
> Whoever implements the recovery mechanism can clear the flag. You may
> like to clear the flag on reset? We would have to be more careful about
> the manipulation of engine->flags as it's not serialised atm (since it's
> _meant_ to be write-once during init).
> -Chris

The error that would occur here is a failure of GuC to *initiate* the
preemption, and is different from a slow resolution of the preemption on
hardware caused by the workload blocking scenario that Satyeshwar
describes. GuC will wait forever for preemption resolution, as will i915
currently without a timeout mechanism. A failure of GuC to initiate a
preemption would be a very strange and bad thing and probably would
warrant a WARN and disabling. Is anyone actually seeing that with current
firmware? I have not in my own testing. Is it an actual error returned
from GuC or a timeout waiting for GuC response?
-Jeff
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux