Vergelijking 3dfx Rampage en nVidia NV20 specs

Na de recente speculaties over de 3dfx Napalm en nVidia NV20 durfde Wazige Angelfire Site het aan om beide chips in een vergelijking neer te zetten. Beide kaarten gaan eind dit jaar keihard met elkaar concurreren - als nVidia en 3dfx tenminsten op schema blijven lopen. nVidia lijkt met 'Hidden Surface Removal' een interessante feature in handen te hebben, waarmee zijn hun huidige geheugen bandwidth problemen mogelijk kunnen beperken:

Ok, now that we have the ugly little specs out of the way, some commentary. The NV20 uses Hidden Surface Removal. It is unknown at this point whether it actually does this to gain performance, or it is just a marketing gimmick. My suspicion is the former, as if it was just a marketing gimmick, this card would perform almost identically to the GTS, just due to memory limitations, and it wouldn't make much sense on Nvidias part to have all that fill-rate in there for nothing, especially since they could cut out half the pipelines, double the number of texturing units, and still claim the same megatexel fill-rate at a lesser cost to them. So lets assume that it is actually performing hidden surface removal to the benefit of the consumer. This means that assuming an overdraw of 3, this card will(other features notwithstanding), outperform the GTS on a 3 to 1 basis(although the AGP bus is worrying me at this point). If this is true, it would explain why Nvidia is charging so much for the GTS, as it will be worthless come winter.

Uiteraard is een vergelijking tussen twee produkten waarvan de specs nog lang niet vasstaan nogal prematuur, maar een beetje speculeren kan IMO geen kwaad (het leven is anders zo saaaaai).

Reacties (18)

[Haywire]

Hmmm. Toch bijzonder, hoor. Laat nou de populaire Z-buffer een techniek zijn voor "hidden surface removal" (volgens "3D Computer Graphics" van Alan Watt, aanradertje als je geinteresseerd bent in 3D graphics).

3D kaarten hebben dus al jaren en jaren (zeg maar sinds ze bestaan) hidden surface removal. Het idee bij de Z-buffer is dat objecten een voor 1 worden gerenderd in de buffer (het is dus een soort frame-buffer, aan het eind van het proces bevat de Z-buffer het daadwerkelijke frame dat op de monitor komt - tenzij er nog wat nabewerking wordt toegepast, zoals de Rampage dacht ik meekreeg). Zo nu en dan wordt er een object gerenderd over een oude heen, maar als de engine op het punt staat een deel te renderen dat onder een al gerenderd object ligt, dan gaat dat niet door. (Het heet Z-buffer omdat hij in de diepte, de kijkrichting, werkt, wat klassiek de Z-as is in 3D visualisatie. Voor elk punt wordt de Z-coördinaat ook opgeslagen, zodat het makkelijk is om na te gaan of een punt "dieper" ligt dan het al gerenderde).

Waarschijnlijk is dit proces wel te sturen door de volgorde van rendering van de objecten intelligent te doen, zodat het voorste object altijd als eerste wordt gerenderd, dan het 1 na voorste, etc. Als je dat doet, zorgt het Z-buffer meechanisme ervoor dat je nooit dubbel werk doet. Misschien dat NVidia dat bedoeld met hidden suface removal. Maar om nu ineens te roepen dat er hidden surafec removal wordt toegepast is bullshit, dat zit er, in de vorm van de Z-buffer, al in sinds de allereerste Voodoo 1. Anders zou het hele 3D-kaart verhaal ondoenlijk zijn. Het zal wel weer op definitie aankomen.

[GaMeOvEr]

Het hele Tile based rendering systeem is afkomstig van Videologic, van hun PowerVR series.

De eerste daarvan, zou de concurrent van de VooDoo 2 moeten worden, maar kon dit qua bandbreedte wel aan, maar het hele systeem werd geplaagd door Visual Artifacts.

De laatste kaart van Videologic, de Power VR Neon 250 is nooit een serieuze concurrent geworden, omdat de kaart ongeveer anderhalf jaar te laat uitkwam, omdat Videologic zich eerst heeft bezig gehouden met de Chip voor de Sega Dreamcast, wat dezelfde is als diegene die gebruikt wordt op de Neon 250.

Het principe is dus niet nieuw (zoals de Kyro het geimplementeerd heeft), maar werd in het begin wel geplaagd door visual artifacts en incompatibilities.

Er zit zeker toekomst in zo'n systeem, omdat je nu ziet dat alles tegen het geheugen-bandbreedte probleem oploopt.

Ik ben alleen benieuwd of de implementatie op kaarten zoals de Kyro goed genoeg is, om niet heel veel gezeur met Games te krijgen, en in een eeuwig Beta-driver traject terecht te komen.

Het feit dat "de grote jongens" zoals Nvidia en 3dfx zich hier nu ook mee bezighouden, geeft alleen maar aan hoeveel efficienter het allemaal nog kan, en dat het ook nodig is dat er naar dit soort alternatieve oplossingen gekeken gaat worden, om het bandbreedte probleem te omzeilen.

