Guesswork: How does the hardware work?

[skmp]

Resources & notes

Very interesting analysis by RTL Engineering on PS2 and CLX2 on youtube (link directly to dreamcast part)

Overal unknowns

• Is the pipeline in float? fixed point? mix?
• OIT can 'skip' (some? all?) triangles once done with them, called 'discard processing'. Does it update things in vram? It would be possible to have a special 'do not process' value that gets written. This can be tested.
• OIT may be processing PT polygons in chunks, and TR ones in their entierty? There are mentions of PT 'chunks' and TR 'cache', and not of TR 'chunks'.

ISP

We know it processes '32' pixels at once. It is a question of how that happens, interpolation wise. Does it do barycentric test x32? is it a deep interpolation pipeline with up to 32-pipes to fill?

Documentation and practice seem to support that the depth buffer is indeed 32-bit float (or at least, 31-bit, no sign). There seems to be 2 stencil bits to calculate the ModVols for shadows.

TSP

We know it processes lists of pixels RLE encoded from the ISP buffer. It does one pixel at a time, though again, it is a question on how it calculates the pixel parameters.

It is widely accepted that all parameters are perspective correct in their calculations (up to: 4 uv coords, 16 colors, though only 2/8 at the same time).

Best case throughput with bilinear filtering is 1 pixel per clock, probably deeply pipelined and buffered as well.

OIT

My opinion is that a version of layer peeling is used, both for PT (front to back) and TR (back to front) as there are several references to such a process in the documentation. The RTL Engineering video disagrees. Also, the calculations it has for the micro depth buffers would make things not fit.

TSP feedback for PT

After the pixels (a pixel?) are (is?) rendered, there is some backchannel to notify which failed the alpha tests. Those are then marked as 'to render again' for the next layer peel.

Likely, the same feedback mechanism is re-used to mark which triangles no longer have visible triangles for discard processing.

Notes from skmp

Interesting analysis, and the reliance on die imaging is intriguing. Some notes I took during the dreamcast part of the video:

• Afaik, the FA fifo is 256 bytes (in 32-byte words, for the SH4/DDT interface)
• The triangle tags are several bits (20ish iirc)
• The depth buffer also includes at least 2 bits of stencil (for modifier volume computation)
• There seem to be two depth buffers, which are used for layer peeling to process OIT (optional, only for one depth direction)
• I don't think the RLE/Span sorters are involved in the OIT functionality
• I haven't evidenced a hard limit on the amount of layers for OIT
• There is a feedback channel to synchronize ISP/TSP (for PT/Alpha Masked rendering mode), which I didn't see in the schematics / functionality description
• SS downsampling (2:1) only happens in the X direction
• The Y scaler is a separate, post-processing 3-parameter FIR filter iirc (configurable, fractional scaling)
• 32-bit textures are fully supported (RGBA8888 mode, and also in palletes), though rarely used
• Palletes can indded be broken into 4 32-bit banks or 256 16-bit banks
• In parameter space, as generated per the TA binner, there is a bit per triangle so that bin/triangle culling is exact. While the insertion seems to be based on a bounding box, it seems (?) that per-triangle, per-bin decisions are made. ldxream emulates as much, and I follow those instructions in refsw.
• I thought ISP also had a vertex cache, though maybe not? It would have been usefull for multipass texturing.
• the 2ndary accum. buffer exists for multipass texturing, and can be directly controlled from the display lists. Not sure if it plays a role in OIT, I think not, as that would be conflicting with bump map usage.
• I haven't heard before of the ISP having some limit on how many object it processes at once. It would kill the effective fill rate.
• It is indeed odd if the depth has to be re-calculated, but then, weirder things have happeend. If the spans include depth information though, that'd make sense for the input buffer on TSP.
• As far as I can tell, the pixels don't have valid bits, as there is always something drawn (bgpoly)
• The primary accum buffer is always the one used for color writeout
• There is a default TSP parameter (aka 'background polygon'), and there are specific bits to clear depth in the region array command lists, so there must be some fast-fill action going on
• It is /really/ nice to see numbers/estimates on the buffers and ports and physical structure. Would love to see your draft notes ;)

((This comment has some errata, check replies bellow for some clarifications))

[references]

refsw: https://github.com/skmp/reicast-emulator/blob/alpha/libswirl/rend/soft/refrend_base.cpp, https://github.com/skmp/reicast-emulator/blob/alpha/libswirl/rend/soft/refsw.cpp, https://github.com/skmp/reicast-emulator/blob/alpha/libswirl/rend/soft/refsw_pixel.cpp

lxdream's ta: https://github.com/skmp/reicast-emulator/blob/alpha/libswirl/gpl/lxdream/tacore.cpp

A few erratums in the above notes

It seems like palettes can do direct argb8888 and YUV gets decoded to argb8888, however there seems to not be a direct argb8888 format for textures. Fun oddity I forgot :3.

The ISP also might have up to 512(!?) vertexes cached, used during PT (alpha-test/auto sort) and TR (alpha-blend/auto sort) modes. There are registers to partition this cache.

PT mode seems to render from front to back, while TR seems to render from back to front.

Double checked, there is clear reference in various places for a 'reference depth buffer'. Not sure how the span sorter might be involved there - though that'd be trippy.

There is something mentioned for 'discard processing' in some places, which seems to mean that fully processed polygons get removed from the Layer Peel. I wonder how that works, does it modify the display lists in memory during rendering to keep track of that ?

(will merge at a later time)

Clipping

As quads are supported nateivelly, clipping against one plane transforms a triangle in a quad. I need to look at worse case for 4 planes, though .. likely more complex.

An idea would be that CORE itself uses 0..31 coordinates for pixels, doing clipping before and rendering them as quads. Would certainly make the math easier.

[skmp]

Testable things

• Is there a limit on the number of TR layers?
• What range of depth is visibile?
• Does depth interpolation overflow colors/textures? (I recall seeing some tests for this back in early 00s)
• Do uvs overflow with HUGE values and Flip modes?
• How big can X/Y be before things break down? are they f32 range?
• Does discard processing modify object lists?

[skmp]

ISP_BACKGND_D indicates that the frame-buffer is truncating the last 4 bits of mantissa, leading to a (?) s1e8m19 format (?).

ISP_BACKGND_T indicates that the tags are 29 bits wide. For arrays, a separate tag address is used for each render.

[skmp]

ISP/TSP parameter cache seemingly exists in the hope of re-using triangle parameters across tiles. for ISP it is said to be 8KB, and in TSP (4KB) in the RTL video. Roughly that'd mean (5 4 prms + 8 4 cols + 1 4 Z + 4 4 UVs) = 72 bytes per entry ~ 56 triangles in TSP cache worst case, 102 best case (no 2 volume modvols).

That means expectations for TSP minimum ~ 10 to 20 pixels per triangle, which at 640x480 is ~ 30 to 15k triangles / frame, 1.8M ~ 0.9M per second @ 60 fps, which is close to peak performance of DOA2LE.

Also note, the cache doesn't get polluted for fit only in one bin (or that won't make use of it ? not sure if TA has smarts for direction).