Foveated rendering requires eye tracking to be AT LEAST within 4 milliseconds from tracking to input the coordinate to the processing unit, because it has to be ALWAYS before the actual render begins. And since it has to work even with games which are native on 120 fps, eye tracking has to track at least 240 times per second. That's the bare minimun in this situation. The coordinate can arrive after the render defined the poligons, but resolution and rendering quality must be defined only after eye position has been updated. The window is very narrow, but eye trackers can sample even at higher frequency (480 samples per second).
I'm aware of the trackers being high-frequency, but IMO - that's not really the big problem (ultimately hw either works, or it doesn't ;P ). But the software stacks/engines are just
not low latency for most part - in fact for 3rd party middleware the complete opposite is usually true.
That being said - the 'before
render begins' - I'm not sure we're using the same terminology here, but there are a bunch of implementation details that dictate what's even possible. Eg. if you're deferred (and have some form of pixel/fragment processing control - VRS or similar) it's totally possible to insert eye-tracking inputs very late in the
GPU frame - at least on a console. This is the most optimal way to handle all VR inputs - but the number of games that have done so for hand/head tracking are probably less than what we can count on two hands in entire history of modern VR. No idea if eye-tracking will spearhead a revolution on it - finally (and presumably Sony SDK offers some support to make it easier now).
On the flip-side afaik on some software stacks messing with GPU parameters during execution would be prohibitively complex/difficult, so you need to insert the inputs in the Command-buffer generation frame or even earlier - which automatically puts things at least one frame behind the case above. The obvious trade-off is that if eye-tracking sensor sampling is much less predictable than other inputs, longer latencies = larger safe areas = less efficient/optimized rendering. But it'd still work.