Ever seen the GPU rendering in slow motion?

Graphic based area of development (Graphics Processing Unit), including the Geometry Transform Engine (GTE), TIM, STR (MDEC), etc.
Post Reply
User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 574
Joined: Nov 12, 2012
Contact:

Ever seen the GPU rendering in slow motion?

Post by nocash » November 4th, 2022, 8:53 am

Here's a small demo that allows to view the GPU rendering in slow motion. Apparently, the GPU does always start at the left-most vertix & progress downwards, and does then restart at left-most vertex & progress upwards. With corner cases when drawing polygons or lines with two left-most vertices.

The demo is displaying 15 triangles at different rotations, one rectangle, and one line with eight line segments.
All items are first drawn in dark gray (to indicate the drawing region), and then drawn in color (but getting aborted via GP1(01h)), the aborts are happening after increasing delays to create the slow motion effect.

That's probably not working in any emulators, but you can view it on real hardware; if you have some flash/cable for testing (please don't waste CDRs for that). If you have a video grabber, feel free to record a video or post some screenshots near begin/middle/end of the drawing operations.

Observe that the coordinates of the red/blue vertices are swapped after each pass (that affects the drawing order of the upper-left triangle; that with two left-most vertices).
You do not have the required permissions to view the files attached to this post.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 574
Joined: Nov 12, 2012
Contact:

Post by nocash » December 23rd, 2022, 4:01 am

Last unknown GPU command GP0(03h)... is timing related!
I've tried to insert GP0(03h) in the above test program... mostly because I wanted to see if it requires additional parameter words, or if it does affect the visual appearance, I didn't specifically watch out for timing stuff... but I've been lucky there: With GpuSloMo being a timing test, it's been easy to spot that GP0(03h) is affecting the timings.

The difference isn't too significant, but it's well visible: With the slowest setting it's finishing only 98% of the triangle pixels (the default/fastest settings does finish all pixels and does then keep displaying the fully drawn triangles for a moment).

Code: Select all

GP0(03h) - Memory/Timing Control - New 208pin GPU only?
  1st  Command           (Cc00000xh)
The lower 4bit affect the GPU rendering speed (00h=Fastest, 0Fh=Slowest)
(probably related to VRAM access or VRAM refresh). The other 20bit seem to have
no effect on VRAM write timings (they might be unused, or have other purposes
like VRAM read timings or buswidth/cache control or whatever).
The command isn't used by any known games, so the existing games are always
using the default speed (which seems to be 00h, or at least close to that).
Old 160pin GPUs do not add GP0(03h) to the FIFO (that is, it's probably not
supported at all, or it's executed immediately without using the FIFO).
Still unknown details...
- measure clock cycles and try to determine any relation to pixels/texels
- scope test memory access signals
- test if the command is really fully ignored on old 160pin GPUs
- do more tests to see if the upper 20bit have some effect
- verify if default is 00h (and if GP1(00h) does restore that default)

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests