4 replies to this topic

[Steven Hansen]

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]

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]

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]

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]

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