Sort of, when doing normal async reprojection there is a reserve of CPU power to catch when a frame isn’t going to make it in time to then resend the previous frame and move the frame to compensate for head movement. So when always on reprojection is enabled that reserve (idle-sleep) doesn’t occur and a bit more CPU is released for use by the pc if required.
Just like assigning power to systems in ED / Bridge Crew
But when always on reprojection is on, it’s not able to compensate for large head movements, just slight. So it would make things look more bleh if you’re in anything other than seated games.
I am no engineer of Pimax’s, nor of their display manifacturer partner’s, nor an engineer in any way or capacity whatsoever, for that matter, but I can only surmise this would all be part of the normal operation cycle of the… what was it? -“Customized low persistence liquid” displays, that the former has commissioned from the latter.
The signal from the graphics card contains the VBlank synchronisation pulse, that causes refresh to start (/me shoves the carriage return arm of ye olde typewriter back to its home position on the right. ding!, and inserts a new sheet of paper ratchet, ratchet :P); The bridge chip should catch this incoming image data, pumped by the graphics card at a clock rate that the receiving device can handle, and translate it to to the MIPI protocol of the displays, however that works, from which point I figure the logic and drivers that go with the display would take care of the rest; Wait for the raster scan to finish, holding all pixel values, and then trigger the backlight pulse. …but I suppose clocks and control could lie just about anywhere the designer wanted it. :7 (TLDR: Aahdunno. :P)
(Anecdotally: You may recall that early Valve HMD prototypes had two phone screens in portrait mode, with the bottom third of each screen just sticking out below, impossible to be seen through the lenses…?
It feels kind of safe to conclude that the reason they were built that way, was in order to botch 90Hz out of 60Hz panels, whereby you’d simply forget about the last part of the screen, and send a new VBlank, restarting refresh with the next frame, without letting the previous frame roll all the way down to the bottom of the screen. :7)
So I’m understanding that it really lies within the behavior of the mipi protocol for what level of synchronization is happening. Super awesome answer, please don’t stop talking. Serious. I’d love to know more about point a from the gpu to point z of the backlight, data synchronization and pixel timings.
Maybe I would, had I had more of a half-clue what I am talking about.
Would be cool if one of the engineers on the project were to chip in with some real technical information (as opposed to the usual ambigous-to-misleading PR guff), relevant to the specific product. :7
