"Present" whacks up CPU usage to 25%!
Author
Hi there,
I have NOTHING in my render loop - nothing at all - except a Clear of the screen and a "present":
m_pd3dDevice->Present( NULL, NULL, NULL, NULL );
The trouble is, my CPU usage goes right up to 25% when I use the present, and its near zero when I don''t. I''m thinking there is some software dodgyness going on with my backbuffer swap. Here is how I create my device:
D3DPRESENT_PARAMETERS d3dpp;
ZeroMemory( &d3dpp, sizeof(d3dpp) );
d3dpp.Windowed = TRUE;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.BackBufferFormat = D3DFMT_UNKNOWN;
if( FAILED( m_pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd, D3DCREATE_HARDWARE_VERTEXPROCESSING,
&d3dpp, &m_pd3dDevice ) ) )
Did I do something dumb here?
Thanks for any hints.
No, 25% seems about right. The CPU can''t do anything while it is waiting for the video card to finish. Don''t worry about CPU usage...
quote:Original post by Robbo
But why does it wait for the card to finish? I have a "sleep(20)" in my message loop.
...Why...?
It has to wait for the video card to finish. Common sense...
Because functions finish before returning. Imagine then if I did something else with my Direct3DDevice (say release it.) If that Present was still doing something we would only hope that it doesn''t crash.
Even if you release the device, the IDirect3D9 (or whatever version you are working with) is a COM interface that is referenced counted.
The thing to realize is that the GPU and the CPU both cache operations and don''t necessarily execute instructions at the time the functions are being called (and not necessarily in the order called).
So Present doesn''t necessarily just swap buffers.
The thing to realize is that the GPU and the CPU both cache operations and don''t necessarily execute instructions at the time the functions are being called (and not necessarily in the order called).
So Present doesn''t necessarily just swap buffers.
KershAtWork is right. Present can queue and execute asynchronously.
What''s most likely happening here is that the CPU is feeding Clear and Present operations to the driver faster than the hardware can execute them. This obviously can''t continue indefinitely, so drivers are supposed to block once they''ve accumulated three frames worth of commands.
What''s most likely happening here is that the CPU is feeding Clear and Present operations to the driver faster than the hardware can execute them. This obviously can''t continue indefinitely, so drivers are supposed to block once they''ve accumulated three frames worth of commands.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
