OK, for the moment, let's ignore the possibility of explicit uniform location and assume that the compiler has carte blanc to assign uniform locations as it sees fit.This doesn't make sense. Uniform locations are assigned at link time, so this is a link-time-only issue. There are no performance implications at run-time from it.
The compiler has to transform a location from a number to a byte offset in order to actually do anything useful with it (remember: uniform indices are how you query information; uniform locations are only used to set the state). Therefore, the linked program must have a table that maps from location to a byte offset.
The fastest way to implement this table is with an array, where the locations are simply the indices into that array, and the values are the byte offsets. Now, it's slightly more complex than that, since a location can represent multiple byte offsets (the same uniform in different shader stages), but that's the general idea.
If you now randomly assign a location, such that the entire 31-bit space of positive numbers could be any active uniform location, you can't use an array. You must now have hash table. And while hash tables are quite fast, they're not as fast as an actual array. At the very least, you must apply your hash function. Even if your "hash function" is nothing more than "subtract by a global integer", that will be slower than not subtracting by a global integer.
There is no way to implement random locations that is slower than the fastest possible implementation of purely arbitrary locations.
Now, you could randomly select the location within the bounds of the array of possible locations. But that won't break things properly. You don't want the user to be setting the wrong uniform; you want them to get no uniform at all. Because that's a proper OpenGL error which you will report and they will catch. Them merely setting the wrong uniform may cause weirdness, but it won't be clear exactly where it's coming from. With a hard GL Error, you can trace it to the exact line where the problem happened.
Will the performance difference be significant? Probably not. But I see no reason to take the chance.
I'm glad you are answering your own questions.
When I said slots, I meant entries in an array (or table).
Remember, also, that hash tables have to be larger than the maximum number of data that can be stored in it.
As we all know, GL_MAX_*_UNIFORM_COMPONENTS is pretty hight. Even for the modest GPUs GL_MAX_VERTEX_UNIFORM_COMPONENTS is 4096. An open addressing hash table requires at least 20% more space. Hence, you need 5K-entry hash table for the translation.
Oh, I've forgotten to ask, should each program has its own table?
So, the implementation would be slower, more complicated, has greater memory footprint, and all that for what... Just to prevent someone to misuse way how uniform-ids are automatically generated.
I still think this is not a valid proposal, but it's only my humble opinion.
Yes, that is what we're talking about: using debug contexts to help find bugs in your code.Just to prevent someone to misuse way how uniform-ids are automatically generated.
Welcome to the conversation; glad you could make it.
Do you think all that stdout spam that NVIDIA does in debug contexts is cheap? Do you think that ARB/KHR_debug is inexpensive to implement? So there's plenty of precedent for driver developers to implement different, performance-hampering stuff in debug contexts than in non-debug.
The entire point of debug contexts is for the user to tell the implementation, "stop caring so much about performance and help me find bugs." That's why ARB_debug won't exist without debug contexts. That's why the spec allows KHR_debug to basically stop being useful in non-debug contexts. That's why NVIDIA's drivers stop spamming stdout with every message they generate for ARB/KHR_debug in non-debug contexts.
Debug contexts are for debugging. I kinda thought the name spoke for itself.
I have tried on several (versions of) drivers, and I couldn't spot any difference in the performance between debug and non-debug contexts.
I would ask other developers to share their results in testing debug-context performance. Thanks!
Who cares? I mean, it's nice to know but, like Alfonse said, debug-contexts are for finding bugs and are not intended for production code.testing debug-context performance
I didn't want to offend, of course. Surely it's worth knowing what you're dealing with. Since enabling debugging capabilities has to be a run-time decision, I assume the cost boils down to conditionals which can be efficiently avoided by branch prediction.Originally Posted by Aleksandar
I'd rather get some details on how drivers implement checks instead of profiling a whole series of drivers from different vendors.
So what you're saying is that the ARB is stupid. All OpenGL implementations that don't expose ARB_debug_output in non-debug builds are just being annoying for no adequately explained reason. The effort the ARB went through to allow KHR_debug to be effectively shut off in non-debug builds was a waste of time, and all OpenGL implementations that take advantage of this are just doing pointless things. Indeed, the very idea to have a separation between debug and non-debug builds was stupid to begin with.In fact, I guess most of the additional debugging code is active in both debug and non-debug profiles, and it does not affect performance (at least in a noticeable fashion).
Because that's what you're saying. You're saying that all of the effort spent, both in the spec and by implementations, to separate debug from non-debug leads to no actual gain. And therefore there is no point in spending all of that effort to begin with.
I have pretty much zero faith in the ARB to make good decisions, and even I don't think that poorly of them.
BTW, when you did these tests, did you by chance actually create any errors? Would your code have had any debug output messages in a debug run? Did you emit errors several times in the rendering loop?
Because otherwise, you're just measuring how quickly the implementation doesn't call the expensive error reporting code.