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

Paul Berry stereotype441 at gmail.com
Wed Oct 30 05:29:20 CET 2013

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:

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

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>

More information about the mesa-dev mailing list