We have gone far off topic. The question is how we want __i915_wait_request() to handle a wedged GPU. It currently reports EIO, and my argument is that is wrong wrt to the semantics of the wait completion and that no caller actually cares about EIO from __i915_wait_request(). * Correction: one caller cares! If we regard a wedged GPU (and in the short term a reset is equally terminal to an outstanding request) then the GPU can no longer be accesing thta request and the wait can be safely completed. Imo it is correct to return 0 in all circumstances. (Reset pending needs to return -EAGAIN if we need to backoff, but for the lockless consumers we can just ignore the reset notification. That is set-domain, mmioflip, modesetting do not care if the request succeeded, just that it completed. Throttle() has an -EIO in its ABI for reporting a wedged GPU - this is used by X to detect when the GPU is unusable prior to use, e.g. when waking up, and also during its periodic flushes. Overlay reports -EIO when turning on and hanging the GPU. To be fair, it can equally report that failure the very next time it touches the ring. Execbuf itself doesn't rely on wait request reporting EIO, just that we report EIO prior to submitting work o a dead GPU/context. Execbuf uses wait_request via two paths, syncing to an old request on another ring and for flushing requests from the ringbuffer to make room for new commands. This is the tricky part, the only instance where we rely on aborting after waiting but before further operation - we won't even notice a dead GPU prior to starting a request and running out of space otherwise). Since it is the only instance, we can move the terminal detection of a dead GPU from the wait request into the ring_wait_for_space(). This is in keeping with the ethos that we do not report -EIO until we attempt to access the GPU. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
