0

I would like to synchronize rendering within my Direct3D9 application with the monitor's refresh rate. I would like to avoid using VSync because it locks processing until each frame is rendered thus reducing frame rate. Ultimately, I would like to 'present' a frame only 60 times per second and process frame data between each call to 'present'.

Is there a way of 'hooking' the monitor?

P. Avery
  • 779
  • 1
  • 16
  • 34
  • Why not double (or triple) buffer your rendering pipeline? You don't need to pause processing to wait for vsync; you just need to make sure you don't flip to the next buffer except during vsync. – Peter Duniho Mar 08 '15 at 16:06
  • @PeterDuniho I agree with triple buffering but what do you mean 'make sure you don't flip to the next buffer except during vsync'? With triple buffering couldn't I eliminate vsync altogether? That's what I would like to do because I need to process data between frames... – P. Avery Mar 08 '15 at 16:27
  • 1
    By "flip" I mean to change the _displayed_ buffer. In general, you want to avoid doing that except during vsync, so as to prevent tearing. You can structure your code so that you have one thread doing the data processing (i.e. a producer thread), and one thread doing the buffer presentation (i.e. a consumer thread). The consumer thread would flip buffers during vsync, preventing tearing and also giving you a signal you can use to know when vsync has happened (it's not clear from your post _why_ you actually want to know this...I'm just taking for granted there's a real need :) ). – Peter Duniho Mar 08 '15 at 16:30
  • @PeterDuniho so, the idea is to use vsync along with multithreading? Will the 'producer thread' execute while vsync is waiting for monitor refresh signal? – P. Avery Mar 08 '15 at 16:35
  • 1
    I don't see why it wouldn't, but it does depend on the exact code, which you haven't shared. The thread that waits will be the consumer thread; it will wait on vsync, and might also have to wait on the producer thread (if the scene is too complicated to render at the monitor's refresh rate). You may wind up having to throttle the producer thread, if it winds up being able to produce frames faster than the monitor's refresh rate. Again, you're not very clear about what data processing you want; if it's unrelated to the actual rendering, then you can let it run unthrottled. – Peter Duniho Mar 08 '15 at 16:38
  • @PeterDuniho the data processing between frames would be handled by CPU(not GPU). Although, potentially, some of the processing could be handled by the GPU...occlusion queries for visibility testing – P. Avery Mar 08 '15 at 16:45
  • Obviously processing in the producer thread would be handled by the CPU. But just as obviously, _some_ processing for each frame is done by the GPU; that's just not represented as a thread in your program. In any case, as I've mentioned, by running your processing in a separate thread from the thread handling presentation of the frame buffers, it can take advantage of the activity of the presentation thread (which is waiting for vsync on each frame) to know when vsync has occurred. – Peter Duniho Mar 08 '15 at 16:51

0 Answers0