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

Xiang, Haihao
2013-12-09T04:46:14Z

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.

>