Presence of buffer-data

I put this into the beginners-section depite of reading some discussion about that issue.
If working with opaque buffer-objects the question arises whether the gl-implementation will Keep data set by BufferSubData at Hand. Not knowing this (assuming that gl just sends it away and Forgets about it) one is tried to keep a copy of the data oneself. Actually this may result in the data being around three-times: One copy in the app’s Memory, one copy that the gl-implementation may Keep at Hand for itself and one copy residing on the graphics-board. The same goes for textures.
Does someone know (or have a good guess about) the policies gl-implementations have in that manner?

Add:
The vague Interpretation of - for example - GL_DYNAMIC_DRAW is not enough for my taste to assume that one could implement interfaces about buffers providing get/set accessors to parts of it implementing them in a way as to use glGetBufferSubData frequently.

Add2:
I guess in respect to this the Problem is that that the man-page only speaks about “used”. “… the data used many times…”
It does not state used by whom. So one is tended to think this only matters in respect to the graphic Card - the Card will use it many times. Is it safe to say that “will be used many times” includes optimization for queries to the buffer-data via the gl-api?

Add3:
Could there be hints to the GL how much Memory to use at most for at-hand-for-queries copies of data and/or hints stating how much Memory there has to be still-available for the application so that mallocs do not fail and gl keeping buffers with certain flags at Hand for queries until the Memory-Limit gets exhausted and then starting to drop local copies?

Having thought about this again: Is it likely at all that data given to the gl via gets completely moved to graphics-Memory so that a get will require waiting for the GPU to copy it back to system-memory? And is it likely that this will happen again if gl notices that this buffer is one the user uses for reading as well? Maybe I’m doing badly in inferring from myself to others but I’ve quite often seen the pattern that the users are managing the data themselves instead of using glGets.

Buffer data may be kept in CPU memory or GPU memory or both. At least two things can affect this: The usage parameter passed to glBufferData, and how you actually use the buffer. I would say it is less likely that both copies are kept (CPU and GPU), but it is still possible.

It is possible that initially the buffer is created using one kind of memory (possibly based on usage) and later, when actual usage information is available, the driver can move the memory somewhere else.

If you do frequent updates, it is possible that the driver keeps two (or even more) copies of a buffer: It would hurt performance to wait until CPU/GPU is done with the buffer when the other one wants to access it.

I would suggest using MapBufferRange / FlushMappedRange (instead of BufferSubData). These give more information to the driver, helping it to do the right thing, and also potentially eliminate the CPU memory copy needed by the application which you always need when using BufferSubData.

This was my first thought about that, too. But then I took into account the fact that having a huge memory on board is a relatively new thing. And when having a lot of large textures even that is not that large. So I’d guess that a certain degree of round-tripping with the system-memory is quite common which requires keeping a copy there.

I would suggest using MapBufferRange / FlushMappedRange (instead of BufferSubData). These give more information to the driver, helping it to do the right thing, and also potentially eliminate the CPU memory copy needed by the application which you always need when using BufferSubData.

In some respect (and the usage I have in mind) I’d call the copying an advantage - besides the fact that copying data from the buffer should be one of the most stressless reading-operations. The advantage of BufferSubData in writing operations is the Absence of any Options as the GL can decide when to update the buffer.