Do note that I haven’t tried rendering to integer framebuffers before, so I could be wrong. You could use apitrace to inspect the OpenGL state and verify your findings.
Yes, the GLSL specification. Quoting from the 1.30 spec:
Your shader compiler may happen to be lenient enough to allow it (NVIDIA’s compiler, in particular, is extremely lenient). It may fail to compile under a different driver.
Indeed, if I use the Khronos reference compiler, I do get an error:
$ glslangValidator glsl.frag
glsl.frag
ERROR: 0:3: 'gl_FragColor' : identifiers starting with "gl_" are reserved
ERROR: 1 compilation errors. No code generated.Please note that T_int is the ComponentType. It indicates how the data is stored in memory, not what type of values the texture produces when sampled.
The F_r32i format is what indicates that it’s sampled as an integer format, as opposed to F_r32 in combination with T_int, which would be signed normalised floating-point data, according to the OpenGL rules.
Well, you could just go for a normalised format and divide by 255 (or 2**32-1 if you choose F_r32) when writing the output. That would yield the same result in the texture data. You would have to use a regular sampler to read the values again, of course. There are the GLSL packing functions for packing an integer into a floating-point channel, but that seems irrelevant to your example.