Bug 107579

Created attachment 141106 [details]
a bit more description about "magic trash" in state buffer

Created attachment 141107 [details]
The graphical corruption example 1

Created attachment 141108 [details]
The graphical corruption example 2 (randmo dots on the screen)

At the begging of the investigation we found out the "MESA_GLSL_CACHE_DISABLE=1" option fixes this issue but later 
we found out that this option just helps to avoid the mandatory 
condition of this bug the "magic trash" in the "statebuffer" because 16KB default "program cache" was release too early when we used the disk shader cache.

Actually the 

>if(batch->state.map) { memset(batch->state.map, 0, STATE_SZ); }  

immediately after

>recreate_growing_buffer(brw, &batch->state, "statebuffer", STATE_SZ,
>                           BRW_MEMZONE_DYNAMIC);

helps to fix this problem but unfortunately it is not a root cause of the issue.

Created attachment 141111 [details]
The apitrace which cause to the graphical corruption

The following code could help us to show state buffer before send (last 3 byte could be missing but i think they is do not matter):

--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -750,6 +750,19 @@ submit_batch(struct brw_context *brw, int in_fence_fd, int *out_fence_fd)
       memcpy(bo_map, batch->state.map, batch->state_used);
    }
 
+      fprintf(stderr, "=================================================\n");
+      if(batch->state.map)
+      {
+        uint32_t * data = (uint32_t *)batch->state.map;
+        const size_t s = batch->state_used / 4;
+        for(size_t i = 0u; i < s; ++i)
+        {
+           fprintf(stderr, "0x%08x : 0x%08x\n", (uint32_t)(i*4), data[i]);
+        }
+      }
+      fprintf(stderr, "=================================================\n");
+
+
    brw_bo_unmap(batch->batch.bo);
    brw_bo_unmap(batch->state.bo);

Created attachment 141137 [details]
simple program and makefile

Added simple reproducer program

Note: I was a bit wrong the magic value 0xFFFFFFFF is enough for HANG only for the graphical corruption we need the following values:

((uint32_t*)vbuffer0Ptr)[0] =  0x2003625aU;
((uint32_t*)vbuffer0Ptr)[1] =  0x02040110U;
((uint32_t*)vbuffer0Ptr)[2] =  0x2027625aU;
((uint32_t*)vbuffer0Ptr)[3] =  0x02040210U;

They are used in the following function:
>bool allocBufferWithMagicTrash(GLuint idx)
>{
>   bool oval = false;
>   enum { kSize = 16384 };
>   glBindBuffer(GL_ARRAY_BUFFER, idx);
>   glBufferData(GL_ARRAY_BUFFER, kSize, NULL, GL_STATIC_DRAW);
>   void * vbuffer0Ptr = glMapBuffer(GL_ARRAY_BUFFER, GL_READ_WRITE);
>   assert(vbuffer0Ptr);
>   if(vbuffer0Ptr)
>   {
>      memset(vbuffer0Ptr, 0xFF, kSize);
>      ((uint32_t*)vbuffer0Ptr)[0] =  0x2003625aU;
>      ((uint32_t*)vbuffer0Ptr)[1] =  0x02040110U;
>      ((uint32_t*)vbuffer0Ptr)[2] =  0x2027625aU;
>      ((uint32_t*)vbuffer0Ptr)[3] =  0x02040210U;
>      glUnmapBuffer(GL_ARRAY_BUFFER);
>      glBindBuffer(GL_ARRAY_BUFFER, 0);
>   }
>   return oval;
>}

This issue should be fixed by commit:

1b0df8a46020cc88afeaa4decb42a782ab168afb

i965/gen6/xfb: handle case where transform feedback is not active