Skip to main content
gamedev.net
🔒 Locked

memcpy performance issue

Started by HanSoL0 Jul 16, 2004 at 8:33 AM 4 replies 750+ views
Original Post
HanSoL0
HanSoL0
Hey guys, I'm having a bad performance problem when trying to concatenate some DirectX vertex buffers using memcpy. The particular code I'm having issues with isn't DirectX-specific, so that's why I'm posting here instead. I'm wondering if anyone can spot any obvious bugs in these few lines:
// Concatenate the missile trail vertex buffers into one big buffer
for (m = 0; m < pr_num_missile_tubes; m++)
{
	for (i = 0; i < MAXAMMO; i++)
	{
		for (int c = 0; c < MAX_VAPORTRAIL_SECTIONS; c++)
		{
			pr_vaporVerts[(m * (MAXAMMO * MAX_VAPORTRAIL_SECTIONS * 2)) + (MAX_VAPORTRAIL_SECTIONS * 2 * i) + (c * 2)] = pr_missile[m].vaporVerts[(MAX_VAPORTRAIL_SECTIONS * i + c) * 2];
			pr_vaporVerts[((m * (MAXAMMO * MAX_VAPORTRAIL_SECTIONS * 2)) + (MAX_VAPORTRAIL_SECTIONS * 2 * i) + (c * 2)) + 1] = pr_missile[m].vaporVerts[((MAX_VAPORTRAIL_SECTIONS * i + c) * 2) + 1];
		}
	}
}

// Activate the main vertex buffer
VOID* pVertices;
if (FAILED(pr_missileTrailsVB->Lock(0, sizeof(pr_vaporVerts), (BYTE**)&pVertices, 0)))
        MessageBox(NULL, "Missile trail vertex buffer locking failure.", "Error", MB_OK);
memcpy(pVertices, pr_vaporVerts, sizeof(pr_vaporVerts));        // THIS IS THE OFFENDING LINE!!!!
pr_missileTrailsVB->Unlock();


Thanks for any help you can possibly give. If you need any more explaination of the problem or my algorithms here, please ask. Thanks,
Agony
Agony
Maybe I'm thinking wrong, but couldn't you use the flag D3DLOCK_DISCARD to lock the vertex buffer before your loop, and then copy all the vertices straight to the vb, and therefore never need to use a memcpy? D3DLOCK_DISCARD will tell D3D that you don't care about the contents in the vb previously, and it will therefore actually create a second area in memory, while keeping the original vb untouched, if it is currently being used by the GPU, and then when you unlock, it will basically get rid of the previous data, and point to this new data instead, but to the programmer, it looks like the same vb with new data. So this prevents the Lock() from stalling the GPU. (I'm assuming that's the reason you Lock() only when you do a memcpy(), in order to reduce the amount of time that the vb is locked.)
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas nly, and not for things themselves." - John Locke o
phlaz
phlaz
I'd say the problem is not the memcpy but that nasty tripple nested loop.
HanSoL0
HanSoL0
Agony, that's a terrific idea. I'll have to try that when I get home. Thanks for the quick reply! :)

Quote:
I'd say the problem is not the memcpy but that nasty tripple nested loop.


Actually, that uber-loop runs fast enough. If I comment out the memcpy line, I get my 60fps back, but when the memcpy happens, I drop to about 15fps. I tried commenting out the entire loop, and my framerate didn't increase much.

Again, thanks for the quick replies guys. :) Have a great day.
Etnu
Etnu
Your frame rate jumps to 60fps when you omit the memcpy because nothing is being drawn at that point...

Anyway, the problem is that you're not using D3DLOC_DISCARD / D3DLOCK_NOOVERWRITE. You're creating a brand new VB from scratch every frame. Ouch.
---------------------------Hello, and Welcome to some arbitrary temporal location in the space-time continuum.
HanSoL0
HanSoL0
Quote:
Original post by Etnu
Anyway, the problem is that you're not using D3DLOC_DISCARD / D3DLOCK_NOOVERWRITE. You're creating a brand new VB from scratch every frame. Ouch.

Ah, thanks for clearing that up. That makes sense. If only I knew the particulars of all this manual VB creation and modification....

*sigh*

Thanks for the feeback. [smile]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.