On Thu, Apr 14, 2016 at 05:29:31PM +0300, Ville Syrjälä wrote: > On Mon, Apr 11, 2016 at 10:06:28AM +0100, Chris Wilson wrote: > > On Mon, Apr 11, 2016 at 11:34:54AM +0300, Ville Syrjälä wrote: > > > On Sat, Apr 09, 2016 at 11:14:44AM +0100, Chris Wilson wrote: > > > > In order for the MI_SEMAPHORE_SIGNAL command to wait until after the > > > > pipecontrol writing the signal value is complete, we have to pause the > > > > CS inside the PIPE_CONTROL with the CS_STALL bit. > > > > > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > --- > > > > drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +-- > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c > > > > index 556924ee47f9..62d09cf2ea8f 100644 > > > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > > > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > > > > @@ -1301,7 +1301,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request *signaller_req, > > > > intel_ring_emit(signaller, GFX_OP_PIPE_CONTROL(6)); > > > > intel_ring_emit(signaller, PIPE_CONTROL_GLOBAL_GTT_IVB | > > > > PIPE_CONTROL_QW_WRITE | > > > > - PIPE_CONTROL_FLUSH_ENABLE); > > > > + PIPE_CONTROL_CS_STALL); > > > > > > Doesn't this just stall when parsing the pipe control? Shouldn't > > > we intead make sure the post-sync write is issued before the semaphore > > > is signalled? (pipe_control /w post-sync write + second pipe control w/ > > > flush enable?) > > > > No, afaik and can determine experimentally. The stall is after the > > post-sync write. The pipe-control dosn't emit the write until it has > > done the flush/invalidate and will not complete until the write is > > commited (in theory, until it is coherent). The CS stall prevents the > > command parser advancing until the pipecontrol is finished. > > OK, so I did a quick experiemnt here doing something like: > > for i=0-128: > pipe_control w/ qw write data=0xdead0000+i offset=(i%8)*8 > for i=0-8: > pipe_control w/ qw write data=i offset=(i%8)*8 > mi_lrm reg=0x2310+(i%8)*4 offset=(i%8)*8 > > and then check the regs afterwards. > > If I use CS stall in the second pipe control, it does seem to wait for > the post-sync operation initiated by itself. So seems you are right > about that. So the register values I saw were: > (0x00002310): 0x00000001 > (0x00002314): 0x00000002 > (0x00002318): 0x00000003 > (0x0000231c): 0x00000004 > (0x00002320): 0x00000005 > (0x00002324): 0x00000006 > (0x00002328): 0x00000007 > (0x0000232c): 0x00000008 Oh and based on that I guess I can say Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > I also noticed something about the "pipe control flush" (bit 7). It > only really seems to wait for already initiated post-sync operations. > If the pipe control that is going to initiate the post-sync op itself > is still in the pipeline, bit 7 won't actually wait for it. Or at > least that's how I would interpret these results: > > bit 7 == 0: > (0x00002310): 0xdead0058 > (0x00002314): 0xdead0059 > (0x00002318): 0xdead0062 > (0x0000231c): 0xdead0063 > (0x00002320): 0xdead006c > (0x00002324): 0xdead006d > (0x00002328): 0xdead006e > (0x0000232c): 0xdead0077 > > bit 7 == 1: > (0x00002310): 0xdead0078 > (0x00002314): 0xdead0079 > (0x00002318): 0xdead007a > (0x0000231c): 0xdead007b > (0x00002320): 0xdead007c > (0x00002324): 0xdead007d > (0x00002328): 0xdead007e > (0x0000232c): 0xdead007f > > So even with bit 7 == 1 I didn't see the value the previous pipe control > would write. > > So not sure what good that bit really is then since you always need a > CS stall to make sure that previous pipe controls have reached the end > of the pipe, and CS stall anyway seems to wait for the post-sync > operations, so adding bit 7 to the mix seems redundant. > > -- > Ville Syrjälä > Intel OTC > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
