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 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 48

Thread: A quote from - Mark J. Kilgard Principal System Software Engineer nVidia

  1. #31
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    Quote Originally Posted by thokra View Post
    The upper bound is defined as a function of both the values specified by glVertexAttribPointer and the draw call.
    Right. And that bound is (at least to some extend) given if the data resides in a BufferObject. But this makes things just a little better 'cause the the upper part of the buffer may still not be intended to draw. Having an opportunity to give the upper bound explicitely would likely ease error-tracking as the range of indices that can accidently be drawn without triggering a segv gets narrowed down.
    On the other hand - if the attributes reside in a buffer a draw-call maybe deffered in another thread to a later Point of time which makes tracking more difficult. But at least there is an implied upper bound which gives the opportunity for the GL-implementation to return with an appropriate error-code more easily (I guess signals/exceptions had to be cought otherwise - I seldomly run crashing code outside the Debugger so I don't have that much experience when it comes to the default-behaviour in such situations).

  2. #32
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    And that bound is (at least to some extend) given if the data resides in a BufferObject.
    The bound is specified for client-side arrays and vertex buffer objects. Only the place from where you fetch is different, i.e. system-memory or VRAM.

    But this makes things just a little better
    It doesn't make anything better - at all. The upper bound can still be completely invalid - again, in both usage scenarios.

    Having an opportunity to give the upper bound explicitely would likely ease error-tracking as the range of indices that can accidently be drawn without triggering a segv gets narrowed down.
    But you have the opportunity. It's all right there. The problem is: you also have the opportunity to screw everything up. But that's inherently a problem of unchecked random memory access - it's nothing specific to OpenGL. That's why they specified GL_ARB_robustness. When enabled, you at least avoid program termination but values are still undefined. One advantage is, that you probably see that fetching goes wrong and for which objects in your scene it goes wrong. This narrows down the choices when searching an error.

    I seldomly run crashing code outside the Debugger so I don't have that much experience when it comes to the default-behaviour in such situations
    I actually don't understand that sentence. The default behavior of a crashing application is a crash. That's actually not the worst that could happen. The worst would be a running application with bogus memory accesses and inconsistent state that runs in perpetuity.

  3. #33
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    Quote Originally Posted by thokra View Post
    The bound is specified for client-side arrays and vertex buffer objects. Only the place from where you fetch is different, i.e. system-memory or VRAM.
    I guess you got me wrong there. When calling VertexAttribPointer there is no upper bound given in that API-call - if it refers to a buffer then a upper bound is implied by the buffer-size and the Offset and Stride Parameters.
    I have a quite specific Scenario in mind: A VertexAttribPointer gets bound (be it in Client-Memory or a gl-buffer), enabled and for whatever reason does not get disabled. Another Scenario is an attrib-Pointer getting bound, enabled and an out-of-range index emitted (which is technically the first Scenario when the bug gets apparent). It is not that
    values are still undefined
    makes me happy in that case. The implementation should return immediately with an appropriate error-code then. It was to narrow down the point as to when this is possible and what could be done to increase the error-spotting-ability of the GL-implementation to make debugging GL-applications easier - security considerations apart: If any of the driver's threads runs with elevated permissions or not is beyond my knowledge.

  4. #34
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    then a upper bound is implied by the buffer-size and the Offset and Stride Parameters.
    That goes for client-side arrays as well. There is always an implicit upper and lower bound. No matter where you allocate memory. The problem is moving past them explicitly with glVertexAttribPointer and draw calls.

    For fun's sake I just checked a very wrong piece of code with a Radeon HD 7970 and Catalyst 13.4 on Linux. You can do the craziest crap, like render a billion points way out-of-bounds of the underlying data store and it will neither terminate, nor render nothing nor give you any hint via debug output. It will invoke the current shader program as expected and draw, with a somewhat random pattern, a square in the xz plane. That's cool.

  5. #35
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    That goes for client-side arrays as well. There is always an implicit upper and lower bound. No matter where you allocate memory. The problem is moving past them explicitly with glVertexAttribPointer and draw calls.
    But OpenGL can verify the size of storage for buffer objects. It can detect when you're trying to fetch outside of the bound range and, given robust access, allow it to return an innocuous value rather than arbitrary memory or potentially crash.

    You can't do that with an arbitrary client-side pointer, because the range information simply isn't there. All it has is the lower bound, not the upper.

  6. #36
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    Quote Originally Posted by Alfonse
    You can't do that with an arbitrary client-side pointer, because the range information simply isn't there. All it has is the lower bound, not the upper.
    Yes, that's true.

    Quote Originally Posted by hlewin
    The implementation should return immediately with an appropriate error-code then.
    Do you mean in the context of robustness or in general?

  7. #37
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    Quote Originally Posted by thokra View Post
    Do you mean in the context of robustness or in general?
    I mean the General case. Something like
    Code :
    BindBuffer...
    BufferData...
    VertexAttribPointer...
    ArrayElement(1000000000)
    should return with an error instead of Rendering crap. Notice the buffer. This is the case where this is easily possible - and for WebGL such bounds-check are a MUST imho. A segv/Access violation typically occurs only when the Memory-block dedicated to the whole process gets passed, which may be the whole Webbrowser-process with WebGL. Would be worth a try writing a WebGL-shader that searches for the data on the Website the shader is on with this.

  8. #38
    Advanced Member Frequent Contributor
    Join Date
    Apr 2010
    Posts
    719
    WebGL checks indices are valid, see WebGL spec, #6.5.

  9. #39
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    Thats a good thing.

    @thokra: You don't understand the principle argument. If I do NOT know what arb_robustness is chances are quite a degree higher that out-of-range accesses will happen to me. The spec should have been the other way around. I pretty much enjoy that it is enforced with WebGL.
    arb_robustness is not even mentioned in the wglCreateContextAttribs-spec. An arb_uncheked_... would have been much more senseful. And the spec should have enforced to return with an error-code instead of rendering zeroes. That would point out such errors in place.
    This may also be read as a critique of the absence of a complete-in-itself documentation but that's another story.

    Sorry for taking this thread apart.

  10. #40
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    Quote Originally Posted by hlewin
    You don't understand the principle argument.
    I don't? You want universal bounds-checks, where applicable, without the need to create a robustness context, i.e. the default. Plus, since it should have been the other way around, one would need to create a non-robust context explicitly. That about right?

    Quote Originally Posted by hlewin
    arb_robustness is not even mentioned in the wglCreateContextAttribs-spec.
    It's all right here ...

    Sorry for taking this thread apart.
    This thread has been pretty much worthless in large part anyway.

Posting Permissions

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