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 2 FirstFirst 12
Results 11 to 18 of 18

Thread: Unsynchronize SSBO

  1. #11
    Junior Member Newbie
    Join Date
    Aug 2015
    Posts
    19
    Quote Originally Posted by Dark Photon View Post
    For a desktop GPU, the conventional way to deal with that is to put a glFinish after your SwapBuffers call ("and only" after your SwapBuffers call). After that glFinish, you then know that the GPU has processed all of the calls for the previous frame, and performed any frame post-processing required to present the frame you just submitted to the user.

    This also has the benefit of synchronizing your draw thread with the frame clock, which has some nice benefits in terms of providing consistent end-to-end latency through the system.

    Don't do this on most mobile GPUs though.

    Alternatively, use the sync object method GClements suggested.
    glFinish didn't do much different. I guess that's because glMapBuffer kinda does that already. I will try with sync objects.

  2. #12
    Junior Member Newbie
    Join Date
    Aug 2015
    Posts
    19
    Looked into sync object. Seems to me that what they do is simply put a fence after a certain buffer command and wait for just the buffer command before it to be done. Then you can wait for the fence and be sure that the buffer command you called just before that is done. However I don't see how that would make glMapBuffer to wait a shorter time since I guess in that command something like glFinish is called anyway.

    I also looked in to PBOs. They seem very promising since what I've understood after they are done writes the output texture to a given place in memory. However the problem with PBO is that what you recieve is based on the output of the fragment shader and I would not want to render the scene twice. I guess I could make a 1x1 pixel texture as the output for the PBO however then I would need to discard fragments to not after each fragment write to the texture since then I would just overwrite the value I want with something like 0 all the time. But if I discard fragments all the time the scene will not be seen on my main frame. So what would be needed is either to be able to read what is already in the PBO texture from the fragment shader and overwrite the 1x1 pixel with what is already in it. However this would probably make data races very common and give bad results since many fragments are rendered parallell. The second solution would be to be able to only discard the part of the fragment that writes to the PBO. Which I guess would be the best.

    Something that would be really cool would be if you after you a buffer command has been done by the GPU could have specified a function to run in a new thread. Then I could do my function just after the the rendering Is complete and everything would be awesomely synced and working. I guess that could come in handy for many situations when you don't want the CPU to wait for the GPU to be done with something.

    I would love to have my teories confirmed since I'm not sure I'm right about what I said Thanks!

  3. #13
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,480
    Quote Originally Posted by Trionet View Post
    Looked into sync object. Seems to me that what they do is simply put a fence after a certain buffer command and wait for just the buffer command before it to be done. Then you can wait for the fence and be sure that the buffer command you called just before that is done. However I don't see how that would make glMapBuffer to wait a shorter time since I guess in that command something like glFinish is called anyway.
    glFinish() waits until the command queue is empty. glMapBuffer() only needs to wait until there are no pending commands which could modify the buffer (for some value of "could"; make sure you unbind it after the call which writes to it).

  4. #14
    Junior Member Newbie
    Join Date
    Aug 2015
    Posts
    19
    By the way I tried GL_MAP_UNSYNCHRONIZED_BIT, with or without GL_MAP_READ_BIT on glMapBufferRange. It didn't work in the meaning that p always was nullptr and the CPU still worked 100%. How's that?

  5. #15
    Junior Member Newbie
    Join Date
    Aug 2015
    Posts
    19
    Quote Originally Posted by GClements View Post
    glFinish() waits until the command queue is empty. glMapBuffer() only needs to wait until there are no pending commands which could modify the buffer (for some value of "could"; make sure you unbind it after the call which writes to it).
    Didn't unbind before. However the gains were about 2% cpu I think maybe no gain.

  6. #16
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,480
    Quote Originally Posted by Trionet View Post
    By the way I tried GL_MAP_UNSYNCHRONIZED_BIT, with or without GL_MAP_READ_BIT on glMapBufferRange. It didn't work in the meaning that p always was nullptr and the CPU still worked 100%. How's that?
    According to the glMapBufferRange reference page:

    GL_INVALID_OPERATION is generated for any of the following conditions:

    * length is zero.

    * The buffer object is already in a mapped state.

    * Neither GL_MAP_READ_BIT nor GL_MAP_WRITE_BIT is set.

    * GL_MAP_READ_BIT is set and any of GL_MAP_INVALIDATE_RANGE_BIT, GL_MAP_INVALIDATE_BUFFER_BIT or GL_MAP_UNSYNCHRONIZED_BIT is set.

    * GL_MAP_FLUSH_EXPLICIT_BIT is set and GL_MAP_WRITE_BIT is not set.

    * Any of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT, GL_MAP_PERSISTENT_BIT, or GL_MAP_COHERENT_BIT are set, but the same bit is not included in the buffer's storage flags.
    If you set GL_MAP_UNSYNCHRONIZED_BIT, don't set GL_MAP_READ_BIT, and don't set GL_MAP_WRITE_BIT, it will fail for the first of the highlighted cases above.

    If you set GL_MAP_UNSYNCHRONIZED_BIT and set GL_MAP_READ_BIT, it will fail for the second of the highlighted cases above.

    If you set GL_MAP_UNSYNCHRONIZED_BIT and set GL_MAP_WRITE_BIT, it should return a valid pointer, but you can't write to that region (doing so will result in undefined behaviour, e.g. an access violation).

  7. #17
    Junior Member Newbie
    Join Date
    Aug 2015
    Posts
    19
    Quote Originally Posted by GClements View Post
    If you set GL_MAP_UNSYNCHRONIZED_BIT, don't set GL_MAP_READ_BIT, and don't set GL_MAP_WRITE_BIT, it will fail for the first of the highlighted cases above.

    If you set GL_MAP_UNSYNCHRONIZED_BIT and set GL_MAP_READ_BIT, it will fail for the second of the highlighted cases above.

    If you set GL_MAP_UNSYNCHRONIZED_BIT and set GL_MAP_WRITE_BIT, it should return a valid pointer, but you can't write to that region (doing so will result in undefined behaviour, e.g. an access violation).
    Ooh I thought it was only reading that was possible.

    However when I use GL_MAP_UNSYNCHRONIZED_BIT and GL_MAP_WRITE_BIT it works just as normal, with the cpu use and all. Isn't that weird?

  8. #18
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,480
    Quote Originally Posted by GClements View Post
    If you set GL_MAP_UNSYNCHRONIZED_BIT and set GL_MAP_WRITE_BIT, it should return a valid pointer, but you can't write to that region (doing so will result in undefined behaviour, e.g. an access violation).
    Sorry, I meant to say that you can't read from the region, only write to it.

Tags for this Thread

Posting Permissions

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