First, a look at what we actually use in graphics. As an example, let's have a frame rendered at 1024x768, with mipmapping and aniso filtering on (make it a bad case and say a 2:1 texel to pixel ratio), and 3 textures for each object onscreen (diffuse, normal data, and some specular stuff. Let's say that that data is all 3Bpt). It doesn't matter how hi res any of the source data is. As long as it satisfies those requirements, you only need 13.5MB of data onscreen, and that's a pretty bad case. Oh, and that's without even thinking about data compression.
Let that number sink in a bit:
That's 10.5% of the total texture memory on an average video card with 128MB of memory.
At 60fps, and needing a COMPLETELY new set of data every frame, that's 810MB/s of data transfer, less than 40% of the full AGP8x transfer rate.
And yet, here we are, with cards on the market that have 4 times that data; and PCIe 16x now in existence with 2 times the transfer rate.
Where is this absolutely ridiculous need coming from? Why do we think that regardless of an object's position, orientation, and visibility that we need to send to the video card 1024*1024*4/3*4Bpp = 5.3MB (the 4/3 is due to mipmapping) for a hires texture and just forget about it? It could be 4 pixels wide but we'd still kindly ask API to use the full 5.3MB of data even though you're using less than a kilobyte of it. And what about future games (e.g. UT2007 and other UE3 titles), where we're going even HIGHER than that, with 2048*2048*4/3*4Bpp = 20MB of data for a SINGLE texture, WHEN WE CANNOT EVEN SEE THAT FULL TEXTURE, EVER?!
This is just a huge waste, and the answer to that is memory virtualization. Obviously, we don't have the hardware to do that, so the programmers have to do it manually. Basically this boils down to sending to the video card only the data that we need in a frame, all the way down to 64x64 or 32x32 chunks of a given mipmap.
Which leads into my solution. It's still a high level design, but I see no real problems with this:
So, motivation for a software rasterizer: Well, like how Yann used one to determine occlusion of whole characters, a softrast could be used to determine occlusion of sub-triangle data. For example, let's take a look at this picture I found on a GIS:
(click for bigger image)
With a softrast, you can say that parts of the books behind the kids head are not visible, and that the hidden texture data is not needed. Also, consider the stacks of floppies and CDs to his right. Only a sliver of the data on some of those disks or cases is visible, so a softrast could easily tell you that exactly what parts are not needed. Even without those considerations though, it can help out in determining what mipmaps of textures are needed based on aniso filtering. Heck, an image like that is almost the poster child (no pun intended) for why you'd want a softrast to help with the paging of only necessary data.
The arrangement of the tiles is going to be a bit hairier though, and as I said will be the hardest part of this. The reasons are two fold:
Lastly, what're the benefits that all of this will bring?
So, that's what I'm working on right now, and I really hope that it turns out nicely.