memcpy after Lock() ?

Started by
5 comments, last by Coudrak 22 years, 2 months ago
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
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
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
_________WebSnozz"We should genetically engineer cats and dogs to have butt cheeks so we''ll be warned when they fart."
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
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
Nathan Voshttp://www.triple-interactive.nl/nathan
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.
/* Bullmax */-------------Reality has many forms : good and evil, black and white, yin and yang.
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
--- foobarWe push more polygons before breakfast than most people do in a day

This topic is closed to new replies.

Advertisement