Bug 98840

This is really Tim's bug.  The problem occurred when he moved us to using nir_gather_info.  When we start off, the nir_shader::info field points to gl_program::info.  However, when the shader gets cloned, we ralloc a copy of the shader_info and copy the data into that and nir_shader::info no longer points to gl_program::info but points to a copy of the shader_info.  With NIR_TEST_CLONE=1, nir_shader_gather_info gets run after some cloning has been done and so the copied shader_info is what gets filled out and gl_program::info gets left alone.  One hack solution is to just do "prog->info = *nir->info" after we run nir_shader_gather_info, but I don't think this is a long-term solution.

After going around in circles a bit, I think the answer is probably to make nir_shader::info an embedded struct again and not a pointer.  Now that we use the same shader_info struct in gl_program as we do in nir_shader, we can easily pre-populate the one in nir_shader and, after we're done with our early NIR optimization and we've run nir_shader_gather_info, we copy it back.

(In reply to Jason Ekstrand from comment #1)
> This is really Tim's bug.  The problem occurred when he moved us to using
> nir_gather_info.  When we start off, the nir_shader::info field points to
> gl_program::info.  However, when the shader gets cloned, we ralloc a copy of
> the shader_info and copy the data into that and nir_shader::info no longer
> points to gl_program::info but points to a copy of the shader_info.  With
> NIR_TEST_CLONE=1, nir_shader_gather_info gets run after some cloning has
> been done and so the copied shader_info is what gets filled out and
> gl_program::info gets left alone.  One hack solution is to just do
> "prog->info = *nir->info" after we run nir_shader_gather_info, but I don't
> think this is a long-term solution.
> 
> After going around in circles a bit, I think the answer is probably to make
> nir_shader::info an embedded struct again and not a pointer.  Now that we
> use the same shader_info struct in gl_program as we do in nir_shader, we can
> easily pre-populate the one in nir_shader and, after we're done with our
> early NIR optimization and we've run nir_shader_gather_info, we copy it back.

Wouldn't that just mean we would end up with:

"prog->info = nir->info"

rather than

"prog->info = *nir->info"

How is that any better?

I'll need to take a look at what NIR_TEST_CLONE=true is meant to do this is the first time I've heard of it.

Should be fixed by:

commit f562b13bc7d0b4fd954d285a9325e94167b16bf5
Author: Timothy Arceri <timothy.arceri@collabora.com>
Date:   Thu Dec 1 13:37:38 2016 +1100

    i965: keep gl_program shader info in sync after gather info
    
    It's possible that nir_shader was cloned and it no longer contains
    a pointer to the shader_info in gl_program. So we need to copy
    shader_info back to gl_program if that is the case.
    
    Fixes a regression with NIR_TEST_CLONE=true
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98840

Tim's patch fixed most of the errors, but we still have some failures:

    piglit.spec.glsl-1_10.execution.vs-nested-return-sibling-loop
    piglit.spec.glsl-1_10.execution.vs-nested-return-sibling-loop2

/tmp/build_root/m64/lib/piglit/bin/shader_runner /tmp/build_root/m64/lib/piglit/tests/spec/glsl-1.10/execution/vs-nested-return-sibling-loop.shader_test -auto
Probe color at (0,0)
  Expected: 255 255 0 255
  Observed: 0 255 0 255
Test failure on line 46

This may be some other NIR_TEST_CLONE regression in mesa since the one that Timothy fixed.  The test target has not been functional in the intervening weeks, so Timothy's fix will need to be rebased back in the history for a bisection.

My mistake:  these tests were recently added to piglit and fails on master.