4 ms·
You misread OPs point. He is saying Windows can do both. And vsync across cards. That is quite a feat. If using separate outputs, this is probably achievable
by ccrush 11y ago
You misread OPs point. He is saying Windows can do both. And vsync across cards. That is quite a feat. If using separate outputs, this is probably achievable on Linux with a bit of work. Also vsync with a compositor shouldn't be impossible. However, if the processing is done on on two graphics cards and we output only on one of them then we need cooperation from the device manufacturers to provide us drivers or implementation details on how to drive their hardware muxers. Without that info, we're dead in the water.
- makomk 11y agoInitially at least, I don't think Windows did anything of the sort - laptop vendors were shipping carefully-vetted and tweaked versons of the Intel and $OTHERVENDOR drivers that knew how to talk to each other and couldn't be upgraded in the normal way. Naturally, they didn't bother doing this for Linux.
- datenwolf 11y ago> And vsync across cards. That is quite a feat. Well, what it does is, that the compositor (DWM) keeps a (small) backlog of presented window framebuffers (think GL SwapBuffers, that add to the queue) and whenever a screen's VSync comes along it blits the most recent picture presented to it. Which has the effect that if you have a window spanning multiple GPUs' outputs they may not all show the same frame, because the display refresh frequencies will beat (even if you set the same refresh frequency on all outputs, since between different GPUs they're not driven by the same clock, you'll get a little bit of clock skew; and video clocks are usually not of the low drift type, because for video it doesn't matter if you're off a few ppm). If you need synchronized video sync vendors are happy to sell you genlock-able cards for $$$.