4 hours ago, turanszkij said:

Interesting, and what happens when you have 2 back buffers and maximum frame latency of 3? Doesn't in this case 2 the maximum number of frames that can be queued up? Would it make sense to take the minimum of [maximum frame latency and backbuffer count] to determine how long we need to wait for a resource to be finished on the GPU? 

The CPU can queue up three frames. If your GPU work is super fast, and you're fullscreen or using windowed flip model, and you requested VSync, then the GPU will only render two frames, and then stop and wait for the screen/compositor to be done with one of your buffers before continuing. If you're using windowed blt model, or not using VSync, then the number of buffers you have doesn't matter, because the GPU never needs to wait for anything before overwriting them. If your GPU work is slow, then the GPU doesn't need to wait because it was busy working while the buffers were being used.

Thanks for the replies.

The reason I was doing picking this way is that it seemed like a much simpler approach, as it just works, no matter how complicated the geometry is. Testing the geometry on the CPU is a lot more work (programming wise), it also means I would need to have a copy of the geometry on the CPU as well as the GPU, which I currently don't have.

The suggestion for doing the picking on the GPU sounds very clever. My only issue with that is that I also need to support marquee selection of objects in the viewport, which that wouldn't really work with. Although your suggestion of optimising how much I actually read back (single pixel, or small rectangles for marquee) makes a lot of sense and something I'll add. I probably don't even need to be reading back every frame either, only when a pick, mouse move (for hover indication) or marquee selection is requested.