White Paper about Vertex Buffer Objects at nvidia website

Originally posted by Korval:
The behavior that I would like to see is for the VBO’s to remain in video memory at all times as I frequently (maybe every 5-20 seconds) upload new information to them. When I do an upload, it will be to VBO’s that are not in actual rendering use. (SNIP) The only thing that’s left seems to be STATIC_DRAW, but will this cause problems (as the driver expects the data to be uploaded only once)?

STATIC_DRAW is just a hint. The code still has to work even if you update the buffer seven times per frame, although the updates might be slower than when you create your VBO as STREAM or DYNAMIC.

If however you’re only going to update once every 5-20 seconds and while you’re not using the VBO, that’s potentially hundreds of frames in between updates. I think that qualifies as “static enough”

– Tom

Originally posted by Korval:
How would PBO be any faster than copying to a texture? And, therefore, how would this be a decent alternative to ARB_render_texture, which (at least on ATi cards) is faster?

It’s not about speed, it’s about flexibility. The current render texture extension is a freakin’ mess, and the PBO extension would “fix” any platform issues (at least I would hope so).

You don’t happend to be thinking of super_buffers rather than PBO?

Originally posted by Korval:
How would PBO be any faster than copying to a texture? And, therefore, how would this be a decent alternative to ARB_render_texture, which (at least on ATi cards) is faster?

Hm… context change penalty?

Originally posted by knackered:
[b] [quote]I’ll have to test this, but it also seems to me after reading this that if Map/Unmap potentially demotes a buffer back to system memory

Yes, I’m a little worried about this too for the same reason - I keep an application copy of the vertex data in system memory too - for arbitary reading and enabling the app to make changes to a single copy of the vertex data while the various renderers copy from that common store.
I think I’d have prefered it if, when the map call is made, we could specify a system memory pointer for the buffer to ‘unmap’ (copy) from once the unmap call is made - instead of being given a portion of memory to copy into.
Wouldn’t that potentially eliminate a redundant copy?[/b][/QUOTE]

That is a little bit more complicated than that. As operating System Developer I am inclinated to say that probably the mapping is not a copy. If the maping made a copy to a pointer you give… it would not be called mapping.

I beleive it a two level adressing system… like in logical->phisical memory mapping.
Or like the VIA sirtual interfaces for high speed network interfaces (Myrinet and so). In fact… if anyone wants to give alook… I think VIA buffers are pretty much the same thing.

I may be wrong (my impressions are of SO developer), but that way would justify the name (mapping) and would provide much better performance.