[Mesa-dev] i965: Uniform loading via samplers with discard

[Kenneth Graunke]

On Tuesday, June 24, 2014 08:17:23 AM Ian Romanick wrote:
> Send patches with git-send-email and no other method.  Save this message
> and apply it to origin/master using git-am to see why.
> 
> Hopefully Matt or Ken can review this...
> 
> On 06/12/2014 12:35 PM, Cody Northrop wrote:
> > Commit 17c7ead7 exposed a bug in how uniform loading happens in the
> > presence of discard.  It manifested itself in an application as randomly
> > incorrect pixels on the borders of conditional areas.
> > 
> > We believe it is due to how discards jump to the end of the shader
> > incorrectly for some channels.  The current implementation checks each
> > 2x2 subspan to preserve derivatives.  When uniform loading via samplers
> > was turned on, it uses a full execution mask, as stated in
> > lower_uniform_pull_constant_loads(), and only populates four channels of
> > the destination (see generate_uniform_pull_constant_load_gen7()).  We
> > think that is happening incorrectly when the first subspan has been
> > jumped over.
> > 
> > A possible fix is to only jump to the end of the shader if all relevant
> > channels are disabled, i.e. all 8 or 16, depending on dispatch.  This
> > preserves the original speedup noted in commit beafced2.  There are
> > other more heavyweight fixes (i.e. don't use sampler for uniforms if
> > discard in use), but this seems like a good fix.  I've appended it below
> > as a patch.  It changes the shader accordingly:
> > 
> > before    : 0x000000d0: (-f0.1.any4h) halt(8) 17 2     
> > null                            { align1 WE_all 1Q };
> > after(8)  : 0x000000d0: (-f0.1.any8h) halt(8) 17 2     
> > null                            { align1 WE_all 1Q };
> > after(16) : 0x00000250: (-f0.1.any16h) halt(16) 17 2   
> > null                            { align1 WE_all 1H };
> 
> All of this information should go in the commit message.
> 
> > I attached a test case to the bugzilla entry below.
> 
> Was the test also sent to the piglit mailing list for inclusion in the
> the test suite?

Hi Cody,

I noticed that the Piglit test is a hack to an existing SSO test - would it be 
possible to create a new Piglit test for this, and submit it to 
piglit at lists.freedesktop.org for inclusion upstream?  It'd be great to have a 
regression test in place so we don't break it in the future.

Also, it apparently tries to use GLSL 1.40 in a legacy GL 3.0 context, which 
Mesa doesn't support.  I had to hack Mesa to get it to run.

Thanks again,
--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140624/aba5d9e5/attachment.sig>