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 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 48

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

  1. #21
    Member Regular Contributor
    Join Date
    Jun 2013
    Posts
    474
    Quote Originally Posted by kRogue View Post
    [*]Removal of QUAD primitive types was, IMO, a mistake. One can simulate it with a geometry shader, but that seems awfully silly. As a side note, OpenGL ES3 does NOT have geometry shaders.
    The main problem with quads was that their tessellation into triangles was unspecified, i.e. which diagonal was used for the split. It seems like it would have been simple enough to just specify the behaviour, although this might have had political ramifications (i.e. unless all drivers behaved the same way, any given choice would make some existing drivers "correct" and others "incorrect").

    Quote Originally Posted by kRogue View Post
    Removal of client side arrays (i.e. non-buffer object backed index and vertex buffers) was IMO a mistake as well. The use case of vertex and index data changing from frame to frame got ickier. With client side arrays, the GL implementation did the right thing for you.
    The main problem with client-side arrays is that the implementation has to assume the least efficient scenario, i.e. that the entire contents of all arrays changes between every draw call. Forcing the use of buffers requires the user to specify the behaviour explicitly, rather than simply adopting the path of least effort (which is also the path of least efficiency).

  2. #22
    Member Regular Contributor
    Join Date
    Jun 2013
    Posts
    474
    Quote Originally Posted by mhagain View Post
    Display lists were far too complex in the old API, with lots of weird edge cases and fiddly rules about what can and cannot be put into them
    Display lists are actually very simple. If you understand what they are, along with OpenGL's client-server model (which allows the two to be separated by a network connection), you can usually figure out whether or not a command can be put into one.

    As a general principle, any feature which requires synchronisation between client state and server state can't go in a display list, as that would require glCallList() to be "executed" on both the client and server so that the states don't become desynchronised. E.g. glBindBuffer() can't go into a display list as the client needs to know whether a buffer is bound in order to determine whether "pointer" arguments to glVertexPointer() etc are pointers to data which should be sent with each draw command, or offsets into server-side buffer objects.

    The fact that a display list can contain mismatched glBegin/glEnd commands, partial immediate-mode vertex specifications, etc is a consequence of display lists being nothing more than recording and playback of the command stream. Contrary to what might be inferred from "GL_COMPILE", implementations typically don't attempt to optimise the contents of a display list, they just store the commands verbatim.

    A notable exception is that some OpenGL 1.0 implementations worked around the single-texture limitation (glGenTextures, glBindTexture etc were added in 1.1) by optimising display lists containing glTexImage() commands. But that's ancient history.

  3. #23
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    578
    Quote Originally Posted by GClements
    The main problem with client-side arrays is that the implementation has to assume the least efficient scenario, i.e. that the entire contents of all arrays changes between every draw call. Forcing the use of buffers requires the user to specify the behaviour explicitly, rather than simply adopting the path of least effort (which is also the path of least efficiency).
    Indeed, a GL implementation essentially needs to "flush" the used vertices and indices from client side memory to GPU at each draw call, so yes it sucks. However, there was no need to throw the baby out with the bath water. There were several ways out, for example a set of additional calls giving the GL implementation "promises" that the client side data would not change until the pointer was changed for example. The catch being that that can end up walking a similar road as the current buffer object Ouija board we have now. Right now for streaming vertex data, it is.. a pain. Greater hilarity is in order for when the memory is unified. The current GL interface for buffer object data is an embarrassment when one sees that all one wants is to write the data into memory with the promise that one is not writing into that memory while the GPU is using it.

    The main problem with quads was that their tessellation into triangles was unspecified, i.e. which diagonal was used for the split. It seems like it would have been simple enough to just specify the behaviour, although this might have had political ramifications (i.e. unless all drivers behaved the same way, any given choice would make some existing drivers "correct" and others "incorrect").
    Or just provide a query what the behavior is and let it be undefined. There are plenty of bits in the GL specification that are undefined and left at the vendor's discretion on what to do. For example when a triangle edge passes exactly through the center of a pixel weather or not that pixel is rasterized; all that one has is that neighboring triangle sharing an edge shall not rasterize the same pixels twice.

  4. #24
    Member Regular Contributor
    Join Date
    Apr 2009
    Posts
    268
    Quote Originally Posted by GClements View Post
    The main problem with client-side arrays is that the implementation has to assume the least efficient scenario, i.e. that the entire contents of all arrays changes between every draw call.
    No they don't. If they can sniff changes (or lack of them) they can be efficient (or at least, more efficient).
    NV does such optimization on Windows iirc.

  5. #25
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    One big problem with client-side arrays in their current form is that their overall-size is unknown to the GL-implementation. One can easily cause access-violations using them, or - even worse - just pull data from random memory locations without anything special happening immediately because there is no possibility of bounds-checking (Not to say that GL-implementations should check the buffer-bounds). So, especially for embedded devices, it was the right decision not to support them imho as the principle requirement of a gl-call never to crash the program but to return with an error in the case of bad operation-parameters may not be possible to achieve if they are in use - this goes a little beyond my knowledge of different architectures. For WebGL the security holes that would potentially be introduced with them are dramatically - who knows what data would follow in memory after some typed-array in JavaScript ...

  6. #26
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,136
    Quote Originally Posted by hlewin View Post
    One big problem with client-side arrays in their current form is that their overall-size is unknown to the GL-implementation. One can easily cause access-violations using them, or - even worse - just pull data from random memory locations without anything special happening immediately because there is no possibility of bounds-checking (Not to say that GL-implementations should check the buffer-bounds). So, especially for embedded devices, it was the right decision not to support them imho as the principle requirement of a gl-call never to crash the program but to return with an error in the case of bad operation-parameters may not be possible to achieve if they are in use - this goes a little beyond my knowledge of different architectures. For WebGL the security holes that would potentially be introduced with them are dramatically - who knows what data would follow in memory after some typed-array in JavaScript ...
    True, but the same applies to any GL call that requires a client-side memory pointer (or returns one that may be written to): glBufferData, glTexImage, glMapBuffer, etc.

  7. #27
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,099
    ... glVertexAttribPointer by specifying values that aren't correct even with VBOs. In conjunction with a corresponding draw call, you can easily go out of bounds of the buffer object's data store ... but that's what GL_ARB_robustness is for. Even if the draw call specifies the correct values for the set of primitives to be rendered, incorrectly setup arrays can still lead to access violations - and vice versa.

    In general, at any time you operate on memory with accesses that aren't explicitly checked, caught and handled if incorrect, you can get into trouble.
    Last edited by thokra; 07-22-2013 at 05:00 AM. Reason: Factor in Alfonse's remark on the interaction of draw calls and vertexattribpointer

  8. #28
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    Quote Originally Posted by mhagain View Post
    True, but the same applies to any GL call that requires a client-side memory pointer (or returns one that may be written to): glBufferData, glTexImage, glMapBuffer, etc.
    It's true that those can be fed with wrong data and cause crashes too but with those arrays the errors are much harder to find. I can remember spending some time Debugging old code that made massive use of TexCoordPointers. Due to some code-change the Arrays didn't get disabled after that passage was done. This resulted in a situation where the program crashed an indefinate amount of time later when other (correct) drawing code eventually tried to draw arrays that were large enough to exceed the old texcoord-pointers Segment border or dedicated Memory block or whatever while quite a amount of small arrays was drawn successfully in between.

  9. #29
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    True, but the same applies to any GL call that requires a client-side memory pointer (or returns one that may be written to): glBufferData, glTexImage, glMapBuffer, etc.
    That's not true. The size of memory that is passed to glBufferData or glBufferSubData is an explicit parameter. Yes, the user can get it wrong, but at least the size is there, as opposed to glVertexAttribPointer, where there is no size at all. The size of the buffer for a pixel transfer is implicitly specified based on a complex function of the parameters to the pixel transfer call (and a few global parameters). With mapping, again the size is either explicitly given or is implicit.

    And most important of all, all of these functions will be done with the pointer upon their return (well, except for mapping, but that's a special case). So any modifications to client memory are local modifications. Everything you need to know to verify that you have provided sufficient memory should be right there.

    glVertexAttribPointer's boundaries are defined only by the eventual draw call, which may be an indexed rendering call that could fetch from quite simply anywhere. And the fetching is non-local; indeed, the place where the render call happens could be very far away from where the initial setup happened.

    This all leads to it being nearly impossible to verify via inspection that any particular use of client-side arrays is safe. You will have to trace through a lot of non-local code to make sure.

  10. #30
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,099
    Quote Originally Posted by Alfonse
    glVertexAttribPointer's boundaries are defined only by the eventual draw call
    I think this wording is misleading. Yes, I know what you mean, but you don't bound glVertexAttribPointer - the lower bound for fetching is established by glVertexAttribPointer. You can offset the lower bound but that doesn't change the fact that ultimately the lower bound is specified by the offset passed to glVertexAttribPointer. The upper bound is defined as a function of both the values specified by glVertexAttribPointer and the draw call. Your statement sounds as if a draw call could make up for an incorrectly specified offset in glVertexAttribPointer, for instance by specifying a negative first argument (which leads to undefined behavior) or by specifying negative indices (which will simply be converted to an unsigned integral type).
    Last edited by thokra; 07-22-2013 at 06:12 AM. Reason: Remove random access nitpicking.

Posting Permissions

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