Hi!
I believe that even if you want to update a small memory area in vertex/index buffer, you have to upload entire buffer unless you are ready to stall pipeline.
Am I right?
This is CLOD-related question. Thus, I guess issuing many syncronization tokens (using NV_fence for example) does not really solve anything. I hope I’m wrong.
If you only want to change data and not add more data, you can map the vertex buffer and then alter the data. If you want to increase the size of the buffer, you must delete the original and create a new one.
Probably you’re missing the point. If you try to lock VBO buffer when it is still used by GPU, most likely you’ll have to wait until it’s released. Of course driver may use “rename buffers” and return to you a pointer to a most recent copy of buffer’s data (which obviously is not used by GPU). But this means that driver keeps a copy of buffer internally, and each time it has to upload the entire buffer to GPU-accessible memory, since driver has no idea what you’ve updated.
[This message has been edited by Galstaff (edited 01-26-2004).]
Yes, you cannot selectively update portions of the VBO. However, implementations of streaming VBOs may be double-buffered, thus letting you set data in them while they are being used.
In any case, if you are really wanting to change only part of a VBO in the middle of rendering (rendering two instances of a slightly modified version of the same mesh), I’d cut the vertices that are going to be modified out and put them in a separate VBO, one for each instance. That way, you can be sure that you’re not going to cause a stall.
Korval, unfortunately I cannot cut small updated area. The problem is that almost all entries in index buffer are changed when adjusting LOD, but they’re changed slowly.
[This message has been edited by Galstaff (edited 01-26-2004).]
The only non-stalling CLOD algorithms I know of are sliding window based. I e, they use pre-calculated index buffers and offset the start/size used within that buffer.
You can use BufferSubDataARB() to update only parts of a buffer, but it’s implementation defined whether this stalls the pipeline or not.
Perhaps you could double-buffer yourself; you could keep two copies of the buffer, and issue one, then update the other (re-applying whatever changes you just applied to the issued buffer in the same pass). Switch, repeat.
jwatte, please could you give a link to ‘sliding window based’ aglorithm implementation or maybe discussion. Actually, I do remember (well, I can be wrong) something similar was mentioned a couple of years ago probably in DIRECTXDEV list, but did it make its way to implementation?
Perhaps two is not a right number, I think by default NVIDIA driver caches up to tree frames, thus four buffers are more realistic.
Ok, I’ve found some links on sliding-window VIPM. Thanks to everyone for discussion.