Quality of Implementation: Debug shader variable locations

[thokra]

Not how fast it outputs messages. If there is a problem in the execution, it would cause slow execution in any case.

The thing is, ouputting messages is costly as hell. And being able to have the GL report stuff on its own without querying with glGetError() is the crux and the real benefit of ARB/KHR debug. Error checks take place anyway because they have to be done - all the time - so it’s no wonder that stuff doesn’t seem to impact performance if everything is fine and nothing is actually reported. But what about undefined behavior? Performance hints? Those aren’t pieces of information an implementation would gather and report if it disabled ARB/KHR debug in non-debug contexts - at least I wouldn’t implement it this way. And this is exactly where the lack of knowledge about the degree of actually implemented checks and hints for a specific GL implementation comes into play - and I’m pretty sure, AMD, Intel and NVIDIA differ substantially in this department. If the driver does only error reporting and no errors are currently present, why should it perform noticably worse?

Also, you probaly neglect the overhead introduced by using debug groups, labels and inserted messages which will produce output and thus reduce performance - all of the stuff you might not see in your specific test case and would probably have no bearing in a non-debug context.

What I’d like to see is for vendors to actually tell us what we can expect from their implementation when using ARB/KHR debug. But I guess we’ll be on our own there …

[kRogue]

I like Alfonse’s suggestion, the idea that the uniform locations that are not explicitly assigned are slightly randomized is a very, very good idea. Also, along the same line, having vertex attributes that are not explicitly assigned having randomized index would be nice too .

I have not been bitten by the uniform, but by vertex attribute I have… mostly because the vast majority of implementation give the index in order of declare, so the bug can be hiding for a long, long time.

I suggest we move this topic, or repost it to suggestions for next version of GL.

[Aleksandar]

@kRogue;1251054

I like Alfonse’s suggestion, the idea that the uniform locations that are not explicitly assigned are slightly randomized is a very, very good idea. Also, along the same line, having vertex attributes that are not explicitly assigned having randomized index would be nice too .

Well, explicit attribute/uniform locations are one vote more against the proposal.

If implementation uses explicit locations, then no randomization is possible. Second, explicit locations are introduced exactly to help applications assume the location values in the shaders (exactly what you want to prevent).

@kRogue;1251054

I have not been bitten by the uniform, but by vertex attribute I have… mostly because the vast majority of implementation give the index in order of declare, so the bug can be hiding for a long, long time.

It depends. I remember (since I’m currently not using that) NV assigned subroutine IDs in the opposite order they are declared (probably because they put them on the stack). So, you know (from the experience, not from the specification) how some implementation is working, you are (mis)using that, and then you are complaining that it makes hidden errors.

@kRogue;1251054

I suggest we move this topic, or repost it to suggestions for next version of GL.

I disagree. Not because this is worthless, but because it is superfluous and there are lots of more important aspects of the implementation that have to be fixed.

[Alfonse_Reinheart]

I suggest we move this topic, or repost it to suggestions for next version of GL.

No, we shouldn’t. The reason I titled this post “Quality of Implementation” is that this is exactly waht this suggestion is: a matter of the quality of an implementation. Good implementations would implement this; less good implementations would not.

How exactly would you specify this behavior anyway? The spec already says that the values you get for non-explicit uniform locations are implementation-defined. How do you decide that it’s “random”? Can it be “random, but only if you create a new context”, such that the implementation can pick a random number at the start and bias all uniform locations by that number? Does it have to be random for every glLinkProgram? How much “randomness” does it have to have?

And most important of all… how would you test randomness?

This isn’t something that can be standardized. It’s a quality of implementation issue; a good debug context will help catch errors like this.

If implementation uses explicit locations, then no randomization is possible.

Nonsense. Simply allocate the first 1024 locations for explicit locations, and the rest are randomized for non-explicit.

Second, explicit locations are introduced exactly to help applications assume the location values in the shaders (exactly what you want to prevent).

Sure, and when you go back in time and force explicit uniform locations into the standard since ARB_shader_objects and remove non-explicit locations, then it won’t have been necessary. But so long as code exists where explicit uniform locations are not used (and, this can happen by accident, since it’s not a compiler error to forget the layout(location)), this will be useful.

So, you know (from the experience, not from the specification) how some implementation is working, you are (mis)using that, and then you are complaining that it makes hidden errors.

Yes, and since this was completely accidental on his part (due to forgetting the query), he was unable to find the bug until much later. Welcome to the point of the thread; glad you could make it.

We’re not talking about someone who was deliberately using it, but who was accidentally using it.

[kRogue]

How exactly would you specify this behavior anyway? The spec already says that the values you get for non-explicit uniform locations are implementation-defined. How do you decide that it’s “random”? Can it be “random, but only if you create a new context”, such that the implementation can pick a random number at the start and bias all uniform locations by that number? Does it have to be random for every glLinkProgram? How much “randomness” does it have to have?

And most important of all… how would you test randomness?

I’d make it a hint, so nothing actually really testable Though, suggesting to GL implementor’s to add that to their debug contexts is fine too, but I think this idea will get lost here.

As for my situation on the bug, I had the GLSL program working on multiple different hardware platforms, including embedded, before the bug manifested that I forgot to bind the attribute location. Now I am paranoid and have in what when I make a GLSL program, I emit a warning whenever an attribute location is not forced but found in the attribute list.