steven_hansen at December 14th, 2004 14:09 — #1
DirectX specific question. Does Present() block until the hardware has finished presenting?
--- Specific scenario: Present_Interval_one, 2 back buffers - I would expect Present() to *not* block (unless back logged of course), but the tests we are making on both ATI and NVidia hardware are both blocking for the entire 1/60th of a second interval. However, if Present() blocks under this scenario, multiple backbuffers wouldn't provide any benefit whatever (no triple buffering). Anyone *know* the answer to this? ---
bladder at December 14th, 2004 18:50 — #2
IIRC Present does block. But only after a certain number of frame buffers have been filled up. WHQL certified drivers allows at max a 3 frame buffer queue. But after the frame buffer queue is filled up. Present will have to block.
steven_hansen at December 14th, 2004 19:34 — #3
The behavior you guess would be mine as well. However, our tests are showing otherwise...
Every frame we have (even with 3 back buffers) takes 16 ms to do nothing but clear the buffer. This includes the first 3 frames (which according to our guess shouldn't block because the buffer queue hasn't been filled yet). I would expect the first 2 frames to take absolutely zero time, and then frames to start taking 16 ms.
Is it possible that triple buffering does not work with D3DPRESENT_INTERVAL_ONE?
bladder at December 18th, 2004 23:27 — #4
Well WHQL does say *upto* 3 buffers in the queue. Maybe the driver implementation you have dosent make use of that... But either way, is this really a bad thing if present is blocking?
bladder at December 19th, 2004 04:46 — #5
doh! I just realized. You're specifying interval_one, so there is no way the frames will be shown faster then your refresh rate. So if it's every 16 milliseconds, Im gussing your refresh rate is at 60? interval_one is synced with the vertical retrace. Try interval_immediate if you want different behaviour