Forward Declaration of Scoped Variables (Uniform Buffer Objects)

[thokra]

Um, no. You can have multiple declarations in different translation units just fine. Both C++ and GLSL allow this. The problem is that his GLSL compiler/linker is broken and not doing what it's supposed to.

I am well aware of that. I shouldn't have used the term link in the first statement. I actually was thinking about what I clearly stated later, the merging of multiple source strings to form a single translation unit which is substantiated by the quote

If i use glShaderSource with multiple strings (from multiple files), the line-numbers of the error messages from the GLSL-Compiler are from the concatenation of all strings.

In that case there would be multiple declarations of the block. It is beyond me why the option of linking seperate objects isn't tested well enough since this has been around since 110 (judging from the API ref).

[Alfonse Reinheart]

If i use glShaderSource with multiple strings (from multiple files), the line-numbers of the error messages from the GLSL-Compiler are from the concatenation of all strings. If i compile the strings separately, i get a sepperate error handling and thus the line numbers start at zero for every string. => Just nicer to debug.

The NVIDIA driver (at the very least) gives line numbers and shader string indices. It looks something like this: `(X)YY`, where `X` is the shader string index and `YY` is the line number. I'm pretty sure the AMD driver does something similar.

Indeed, this is a required part of the GLSL specification:

Diagnostic messages returned from compiling a shader must identify both the line number within a string
and which source string the message applies to.

[Kastenfrosch2]

The NVIDIA driver (at the very least) gives line numbers and shader string indices.

Even with the latest nVidia drivers (296.10 and 301.32) i always get "0(XY)" where XY is the line of the concatenation, as you explained in Opengl.org - Multi-string-shaders-compiler-diagnostics-wrong.

So if the pro-way is using multiple strings in glShaderSource, then all the pros have to live with this bug?! too bad.

Or did i get something wrong?

Edit:
Just found the "#line" directive. That should be sufficiant as a workaround.
Thanks again for all answers.

[Alfonse Reinheart]

Someone should file a bug with NVIDIA then. Personally, I haven't needed to use multiple strings, so I assumed that it would actually work.

[thokra]

I think the problem goes further. Except for NVIDIA disregarding the GLSL spec in the above mentioned case the format of diagnostic messages varies across vendors. The differences are manageable but implementing 3 or more special cases (in my case Intel, AMD and NVIDIA) is tedious and there is no guarantee the format is forward compatible. Although this is a minor proposition it could be worthwhile standardizing a common reporting format. Any thoughts on that?

Someone should file a bug with NVIDIA then.

Incidentally, how do you generally submit bugs to NVIDIA? Via the dev forums? Via nvnews.net? Is there a bug tracker somewhere?

[Dark Photon]

Incidentally, how do you generally submit bugs to NVIDIA? Via the dev forums? Via nvnews.net? Is there a bug tracker somewhere?

In the past, I've used their bug form/tracking system on http://nvdeveloper.nvidia.com. Works pretty well, particularly if you include a small repro test program.

[Alfonse Reinheart]

Although this is a minor proposition it could be worthwhile standardizing a common reporting format. Any thoughts on that?

It wouldn't help. The standard already says that it should report the string number of the error. Standardizing it more won't make NVIDIA suddenly comply.

[thokra]

It wouldn't help. The standard already says that it should report the string number of the error. Standardizing it more won't make NVIDIA suddenly comply.

On the count of this particular problem this is probably true. However, just because they don't report the correct source string ID in their messages that doesn't mean they're not able to put out messages in a standardized formatted string. I can't fathom how sophisticated error reporting is inside GLSL compilers but at some point they're going to need to write a string somewhere. The general format of that string is what I'd like to see consistent across vendors, regardless of the fact that some information might be incorrect inside that string. As far as I can tell the spec doesn't say anything about that - just about what should go into a diagnostic message.

Something as simple as

source:line:severity(code):message

or

severity(code):source:line:message

(where message may include the symbol or operation in question. Something like 'initialize' in VS)

would do. Very easy to parse and understand and useful if you're writing tools which need to analyze diagnostic messages beyond printing them to stdout.