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 8 FirstFirst 1234 ... LastLast
Results 11 to 20 of 74

Thread: Official Bindless Graphics feedback thread

  1. #11
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    934

    Re: Official Bindless Graphics feedback thread

    What about VAO with this? Oo

    I spent post and post to debate with Korval a while ago about "VAO don't allow fast buffer" switch so I'm glade to see such feature but I'm a little be confused VAO and this now. It even deprecate the new uniform buffer ... Oo

    I definitely need more information about all this, I don't actually know where to go now.

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

    Re: Official Bindless Graphics feedback thread

    well it's only G80 cards, so you'll have two very different code paths.
    This stuff has actually got me excited about GL again. Thanks nvidia.

  3. #13
    Junior Member Newbie
    Join Date
    Oct 2006
    Location
    Sweden
    Posts
    23

    Re: Official Bindless Graphics feedback thread

    Wow, that's daring stuff. Basically cuts open big holes through the thick mud that the current OpenGL API is

    I like it. If only it was universal.

  4. #14
    Advanced Member Frequent Contributor Mars_999's Avatar
    Join Date
    Mar 2001
    Location
    Sioux Falls, SD, USA
    Posts
    519

    Re: Official Bindless Graphics feedback thread

    All I can say is about time! As usual Nvidia leading the pack for OpenGL. This is why I buy Nvidia only due to their support for OpenGL vs. ATI. Just wish ATI would pick up the slack and get in gear... Here's to wishing!!!

  5. #15
    Junior Member Newbie
    Join Date
    Feb 2007
    Posts
    21

    Re: Official Bindless Graphics feedback thread

    > How does this extension interact with Map/Unmap usage patterns? I use map/unmap so I can update the VBO data in another thread. Will it still work?

    Yes, MapBuffer (and MapBufferRange) will still work, but please read issues 7-9 of NV_shader_buffer_load for more info.

    > Is automatic scaling with multiple GPU still working ?

    Yes, SLI can still work.

    > What about VAO with this?

    The new vertex attrib state is contained in the VAO (see the "New State" section), so these can be used in conjunction with VAO. However, it's not clear that VAO will provide additional benefit since switching vertex attrib addresses should be cheap (Groovounet, some of your posts about VAO have been very insightful).

    > Are these extensions GL 3 only?

    They do not require a GL3 context, and should work with all the ARB_compatibility features.

  6. #16
    Intern Newbie
    Join Date
    Feb 2004
    Location
    Grenoble - France
    Posts
    35

    Re: Official Bindless Graphics feedback thread

    Quote Originally Posted by jeffb
    > Is automatic scaling with multiple GPU still working ?
    Yes, SLI can still work.
    Thanks for your answer.
    Do you know if it's currently working with NVIDIA R185 drivers ? If so, does it work in heterogeneous SLI configurations, with GPU not having the same amount of memory for instance ? Any idea of how it is implemented ? Does each GPU clone the same address space ?

  7. #17
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    665

    Re: Official Bindless Graphics feedback thread

    Ok, I had a bit time to read/think through the specs and I think, I might have grasped it :-)

    First of all, I think its a step in the right direction. It offers new features, even D3D10 has not. Issuing draw commands will get faster, leaving more CPU time for the appliaction itself. Although the GPU will not render faster per-se, there are now more possibilities for complex datastructures used in the shaders.

    I have a few points to criticise, though. First of all the naming of the extensions is... just awkward.
    Why not use "NV_shader_memory_access" (its about shaders directly accessing memory, right?) and "NV_buffer_direct_memory" (I don't get the "unified" part...)

    I think it might be good to not provide the non-Named Functions. We all know that bind-to-edit will die out some day, so why provide these obsolete semantics for brand new functionality?! Just provide the Named-Function semantics (but please, without the "Named" prefix).
    Also, the specs refer to some functions of EXT_direct_state access without mentioning dependencies on it.

    Now we get pointers and pointer arithmetic in shaders. That allows to create really complex data structures, like lists, trees, hashmaps - the specs even talk about whole scenegraphs. But how are we supposed to debug such monsters?

    Is the driver using the "sizeiptr length" parameter of BufferAddressRangeNV to determine that a certain region of memory is in use by drawing commands? If not, do we have to use fences for that (welcome back, NV_vertex_array_range)?

    It seems, that once a VBO is made resident, it never can become non-resident (unless the application tells it to be). How can GL make that guarantee? What is the use of a non-resident buffer then? Does a resident buffer have any performance penalties?

    I like the separation of vertex attribute format, enable and pointer. VAO did not offer this and therefore was useless (for me). You could it one step further and provide "vertex format" objects which encapsulate the format and enables. I don't know if that would be a great benefit, though (switching a stream setup with one command).

    I'd like to suggest to move all the buffer-object related functions (MakeBufferResidentNV, IsBufferResidentNV, MakeBufferNonResidentNV) from NV_shader_buffer_load into NV_vertex_buffer_unified_memory. They feel more natural there. Additionally, IsBufferResidentNV may be replaced or accompanied by a new parameter to glGetBufferParameteriv().

    Last but not least, IMHO the use of these new extensions probably has a fair impact on the design of a renderer. It cannot be used optional easily. Therefore, I will probably hesitate to actually make use of these features, if they are not available on ATI as well.


    my 2c :-)

  8. #18
    Junior Member Newbie
    Join Date
    Feb 2007
    Posts
    21

    Re: Official Bindless Graphics feedback thread

    > the "sizeiptr length" parameter

    D3D10 has some guarantees that accessing beyond the end of a buffer will not crash, this is providing something similar. If that's not useful to you, you can use INT_MAX and ignore it.

    > ... once a VBO is made resident...

    Issue 6 of shader_buffer_load discusses the purpose of residency. It shouldn't adversely affect performance most of the time.

    > probably has a fair impact on the design of a renderer.

    The presentation on the developer site has some examples of how to port. The vertex buffer extension should be easy to maintain both codepaths, although I can appreciate that maintaining multiple versions of shaders has some cost to developers.

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

    Re: Official Bindless Graphics feedback thread

    So, will there be new texture formats to render pointers into FBOs ? Could be useful for deferred renderers to "render materials" for later lookup.

    I guess i could also store all materials in a big array and use an integer from an FBO for lookup, should be flexible enough.

    I find the extension very intriguing, probably the most interesting and powerful idea since the introduction of shaders. However, debugging is indeed a problem. With standard GL/GLSL a broken shader usually crashes a program. With this i fear the blue-screen might become much more common. And debugging standard shaders can be a nightmare today already.

    Jan.
    GLIM - Immediate Mode Emulation for GL3

  10. #20

    Re: Official Bindless Graphics feedback thread

    So it's basically adding 'GPU address pointers'.

    1. Handles now become direct GPU pointers on client side.
    2. Shading language now has C-like pointer syntax.

    It's a very nice feature but I really would have
    preferred that the wording be more direct (i.e.
    new feature: pointers to GPU memory!) so it is
    easier to read, understand and use!

Posting Permissions

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