glBindFragDataLocation: GL errors when passing a name not contained in shader source

OpenGL
1

Hello,

void glBindFragDataLocation(GLuint program, GLuint colorNumber, const char * name);

https://www.opengl.org/sdk/docs/man3/xhtml/glBindFragDataLocation.xml

According to this page:

any name may be specified in name, including a name that is never used as a varying out variable in any fragment shader object.

But on AMD Radeon HD 5850 it will trigger a GL error when passing a name not contained in the fragment shader source code.
For example when calling

glBindFragDataLocation(handle, 0, string(“f_Color”).c_str());
glBindFragDataLocation(handle, 1, string(“f_Color1”).c_str());

for a program which actually only writes to one render target (f_Color).

Is this a driver bug? Or is my understanding wrong.

Basically this means that you cannot setup a constant range of (default) f_ColorN, you really need to know how many of them are used in the shader. I have no problem with that, just wondering if that is a bug.

Thanks!

Treiber-Paketversion 14.501.1003-141120a-178000C
Catalyst-Version 14.12 AMD Catalyst Omega Software
Anbieter Advanced Micro Devices, Inc.
2D-Treiberversion 8.01.01.1443
OpenGL-Version 6.14.10.13283
AMD Catalyst Control Center-Version 2014.1120.2123.38423

2

Ah wait, maybe I already found the problem. Seems that I just exceeded the maximum number of render targets.

3

https://www.opengl.org/sdk/docs/man3...taLocation.xml

It should also be noted that the man3 pages are not being updated anymore and may contain errors that will never be fixed (yet the inaccurate information is left online for no good reason). You need to look at the real documentation.

4

We’ve discussed getting rid of the GL2/GL3 ref page sets in light of this comment. The Version Support tables in the current ref pages serve most of the same function of identifying what functionality was implemented in what version (mostly better, since they’re actually version-specific, not just 2.x/3.x/4.x-specific). But at the moment we’re holding back because the current ref pages are core profile only. Getting the compatibility profile information out of the older ref page sets and updating it is a project nobody in Khronos has time for, with Vulkan ramping up.

5

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.