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 15 FirstFirst 123412 ... LastLast
Results 11 to 20 of 144

Thread: Pipeline Newsletter Volume 4

  1. #11
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: Pipeline Newsletter Volume 4

    "As I said - let's not start discussion over it here."
    Well, this is a discussion board...

    I demand, that the next newsletter is posted at 10 AM European time, not American, this is just too late.

    The only thing, that comes to mind right now, is that drawcalls do not include an "offset" parameter for the indices (offset added to each index, not the thing the "first" parameter is used for). As discussed in several long threads, that i leave to other people to find links to.
    Just want to make sure, it is not forgotten.


    I also am wondering, whether rectangle textures might be gone for good. I am not sure, whether i think this is a good thing, maybe it is, but i do find them useful, even with NPOT textures, so, as long as hardware can be made faster with rectangle textures than with NPOT textures, i'd like them to stay (including non-normalized texture coordinates).

    I like the idea, to remove the framebuffer and use FBOs throughout the pipeline. The question, how we present the result on screen is of course a valid one.

    I find the "Non-serialized access" weird. If i am forced to make sure i don't do anything wrong, using semaphores and sync-objects, doesn't that come down to the same stuff, the driver needs to do? I am pretty sure only very few people would use this fragile feature. Not with partial and whole buffer invalidation, which seems to be a good idea.

    None of the ideas for shader/program objects, i have read/used so far have convinced me. The ARB_xxx_program system was a mess, the current GLSL system is not good and the way i understand the lp system it seems not to really change. Also, i fear i need to link or create new program objects, every time i only want to bind a different texture to the shader / pipeline.

    Well, some interesting information, nothing that surprised me (though that's certainly a good thing).

    Jan.
    GLIM - Immediate Mode Emulation for GL3

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

    Re: Pipeline Newsletter Volume 4

    I've never seen the point in texturerect. I must be missing something. For me they just clutter up glsl.
    Knackered

  3. #13
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: Pipeline Newsletter Volume 4

    About Corrail's idea to specify ones own instance IDs: That's GREAT !!!
    GLIM - Immediate Mode Emulation for GL3

  4. #14
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Pipeline Newsletter Volume 4

    Non-serialized access is roughly equivalent to the non-blocking MapBuffer extension on OS X OpenGL (flush buffer range).

    It turns out to be straightforward to use if adopted as part of a "write once" policy; if for example you set up a large VBO, map and write the first N KB, then draw that, then map and write the next N KB, and draw that, etc - having this option means the second map need not wait for the drawing of the first batch to complete, giving you concurrency. But note, in this example each block of data was only written to once and so there is no risk of a scheduling hazard.

    Using the non-serialized option is much more difficult in situations where you might overwrite a section of the buffer with previously specified data in favor of new data, and if you are not handy with fences, should definitely be avoided.

    Note that you can still potentially get concurrency (avoiding a block condition in MapBuffer) if you specify write-only, invalidate-range and explicit-flushing, because this gives the driver an "out" to optionally provide an efficient scratch buffer for your writes, which it can deliver into the specified buffer range later, based on the flush mapped data calls you must make after writing when explicit flush is enabled.

    (why/how is this different from BufferSubData? because it allows you to maintain any representation for source data that you like, and to be able to uncompress directly to the destination using your own code - BufferSubData would not allow this, the source data must be in a copyable form)

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

    Re: Pipeline Newsletter Volume 4

    If that is possible I can store all objects of a similar type (for example trees) in one VAO and use instancing for rendering.
    Um, you can do that currently (well, currently as LP stands). What you can't do is specify directly what the ID will be. I don't really see a problem with that. Is an increasing counter not good enough to index into an array?

    I mean, in the typical case, the contents of that array are being updated every frame. So, you're going to have to fill out the buffer anyway; you may as well fill it out in order.

    The thing I like about this is that it suggests that this functionality will be properly emulated transparently for non-DX10 hardware. That way, we don't have to worry about it. Worst-case, it acts like a number of repeated draw calls that modify a uniform value, which would be what you would have done in the first place.

    Just want to make sure, it is not forgotten.
    It probably hasn't been forgotten so much as made unnecessary.

    If VAOs do all the validation and so forth up-front, then there is an open question as to the need for such a thing. After all, the impetus for the call is performance based on the current GL API. It's entirely possible that simply making a VAO for each of the things you want to render and swaping them in/out as needed will offer all the performance benefits of the parameter.

    The ARB_xxx_program system was a mess, the current GLSL system is not good and the way i understand the lp system it seems not to really change.
    What is the specific problem?

    I've never seen the point in texturerect.
    The main point was to have NPOTs before we had NPOT hardware. It's rather important to be able to at least expose something of that hardware, such that we can create unmipped textures on hardware that supported rects and not generalized NPOTs.

    It turns out to be straightforward to use if adopted as part of a "write once" policy
    Sounds like the perfect way to implement a GL 2.1 wrapper

  6. #16
    Senior Member OpenGL Pro k_szczech's Avatar
    Join Date
    Feb 2006
    Location
    Poland
    Posts
    1,107

    Re: Pipeline Newsletter Volume 4

    Instance ID's - we usually have to specify some instance-specific data anyway (like transformation matrix), but it could be usefull if that data is static and we just want to skip some instances (frustum culling). It would give some extra performance in this case.
    But what if someone is drawing a bunch of particles and he doesn't want to do frustum culling for every one of them individually (that would be crazy)? Then such array of instance ID's is unnecessarry and introduces additional performance cost.
    So if there will be such functoinality, then I should be able to pass NULL as a pointer to this array, so my instances will receive ID's automatically.

    Also, i fear i need to link or create new program objects, every time i only want to bind a different texture to the shader / pipeline.
    Why would one have to link or create new program object when binding another texture? It doesn't make any sense to me.

  7. #17
    Junior Member Regular Contributor
    Join Date
    Aug 2006
    Posts
    231

    Re: Pipeline Newsletter Volume 4

    At last, it's been released (of course I've been reading it since before it's release ).

    Everything looks good, apart from no spec

    Judging by the comments in this thread, it seems like we could use an 'lpSuperDrawArrays' and 'lpSuperDrawElements':

    Code :
    void lpSuperDrawArrays(LPsizei instanceCount, LPsizeiptr *instanceIDs.
                           LPsizei primCount, 
                           LPenum *mode, LPint *first,
                           LPint *count, LPint *offset)
    Code :
    void lpSuperDrawElements(LPsizei instanceCount, LPsizeiptr *instanceIDs,
                             LPsizei primCount,
                             LPenum *mode, LPsizei *count,
                             LPsizeiptr *indices, LPsizei *offset)
    Where offset is the value to add to each index read from the buffer. instanceIDs[i] can be NULL if want to draw all instances of primitive i and instanceIDs can be NULL if you want to draw all instances of all primitives. Same for offset.

    I also rearranged the parameters, they seem to make more sense to me like this:, i.e. draw 1 instance of 2 primitives.

    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);

    Regards
    elFarto

  8. #18
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    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. Otherwise, in this scenary, i would be creating and deleting hundreds of drawobjects every frame (or even worse, i would need to reuse them, for performance reasons ... if they would be mutable, at all).

    "Why would one have to link or create new program object when binding another texture? It doesn't make any sense to me."

    I have to admit, that i haven't fully understood what the program object contains and which parts can be changed, without relinking it. 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. I hope it is not that way, because changing a buffer object is a very common operation.

    Jan.
    GLIM - Immediate Mode Emulation for GL3

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

    Re: Pipeline Newsletter Volume 4

    Originally posted by Jan:
    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.
    If the buffer has different layout, you will almost certainly need different program object because the shaders must be updated to match the layout so layout will likely be part of the immutable attachment properties of the program object.

    It is possible to modify the attachment point of existing program object to reference different buffer with the same layout so, when swapping multiple buffers with the same layout, you can use single program object.

  10. #20
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    669

    Re: Pipeline Newsletter Volume 4

    To me, VAO's look a bit scary. If it really means, IŽd have to create and fill out a specific VAO whenever I want to draw a certain range out of one or more buffer objects it could be even worse than Jan's 20000 statically allocated VAOs.

    IŽm using a number (ca. 100) of buffers of medium size (ca. 4mb) to upload geometry on the fly. Because of this, each geometry might end up in a different buffer at a different position each time it gets uploaded again. Sometimes, even the attribute count differs between geometries (so they don't have a homogeneous layout inside one buffer).

    This means: every time, geometry is uploaded, I'd have to recreate a corresponding VAO and for each uploaded piece of geometry (several thousands) IŽd have to keep a VAO around.
    Of course, at draw time IŽd save alot of calls with this model!

    I just want to make sure, that LP is ready to create/delete/recreate/keep several thousand VAOs :-)


    If a VAO really means an immutable combination of:
    buffer(s), generic attribute Id(s), offset(s), size(s), type(s) and strides(s)
    it would sound logically to me to include the indexbuffer into it as well... and we would wind up with what elFarto called "DrawObject".

    What just comes to mind: often you need to render the same object, but with different attributes. Imagine for instance, a z-fill pass, where youŽd need only the position (no normals, no texcoords). Would that mean, IŽd have to create another VAO for each object just for this pass?
    Of course, if the shader is not using the additional attributes, it should not hurt correctness, but since the 'normal' VAO also specifies normals and texcoords the driver believes IŽm accessing buffers which in fact are not accessed. The driver then possibly blocks those buffer objects unnecessary.

    Anyway, looks like VAOs need some more detailed explanation

Posting Permissions

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