[Mesa-dev] [PATCH V2 11/12] i965/gen7: Enable the features required for GL_ARB_sample_shading

[Paul Berry]

On 29 October 2013 21:28, Paul Berry <stereotype441 at gmail.com> wrote:

> On 29 October 2013 17:16, Anuj Phogat <anuj.phogat at gmail.com> wrote:
>
>>
>>
>>
>> On Tue, Oct 29, 2013 at 4:31 PM, Paul Berry <stereotype441 at gmail.com>wrote:
>>
>>
>>> I think the right thing to do is to add:
>>>
>>> if (dispatch_width == 16)
>>>     fail("...");
>>>
>>> to whatever parts of the visitor you aren't confident will work properly
>>> in SIMD16.
>>>
>> Yes. But that only covers the per sample shading enabled due to
>> gl_SampleID and gl_SamplePosition.
>>
>> It still doesn't cover the case when there's no  gl_SampleID or
>>  gl_SamplePosition in fragment shader but GL_SAMPLE_SHADING is enabled.
>> To disable simd16 for this case I either need to keep the relevant
>> changes I made in gen7_wm_state.c
>> or
>> may be set  simd16_instructions = null in brw_wm_fs_emit() when
>> GL_SAMPLE_SHADING is enabled. It should also be safe to
>> call _mesa_get_min_invocations_per_fragment() in brw_wm_fs_emit(). So, we
>> can take care of all the cases of sample shading enabled at the same place?
>>
>
> Oh, I didn't realize that you were getting hangs with SIMD16 mode even
> when neither gl_SampleID nor gl_SamplePosition is used.
>
> A large part of the reason I had suggested putting calls to fail() in
> brw_fs_visitor was because I thought the hangs were due to improper code
> generation.  Since you're getting hangs just by using GL_SAMPLE_SHADING,
> the cause mustn't be improper code generation, so my idea of failing out of
> SIMD16 compilation doesn't make sense anymore.  Based on this information I
> guess I'm ok with the patch as originally written.
>


BTW, on the off chance that it helps you get unstuck with your SIMD16
hangs, have you noticed that you have to change KSP[0] (kernel start
pointer 0) in order to get "SIMD16 only" mode to work?  Currently we always
emit 3DSTATE_PS like this:

   BEGIN_BATCH(8);
   OUT_BATCH(_3DSTATE_PS << 16 | (8 - 2));
   OUT_BATCH(brw->wm.base.prog_offset); /* KSP[0] */
   OUT_BATCH(dw2);
   OUT_BATCH(dw3);
   OUT_BATCH(dw4);
   OUT_BATCH(dw5);
   OUT_BATCH(0); /* KSP[1] */
   OUT_BATCH(brw->wm.base.prog_offset + brw->wm.prog_data->prog_offset_16);
/* KSP[2] */
   ADVANCE_BATCH();

That's always worked in the past because (see Graphics BSpec:
3D-Media-GPGPU Engine > 3D Pipeline Stages > Pixel > Pixel Shader Thread
Generation > Pixel Grouping (Dispatch Size) Control):
- In "SIMD8 only" mode, KSP[0] is the SIMD8 program, and KSP[1] and KSP[2]
are ignored.
- In "SIMD8+SIMD16" mode, KSP[0] is the SIMD8 program, KSP[1] is ignored,
and KSP[2] is the SIMD16 program.

However, in "SIMD16 only" mode, KSP[0] needs to be the SIMD16 program.

(my apologies if you've already accounted for this--it just seems like a
likely explanation for "SIMD16 only" GPU hangs)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131029/98b2237f/attachment.html>