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 4 of 22 FirstFirst ... 2345614 ... LastLast
Results 31 to 40 of 212

Thread: Official feedback on OpenGL 3.2 thread

  1. #31
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by GeLeTo
    Currently sending data to VBO (or any other buffer data object) works like this:
    1. Allocate and fill the data
    2. Give it to glBufferData
    3. glBufferData immediately makes a copy of the data (or sends it directly to the card which is unlikely)
    4. When glBufferData returns the data is no longer needed and I can delete or modify it

    What I want is to skip #3 to avoid the extra copy done by glBufferData. When using glBufferDataRetained the data is not immediately copied and I cannot change/delete it till OpenGL signals that this data is no longer needed.
    OK, I understand now. I think both Sun and Apple have done vendor extensions along these lines, and we have sometimes discussed it as a future use case in the ARB. If we do something like this in a future release I hope it would use sync objects to signal the driver being done with the client buffer, but at present it's not being actively discussed in the group.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

  2. #32
    Junior Member Newbie
    Join Date
    Nov 2007
    Posts
    22

    Re: Official feedback on OpenGL 3.2 thread

    Now I'm just waiting for extension APIs like GLEW to catch up with a major release.

    Does anyone know of any APIs like GLEW that allow for the easy handling of extensions in openGL 3.1/3.2?

  3. #33
    Intern Contributor
    Join Date
    Apr 2001
    Location
    Sofia, Bulgaria
    Posts
    65

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by Jon Leech (oddhack)
    I think both Sun and Apple have done vendor extensions along these lines, and we have sometimes discussed it as a future use case in the ARB. If we do something like this in a future release I hope it would use sync objects to signal the driver being done with the client buffer, but at present it's not being actively discussed in the group.
    Now that we have sync objects, the API to implement this functionality is a no-brainer, so I hope to see it implemented sooner rather than later.

  4. #34
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Czech Republic
    Posts
    317

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by GeLeTo

    Currently the only way (that I know of) to avoid the extra copying is to use glMapBuffer. And this is another can of worms...
    Al least for PBO the glMapBuffer API works fine.
    - Mapping buffer is pretty straight forward usage pattern.
    - NVIDIA drivers provides good performance.
    - Loading the data using glTexImage and similar is async
    - Current ARB_sync should fill the missing gap

  5. #35
    Junior Member Newbie
    Join Date
    Nov 2007
    Posts
    22

    Re: Official feedback on OpenGL 3.2 thread

    In my experience glMapBuffer works very well for the initial loading of any buffer. It's once you start to use that buffer that you suffer synch issues. Certainly it's much faster than multiple calls to glBufferSubData.

  6. #36
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Czech Republic
    Posts
    317

    Re: Official feedback on OpenGL 3.2 thread

    yes, calling glBufferData with data set to NULL is painless.

    Maybe glCopyBufferSubData (ARB_copy_buffer) for updating subdata can help.

  7. #37
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    352

    Re: Official feedback on OpenGL 3.2 thread

    C# wrappers for OpenGL 3.2 available here. Also usable by VB.Net, F# and the rest of the Mono/.Net family of languages.
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

  8. #38
    Junior Member Regular Contributor
    Join Date
    Feb 2006
    Location
    greece
    Posts
    181

    Re: Official feedback on OpenGL 3.2 thread

    Very well done Khronos!!Now let's see some drivers!..NVIDIA (officially) released 3.1 just a few weeks ago.
    Again, great release!
    while(1){keyboardsolo(FORTE, BPM_190);}

  9. #39
    Intern Contributor
    Join Date
    Apr 2001
    Location
    Sofia, Bulgaria
    Posts
    65

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by mfort
    Al least for PBO the glMapBuffer API works fine.
    - Mapping buffer is pretty straight forward usage pattern.
    - NVIDIA drivers provides good performance.
    - Loading the data using glTexImage and similar is async
    - Current ARB_sync should fill the missing gap
    Straightforward usage pattern? Mapping a buffer to update data will most certainly lead to sync issues. Even discarding the buffer with glBufferData(…, NULL) and updating the whole thing might not help. And of course updating the whole buffer migh not be what you want.
    glTexImage being async comes at a cost - it will most likely create a copy of your image data right away. And this is what I want to avoid.
    Quote Originally Posted by Scribe
    In my experience glMapBuffer works very well for the initial loading of any buffer. It's once you start to use that buffer that you suffer synch issues. Certainly it's much faster than multiple calls to glBufferSubData.
    This very much depends on the sizes of your data/subdata.
    The intricacies of glMapBuffer have been discussed to death. The solution to use buffer objects with sync objects is both elegant and simple.

  10. #40
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Czech Republic
    Posts
    317

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by GeLeTo
    And of course updating the whole buffer migh not be what you want.
    OK

    Quote Originally Posted by GeLeTo
    glTexImage being async comes at a cost - it will most likely create a copy of your image data right away. And this is what I want to avoid.
    It is hard to argue on this. Only driver guys can tell. But I see no reason why driver needs to make a copy. Probably it starts some DMA to copy the data from system memory to GPU memory.


    Quote Originally Posted by GeLeTo
    This very much depends on the sizes of your data/subdata.
    The intricacies of glMapBuffer have been discussed to death. The solution to use buffer objects with sync objects is both elegant and simple.
    Using buffers for small chunks of data is questionable. The overhead could be larger then using simple memory pointers and letting driver to copy it.

    I am using buffers glBufferData(…, NULL) for streaming several hundreds of megabytes per seconds without problems. Of course I am not using SubData. Driver developers should write some performance hints&tips for using smaller chunks with SubData. I can imagine it is not for free.

    If you are afraid of copying data in system memory try to use WriteCombined memory and/or SSE instructions with non temporal hint to not pollute cache.

Posting Permissions

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