glBufferSubData memory usage increasing

[DaveHoskins]

Hello, I want to update some fixed size vertex data, which should be straight forward, but I'm getting increasing memory usage if I'm updating with 'glBufferSubData.'
In the test example below, if I press 'Q' then memory usage keeps the same size, otherwise SubData will increase memory by the data amount used every time.
When it updates my memory used goes from 500Mb to 615Mb in increments then settles down. I find this unacceptable, and a bit weird.

'numVert' never changes.

I thought it would work, is this a driver error, or mine?

if (GetAsyncKeyState('Q'))
{
// Delete it all and submit new data... GOOD but slow?
glDeleteBuffers(1, &vertexBuffer);
glGenBuffers(1, &vertexBuffer);
glBindBuffer(GL_ARRAY_BUFFER, vertexBuffer);
glBufferData(GL_ARRAY_BUFFER, sizeof(Vertex)*numVert, vertex, GL_DYNAMIC_DRAW);
}else
{
// Wipe over old data... Increases memory - BAD
glBindBuffer(GL_ARRAY_BUFFER, vertexBuffer);
glBufferSubData(GL_ARRAY_BUFFER, 0, sizeof(Vertex)*numVert, vertex);
}

Does anybody else experience this?
I'm on Windows XP, and a GTX 260 card with latest drivers.
Thanks,
Dave.

[DaveHoskins]

It seems to not be a problem on a Win7 laptop. So I'm presume it's wasteful driver software that's munching up memory on my GTX 260. In fact, my same executable uses 200Mb less memory on the laptop!
Is that an Nvidia problem, or an old Microsoft problem I wonder?

[mbentrup]

You can just use glBufferData without calling glDeleteBuffers and glGenBuffers, that is usually the preferred method to update the whole buffer.

[DaveHoskins]

You can just use glBufferData without calling glDeleteBuffers and glGenBuffers, that is usually the preferred method to update the whole buffer.

OK, like textures. Thanks I'll do that.

Although my point was that SUBData is supposed to be the preferred way to update a buffer of the same size, isn't it?

[mbentrup]

OK, like textures. Thanks I'll do that.

Although my point was that SUBData is supposed to be the preferred way to update a buffer of the same size, isn't it?

If the data in the buffer is still required for some OpenGL commands waiting in the pipeline, glBufferData will keep an (orphaned) copy of the old data and allocate new storage for the buffer opject to upload the data to.

glBufferSubData may need to wait until the GL commands have finished before it can modify the buffer, though some drivers avoid this by creating a temporary buffer for the subdata and inserting the equivalent of a glCopyBufferSubData into the pipeline.

There is no guarantee that one way or the other is better on all drivers / OSes / GPUs, but I'd take glBufferData when I have to replace the whole buffer.

[DaveHoskins]

If the data in the buffer is still required for some OpenGL commands waiting in the pipeline, glBufferData will keep an (orphaned) copy of the old data and allocate new storage for the buffer opject to upload the data to.

glBufferSubData may need to wait until the GL commands have finished before it can modify the buffer, though some drivers avoid this by creating a temporary buffer for the subdata and inserting the equivalent of a glCopyBufferSubData into the pipeline.

There is no guarantee that one way or the other is better on all drivers / OSes / GPUs, but I'd take glBufferData when I have to replace the whole buffer.

Oh that's great. Thanks for the definitive reply, I'd suspected something like this was going on, but it's nice not to feel isolated as I've spent hours tracking down something that I had no control over after-all.