AFAIK while there are some DC games that will only output at 480i (even with the VGA box trick), the DC hardware could only render at 640 x 480, and all rasterisation was done internally at 24-bit. The GPU gubbins that accelerated binning of polys over tiles could only work at a 640 x 480 number of tiles iirc, and tiles were of a fixed resolution. This was very fast and used more silicon, but was less flexible than the PC Neon 250 way of doing the same calculations which involved the CPU.
I used to have a link to a very interesting SimonF breakdown of the respective chip's features - DC is actually faster than the later PC part in many ways. Opaque poly fillrate for CLX2 was insane for the time and the size and clock of the chip.
This is a bunch of correct stuff getting a bit mixed up into not quite right.
Internally, all rendering is does to a 32x32 pixel buffer with 24-bit color+ 8-bit alpha. All blending occurs at this precision and is only optionally dithered when writing to a 16-bit framebuffer. There's actually two color buffers, it renders to one while the other is written to RAM. After the backbuffer is written, it can be reused as temporary storage for preforming multitexture effects.
The pixel clock video DAC is mostly fixed and is designed to run only at 640x480 at 59.94 FPS. You can divide the clock in half, to support NTSC/PAL interlaced, but that's it. It has an options to draw double columns or rows to allow displaying 320x240 (or 640x240 or 320x480) framebuffers. The only other interesting standard resolution supported is 640x400 at 70 FPS on VGA. It's possible to tweak some of the sync timing to make monitors think that a different, higher resolution is being used, but you always end up with a lower actual resolution. The only real use is to trick a monitor into thinking it's getting a widescreen signal, as a kind of automatic anamorphic widescreen switch. It's also possible to extend the display a bit into overscan, but it can cause brightness problems depending on what is displayed.
The actual rendering part of the PVR seems capable of rendering at a resolution of 2048x2048 (or at least various bit fields seem sized so that it can work, I haven't actually tried it). The tile accelerator, the part that generates the lists for the PVR to draw, is limited to a resolution of 1280x480 (i.e. 640x480 with 2x horizontal supersampling). It's probably possible to manually generate command lists on the CPU to bypass this limitation and render at 2048x2048, but I don't really see any practical use for it, outside of some kind of demo-scene style trick.
While the PVR always renders in 32x32 tiles, it's possible to render to a framebuffer that isn't a multple of 32x32 pixels. There's a clipping function that can occur when the tile writing to RAM. So if you wanted to render to something like 33x33 (for some bizarre reason) it would internally render four 32x32 tiles, then only write the 33x33 region. This is how low res 240 row rendering is possible, since 240 isn't a multiple of 32. You aren't limited to clipping the right and bottom off, you can clip the top and left edges, too.
The PVR has scalers when writing the tile to the framebuffer. There's a 1/2 horizontal downscaler, for supersampling, and a more flexible vertical scaler. The vertical scaler can work on almost any ratio, so can scale up, to stretch a 480 row render to fullscreen 576 row PAL, or scale down for supersampling. The downscaler is also used for deflickering on interlaced NTSC/PAL. The upscaler seems like it's bilinear, and is limited to a max 2x upscale. The downscale can work on any ratio, but downscale just blurs the tile a bit (with a user defined weights) then discards rows. It's not actually possible to do a correct 2x box filter vertical downscale. Three taps are used, but only two coefficients can be specified. One coefficient is used for the center row, and the other coefficient is used for both top and bottom rows. The PVR correctly handles blur crossing the top/bottom of a tile.
There seems to be a bug in the official SDK when horizontal supersampling is used. It would turn on the deflicker on VGA, where it's not necessary, making the screen blurrer than it should be.
I made a Codebreaker code a while back to fix this. I had to disassemble part of Codebreaker to do it, since normal codes were limited to writing to main RAM, and I wanted a code to disable the blur by modifying the coefficient register, since that would be universal to all games. The only known official games to use supersampling are Ready 2 Rumble Boxing (only the first one, not the sequel), Omikron, Wacky Racers, and some Japanese only Toyota promotional demos.
As for fillrate, I accidentally did a fillrate test a while back. I've been working on improving a
Genesis emulator for the Dreamcast by getting it to use the PVR to render the screen, instead of doing it in software. (60 FPS, no frameskip, decent audio) When working on the code to draw the Genesis's background layer/display off handling (generally just a solid full screen color, but some games can change it per line), I made a mistake modifying it. Originally, it was handled by drawing a 320x224 solid color quad. I wanted to change it to drawing 224 quads with a size of 320x1, so I could change the color/depth per line. I forgot to change the height of the quad, so it was drawing 224 quads with a size of 320x224. This added about 5 ms to the render time.
So the first 24 quads were processed unclipped (first quad drawn at row 8, rendering to a 320x256 tile buffer, clipped to a 320x224 framebuffer), so that's 24 quads fully "drawn", or 5376 rows. the remaining quads where partially rendered, each quad one row is less than the previous. I think that's 24700ish rows? So 25476 rows times 320 columns at 60 FPS is 577 Mpixel/s. Since that only added on a bit less than a third of a frame, it looks like about 1.9 Gpixel/s was possible? You could probably get more if you went out of your way to design a best case benchmark.
(Also, I don't draw 224 320x1 quads anymore. It was taking about a third of a millisecond to draw those lines, so now rows with identical colors/depth get merged into a single quad.)
Thank you for your amazing response!