On Tue, Jun 24, 2014 at 10:29 AM, Kenneth Graunke <kenn...@whitecape.org>
wrote:
> 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
> pig...@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.
>
Yes, I'll create a different test and submit it for inclusion.
>
> 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.
>
>
I just rebased the changes to latest mesa/piglit/waffle masters and the
test runs fine. :\ Anyway, I agree it has a couple problems and I'll
avoid them in the new version.
Thanks again,
> --Ken
--
Cody Northrop
Graphics Software Engineer
LunarG, Inc.- 3D Driver Innovations
Email: c...@lunarg.com
Website: http://www.lunarg.com
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
