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 5 of 8 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 74

Thread: Official Bindless Graphics feedback thread

  1. #41
    Intern Newbie
    Join Date
    Feb 2000
    Location
    UK
    Posts
    42

    Re: Official Bindless Graphics feedback thread

    Hey this looks really very interesting - hats off to NVidia.

    A couple of questions:

    With Shader Buffer Load the addresses are virtual, and mapped to the GPU address space at Init() - presumably it doesn't matter from a functionality perspective whether the data is in Host or V-Ram here right? Is the idea to use the standard GL buffer API to upload the data to V-Ram prior to the draw call for speed (presumably multiple buffers of dependent fetches that might criss-cross Host<->V-Ram may not have the fastest access patterns there).

    Secondly when are you likely to be adding support for this within Cg?

    Finally - I'm thinking of this firstly in terms of iterating through a light parameter buffer via a buffer of indirected pointers to affecting lights here - so a general but related question: are there any profiles that support dynamic (from constant rather than compile-time) loop iteration counters yet?

    Thanks.

  2. #42
    Member Regular Contributor Jackis's Avatar
    Join Date
    Sep 2005
    Location
    Saint-Petersburg, Russia
    Posts
    275

    Re: Official Bindless Graphics feedback thread

    Do 185.85 WHQL support these extensions? Or we should use beta for now?

    [EDIT] Sorry, stupid question. Just installed these new drivers and saw, that these extensions are supported. Thanks for suc on-the-fly WHQL drivers!

  3. #43
    Intern Newbie
    Join Date
    Dec 2001
    Location
    Jyväskylä, Finland
    Posts
    31

    Re: Official Bindless Graphics feedback thread

    Quote Originally Posted by Auto
    Secondly when are you likely to be adding support for this within Cg?

    Finally - I'm thinking of this firstly in terms of iterating through a light parameter buffer via a buffer of indirected pointers to affecting lights here - so a general but related question: are there any profiles that support dynamic (from constant rather than compile-time) loop iteration counters yet?
    About the loop iteration counters: You mean in Cg or in GLSL? GLSL works fine if you mean through uniforms.
    Timo Heubach
    Ragged Games
    weblog: http://sleazycoding.com

  4. #44
    Intern Newbie
    Join Date
    Feb 2000
    Location
    UK
    Posts
    42

    Re: Official Bindless Graphics feedback thread

    Yep I was referring to Cg there, but thanks - I didn't know that. I'm a bit locked in to CgFX/GL with my code so I don't use GLSL.

    So am I correct in thinking it's totally uniform based and not a recompilation job prior to shader upload in the driver?

    If so that's pretty interesting, though surely only some hardware (presumably post G80-class) supports that right?

  5. #45
    Intern Newbie
    Join Date
    Dec 2001
    Location
    Jyväskylä, Finland
    Posts
    31

    Re: Official Bindless Graphics feedback thread

    Quote Originally Posted by Auto
    So am I correct in thinking it's totally uniform based and not a recompilation job prior to shader upload in the driver?

    If so that's pretty interesting, though surely only some hardware (presumably post G80-class) supports that right?
    G80 inclusive.
    Timo Heubach
    Ragged Games
    weblog: http://sleazycoding.com

  6. #46
    Intern Newbie
    Join Date
    Feb 2000
    Location
    UK
    Posts
    42

    Re: Official Bindless Graphics feedback thread

    Right - got you, that's what I meant, should've been clearer.

    Thanks.

  7. #47
    Member Regular Contributor
    Join Date
    Mar 2005
    Posts
    301

    Re: Official Bindless Graphics feedback thread

    Kickass!

    This is bringing back the old nvidia I liked - taking the lead in experimentation and actual innovation. If this is a sign of a "new" (or simply reborn) spirit - for all that is dear, don't let it be a single drive-by bullseye!

    Some input on the vertex buffer spec:

    If I'm to use all (remaining) space in the buffer anyway (as in the example), could perhaps -1 as "size" (last) argument to BufferAddressRangeNV work (using the size from the previous BufferData call)? I just found the code to manually having to adjust buffer size ("vboSizes[i]-4") to be... inelegant. Possibly also error-prone. Comments?

    Would it perhaps make more sense to rename GetBufferParameterui64vNV to simply GetBufferParameterAddr, and have it expect a holder of size void*? That way it could satisfy requirements for both 32- and 64-bit platforms, without wasting the upper 32 bits for 32-bit platforms.

    Are the *FormatNV functions just working names (not wanting to interleave the working code path too much with experimental stuff)? I'm not thinking of the "NV" moniker, I'm thinking "Hmmm, haven't I already seen this, even if in another incarnation, in plain VBO?".

    Are there any scenarios where one could actually want to modify stride for an interleaved attribute in a single array? In the example "20" (4*sizeof(float)+4*sizeof(UBYTE)) is used in both the ColorFormatNV call, and the immediately following VertexFormatNV. Could this be simplified in some way? F.ex. a few client-side-only functions with a stride-setting call first, then a few calls to set the different buffer's offset? (just brainstorming here)

    Anyway, while I just noticed this announcement and haven't had time to play with it; bloody good work!

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

    Re: Official Bindless Graphics feedback thread

    tamlin,

    > could perhaps -1 as "size" (last) argument to BufferAddressRangeNV work

    A GLsizeiptr is signed, but you could use INT_MAX.

    > GetBufferParameterAddr, and have it expect a holder of size void*

    This is a GPU address, not a CPU address, and may be 64bit even if the CPU address space is only 32bits.

    Sorry, I didn't follow the question about the *Format functions.

  9. #49
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    665

    Re: Official Bindless Graphics feedback thread

    Quote Originally Posted by tamlin
    Are there any scenarios where one could actually want to modify stride for an interleaved attribute in a single array? In the example "20" (4*sizeof(float)+4*sizeof(UBYTE)) is used in both the ColorFormatNV call, and the immediately following VertexFormatNV. Could this be simplified in some way? F.ex. a few client-side-only functions with a stride-setting call first, then a few calls to set the different buffer's offset? (just brainstorming here)
    There are useful scenarios where you can mix interleaved and non-interleaved atributes in one VBO or have a mixture of formats spread across separate VBOs. I would not restrict this to either interleaved or linear, EXCEPT for real performance advantages (someone of the HW guys can comment on this?).
    I'd suggest vertex format objects instead (or put the format specification into a display list). This would allow the driver to detect "all attributes have same stride" or "all atributes are linear" etc. and then do special handling of these cases. But this only pays off, _if_ the driver could take any advantage of this knowledge. But as I'm not a HW guy, I don't know...

  10. #50
    Senior Member OpenGL Pro
    Join Date
    May 2000
    Location
    Naarn, Austria
    Posts
    1,102

    Re: Official Bindless Graphics feedback thread

    I've finally had time to go through these specs, and it really looks cool.

    I just have a question:

    From the examples of NV_shader_buffer_load:
    in vec4 **ptr;

    glVertexAttribI2iEXT(8, (unsigned int)pointerBufferAddr, (unsigned int)(pointerBufferAddr>>32));

    It seems like there is some implicit packing/unpacking going on.

    Why not introduce a function like this:
    glVertexAttribui64NV(8, pointerBufferAddr); (plus corresponding type specifiers for glVertexAttribFormat)
    You did it with glUniformui64NV, so why not for attributes/varyings? It would make the code a lot more explicit and less confusing.

Posting Permissions

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