GLSL Compute Shader have a bug with loop operation

first of all, sorry about my short English.

i found a unexpected situation when using “for” loop increment term with decreasing.
this situation could reproduce with code like below.

#version 430
#extension GL_ARB_compute_shader : enable
#extension GL_ARB_shader_storage_buffer_object : enable

layout( std430, binding=4) buffer offsetRaw{int oData[];};

layout (local_size_x = 1, local_size_y = 1, local_size_z = 1) in;

void main(void)
	for(int loop = 8; loop>0; loop-=2)
		oData[loop+gl_LocalInvocationIndex  ]=loop  ;


the index value “gl_LocalInvocationIndex” is zero because the shader is dispatched by single invocation and single group.
so we can predict a result easily.
but result is not matched.

oData[1] = 1 oData[1]=0
oData[2] = 2 oData[2]=0
oData[3] = 3 oData[3]=3
oData[4] = 4 oData[4]=4
oData[5] = 5 oData[5]=5
oData[6] = 6 oData[6]=6
oData[7] = 7 oData[7]=7
oData[8] = 8 oData[8]=8

is this a bug? or my mistake?
if it is a bug, what should i doing for resolve it?

First of all, for the record, is indexing of oData You written in Your post correct? You know that indexing starts from 0 in most of the C-derived languages?

Second question - I can’t deduce the size of oData buffer? Or is it set up in host code?


  1. the value of predicted and result oData at index [0] is 0 respectively, just it was omitted. and indexing rule of c-language is common sense. :)

  2. the size of shader storage buffer is initialize in host side. in this case, it was allocated 1024 bytes and set by zero before the compute shader dispatched.

the link of below is a captured screen of IDE. it could be helpful, if you want to check a result.

and the link of below is indexing with increasing case.