Hardware Page Flipping

From what I understand, Hardware Page Flipping accomplish the same effect of V-Sync, but without the latency caused by double/triple buffering (still more latency/variance than a-sync).
So here are some of my questions:
Does AMD/Nvidia’s graphics cards have hardware page flipping?
Does TearFree option in xorg config uses hardware page flipping when available?

No quite. Two different things.

Hardware page flipping at the wrong time will still cause a tear.

The tear is caused by the monitor refresh having the display change half-way through an update.

Whether that is hardware page flip or any other means, the tear will happen.

VSYNC ensures that the page flip happens during the “vertical blanking interval” - which is the time in between screen updates.

All cards since at least EGA or CGA have hardware page flipping as i understand it.

edit:
I was messing with hardware page flips and vertical sync back with Turbo Pascal and inline assembly poking at the VGA card back in the 90s :smiley:

You’ll probably find that any display driver, game, etc. these days is most likely already using hardware page flipping.

What hardware page flipping CAN help with (especially back in the day with SLOW CPUs and slow access for writing to video memory in particular) is ensure that a complete screen re-draw happens off-screen and you’re ready for the new screen update in time, as the hardware page flip is fast enough to be virtually instant. So you can get it done within the vertical blanking interval. i.e., you still wait for vsync, you just do the hardware page flip on vsync…

1 Like

Ah, looks like I completely missed the point. I thought it will to something clever like flip a page during V-blank when the back buffer is ready(and don’t flip if not).

Edit: I mean flip page when the back buffer finish drawing and the front page not being scanned.

Nah, the page flip happens when you tell it to happen (as i understand it, unless something has happened in the meantime with the technology - essentially it’s just an address register in the card).

To get it to happen at the correct time, you simply wait for vsync then tell it to flip.

What hardware page flipping does help with is avoiding the need to either transfer a CPU memory region over the bus “in time” during the refresh interval (traditionally, accessing video memory over the ISA bus for example was real slow in comparison to “drawing” to a buffer in CPU memory then blasting it to the card in one big chunk), OR the problem of trying to get all your “on-screen” drawing done before the vertical refresh catches up (if you weren’t fast enough, the things you hadn’t put on screen yet wouldn’t be displayed if the scanline reached them before you drew them).

edit:
ISA was so slow, lol. 4.77 - 8 mhz with 8 or 16 bit transfers :smiley:

That’s too sad, wouldn’t it be nice if it was implemented like this(pseudo c):

pixel buffer[2xDISPLAYSIZE];
pixel *pagep = &buffer;
int s = 0;

gpu side:
start_drawing_stuff(...info...) {
    t = (s + 1) % 2;
    ...
    write to *pagep + (t x DISPLAYSIZE) (not faster than scan line)
    ...
    s = t;
    return;
}
display side:
display_stuff() {
    read from *pagep + (s x DISPLAYSIZE)
}

It’s more efficient than that. Well. It essentially does the same thing. Just in hardware, not in code you have to write to drive it.

The display adapter outputs what is in a memory buffer (no code to make it do that).

The “page flip” is essentially just telling it to display a different part of it’s video memory on the next screen refresh. i.e., essentially changing the address of a register telling it where to start.

the reason I wrote it in code is that I feel like it explains the logic better
in this implementation “page flip” can happen at any time, because the scanning part takes a copy of the start address, and the write head doesn’t over take scan head.
In other word, the gpu draws and flips the page immediately when it’s done, and when ever the monitor needs a frame, the pointer is always pointing the the latest completed frame, and thus minimum display delay.

AMD offer enhanced sync, where i think they triple buffer, and if the frame rate is faster than the vsync, the vsync may skip frames.

I believe AMD “enhanced sync” does pretty much exactly what you describe?

It looks pretty similar, and more advanced than what I have in mind! I’m surprised it only came out in 2017.