• Advertisement

Archived

This topic is now archived and is closed to further replies.

memcpy after Lock() ?

This topic is 5827 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I notice some people often use memcpy, but... What is the faster between : - Lock the vertices buffer - fill it with a loop and - fill a array of vertices with a loop - lock the vertices buffer - copy the array with memcpy() in the buffer ? Thanks

Share this post


Link to post
Share on other sites
Advertisement
Ive never used vertex buffer, but using a memcpy is MUCH faster for writing and reading a DD surface in hardware. but that was for single bytes, a vertex has a lot of bytes, so a hardcoded vextex list would be fine, and reading from a file should be fine too.

If it only happens once, the speed isnt as important as something that gets called each frame. I would go with direct access for now. if it starts to crawl, the use a temporary buffer on the stack

Share this post


Link to post
Share on other sites
I just did the vertex tut from the SDK and I made the triangle move and change colors by making the g_Vertices a global so I could edit it during the render loop and then I lock the buffer, memcpy, then unlock it. Is there another way of doing it?

What do you mean when you say lock the vertex buffer and fill it with a loop?

Edited by - WebSnozz on February 3, 2002 2:37:46 PM

Share this post


Link to post
Share on other sites
He means to programatically generate the geometry in a loop. the data goes into an array on the stack, then it is copied into the vertex buffer

Share this post


Link to post
Share on other sites
Locking a buffer on your 3D hardware card kills your preformance. It''s important to keep the time of your lock as small as possible. memcpy is the fastes way to update your buffer data. Working in system memory is much faster than working in a locked buffer.

So the fastes way to go is to update your data in systemmem. than copy it all to your buffer (could be any type of data (vertex, texture etc.)



Nathan Vos
http://www.triple-interactive.nl/nathan

Share this post


Link to post
Share on other sites
I think you''re right too. I''m doing this :

...
- Fill an array with transformed and sorted vertices
- Lock the vertex buffer (wich is "dynamic" and "write only")
- memcpy the array into the vertex buffer
- Unlock the vertex buffer
...

I think it''s right because it''s a lot better than editing directly in the vertex buffer. Also if, for example you draw quads, have a index buffer with always the same values (a static index buffer). The values could be 0, 1, 2, 1, 2, 3 for each quad and your vertex buffer would always contain only quads, but I know, I''m out of subject, sorry...



/* Bullmax */
-------------
Reality has many forms : good and evil, black and white, ying and yang.

Share this post


Link to post
Share on other sites
just be sure the system-memory-array you use is small enough to fit into the level-1 cache (cpu-cache).
keep it under 4k id say and youll be fine.
then memcpy() the whole 4k array to the vertex-buffer.
if your vertex-format is exactly 16 or 24 bytes for example (multiple of 8), you could just use ONE vertex-struct on the stack (declared local) and memcpy() it to the VB, this should be equally in performance.

if the VB is NOT in AGP memory, youll be faster when you just fill the VB without memcpy().

bye,
-- foobar


--- foobar
We push more polygons before breakfast than most people do in a day

Share this post


Link to post
Share on other sites

  • Advertisement