Jump to content
  • Advertisement
Sign in to follow this  
DayOldPudding

Beginner Optimization in DX10

This topic is 3342 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'm writing a 2D app in DX10. Everything is drawn using quad aligned to the XZ axis. I just turned on the Environment renderer and my game now crawls along at about 2 frames per second. The environment is just a bunch of quads, each using this code to draw:
// Transforms this quad's UV values to source its texture as appropriate 
g_pUVTransformVariable->SetMatrix( ( float* )&m_uvTransform);

// Set shader's texture variable for the quad
g_pDiffuseVariable->SetResource( m_pTextureRV ); 
		
D3D10_TECHNIQUE_DESC techDesc;
g_pTechnique->GetDesc( &techDesc );	
for( UINT p = 0; p < techDesc.Passes; ++p )
{
    g_pTechnique->GetPassByIndex( p )->Apply( 0 );
    g_pd3dDevice->DrawIndexed( 6, 0, 0 );
}

There's a lot of low-hanging fruit here, and I'm hoping for suggestions on where to focus first. The environment is made of about 600 quads that all try to draw using this code. Most of these quads are outside the frustum, and I don't have any kind of frustum-culling in place, which is a clear opportunity - but I wouldn't have thought 600 quads would be THAT taxing (running an Nvidia GeForce 8600M GT). Are there other opportunities here? For instance, is setting the texture resource view expensive? Should I sort my draw-order by texture? Is applying a shader technique expensive? The same shader is used to render every quad, so there's no point in setting and resetting it hundreds of times per frame. (However, when I set it only once per frame I get the following error: "[ EXECUTION INFO #353: DEVICE_DRAW_SHADERRESOURCEVIEW_NOT_SET ]" for every quad drawn. Should I be drawing using triangle strips instead of lots of quads? Any and all suggestions are welcome. Thanks very much.

Share this post


Link to post
Share on other sites
Advertisement
From what i have as information (without code precise optimization cannot be done)

1) 600 separate draws call are A LOT. Depending on the CPU, you may put a big stress on it slowing down the GPU. (Try batching your calls by texture with instancing or a single buffer. You will get a big speedup)
2) Using trianglestrip over trianglelist if your data is all adiacent will be a minor, but useful speedup caused by reduced memory transfer.
3) Yes applying the shader tecnique is quite costly on the CPU side (slowing down the GPU), if you have only to change the texture instead of reapplying everything, just set the texture using the lowlevel PS functions.

With everything said, i really doubt the game should go 2 fps with that configuration. Maybe there is something other slowing it down, but without code its difficult to tel.

Share this post


Link to post
Share on other sites
600 draw calls is expensive, though, it shouldn't be prohibitively so. How big are these quads that you are drawing? Is there a lot of overlap between the quads? (if so, and the quads are opaque, you are wasting time drawing over top of existing pixels) Its also possible that you are taxing your video card with drawing an enormous number of pixels.

While it won't make a huge difference (probably not even noticeable), but you can save the result from g_pTechnique->GetDesc and not repeat that function call for every quad every frame.

If you comment out your DrawIndexed calls, is your frame rate still bad? If so, there is a major performance problem elsewhere in your code.

Share this post


Link to post
Share on other sites
Yeah, when I comment out the ->DrawIndexed() only the app runs fine. It also appears the 2 frames per second was a freak occurrence, because I can't repro it. The game is still very choppy with the call enabled, but it's more like 10 fps.

Thanks for the good ideas. I've got a lot to think about.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!