Re: [PATCH] drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

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

 



On Fri, Jan 26, 2018 at 08:23:13AM +0000, Chris Wilson wrote:
> Quoting Rafael Antognolli (2018-01-26 01:26:34)
> > Write a PIPE_CONTROL with CS stall followed by 14 dwords of 0 in the
> > indirect context wa bb.
> 
> 14 MI_NOOPS following? That isn't what you wrote in the code, but the

Agreed, sorry. The workarounds says:

0x7a000004 0x00100000 + 14 dwords of 0. I counted 6 dwords from
gen8_emit_pipe_control() and figured "just 8 more to 14". I think I had
it right on my first version of this patch, but...

> main thing you haven't explained is why. A normal batch will already
> have a flush in its setup, but more to the point would be the only
> reason this is required is because of an implicit 3DSTATE inside the
> context image on preemption. Right? Otherwise it seems to be a purely
> userspace problem.

This is the text from the workaround:

"This bug can be hit on a context restore.  To avoid the issue the
following must be programmed by SW to ensure the engine is idle prior to
programming 3DSTATE_SAMPLE_PATTERN:

With RS context enabled: 0x21c8 = 0x000085c0

With RS context disabled:0x21c8 = 0x00001ac0

The above program specifes the offset to insert driver programmed
commands

0x21c4[31:6] = 0x<Addresses>

0x21c4[5:0] = 0x<N>

N=Size of CL needed to fit Workaround

The above programming is the GGTT address of the driver programmed
commands and the size(# of CL) to execute.

The address above needs to be a GGTT address and contain a pipe control
with CS stall(0x7a000004 0x00100000 0x00000000 0x00000000)followed by
12DW’s of NOOP(0x00000000)"

Since it needs to be in a GGTT address, and it's specifically talking
about the Indirect Context Pointer, we figured it should be in the
kernel. I can update the commit message with the above text if it helps.

I originally implemented this trying to fix my GPU hang, but it turns
out the issue was something else and this commit doesn't help at all.
Still, I see no reason to not have it there just in case it prevent any
future hangs...

Rafael
_______________________________________________
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