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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
