The sample code in the extension spec initializes the buffer each time through its while() loop:
// Initialize data store of buffer object
BufferDataARB(ARRAY_BUFFER_ARB, 320, NULL, STREAM_DRAW_ARB);
// Map the buffer object
float *p = MapBufferARB(ARRAY_BUFFER_ARB, WRITE_ONLY);
Is this necessary? Would it be possible to just re-map the buffer with WRITE_ONLY each time through, after sizing it once? Doesn’t the spec actually allow for that, because reading from a WRITE_ONLY buffer is “undefined”?
Also, supposing re-calling BindBufferARB is the thing to do, will drivers optimize for the case where I use a single buffer for all my streaming needs? It seems it could internally cycle through some array of memory and do double-buffering, just like we currently do with NV_vertex_array_range and NV_fence.
There’s also a typo in the spec 
// Delete buffer objects
int buffers[2] = {1, 2};
DeleteBuffersARB(1, buffers);
About VBO…
I don’t know if it has been posted before. But it is good to notice that 43.51 beta driver (http://download.guru3d.com/detonator/) exposes the VBO extension in the extension string.
Sizing the buffer just once at start up should work fine, with the one exception that you also need to do it if UnmapBufferARB() returns FALSE.
– Tom
Tom,
That’s what I think, too (I’d also check for NULL from MapBuffer). It’d be nice to have authoritative answers, though. The spec mumbles about a DiscardAndMap call not being added because it was good enough to do the NULL pointer BufferData call.
Let me re-phrase the question: is it legal for a driver to not provide the data you previously put into the buffer, if you MapBuffer with WRITE_ONLY usage? I would hope it is, because that would make for a better/easier/more convenient/possibly more efficient usage model.
Also, I still want to know if drivers are expected to optimize the case where you use a single logical buffer for all your streaming needs, but, because you discard the contents all the time, there’s actually sufficient renamed physical buffers to not stall the pipe.