I create a buffer object with GL_MAP_WRITE_BIT | GL_MAP_PERSISTENT_BIT and then I map it with GL_MAP_WRITE_BIT | GL_MAP_PERSISTENT_BIT | GL_MAP_INVALIDATE_BUFFER_BIT | GL_MAP_UNSYNCHRONIZED_BIT | GL_MAP_FLUSH_EXPLICIT_BIT.
According to usage examples I've seen, I write to the pointer and do a flush. No unmapping. I was initially doing this for uniform buffer objects holding mainly transforms, so I'd be writing data multiple times per frame. I didn't notice any problems.
However, I tried to use this with pixel buffer objects and I have a big problem. In my setup, I have shared memory into which another application is drawing stuff, and I use it to load as texture in my application. To make the uploading asynchronous, I use the standard way of ping-ponging two PBOs. Initially, I wasn't using the persistent and flush bits. I would map one PBO and write data, then unmap it, and the other one would have an asynchronous texture subimage operation. Then the next frame they switch. When I tried to change the map-write-unmap operation to map once with persistence and then write-flush, the framerate of everything dropped very significantly. How is it that doing this once per frame had so much impact, when it seems to work fine with UBOs as in my first use case? Is there an issue with persistent mapping and simply the amount of memory being transferred (HD-resolution texture during most frames)? I assume I'm probably doing something wrong with the way I'm using it, perhaps when I'm calling the flush operation (right now it's immediately after the write), but I really don't know. The feature is fairly new to OpenGL, so perhaps drivers aren't as well optimized for it, but that doens't seem likely (I'm on GTX 680). Any suggestions? I was hoping to actually get an improvement by saving on the map/unmap calls...
Edited by Prune, 20 January 2014 - 02:18 PM.