3dfx Archive
http://www.falconfly.de/cgi-bin/yabb2/YaBB.pl
3dfx Section >> 3dfx Drivers >> Softwarematic SLI for Multi V5, in theory possible but..
http://www.falconfly.de/cgi-bin/yabb2/YaBB.pl?num=1236821098

Message started by Gold Leader on 12.03.09 at 03:24:58

Title: Softwarematic SLI for Multi V5, in theory possible but..
Post by Gold Leader on 12.03.09 at 03:24:58
Hi all I have been wondering since this is the drivers section and so on and that we are always interested in new goals, this idea may not seem so new hence Nvidia & ATi are using softwarematic Multi chip partually via their drivers, I had this thought why not 3dfx cards?

For example you have a Voodoo5 5500 AGP as main VGA and a Voodoo5 5500 PCI as slave card alongside the 5500 AGP.

In theory it would be possible for both to communicate in SLI via some hybrid driver, though can such a driver actually be made?

Just something I'd like to know, hence we are all interested in new things maybe this idea isn't such a bad idea after all, as for people with a 6000, they could add 2 5500 PCI's to enable 8 way SLI over 3 cards for example, it may not be as powerfull as 8 way SLI via the hardware mode but on the other hand every extra piece of perfomance added even softwarematically is never a bad thing right?

If this is possible to implent in a driver who would have the courage to make something like this SFFT , AmigaMerlin or Raziel64?  

Only thing remains, there has been no-one that has attempted such a thing because they never felt like doing it or so, shame really...

If 3dfx gamers complain that they want new-gen games like Doom3, Quake 4 as HL2 to run on their cards, as the results are as always sluggish, now if you could combine powers with multiple V5's I am quite sure these new-gen games would do alot better.

The thing is are the 3dfx programmers that make us drivers, planned to something really new like this, if people keep saying it is possible in theory, why don't they make it possible just to prove us it is possible in theory as in reality!  8-)

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by Narmounet on 12.03.09 at 10:05:10
I Thougth about it a  lot time ago, but I'v a question : would the Bandwidth of the PCI port enough to do it ?

I mean nVidia, Ati or S3 use a software multi GPU, but in a PCIE port which have a lot of bandwith...

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by GrandAdmiralThrawn on 12.03.09 at 10:56:27
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.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by Gold Leader on 12.03.09 at 14:40:55
Hmm very good read GAT :)

Then I wonder how did NVIDIA & ATi get it working with their GX2's & X2's since a 9800 GX2 and HD 3870 X2 for example are like a 5500 , they have a main GPU/VPU and a slave GPU/VPU, and if adding a second one you'll have the same problem as by adding a 5500 PCI to a 5500 AGP heh, or a 5500 PCI to a 6000.

Okay NVIDIA and ATi have programed quite alot with this idea, hence they can even do 3 way multi chip which would be like combining a 5500 with a 4500 PCI for example.

since the master chips of these GX2's and X2's are the slaves of the host orsay main card as well, so herefore I wonder this aspect on how NVIDIA & ATi did accomplish this :)


Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by GrandAdmiralThrawn on 12.03.09 at 15:27:51
Well, first, nVidia/ATi have the SLI/CF bridge and then, the communication between the chips has been designed to scale farther from ground up. So, it's just by design.

3dfx had to deal with the AGP port, so multiple high-end cards would not have been possible at all (only 1 AGP Port). Plus, at that time, lots of people were complaining about the additional power requirements of v5 5500 cards, so adding even MORE cards might not have given them a very good reputation.

nVidia has a serial interface, that works like a network topology (PCIe..) with Hubs instead of bridged buses (PCI), so i guess, that makes multi-card "Scalable Link Interface" a bit easier to handle and scale than "Scanline InterLeave"...

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by NitroX infinity on 12.03.09 at 15:45:39
AGP 3.0 specifications allowed for multiple AGP ports. But since 3dfx wasn't around then anymore, we never saw AGP SLI.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by Gold Leader on 12.03.09 at 18:27:58
hmm oke, but when we look @ Quantum3D's AA5 setups these were 2 way SLI setups of a total of 16 VSA-100's with either 32 ro 64MB per chip, then I'm like why not use Voodoo2 style instead as Q3D did with their AAlchemy 81.xx series?

Okay I know that Quantum3D is a total different sector but techwise there isn't much difference.

Maybe Dual 5500 PCI's instead heh, ah well someday I hope for sucha  driver to evolve even if it would take a year or two, it would give us more headroom as game support may take us :)

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by GrandAdmiralThrawn on 13.03.09 at 00:42:43
Yeah, 3dfx could have done that too (8-way SLI i mean), by simply using more high end bridge chips and more VSA chips on a single board. But to connect two already bridged PCI buses (like the one of a 6000 and the one of the 5500) together over the actual Host PCI bus might just be more complicated. Q3D did even that, but to be honest I don't even know what two AAlchemy 8164 cards would do that one cannot (would it really give double the speed at all modes, or just free 4xFSAA, but same speed at 2xFSAA and no AA)?

And unfortunately, 3dfx was not the driving force in 3D innovation at that time anymore. Don't misunderstand me, innovations like T-Buffer and FSAA were groundshaking to me (look at how may games use Depth of Field Blur and Motion Blur these days), but at that time everbody followed nVidias Innovations.

So, if 3dfx might have introduced the possibility of running multiple AGP cards in one system, I still doubt that any mainboard manufacturer would have built something like that, just to enable users to run some insane monster SLI..

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by Gold Leader on 13.03.09 at 02:44:08
Yeaps exactly hehe T-Buffer amazed alot of us when that Q3A Motion Blur demo was shown on a rev.A1 1500 V6K @ the Comdex 2000 and now today we can still envy that awesome experience.
it is a shame that everything went NV's way back then, imho 3dfx did have the upper hand tech wise, okay not saying that S3T&L is a bad thing, yeah S3 invented it NV was only the first to ahave put it to use with their GeForce2 GTS heh.

But yeah as you said Motion Blur & Depth of Field Blur are being used today is a hard fact, even Soft Shadows & Soft Reflections are bing used and come to think of it, 3dfx was very ahead of every VGA vendor for it's time, I eman we are speaking Q4 1999, the first 5500 PCB's were from week 44 year 1999 and they had T-Buffer  :-X

Sometimes it is very strange how things packed out, indeed that Naplam was delayed to much, if it hit the market before the NV10 aka GeForce 256, things would been alot different and maybe 3dfx would of been around even today.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by RaverX on 14.03.09 at 00:12:20
I'm sure there were much more problems into getting a working a dual V5 setup. Drivers, operating systems (remember rage fury maxx, that only works in 98, not in xp).

I had my share of experiences with hardware and software, right now I work as a software developer (that's after nearly 5 years of hardware repairs).

During all those years, I found out that hardware tends to be much easier to fix than software to debug. So, I think that the main reason for not getting V5 SLI is the software, not the hardware.


Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by Tim on 14.03.09 at 01:45:26
I would love to see software SLI, but like Grandadmiral said, who is goint to do it? As far as I know, most are enthusiasts, but not to the level needed to make this work, and completely rewrite most of the driver.


wrote on 13.03.09 at 02:44:08:
imho 3dfx did have the upper hand tech wise,


The matter of the fact is unfortunately, that quite quickly after the Voodoo 2, 3dfx didn't have much on nVidia at all tech wise.

Imho nVidia was already showing it's direction and supremacy after the TNT2, questionably the TNT as well.

I know that viewpoint is probably not very popular on a 3dfx forum, but nVidia did turn out to be one of the biggest innovators in the industry, and has been so for a long time.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by NitroX infinity on 14.03.09 at 02:42:21
Innovators? All they did was expand upon the original RIVA design;

From Riva to TNT they doubled the pipelines and tmu's.
From TNT to TNT2 they added 32bit color support in 3D rendering. They also shrunk the die size which let them increase the core speed.
From TNT2 to GeForce 256 they again, doubled the pipelines and tmu's and added a HW T&L engine.

Note that Geometry engines were nothing new, nVidia just managed to integrate one into the graphics chip itself.

nVidia hasn't innovated one bit since their RIVA chip, they just improve. So did 3dfx and ATi btw, don't get me wrong.

The last true innovations were unified shaders, s3tc texture compression and fsaa.

Innovation fell into a coma when 3dfx died and Direct3D became the defacto standard.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by gdonovan on 14.03.09 at 02:42:54

Tim wrote on 14.03.09 at 01:45:26:
The matter of the fact is unfortunately, that quite quickly after the Voodoo 2, 3dfx didn't have much on nVidia at all tech wise.


Rampage (with SAGE) was slated to come out after Voodoo II- Voodoo 3 and Naplam were mere placeholders.

Feature creap and Banshee delayed Rampage.

VSA-100 would have never exsisted if Rampage was on time.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by gdonovan on 14.03.09 at 02:44:22

NitroX infinity wrote on 14.03.09 at 02:42:21:
Innovators? All they did was expand upon the original RIVA design;

From Riva to TNT they doubled the pipelines and tmu's.


TNT had 32 color support in 3D, not very fast mind you but it was there.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by Gold Leader on 14.03.09 at 04:02:47
@ Gdonovan :)
Your speak exactly the perfect details! indeed if Rampy was ontime VSA-100 & VSA-100 were never needed and indeed there would of never existed.

