GrandAdmiralThrawn
YaBB Newbies
Offline
Better are FOUR.
Posts: 22
Bruck, STMK, Austria
Gender:
|
nVidia's SLI isn't all software. Note, that nVidia GPUs have a hardware-based unit inside their GPU die to handle SLI communications and of course to control the little bus, which runs over what we know as "SLI bridge". I guess ATi also has dedicated logic inside their chips to handle crossfire, dunno about S3.
To answer your question (as far as I'm able to that is): Yes, this is in theory possible. It wouldn't even cost too much bandwidth, because the primary VSA card would sit on the AGP, whereas further "Slaves" would sit on another PCI bus.
Some workstation mainboards even have more than one PCI bus, so the PCI slots may be divided over 2 buses, giving additional bandwidth, as long as you plug each Voodoo on its own bus.
Actually, intercommunication between the VSA chips is not done in some super-fast proprietary way. It is simply that: Another PCI bus implemented on the Voodoo card itself. For the v5 5500, the master VSA acts as PCI bridge to the second one, for the v5 6000, the HiNT HB1-SE66 acts as bridge to provide a PCI Bus supporting four devices on the card (hence, four VSA-100). So, it is all just PCI, no fancy proprietary 3dfx stuff anywhere. The rest is handled by the driver, as far as I know.
Now, for your given example: What I think can NOT be done is relable the 5500's master VSA chips to slaves for the 6000. In that case, the primary VSA-100 on the 6000 would be master, all other VSAs in the whole system would be slaves to that one single master. I guess that does not work. Maybe it's a driver thing, but such a modification might even require BIOS changes, maybe it is even a hardware limitation (quite likely even).
So, you would probably have to create another pure software layer, that combines the VSA cards, does performance evaluation on each complete card (to determine, which card should render larger portions of the screen, and which slower cards should render smaller portions), and then does "Software SLI" with them.
Such a solution would be comparable to what Metabyte tried to do with PGC ("Parallel Graphics Configuration").
The problem with our fellow 3dfx driver coders is, that (as far as i know - feel free to correct me if I'm wrong) they always just worked on the 3dfx codebase, patching it, improving it, fixing it. But developing something as groundbreakingly new as "softwarematic SLI" or PGC is extremely more difficult than patching an existing (maybe even well-documented) codebase.
It might just be far too much to accomplish. What you would need are a few full-time coders working 8 hours a day for maybe a few months to even get a prototype working in a single game or test engine with something like this. Plus, unified framebuffers might not work so easily with such a solution, wasting the memory usage advantage when scaling up the number of VSA's (6000 uses less memory per VSA than 5500, because each VSA only has a quarter of the framebuffer to store in its mem patch instead of half).
Bottom line: Maybe I'm wrong in some of my assumptions, but what i truly think that YES, this can be done, and NO, it will most probably not be done, because it is an extremely hard problem to solve.
|