How frame timing ACTUALLY works on Model 3

[gm_matthew]

I think I've cracked exactly how frame timing works on the Model 3: every game on startup writes a value into TileGen register 0x08, and this value is how many active video lines to display before signalling Real3D to flip the ping pong bit and start calculating polygons for the next frame. Most games write 0xEF (239) or 0xEE (238), although The Lost World writes 0x17F (383), Daytona USA 2 writes 0x14F (335), and Sega Rally 2 and Star Wars Trilogy Arcade both write 0x170 (368). Note that The Lost World sets the value to exactly one less than the number of active video lines (384).

Tests performed on a real Model 3 board running Virtua Fighter 3 revealed that ping pong flip occurred about 66% of the frame time after IRQ2; 239 display lines + 40 blanking lines = 279 lines, and 279 / 424 = about 65.8% of the frame (!!!) I must admit I got quite excited when I figured this out

Both Sega Rally 2 and Star Wars Trilogy Arcade wait until IRQ2 before starting to process the next frame on the CPU side, whereas all other games wait for ping pong flip. With the current frame timing in Supermodel this means 33% of PowerPC cycles are wasted, but these games set it up so that ping pong flip occurs much later in the frame and so fewer cycles are wasted on real hardware (about 4% total).

In addition, I have deduced what IRQ8 and IRQ4 represent: they signal when Real3D has finished geometry T&L and rasterization respectively. The timing debug screens present in most games list GP as the time between IRQ8 and ping pong flip and DP as the time between IRQ4 and IRQ2. This basically confirms that 3D rendering is done in two separate stages on Model 3, which I had been theorizing about for a while.

[Ian]

Wow amazing findings Mathew. Many people have been stumped by this for a long time

I wonder if these findings could help resolve the rolling start bug with scud race where the text mask goes out of sync

[Bart]

Wow this is awesome! Great job, man! I would have never figured this out.

GP = Geometrization Period?
DP = Display Period?

So here's a question: For games that set the flip to occur at 66% of the frame, is it possible that rasterization finishes within the remaining 33%, thereby displaying the results on the next frame? This would be similar to 2D games that set up the screen on frame N with the results appearing immediately by frame N+1. However, for SWT or SR2, it seems like setup would occur in frame N, geom+raster in frame N+1, and it would be displayed in frame N+2 (assuming the frame buffer is double buffered, which it almost certainly is). Do you think that is correct?

[Ian]

I assumed the 66% time was the last time you could write to the gpu for that frame. Any other writes after that time would be for the next frame. That gives the gpu around 5ms to process the scene graph and do the rasterizing before vblank happens. But of course these assumptions could always be wrong.

[gm_matthew]

Wow this is awesome! Great job, man! I would have never figured this out.

GP = Geometrization Period?
DP = Display Period?

So here's a question: For games that set the flip to occur at 66% of the frame, is it possible that rasterization finishes within the remaining 33%, thereby displaying the results on the next frame? This would be similar to 2D games that set up the screen on frame N with the results appearing immediately by frame N+1. However, for SWT or SR2, it seems like setup would occur in frame N, geom+raster in frame N+1, and it would be displayed in frame N+2 (assuming the frame buffer is double buffered, which it almost certainly is). Do you think that is correct?

I'd guess they stand for Geometry Processing and Display Processing. It doesn't really matter what they're called as long as we know what they do

The timing makes sense; at ping pong flip the frame buffers have not yet been swapped so there is still time to finish off rasterization. I believe that the "setup in frame N, render in frame N+1, display in frame N+2" is how any modern GPU works since it allows the CPU and GPU to run in parallel. Modern GPUs can optionally queue up additional frames, potentially resulting in more consistent performance but at the cost of latency.