Schijnbaar wacht men ook heel erg op sneller geheugen....

[update]
Jumpstart

Lees mijn 3e alinea nog eens door...

Het is natuurlijk ook zo dat de Games voor de Dreamcast specifiek voor de Dreamcast worden gemaakt. Zou dan wel erg slordig zijn natuurlijk, als er op een specifiek platform waar je geen variaties tegenkomt op Hardware-gebied, zoals bij PC's, dat je dan alsnog artifacts zou tegenkomen.

Ik twijfel er ook niet aan dat de artifacts een fout van de chip waren, maar meer dat het een erg lastige driver-issue was.
[/update]

[JumpStart]

GaMeOvEr:

Hier nog een aanvulling op je verhaal. De KYRO/PowerVR techniek zit ook in de Sega Dreamcast. Dat is toch wel een teken dat de gebruikte techniek de kinderziektes achter zich gelaten heeft...

Otis (zie reaktie hieronder):

Wat jij beschrijft kennen we al veel langer als backside culling (of backface culling??). Dat doen de VooDoo kaarten al sinds de VooDoo 1, als ik het goed heb. In de goeie oude tijd was een Voodoo 1 dan ook minder afhankelijk van een CPU dan een TNT1, want de TNT1 was afhankelijk van drivers om de CPU om achterkanten weg te halen.

Maar: Dit doet nog niks aan het probleem dat, wanneer je door een deurpost een kamer inkijkt, de hele kamer door de 3D kaart gerenderd wordt. De KYRO, en waarschijnlijk dus ook de NV20, zijn in staat om alleen dat deel van de kamer dat in de deurpost zichtbaar is te bepalen en alleen dat deel te renderen.

[EfBe]

Hidden surfaces verwijderen doet men door de normal van de te testen polygoon te berekenen en via dotproduct de hoek tussen kijkvector en die normal vector te berekenen. Is die > 90 graden dan wijst de poly naar achteren en teken je hem niet.

Dit kan heel goed in je driver en veelal doe je dit al in je eigen applicatie, veelal geholpen met bulk culling algoritmen. (bsp's etc). Ik zie niet echt een performance winst hierdoor, omdat dus veel mensen dit zelf doen. Zelf doen in driver of eigen applicatie heeft als effect dat er minder vertexdata over de agp bus moet, en bij grote hoeveelheden polygonen is dat wel aan te bevelen. Het is een tradeoff dus: doe je het niet zelf maar laat je het de card doen, dan moet je veel polygonen over de bus stouwen, maar je kunt als CPU andere dingen doen. Echter, in dit geval zie ik het niet zo.

[sonix666]

Even voor de orde: Hidden surface removal heeft niets, maar dan ook niets met back/front face culling te maken. Met culling kun je aangeven of je polygonen behandeld moeten worden als eenzijdige vlakken of dubbelzijdige vlakken. Indien een polygon eenzijdig is en zijn normaalvector is niet naar de camera gericht, dan zou deze dus niet getekend mogen worden. Daarvoor wordt back/front face culling gebruikt.

Even een quote over hidden surface removal uit de MSDN Library:
</div><div class=b4>
Correct use of BeginScene() and EndScene() is important to support a class of emerging 3-D hardware accelerators which do not use a conventional z-buffer to perform hidden surface removal. Such accelerators may implement a number of mechanisms for performing hidden surface removal (such as internal tiling and polygon sorting). However, to perform hidden surface removal, all such accelerators must process a copy of the entire geometric database for a single frame.
</div><div class=b1>

Hidden surface removal is dus wel degelijk iets anders dan backface culling.

Huidige architecturen doen aan hidden surface removal door middel van een z-buffer. Dit gebruikt helaas nogal veel geheugen bandbreedte. De KYRO doet dit door intern polygonen te verwijderen die niet getekend worden zonder gebruik te maken van de z-buffer. Dit betekent dat er dus geen geheugenbandbreedte voor een z-buffer gebruikt hoeft te worden.

[Genoil]

Nou ik vind dat hidden surface removal wel degelijk met backface culling te maken heeft, JUIST nav dat stukkie op MSDN. Direct3D kan zelf heel goed backfaces cullen (staat ook op MSDN), maar voorziet in het geval dat de GPU-bakkers het zelf en beter willen doen.
Voor TnL kaarten is dit logisch om te implementeren, omdat de vertexdata daarbij ongetransformeerd naar de GPU wordt gestuurd, waar dan zeker nog ruimte is voor optimalisatie. Als die NV20 specs, die gisteren in het nieuws stonden waar zijn, betekent dit niet noodzakelijk het "cloggen" van de AGP bus met onnodige vertexdata, aangezien er stond dat er nurb/b/d-spline support aan zit te komen. Waardoor HSR zelfs noodzakelijk wordt, omdat het in software dan niet eens meer kan.

[EfBe]

sonix666: maar dat is dan toch hidden surface removal? backface culling is het weghalen van faces die je niet ziet. Toegegeven, polies die volledig worden overschreven door andere polies neem je ook mee met hidden surface removal, maar ik zou dat altijd door bulkcull algoritmen doen en niet mn 200.000 vertices laten cullen door een videokaart. Een beetje scenegraph levert een set polies op die niet volledig worden bedekt door andere polies. Enerzijds berekent mbv backface culling, anderzijds mbv bulkculling zoals occlusion culling en bsp tree algoritmen bijvoorbeeld.

Iedere 3D engine die dmv Zbuffer zn hidden surfaces removed is dus niet slim bezig want die heeft bij een grote scene (bv 200.000 vertices of meer) veel problemen om alle polygonen te tekenen.

Zoals genoil net zei is het BF culling wel nuttig op HW tnl maar IMHO is het zelden een speed optimizer die je visueel zult merken, temeer omdat een (grote) 3D scene altijd in een scenegraph zal zitten ivm management, en je daar echt via efficientere cull meganismen te werk gaat. BF culling is goed te doen in een scenegraph want men moet TOCH weten waar de camera is. Een gemiddelde scenegraph levert een poly set op waar nauwelijks backfacing poly's in zitten.

Wellicht alleen in non-statische objecten zoals playermodels en destructable geometry. Hier zie je meteen dat bv de Radeon dan slimmer in elkaar steekt.

[sonix666]

De definitie is heel simpel. Hidden surface removal slaat op het niet tekenen van polygonen die bedekt worden door andere polygonen. Da's dus heel wat anders dan het niet tekenen van enkelzijdige polygonen die niet naar de camera wijzen met hun normaal (culling). Technisch gezien zijn hidden surface removal en culling niet hetzelfde. Daar is helaas gewoon geen discussie over mogelijk. ;-)

Indien je de hele scene telkens zou tekenen zou dus gemiddeld gezien de helft van de polygonen afvallen door backface culling. Dan blijven er nog veel te veel polygonen over.

3D engines gebruiken andere technieken waarbij polygonen gegroepeerd worden en dan op basis van die groepen bepaald wordt wanneer ze zichtbaar zijn.

En belangrijk is het om te begrijpen dat backface culling in Direct3D en OpenGL pas plaatsvind na het T&L gedeelte. Niet ervoor.

[Verwijderd]

Dat klopt inderdaad niet. Het Z-Buffer is heel iets anders dan het frame buffer. Simpel gezegd komt het hier op neer: Voor elke pixel die getekend moet worden, checken we eerst in de Z-Buffer om te kijken of de Z-waarde van deze pixel DICHTER dan oude pixel terecht komt. Zo ja, dan wordt deze pixel getekend in het framebuffer en wordt de Z-waarde van deze pixel ge-update in het Z-buffer

[EfBe]

sonix: nu wil ik niet zeuren, maar culling is een algemene term voor het verwijderen van polygonen die niet hoeven te worden getekend.

_HOE_ je het voor elkaar krijgt om er voor te zorgen dat je alleen zichtbare polygonen aanbiedt aan je rasterizer is niet belangrijk, het zijn allemaal cull methods. Hidden Surface Removal kun je daaronder rekenen, occlusion culling ook etc. Hidden Surface removal cullt, behalve de backfaced polygons OOK de frontfaced polygons die bedekt worden door polys die dichterbij staan in het frustum.

En dit is weer afhankelijk van je 3d engine approach. In quake* engines heb je bv geen backfacing polies zonder een bijbehorende frontfacing polyset (maw: alleen solid objects), in Unreal engines bv is dit wel het geval.

In de quake wereld bevat HSR dus volledig backface culling (maw: door HSR toe te passen hoef je geen backface culling meer te doen). In Unreal dus niet altijd.(theoretisch gesproken. In de praktijk natuurlijk kan het niet, de werelden zijn afgesloten met een box)

</div><div class=b4>
3D engines gebruiken andere technieken waarbij polygonen gegroepeerd worden en dan op basis van die groepen bepaald wordt wanneer ze zichtbaar zijn.
</div><div class=b1>
Dat zei ik dus. Het is daarom niet zo interessant om HSR te hebben, daar door andere technieken de set te testen polies dermate klein is, en de kans dat daar surfaces totaal bedekt zijn door anderen, zo klein, dat HSR niet zo nuttig is in hardware.

</div><div class=b4>
En belangrijk is het om te begrijpen dat backface culling in Direct3D en OpenGL pas plaatsvind na het T&L gedeelte. Niet ervoor.
</div><div class=b1>
Ik geloof ook niet dat iemand beweert heeft dat dit niet zo was. Een renderpipeline is veelal hetzelfde, met dezelfde stages. Wanneer je wat doet is veelal op dezelfde plek, alleen kan het in software soms afwijken tov hardware, omdat de processing nu eenmaal anders is, maar niet in logische zin (frustumclipping na screenspace transformation... ik noem maar iets debiels

Lynx: lang niet altijd wordt er in de zbuffer geschreven of mee getest. Het is niet vanzelfsprekend om altijd te testen middels zbuffer of altijd te schrijven in de zbuffer. Sommige effecten vragen juist om NIET te testen.

zo genoeg gezever over 3d crap... databases maar weer!

* 786562 Otis,