VSa-100 was actually more of a Fill the gap sollution, as to expand the develpment of the VSA-200 which actually was planned after Voodoo2 aka SST-2.

But hence the massive delays Banshee & Avenger were added to fill in the gaps and as for Naplam, & Daytone these twe had Rampage tech like Rotated Grid Super Sampled FSAA, Motion Blur, Soft Shadows, Soft Reflections and depth Of Field, these techs were actually taken from the Rampage design.

But the sad thing was, that these techs were hardly supported hence Rotated Grid Super Sampled FSAA but for the trest left to be unused in the main ames that followed.

Okat that there was a Q3A demo that utilized Motion Blue did show what Motion Blur could do but it never was applied to most games, Descent 3 is one of the very few that supports 3dfx Motion Blur.

This can be seen as how the robots around, Motion Blur can be seen very well.
as I have tested with my Voodoo5 5000 PCI here:
http://www.3dfx.ch/gallery/d/34190-2/Descent3+on+5000+PCI+Win2KPro+_+SP4+c.png

As you can see the cop bot does show a clear Motion Blur effect as it sways to the right :)

I used reso 1024 x 768 x16 in 3dfx Glide + FSAA x4 & LOD Bias -4 with Descent 3 ver 1.5 Beta + PyroMania 1.5 Full, for the 5000 PCI I sued SFFT Alpha 41 modified by ps47 under Win2k Pro + SP4 , yes 3dfx SLI works on the 5000 CPI under any NTFS OS.

@ Nitrox Infinity

Absolutely correct NV didn't really have new designs all what they did is modify the older designs so actually they never had something new under the sun.

I truly agree with you mate.

@ everyone,
I had a few beers tonight  ;D So the typo's do declaire their state hrr hrr.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by NitroX infinity on 14.03.09 at 10:10:06

Quote:
VSa-100 was actually more of a Fill the gap sollution, as to expand the develpment of the VSA-200 which actually was planned after Voodoo2 aka SST-2.


VSA-200 doesn't exist. You mean Rampage ;)

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by Gold Leader on 14.03.09 at 13:15:19
VSA-200 is the code name of Rampage, only it didn;t have the Voodoo Scalable Architecture, thus they called it no Voodoo anymore, it's production name would of been SPECTER which meaned:
SPecial Executive for Control, Terrorism, Extortion, and Revenge hehe, even this card's high end would of worked like a 5500 right?

I even wonder if 3dfx had planned a 2-way AGP x8 sollution since AGP 3.0 would of supported this, uless back then this idea was never mentioned, just imagine what Quantum3D would of done with the Rampage heh, maybe AA5 boards with 4 to 8 rampage chips heh.

But still tio get back to the topic, Software SLI could of given 3dfx more headspace for the leading performance, the only downslide is support in games and the cost extra needed to add a second card.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by NitroX infinity on 14.03.09 at 13:40:52
As far as I know, Rampage is Rampage and the VSA-200 is a made-up name by the community.

I'd like to see evidence supporting your claim that VSA-200 is Rampage.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by Tim on 14.03.09 at 13:55:12
Even the Rampage powerpoint doesn't mention anything about VSA-200, the word Rampage is used throughout.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by gdonovan on 14.03.09 at 14:05:46

NitroX infinity wrote on 14.03.09 at 13:40:52:
As far as I know, Rampage is Rampage and the VSA-200 is a made-up name by the community.

I'd like to see evidence supporting your claim that VSA-200 is Rampage.


