Re: github.com/go-gl/example/gl41core-cube/cube.go

[andrebolle]

Hi Go-gl team,

I found this line in the code

gl.BindFragDataLocation(program, 0, gl.Str("outputColor\x00"))

I don't know what is does, and I don't think I ever came across that function before. The documentation says:

glBindFragDataLocation — bind a user-defined varying out variable to a fragment shader color number.

Anyway, I though I'd comment it out, and see if it still runs. And it did!

Can anyone explain if that line should be there, and if so, what does it do?

Cheers,
Andre

[pwaller]

I think this might be this question on stack overflow: https://stackoverflow.com/questions/43281071/why-comment-glbindfragdatalocation-the-gl-also-works-correctly

Quote:

Because you're "lucky". The OpenGL specification provides no guarantees about how fragment shader output locations are assigned if you don't assign them. It only says that each one will have a separate location; what locations those are is up to the implementation.

However, considering the sheer volume of code that writes to a single output variable without explicitly assigning it to a location, it's highly unlikely that an OpenGL implementation would ever assign the first FS output location to anything other than 0. So while it isn't a spec guarantee, at this point, it is a de-facto requirement of implementations.

Note: That doesn't mean you shouldn't assign that location manually. It's always best to be on the safe and explicit side.

FYI: layout(location) works for fragment shader outputs too. So you should use that if you're using it on vertex attributes. Then you don't have to worry about doing it from code.

Closing since I'm uncertain there is an actual issue here, but feel free to reply if you discover more interesting things. Stack overflow may be a more appropriate venue for this kind of question in the future, this repository doesn't have many people looking at it (and my time is limited).