title: Vulkan compute shader invisible pixel writes
body: <p>I am playing around with a compute shader and have a weird behaviour I really cannot explain. I was wondering if you could help me figure it out.</p>
  
  <p>This is a suboptimal use of a compute shader, but I want to understand what is happening...</p>
  
  <p>I have a 64x64 texture and I want to write 4 horizontal pixels from a single invocation of my shader. Therefore I call <code>vkCmdDispatch( 64 / 4, 1, 1 );</code> with the following shader</p>
  
  <pre><code>#version 450
  
  layout (local_size_x = 1, local_size_y = 1) in;
  layout (binding = 0, rgba8) uniform writeonly image2D resultImage;
  
  void main()
  {
     const uint texPosX = gl_GlobalInvocationID.x * 4;
     const uint texPosY = gl_GlobalInvocationID.y;
  
     imageStore( resultImage, ivec2( texPosX + 0, texPosY ), vec4( 1.0f, 0.0f, 0.0f, 1.0f) );
     imageStore( resultImage, ivec2( texPosX + 1, texPosY ), vec4( 0.0f, 1.0f, 0.0f, 1.0f) );
     imageStore( resultImage, ivec2( texPosX + 2, texPosY ), vec4( 0.0f, 0.0f, 1.0f, 1.0f) );
     imageStore( resultImage, ivec2( texPosX + 3, texPosY ), vec4( 1.0f, 1.0f, 1.0f, 1.0f) );
  }
  </code></pre>
  
  <p>I would expect this to write 4 pixels (red green blue and white) in a single row. I would expect the final image to look like vertical lines with a pattern like { red, green, blue, white, red, green, blue, white, ...}</p>
  
  <p>What I get is instead vertical lines with a pattern of { red, green, blue, white, <strong>green, blue, white, red, blue, etc...</strong> } so it looks like there is a shift by one in the values.</p>
  
  <p>If I instead change the way I compute the texPosX to <code>const uint texPosX = gl_GlobalInvocationID.x * 5;</code> (writing <strong>5</strong> pixels instead of 4) I get the expected result. If I add a fifth write like so </p>
  
  <p><code>imageStore( resultImage, ivec2( texPosX + 4, texPosY ), vec4( 1.0f, 1.0f, 1.0f, 1.0f) ); // purple color at fifth pixel</code></p>
  
  <p>the result is exactly the same as previously, meaning the last write is "invisible". My image is really 64x64, but it seems the number of pixels each invocation is working on is 5, with the last one not being invisible... And as far as I know, 64 / 4 = 16 workgroups and 64 / 16 = 4 pixels per workgroup (since my local group size is 1).</p>
  
  <p>I am surely missing something that is obvious, but I have no clue to what it is. I thought I understood the global/local workgroup size, but it does not seem to be the case...</p>
  
  <p>Thanks a lot for your help !</p>