Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: Quality of Implementation: Debug shader variable locations

  1. #11
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,201
    Quote Originally Posted by Alfonse Reinheart View Post
    Whatever method of randomization is used will necessarily be slower than not using that method.
    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 only reason I can see for not doing it in release contexts is to crutch up legacy programs that didn't do the right thing, and that doesn't seem much of a valid reason. Have you any stats for such programs? How many of them are actually out there in the real world?

  2. #12
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    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.
    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.

    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.

  3. #13
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,144
    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.

  4. #14
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Just to prevent someone to misuse way how uniform-ids are automatically generated.
    Yes, that is what we're talking about: using debug contexts to help find bugs in your code.

    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.

  5. #15
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,144
    Quote Originally Posted by Alfonse Reinheart View Post
    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.
    Your discussion led me to an interesting experiment. If you don't mind, I would hijack your thread for the short survey on debug-context performance.
    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!

  6. #16
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    testing debug-context performance
    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.

  7. #17
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,144
    Quote Originally Posted by thokra View Post
    Who cares?
    I do. 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). Driver instrumentation is enabled in all Vista/Win7 drivers. We will never know what exactly is going on under the hood, but such little experiments could shed some lights on it.

  8. #18
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    Quote Originally Posted by Aleksandar
    I do.
    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.

    I'd rather get some details on how drivers implement checks instead of profiling a whole series of drivers from different vendors.

  9. #19
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    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).
    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.

    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.

  10. #20
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,144
    Quote Originally Posted by Alfonse Reinheart View Post
    So what you're saying is that the ARB is stupid...
    Nope! Just said that blocking message output does not necessarily mean not collecting information. Of course it is highly appreciable to prevent message spamming. So, please, don't try to misinterpret what I said.

    Quote Originally Posted by Alfonse Reinheart View Post
    BTW, when you did these tests, did you by chance actually create any errors?
    No!

    Quote Originally Posted by Alfonse Reinheart View Post
    Would your code have had any debug output messages in a debug run?
    No!

    Quote Originally Posted by Alfonse Reinheart View Post
    Did you emit errors several times in the rendering loop?
    No, again!

    Quote Originally Posted by Alfonse Reinheart View Post
    Because otherwise, you're just measuring how quickly the implementation doesn't call the expensive error reporting code.
    The purpose of the test was to check whether debug-context is slower than non-debug. Not how fast it outputs messages. If there is a problem in the execution, it would cause slow execution in any case.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •