This is, of course, a good idea. But whether or not we can do it will depend on how closely coupled the two pipelines will be. I'm planning to make them really one pixel pipe that processes two pixels. There's enough control logic that would be shared that I'm expecting it to be worth-while. The drawback is that expanding it to 4 or shrinking to 1 is nontrivial. But our goal here is to fit on a small chip. Engineering is all about choosing amongst a set of conflicting requirements. :)
One reason why to make them tightly-coupled has to do with a side-effect in that 64-bit units are simpler to deal with than 32-bit units, because our four memory controllers are all 64 bits wide. If we had two separate pipelines, then we'd have to have some sophisticated way to reallign their data streams and put them back together. Otherwise, we'd end up getting only half our memory bandwidth. We're already going to have to do some goofy pseudo caching thing for texture reads, because we want full throughput in those cases when access patterns are linear (like 2D bitblts), but the texture units request individual pixels. On 4/17/07, André Pouliot <[EMAIL PROTECTED]> wrote:
I have a question about the 3D pixel pipeline, since it probably the most failure prone part when the chip will be fabbed. I don't know the architecture exactly that you plan on using. But would it be possible to enable only 1 of the 2 pixel pipeline? I know it's soon to talk about a feature like that but it's less critical now when the 3D pixel is not yet written. The advantage that I could see is when sorting the chip you could augment your yield. Recuperate some defective chip and sell them as lower performance part for kiosk or other system where 3D performance is even less critical. Or for the user to cut performance when he doesn't really need it. The only thing would be for some part number the video bios should be different. André
-- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
