Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > We observe that the ordering of writes for a CS event is not as strong > from the GPU as we would like, and that on occasions we see the > ringbuffer tail updated before the event is written into the ringbuffer, > leading us to reuse the stale data. > > Through around a big hammer to try and batter ELSQ into submission with > the presumption that perhaps the UC mmio write is not flushing our > writes into the context images. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=108315 > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > --- > drivers/gpu/drm/i915/intel_lrc.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c > index 22b57b8926fc..ba61849fbb9b 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -454,8 +454,10 @@ static void execlists_submit_ports(struct intel_engine_cs *engine) > } > > /* we need to manually load the submit queue */ > - if (execlists->ctrl_reg) > + if (execlists->ctrl_reg) { > + wmb(); /* XXX Big hammer or paper? XXX */ > writel(EL_CTRL_LOAD, execlists->ctrl_reg); Will be difficult to know if it is the additional delay or not. The question is then why would it only be with ctrl_reg and not legacy submission mode. So lets try with legacy mode? -Mika > + } > > execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK); > } > -- > 2.19.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
