PrimBuild gripe
by Tom Spilman · in Torque Game Engine Advanced · 08/16/2005 (6:33 pm) · 6 replies
Was using NvPerfHud and came across this potential issue with the PrimBuild API and people new to TSE.
The PrimBuild::beginToBuffer() will create a new vertex buffer for each call to it unlike PrimBuild::begin() which uses a buffer from the volatile pool held by the device. The comment in primBuilder.h says:
Which is false in the case of GlowBuffer::setupOrthoGeometry() which uses PrimBuild::beginToBuffer() creating a new vertex buffer on each frame.
IMO PrimBuild::beginToBuffer() probably shouldn't exist. Instead have PrimBuild::end() always return a VB and better document it to note that the VB returned is volatile and must be used before the next call to PrimBuild::begin().
UPDATE:
Looking further it seems that PrimBuild::beginToBuffer() really is just being used in a not so good way in GlowBuffer. The GlowBuffer should be holding on to that buffer for longer than that one frame as the VB returned is reference counted. GlowBuffer needs fixing at some point and PrimBuild::beginToBuffer() might just need better documentation on how it is best used.
I'll make any of these changes and submit the patch if Brian, Ben, Pat agree with all this.
The PrimBuild::beginToBuffer() will create a new vertex buffer for each call to it unlike PrimBuild::begin() which uses a buffer from the volatile pool held by the device. The comment in primBuilder.h says:
Quote:
/// The other way to use this is to use the beginToBuffer()
/// and endToBuffer() calls, which let you store the
/// results of your intermediate calls for later use.
/// This is much more efficient than using the immediate style.
Which is false in the case of GlowBuffer::setupOrthoGeometry() which uses PrimBuild::beginToBuffer() creating a new vertex buffer on each frame.
IMO PrimBuild::beginToBuffer() probably shouldn't exist. Instead have PrimBuild::end() always return a VB and better document it to note that the VB returned is volatile and must be used before the next call to PrimBuild::begin().
UPDATE:
Looking further it seems that PrimBuild::beginToBuffer() really is just being used in a not so good way in GlowBuffer. The GlowBuffer should be holding on to that buffer for longer than that one frame as the VB returned is reference counted. GlowBuffer needs fixing at some point and PrimBuild::beginToBuffer() might just need better documentation on how it is best used.
I'll make any of these changes and submit the patch if Brian, Ben, Pat agree with all this.
About the author
Tom is a programmer and co-owner of Sickhead Games, LLC.
#2
It seems to work just fine. The same or similar should occur with the blend of the final glow surface right below.
08/16/2005 (7:10 pm)
I'm actually trying to go thru potential optimizations as i'm having that nvidia framerate issue and i kinda need to solve it. I just stuck this in my GlowBuffer::copyToScreen():// In glowBuffer.h i added RefPtr<GFXVertexBuffer> mGlowVB;
if ( !mGlowVB ) {
GFXVertexBuffer *glowVB = NULL;
setupOrthoGeometry( &glowVB );
mGlowVB = glowVB;
}It seems to work just fine. The same or similar should occur with the blend of the final glow surface right below.
#3
Yep, looks like there may be a leak there too since it appears to be creating a new buffer every time. It's unclear why D3D isn't bitching about a memory leak related to that though.
Your solution above looks acceptable.
If you are trying to determine the impact of the glow buffer, you should eliminate its use entirely by deleting glowbuffer.cs (or commenting out "new GlowBuffer()").
08/22/2005 (6:33 pm)
I agree the begin/endToBuffer needs to be better documented.Yep, looks like there may be a leak there too since it appears to be creating a new buffer every time. It's unclear why D3D isn't bitching about a memory leak related to that though.
Your solution above looks acceptable.
If you are trying to determine the impact of the glow buffer, you should eliminate its use entirely by deleting glowbuffer.cs (or commenting out "new GlowBuffer()").
#4
I did eventually comment out the allocation of the glowbuffer in the script file. It made no visible impact in my issues with the 6600 GT.
08/22/2005 (6:54 pm)
Actually there is no leak... i thought this myself at first. The buffer is reference counted and once all references (the internal PrimBuild reference and the device reference from setVertexBuffer) are cleared it is freed.I did eventually comment out the allocation of the glowbuffer in the script file. It made no visible impact in my issues with the 6600 GT.
#5
Have you tried removing terrain to see if that speeds up your 6600 situation? I believe I did that with a 6600 and it sped way up.
08/23/2005 (5:47 pm)
Ah, OK then, good news on the leak ;)Have you tried removing terrain to see if that speeds up your 6600 situation? I believe I did that with a 6600 and it sped way up.
#6
08/23/2005 (5:54 pm)
There is no terrain or water in my scene. Just a DIF and some DTS shapes. 
Torque 3D Owner Tony Richards