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 1 of 3 123 LastLast
Results 1 to 10 of 25

Thread: Quality of Implementation: Debug shader variable locations

  1. #1
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Quality of Implementation: Debug shader variable locations

    Now that OpenGL's debug context concept is a bit more well-defined (thanks to language in KHR_debug and the like), let's expand on this. NVIDIA already starts spamming stdout when you're in debug, so let's close another source of errors:

    Accidentally using the correct variable locations.

    Unless you explicit assign a variable location in OpenGL, you must query its location to know where it is. However, most implementations will assign locations sequentially, starting from 0. Which means that code can be written which accidentally does the right thing.

    I would suggest that, upon every shader compilation (in debug only), generating a random number and starting the location assignments from there. This will help show where a program is accidentally forgetting an explicit assignment or a query.

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,117
    A very good idea

  3. #3
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,136
    Maybe the idea is good, but I cannot approve it. Uniform locations are "slots", hence the numeration. What are the benefits of assigning number, for example 4387 instead of 0, just to cast the exception? Further more, if that number changes on every compilation, it wouldn't alleviate catching errors, since behavior will change from compilation to compilation. Plus, there should be addition burden to "translate" exposed numbers to real slots. Sorry, maybe I foreseen something obvious, but I don't understand this proposal.

  4. #4
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Uniform locations are "slots", hence the numeration. [...] Plus, there should be addition burden to "translate" exposed numbers to real slots.
    I don't know what you mean by "slot". Uniform locations are arbitrary numbers. They have no meaning to the hardware. They're not byte offsets into a buffer, or even 4D vector register numbers. If the latter were true, then a 4x4 matrix would have to take up 4 uniform locations, and they don't.

    That's why uniform locations can be assigned arbitrarily by the user. If they were some kind of hardware byte offset into a buffer or something, the ARB wouldn't give the user the ability to assign them arbitrary numbers.

    So this "burden to 'translate' exposed numbers to real slots" already exists (if by "real slots" you mean "byte offsets"). I'm simply wanting the burden to be used for something useful.

    Further more, if that number changes on every compilation, it wouldn't alleviate catching errors, since behavior will change from compilation to compilation.
    Let's say that I forget to get the location of a uniform. Or maybe I have some convention for my uniform locations thanks to ARB_explicit_uniform_location, but I screwed up and forgot to assign that location in one shader. Either way, in my C++ code, I have some code that assumes that location 0 represents some variable.

    Given an arbitrary assignment scheme for uniform locations (typically, based on the order defined in shaders), it is entirely possible that 0 may indeed represent that uniform. Thus, my code appears to work. And since the assignment scheme doesn't "change from compilation to compilation", I will never know about it.

    At least, until I take my code to a different implementation that uses a different assignment scheme. Then it breaks. That may have been weeks or months since I wrote the original code that's now broken. Tracking down the variable I forgot to initialize or the shader I forgot to set up properly will be a lot harder.

    If the implementation starts assigning uniform locations from a random number, it is highly unlikely that any particular compilation of a shader will just so happen to pick 0 as the start. Therefore, it is very likely that my code will break the first time I try to use it. And if it doesn't, it will break the second time I try to use it.

    Thus it catches errors sooner rather than later.

  5. #5
    Member Regular Contributor Nowhere-01's Avatar
    Join Date
    Feb 2011
    Location
    Novosibirsk
    Posts
    251
    it's a good idea, although i think it would be better, if that behavior will occur only if debug context is active. cause i'm not sure about possible outcomes of those changes, especially for already existing applications. so if you are aware of it, you can use it. but those developers who unaware of it and existing software won't be affected.

  6. #6
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,181
    I think it's an awesome idea, but instead of starting at a random location and going sequentially from there I'd suggest that each uniform location be completely random, if possible. And not just in debug contexts; make it standard behaviour in all contexts.

    This is in the spirit of "fail early, and fail as noisily as possible" and it's a great idea.

  7. #7
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    it's a good idea, although i think it would be better, if that behavior will occur only if debug context is active.
    *cough* : "in debug only"

    I think it's an awesome idea, but instead of starting at a random location and going sequentially from there I'd suggest that each uniform location be completely random, if possible.
    Why? You're not going to catch more errors that way; it just makes the coding of the feature more difficult. Especially since arrays (of basic types) have to be contiguous in their uniform locations.

    And not just in debug contexts
    Um, why not? Whatever method of randomization is used will necessarily be slower than not using that method. The whole point of having debug vs. release contexts is for implementations to recognize that they can do things different for debugging sake that they wouldn't do in release builds.

  8. #8
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    Totally agree. This has bugged me for years.

  9. #9
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,136
    Interestingly, I have never had such problem. Maybe because I'm using object-wrapper which fetches uniform location in the initialization function, and all access is restricted through interface functions.

  10. #10
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    I ran into this numerous times, albeit during some rapid prototyping which resulted in code which should never make anywhere else - and it worked because I knew the particular implementation will handle it this way. It's still wrong though. We also had questions here asking whether uniform locations always started at 0 so other people actually wrote code and asked afterwards if their code could possibly be incorrect or at least unsafe.

Posting Permissions

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