The only place I have seen VSA-200 used was in Everest Home edition for identification of Daytona.

From Everest information txt file-

"Bus 1, Gerät 0, Funktion 0  3Dfx VSA-200 Graphics Processor"

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by Gold Leader on 14.03.09 at 22:28:15
Well if Everest reads that I'm quite sure it reads it from the core right? I mean this is how Everest works right Gary? Or am I a little confused here?

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by gdonovan on 14.03.09 at 23:18:14

wrote on 14.03.09 at 22:28:15:
Well if Everest reads that I'm quite sure it reads it from the core right? I mean this is how Everest works right Gary? Or am I a little confused here?


I have no idea what Everest uses but they can make the program state "Voodoo XXXI" if they wanted too.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by NitroX infinity on 14.03.09 at 23:25:26
Everest reads the ID of the hardware and checks that against a list of ID's Everest itself has. That list can be edited to add new ID's. So naturally, it can be editted wrongly. We all know Daytona is VSA-101.

At least that's what I suspect, hardware doesn't store all the details about itself, just an ID.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by Gold Leader on 15.03.09 at 01:02:27
hmm oke but then again Napalm = VSa-100 Daytona = VSA-101 right so it would seem logic that Rampage = VSA-200 right, or am I loosing it now  ;D yeah this is funny to some point.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by NitroX infinity on 15.03.09 at 02:49:33
No, Rampage was in the pipeline long before Napalm, so there is no reason why Rampage would be named VSA-200.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by Gold Leader on 15.03.09 at 03:07:19
Well okay for that part maybe, but since 3dfx made the Rampage card in week 47 of year 2000 it was obvious to name it a VSA-200 as it would of been the successor of the VSA-101 & 100 :) so in a way I do agree with you but on the otherhand as it is, I can't :)

For all we know now the VSA-200 is the last thing 3dfx made even when they were bankrupt, the spend 2 weeks to complete a single VSA-200 board and it is obvious to a certain degree that they called the Rampage the VSA-200 just for that point.

Okay my topic has gone offtopic but none the less it's still a very interesting one hehe.

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by NitroX infinity on 15.03.09 at 14:23:55
If it would have been named that just because it was the successor it would have had a different name altogether; SST-6. So again, your logic is flawed. ;)

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by Gold Leader on 15.03.09 at 16:19:15

NitroX infinity wrote on 15.03.09 at 14:23:55:
If it would have been named that just because it was the successor it would have had a different name altogether; SST-6. So again, your logic is flawed. ;)

I hardly doubt that , imho it did make sense ;) can you explain why Everest detects a VSA-200 then?
As what I did post was the facts as it is now only, because it is made after naplam and not as planned after SST-2 ;)

and where did you get SST 6 from? heh since Voodoo3 , 4 and 5 aren't called SST-3, SST-4 and SST-5, so even for that part you are mixxing it up a little or we both are haha  ;D

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by gdonovan on 15.03.09 at 16:33:05

wrote on 15.03.09 at 16:19:15:
I hardly doubt that , imho it did make sense ;) can you explain why Everest detects a VSA-200 then?


Everest can make it state what they want it to state, it is a third party software program.

Ergo the data from Everest is suspect and not to be taken as "canon"

Title: Re: Softwarematic SLI for Multi V5, in theory possible but..
Post by GrandAdmiralThrawn on 16.03.09 at 15:29:33
There are several IDs stored in the PCI registers of a piece of PCI/AGP hardware (PCIe too).

The two most important are:
  • Vendor ID
  • Device ID

3dfx hexadecimal Vendor ID is "121A". So every 3dfx board has this. I don't know about the Daytona (or Rampage) Device IDs, but i guess the authors of Everest just stored that waaay back and never ever changed that again. One might provide a bug report to them, to change that to VSA-101 for Daytona...  but I don't care enough, I'm not even using Everest..

But mostly, there are no Strings stored anywhere in the registers (only possibly in BIOS, which is proprietary anyway). Only Hex Codes. And all those "system analysis" programs simply have a Text Database containing all the IDs and some descriptive Strings for them. So yes, they can be wrong. The only thing read directly from the hardware are the IDs from the device's PCI registers.

3dfx Archive » Powered by YaBB 2.4!
YaBB © 2000-2009. All Rights Reserved.