[Mesa-dev] [PATCH 0/4] i965: skip control-flow aware liveness analysis if we only have 1 block

Iago Toral itoral at igalia.com
Fri Oct 16 05:10:39 PDT 2015


On Wed, 2015-10-14 at 21:40 +0300, Francisco Jerez wrote:
> Jordan Justen <jordan.l.justen at intel.com> writes:
> 
> > On 2015-10-13 22:49:08, Iago Toral wrote:
> >> On Tue, 2015-10-13 at 09:44 -0700, Jordan Justen wrote:
> >> > On 2015-10-13 05:17:37, Francisco Jerez wrote:
> >> > > Iago Toral Quiroga <itoral at igalia.com> writes:
> >> > > 
> >> > > > This fixes the following test:
> >> > > >
> >> > > > [require]
> >> > > > GL >= 3.3
> >> > > > GLSL >= 3.30
> >> > > > GL_ARB_shader_storage_buffer_object
> >> > > >
> >> > > > [fragment shader]
> >> > > > #version 330
> >> > > > #extension GL_ARB_shader_storage_buffer_object: require
> >> > > >
> >> > > > buffer SSBO {
> >> > > >     mat4 sm4;
> >> > > > };
> >> > > >
> >> > > >
> >> > > > mat4 um4;
> >> > > >
> >> > > > void main() {
> >> > > >     sm4 *= um4;
> >> > > 
> >> > > This is using the value of "um4", which is never assigned, so liveness
> >> > > analysis will correctly extend its live interval up to the start of the
> >> > > block.
> >> > 
> >> > This test was derived by simplifying a CTS test case.
> >> > 
> >> > Anyway, I'm not sure what happened on the way to the commit message,
> >> > but um4 should be a uniform.
> >> > 
> >> > http://sprunge.us/cEUe
> >> 
> >> Oh yes, that was me playing around with the example. The patches also
> >> fix the uniform version. Jordan, can you verify if this fixes the CTS
> >> test case?
> >
> > Unfortunately, no. The CTS case has some control flow. I had removed
> > it to minimize the test case.
> >
> > Here is a small shader_test that has control flow and still fails to
> > compile with your patches:
> >
> > http://sprunge.us/LIjA
> >
> >> In any case, since Curro is working on a more general fix for this
> >> stuff, I guess you'd rather wait for his patches...
> >
> > It depends how long we'd have to wait. :) Anyway, since we don't have
> > a short-term fix anyhow, let's wait to see what curro has to say.
> >
> Assuming that at least some of the scalar writes in the shader are being
> introduced by emit_uniformize(), an alternative hack that might get the
> shader to compile for the moment would be to change emit_uniformize() to
> emit a full SIMD-width BROADCAST instruction instead of a scalar one
> (see attachment) -- Which is pretty useless in principle because only
> the first component will ever be used but it might keep dataflow
> analysis from getting confused.

BTW, having a look at dEQP SSBO tests, I see that many of them use CS
and a huge amount of these hit this problem, we are talking close to 700
tests (there are about 2000 SSBO tests in total). It seems that CS
programs hit this problem a lot and this patch that you attached seems
to get all these tests to compile just fine.

Iago



More information about the mesa-dev mailing list