New Vulkan Extension Could Enhance Frame Timing Controls For Games

[phoronix]

Phoronix: New Vulkan Extension Could Enhance Frame Timing Controls For Games

Longtime X11 developer Keith Packard who has been working on various infrastructure improvements to the Linux desktop in recent years under contract for Valve has been eyeing the creation of a new Vulkan extension for dealing with frame timing behavior for Vulkan apps/games...

http://www.phoronix.com/scan.php?page=news_item&px=Vulkan-Present-Period-Proposal

[torbido]

That will be great. If the frame takes a lot of time to render, and misses its time, the next frame takes its place. That may drop the frame rate with heavy games, but it will make the frame time a lot smoother, and consistent.

[patstew]

Isn't the _GOOGLE_ extension doing what you'd normally want? Surely it's better to display a frame *at* the time it was intended rather than *for* the time intended? If you accumulate the delay from every delayed frame, won't that make judder worse?

[Brisse]

It's nice to see really smart people like Keith doing good work that will benefit gamers, while most gamers are probably like "OK Boomer... Moar frames! No such thing as an early frame!".

[nranger]

Isn't the _GOOGLE_ extension doing what you'd normally want? Surely it's better to display a frame *at* the time it was intended rather than *for* the time intended? If you accumulate the delay from every delayed frame, won't that make judder worse?

A properly written render thread won't accumulate delay. To properly calculate changes in the game world, the engine needs to know the length of time between when the last frame was displayed and the next one. If the game starts over and underestimating frame times, then animation will start rubber-banding and causing micro stutter. Better feedback from the driver pipeline is good.

[tildearrow]

That will be great. If the frame takes a lot of time to render, and misses its time, the next frame takes its place. That may drop the frame rate with heavy games, but it will make the frame time a lot smoother, and consistent.

Isn't this what the NES did first? If processing takes too long it drops the framerate to half (by waiting for the next VBlank interval).

How did they screw this up? By making Adaptive VSync a mandatory thing, right?

[bregma]

How did they screw this up?

Who said they screwed this up?

In OpenGL, when you had a frame complete, you'd tell the system "OK, this frame is complete, swap to it now". WIth Vulkan, you fill frames and queue them as fast as you can and the system flips to them at the right time. With OpenGL, if you missed a swap deadline everything gets pushed back and you start to get frame lag and all the usual symptoms but if you're ahead of schedule you just sit an wait, doing nothing. With Vulkan, you can still fall behind filling the queue but at least you can fill the rest of the time with real work. So they did. Next thing you know, the real work is taking so long (say, doing raytracing on your dual 4K screens) that you start to miss deadlines.

For all the web devs here familiar with synch, OpenGL is synchronous with the frame swapping, and Vulkan is asynchronous. The problem with asynchronous is knowing when the frame gets displayed and when the buffer will be ready again.

There's no screwup. Things are working as they should. What Vulkan really needs is a way for the application to know the frames have been displayed and that it needs to stop dicking around with the physics engine and make sure that display queue is full.

[tildearrow]

Who said they screwed this up?

In OpenGL, when you had a frame complete, you'd tell the system "OK, this frame is complete, swap to it now". WIth Vulkan, you fill frames and queue them as fast as you can and the system flips to them at the right time. With OpenGL, if you missed a swap deadline everything gets pushed back and you start to get frame lag and all the usual symptoms but if you're ahead of schedule you just sit an wait, doing nothing. With Vulkan, you can still fall behind filling the queue but at least you can fill the rest of the time with real work. So they did. Next thing you know, the real work is taking so long (say, doing raytracing on your dual 4K screens) that you start to miss deadlines.

For all the web devs here familiar with synch, OpenGL is synchronous with the frame swapping, and Vulkan is asynchronous. The problem with asynchronous is knowing when the frame gets displayed and when the buffer will be ready again.

There's no screwup. Things are working as they should. What Vulkan really needs is a way for the application to know the frames have been displayed and that it needs to stop dicking around with the physics engine and make sure that display queue is full.

Sorry but I thought OpenGL swap behavior was driver-dependent because when I call glXSwapBuffers() it does not block until swap completion but rather returns immediately, which means queueing of the swap. Only doing some graphics operation (like glClear) blocks.