Re: [RFC/CI] drm/i915/icl: account for context save/restore removed bits

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

 



Quoting Paulo Zanoni (2018-08-10 00:58:52)
> The RS_CTX_ENABLE and CTX_SAVE_INHIBIT bits are not present on ICL
> anymore, but we still try to set them and then check them with
> GEM_BUG_ON, resulting in a BUG() call. The bug can be reproduced by
> igt/drv_selftest/live_hangcheck/others-priority and our CI was able
> to catch it. The machine hangs, which prevents further testing on it.

Non-sequitur. Capture the bug report, move on after the panic. How does
that prevent testing? What you might note is that CI's pstore is
reporting -EIO, that is what has prevented remote debugging of this.
 
> It is worth noticing that commit 05f0addd9b10 ("drm/i915/icl: Enhanced
> execution list support") already tried to avoid the save/restore bits
> on ICL, but only inside populate_lr_context().
> 
> TODO: Should we also avoid CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT on ICL
> for execlists_init_reg_state()? We already avoid it inside
> populate_lr_context().

RESTORE_INHIBIT is still very much required. It's just the SAVE_INHIBIT
that they removed for whimsy.
 
> TODO: Shouldn't a new problem surface when we remove these registers?
> What should we do to replace the functionality that was provided by
> them?

Shed a tear. Resource Streamer doesn't exist and would require userspace
support for it anyway. The SAVE_INHIBIT is the one that shaves a few
cycles on preemption, but is supposed to be replaced by a bit in ELSQ at
the expense of forking process_csb/preemption. No one has demonstrated
that the cost would be worth it.
-Chris
_______________________________________________
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