PDA

View Full Version : GPU VBO copy



babis
02-12-2008, 01:25 PM
Hello, which is the fastest way to copy data from a VBO to another offset in the same VBO?

Thanks,
babis

RGHP
02-12-2008, 09:45 PM
UnmapBuffer();
memcpy();//Or memmove() if the are probably overlapped
Mapbuffer();

???

I really don't know if this is the best but It's what I'd do now.
Please more help to this topic OpenGL gurus

CatDog
02-13-2008, 05:18 AM
I think the fastest way is to maintain a copy in RAM and BufferSubData portions of it to the appropriate positions in the VBO. This omits reading back the VBO contents.

But first of all, I would ask myself why moving memory blocks inside a VBO is needed at all.

CatDog

babis
02-13-2008, 08:02 AM
Thanks for your answers

@RGHP
I don't think if this is valid, and if so, would the memory be copied via system RAM copies back & forth?

@Catdog
Yes I thought of this, but I thought if there could be another way, so I wouldn't mess with my main memory, since the source and the target would be located in video memory.

A reason would be to use some memory in the VBO for a 'template' of vertex data, and copy it to other positions in the VBO for other run-time created objects which need their own separate data copy, in order to alter it.

-NiCo-
02-13-2008, 08:22 AM
I'm not sure, but maybe it's possible to use GL_NV_transform_feedback (http://www.opengl.org/registry/specs/NV/transform_feedback.txt) to read from a VBO and write to a different part of the same VBO?
Haven't used it myself so I'm not aware of its limitations...

How do you intend to alter the data? If you're using RTT and a PBO you could use CopyTexSubImage or CopyPixels on your texture.

N.

babis
02-13-2008, 08:43 AM
I don't think GL_NV_transform_feedback would help me much, since I don't intend to process the original data in any way, and if I understood correctly, I would need a dummy shader to avoid any transformation on the data. And a sm 4.0 capable card :)

I guess I'll use PBOs to alter the data, but I won't need copies of the altered data ( so I could use these 2 commands), but a copy of the original data, which wouldn't be processed in any way.
Like a template, residing in a VBO, and then each created object would get a copy of that template, in order to alter it later. For deformable objects, to be more specific & help you understand.

-NiCo-
02-13-2008, 08:52 AM
I don't think GL_NV_transform_feedback would help me much, since I don't intend to process the original data in any way, and if I understood correctly, I would need a dummy shader to avoid any transformation on the data. And a sm 4.0 capable card :)

GL_NV_transform_feedback also works with fixed function, so you can easily create a passthrough operation without a shader. But you're right about the card :)


I guess I'll use PBOs to alter the data, but I won't need copies of the altered data ( so I could use these 2 commands), but a copy of the original data, which wouldn't be processed in any way.
Like a template, residing in a VBO, and then each created object would get a copy of that template, in order to alter it later. For deformable objects, to be more specific & help you understand.


Can't you make alls objects source from the same part in VBO and write to separate parts the first time you alter the data and work on the separate sets afterwards?

N.

babis
02-13-2008, 09:17 AM
Can't you make alls objects source from the same part in VBO and write to separate parts the first time you alter the data and work on the separate sets afterwards?


Interesting, sounds cheap but messy..More like an evil optimization! :) I have now my three options ( initially on CPU & then glBufferSubData or as you said or mapbuffer & memcpy) so I guess I'll try & see for myself..

Thanks!

-NiCo-
02-13-2008, 09:27 AM
Sourcing from the same part of the VBO keeps everything on the GPU unlike mapping the buffers. It will also benefit your vertex caching and you can make use of instancing.

You're welcome :)
N.