Re: [Intel gfx][i-g-t PATCH 3/4] rendercopy/bdw: A workaround for 3D pipeline

["Xiang, Haihao" <haihao.xiang@intel.com>]

On Fri, 2013-12-06 at 13:30 +0000, Damien Lespiau wrote: 
> On Fri, Dec 06, 2013 at 04:54:46PM +0800, Xiang, Haihao wrote:
> > From: "Xiang, Haihao" <haihao.xiang@intel.com>
> > 
> > Emit PIPELINE_SELECT twice and make sure the commands in
> > the first batch buffer have been done.
> > 
> > However I don't know why this works !!!
> 
> Hum :) on one hand, it's great that you found this w/a, on the other
> hand, I'm not comfortable with not understanding why this works.

Thanks for the comments, actually I am not comfortable with it too.
gem_render_copy passed after I happened to run gem_media_fill first, so
I am curious which setting in gem_media_fill impact the result. Finally
I found it works if I emit PIPELINE_SELECT in a separated batch first. 

> So far
> what we know (I don't have Silicon that can't test anything):
> 
>  - Ken was saying that mesa doesn't need this.
>  - There are a bunch of W/A around FF units clock gating, might worth
>    checking that we're not hiting WaDisableFfDopClockGating or one of
>    those 3D Vs GPGPU pipelines ones.
>    This could happen to you but not to Ken because you have been
>    switching between 3D and media pipeline with the 2 igt tests.
>  - In any case, doing a pass on the W/A sounds like a good idea
>  - I'd be interested to know if there a even more minimal batch that
>    works (say an empty batch), or if the active ingredient is the
>    pipeline switch.

Oh, it works even with an batch which has only MI_BATCH_BUFFER_END.

> 
> If people want to push the patch to make progress on other parts, I
> guess that's fine, but we'll need to dig deeper here.

Agree, we should look into the issue to find the real root cause.

>