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 15 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 144

Thread: Pipeline Newsletter Volume 4

  1. #21
    Senior Member OpenGL Guru knackered's Avatar
    Join Date
    Aug 2001
    Location
    UK
    Posts
    2,833

    Re: Pipeline Newsletter Volume 4

    well it looks like they're just like d3d vertex declarations...
    http://msdn2.microsoft.com/en-us/library/bb206335.aspx
    Knackered

  2. #22
    Junior Member Regular Contributor
    Join Date
    Aug 2006
    Posts
    231

    Re: Pipeline Newsletter Volume 4

    skynet, from my understanding of it, and judging by the diagram, the buffer objects used by the VAO are mutable, the rest isn't.

    Jan, looking at it that way draw objects are certainly not a good idea and I can see now why they've done it how they have.

    Regarding the program objects they have (according to the diagram) the following attachment points:
    • Vertex program
    • Fragment program
    • Buffer object (used for the uniforms)
    • Image objects and Texture Filter Objects. (probably set in one go, see this , the glUniformSampler line)


    Regards
    elFarto

  3. #23
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: Pipeline Newsletter Volume 4

    A couple of impressions and an exclamation ...

    1. Increment of ref count when used -- Personally I'd prefer managing object lifetimes myself, without having to second guess the API.

    2. Default framebuffer -- I don't mind supplying my own default framebuffer, in fact I'd prefer it that way.

    3. Debug context -- oh yeah!

  4. #24
    Advanced Member Frequent Contributor
    Join Date
    May 2005
    Location
    Prague, Czech Republic
    Posts
    913

    Re: Pipeline Newsletter Volume 4

    Originally posted by bonehead:

    1. Increment of ref count when used -- Personally I'd prefer managing object lifetimes myself, without having to second guess the API.
    Any OGL specification which creates objects in current OGL version specifies what happens, when you delete object which is currently bound somewhere. The driver then needs to correctly implement that behavior which might have some performance and implementation cost for handling of this very special case which almost never happens.

    Such situation can not happen with the reference counting approach because the object has at least one reference as long it is bound somewhere so both specification and driver does not need to have special case to handle it.

  5. #25
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: Pipeline Newsletter Volume 4

    When you also introduce a "drawobject", that would mean you need to have an awful lot of drawobjects. I am thinking about my octree, which has over 20 thousand nodes and through culling there can be many different combinations of parts of the array i want to render. So, doing this on-the-fly is, in my opinion, the way to go.
    Why? What's wrong with having 20,000 VAOs? Odds are that you have 20,000 C++ objects, one for each node, anyway. It's not that much more memory for the implementation. A few pointers, some offsets, a couple of stride parameters. Hell, you're going to have to store that information yourself anyway. Just let the driver do its job and stay out of it.

    VAO's aren't really on-chip memory; they're client memory allocated and stored in the implementation. They contain references to objects and some state data for them.

    So if you can allocate 20,000 C++ objects, why can't GL?

    However, it sounds like, when changing some buffer-object (that contains uniforms), the shader needs to be validated (linked?), because that buffer might have a different layout.
    Why would it? The program doesn't change just because some uniforms changed, nor does the buffer need to be validated or have its layout changed.

    What it does mean is that nonsensical nVidia "optimization" where they recompile the shader if you change certain uniform values goes away. But as far as I'm concerned, that's the way it should be.

    Would that mean, IŽd have to create another VAO for each object just for this pass?
    Why not? You need to have a different program object and set of blending parameters (maybe) anyway, so what's one more object? From an API standpoint, I prefer that it have an entirely separate VAO, just so that it matches with its entirely separate program and separate blend parameters.

    We are talking about an object that takes up, maybe, 32 bytes per vertex attribute. And that's worst-case; it's probably more like 16 (offset, stride, BO-pointer, and an enum/switch/bitfield for the format [int, short, etc]).

    Personally I'd prefer managing object lifetimes myself, without having to second guess the API.
    Those objects are owned by the server, so no, you won't be doing that. You aren't doing it in 2.1, and you won't be in the future.

  6. #26
    Senior Member OpenGL Guru knackered's Avatar
    Join Date
    Aug 2001
    Location
    UK
    Posts
    2,833

    Re: Pipeline Newsletter Volume 4

    Originally posted by elFarto:
    Of course this raises the question, why can't all these options + all the objects that are bound to the context (fbo/vbo/program objects/etc..) be wrapped up into a 'Draw Object'? Then the draw command is just lpDraw(drawObject);
    Really, what use would that be?
    The common case is state sorted, only an idiot would package everything up like that and just draw in an arbitrary order. I can't imagine a scenario where I would actually use the proposed drawobject, except perhaps in some weird prototype app.
    In any case, this stuff would probably be folded into the display list object, when they get round to it.
    Knackered

  7. #27
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: Pipeline Newsletter Volume 4

    Suggestion to the ARB, on the "per-sample operation" object:

    One object for all of these parameters is wrong.

    From the user's perspective, blending and, say, depth testing are two different settings that are set from two different places. A user's object would know how it blends, so it should have its blend parameters/object/etc. In that way, it is similar to a program object.

    But why would the object decide how the depth test works? How depth testing happens is not really something the object needs to be aware of. Currently, that's a sort of "set and forget" parameter. You set it globally, and change it very infrequently. Certainly not on a per-user-object basis.

    From the user's point of view, lumping the depth test in with the blend functions is asking for trouble. It makes it hard to change the paramter globally, as you have to go around and change it in all of the objects that render with it.

  8. #28
    Junior Member Regular Contributor
    Join Date
    Aug 2006
    Posts
    231

    Re: Pipeline Newsletter Volume 4

    Originally posted by knackered:
    Really, what use would that be?
    None, as I'm starting to see. Just seeing all the shiney new objects, I was wondering why drawing didn't have an object, and it makes sense that it doesn't.

    Regards
    elFarto

  9. #29
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,256

    Re: Pipeline Newsletter Volume 4

    Originally posted by Korval:
    But why would the object decide how the depth test works? How depth testing happens is not really something the object needs to be aware of. Currently, that's a sort of "set and forget" parameter. You set it globally, and change it very infrequently. Certainly not on a per-user-object basis.
    What the heck?
    I haven't had the time to read this stuff but hope it's going to be sensible. The whole idea of a new GL was to clean out the clutter and be a thin layer. The state machine is a beautiful thing.

    Or maybe they want the design it in a such a way that a fixed amount of data is sent to the GPU everytime a draw call is made.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  10. #30
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: Pipeline Newsletter Volume 4

    One object for all of these parameters is wrong.
    Hasenpfeffer.

Posting Permissions

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