'Geen unified shaders maar hybride design voor nVidia G80'

Ja maar het gaat hem ff niet over de softshadows, dat kan geen enkele kaart momenteel aan, het gaat erom dat ATI beter presteert in games met veel shaders.

Zonder softshadows draait het best aardig...overal op....en het gaat mij erom dat blijkbaar shader performance juist in het voorbeeld wat hij aanhaalt NIET de bottleneck is.

Dat herinner je je dan toch verkeerd.
De 5800 had genoeg shader units. (4x2)
Het probleem was echter dat niet alle shader units floating point units waren. Daarom waren ze dus niet allemaal in te zetten voor DX9 code. De integer units waren alleen voor DX8.1 en lagere code te gebruiken.

Dat betekent meteen dat je dus bij DX9 code een enorme achterstand had tov een kaart waarbij alle units geschikt waren voor DX9. (zoals de R300). Bij DX8.1 code was die achterstand er niet.
En dat is dan ook precies wat je toen in de spellen zag gebeuren.

Dan kun je dan een slecht DX9 ontwerp noemen, maar in werkelijkheid is het gewoon een bewuste ontwerp keuze geweest om maar een gedeelte van de shaders voor DX9 geschik te maken.
Als een kaart maar ten dele geschikt is voor DX9 dan kun je naar mijn mening niet meer stellen dat een kaart volledig ontworpen is voor DX9. Daarom noem ik het dus een kaart die ontworpen is voor DX8.1 (waarin ie zijn volle kracht kon gebruiken) met beperkte DX9 functionaliteit.

Dat waren Texture lookup units...

Jij beschrijft de NV37?(FX5700), niet de NV30, die was eigenlijk nog triester, die had een 4x1 design waarvan slechts de helft DX9 shaders kunnen uitvoeren.

NV30 en NV35 hadden beide 4 pixel pipeline met per pipeline 2 texture units en 1 shader unit. De shader units was zo slechts nog niet, alleen gebouwd op de nooit gebruikte PS2.0a standaard, en met gebrek voor FP24.

Het hangt er maar van af wat je vooruitstrevend noemt. Als eerste naar 90nm gaan omdat je chip anders te heet wordt noem ik niet echt innovatie.
Anders zou Intel innovatiever zijn dan AMD op dat vlak.

Het hangt van de scheduler af of een pipe een pixel of een vertex shader gaat zijn. Die moet dus een keuze maken aan de hand van welke pipes er bezet zijn en hoeveel er nog geprocessed moeten worden. Goede load balancing en prediction zijn zeer belangrijk voor de scheduler.
Het is dus de kwaliteit van de keuzes van deze scheduler die de snelheidsbepalende factor zal zijn.

Ik geef toe dat unified the way to go is. Maar nu misschien nog niet. Ik denk dat een gespecialiseerde pixel shader pipe veel nuttiger is dan eentje die zowel pixel als vertex shaders kan doen.
Een pixel shader vergt veel meer rekenkracht dan een vertex shader. Als zo'n pixel shader gebruikt wordt om vertices te processen heb je dus een superkrachtige pipe die praktisch staat te idlen en geen werk heeft. Zonde van het potentieel.

Maar goed, beiden hebben voordelen en nadelen. Maar met in de verste verte nog geen dx10 games in aantocht zie ik "nu" het nut nog niet van een unified architectuur.

Dergelijke schedulers zijn er in belangrijke ook al in de huidige kaarten. Bv in de X1000 serie.
Daarbij moet de scheduler dan wel niet kiezen of er pixel of vertex shaders uitgevoerd moet worden, omdat die scheduler alleen maar pixel operaties afhandeld, maar hij moet net zo hard kijken welke "pipes" er bezet zijn, wat er nog geprocessed moet worden, welke request naar het geheugen al afgehandeld zijn en op welke nog gewacht moet worden.

Je ziet dat de vertragende factoren nu al aanwezig zijn.

Wat betreft een pipe die "nuttiger" is.
Uiteindelijk gaat het om het aantal transistors wat je gebruikt.
Een gespecialiseerde shader units doet zijn werk niet beter dan een unified. Het verschil is dat ie minder transistors nodig heeft. Zoals je zelf al aangeeft kun je die transistors nuttiger gebruiken. Aan de andere kant is een unified design veel simpeler en kun je de pipe makkelijker bezet houden. Daar levert je weer betere efficientie van je transistors op. Uiteindelijk krijg je ergens een omslagpunt.

Kijk weer naar de R300 vs NV30. De R300 had complexere shader units die meer transistors vergden, maar ze waren allemaal dezelfde en de core werd zeer efficient gebruikt. Uiteindelijk pakte het ontwerp van de R300 het beste uit.

De beschikbaarheid van DX10 code zal inderdaad een flink stuk bepalen. Maar ook de wijze waarop de DX9 code in Vista verwerkt gaat worden.
DX10 code geeft wel een aantal opties in spellen die in DX9 (bijna) niet mogelijk zijn. Als die opties gebruikt gaan worden zullen ze wel veel aandacht gaan krijgen.

Dat is onzin, het ligt niet aan de GPU. Dat weet ik 100% zeker! De GPU van de Xbox is (toch?) beter dan de x1900 en moet nog voor de desktop komen? Nou zijn de huidige Xbox360 spellen niet zo zwaar, dus zou de gpu er een dikke anti-alias overheen kunnen gooien. Als je met je x1900 al makkelijk 4x AA over iedere game kan gooeien, hoezo zou het dan niet met de Xbox360 kunnen? Als de Gpu in de Xbox360 slechter was dan een x1900 hadden ze wel een x1900 erin gezet denk ik hoor

Na nader onderzoek denk ik dat het aan de games ligt, ik heb nu even screens gevonden van Fight Night Round 3... Zal nog wel een jaartje of 2 duren voordat ik dat hier op mijn desktop zo mooi kan toveren:
http://media.teamxbox.com...8/full-res/1139868781.jpg
http://media.teamxbox.com...8/full-res/1139408219.jpg
Ik zie hier dus geen aliasing! Bij uitgemolken spellen als Fifa street zie ik het wel, EA is gewoon lui... het ligt aan de games.

De X1900 heeft wat meer shader hardware, 48 pixelshader pipelines en een stel vertex pipelines. Bovendien heeft die een heel stuk meer geheugenbandbreedte.

4xAA is relatief, op 640x480 kan een GF4MX nog wel 4xAA doen...Bovendien is MSAA nog geen SSAA.

Ik begin erg in herhaling te vallen, maar de PGR3 screens zagen er super super super super ongelovelijk mooi uit, dat zegt niet veel...

48 pixel shader units. Geen pipelines!

En jij weet net zo goed als de rest hier, dat wanneer PGR3 aliasing heeft, dat het dan gewoon door de programmeurs komt en niet door de gpu.

De shader units zijn ge-pipelined, iedere FPU is ge-pipelined....Het is anders als een pixel pipeline zoals we vroeger kende, maar het blijven allemaal pipelines.

Als een spel waar ze lang aan gewerkt is, waarvan ik zulke mooie screens heb gezien, dat werkt op een chip die vanzichzelf gratis AA weg hoort te geven, dan kan het inderdaad nogsteeds aan de programeur liggen, maar een beetje vreemd zou ik dat wel vinden.

Een beetje vreemd ja. Maar nog altijd minder vreemd dan wanneer het aan de gpu zou liggen.

We hebben namelijk al het bewijs dat die gpu keurig nette AA levert en dat ie dat "gratis" doet, bij allerlei andere titels.

Btw als je perse over pipelines wilt praten bij de X1900, dan is de enige juiste omschrijving dat het ding 16 pipelines heeft.

Ze hebben gekozen wat voor HEN (vogens hen) de snelste/meest efficiente/goedkoopste architectuur is.

Dat hoeft helemaal niet te betekenen dat dat ook voor ATI geldt.

De ervaring van beide bedrijven is immers verschillend, en er zitten ook de nodige essentiele verschillen in hun huidige ontwerpen, die kunnen verklaren waarom ze er verschillend over denken.

Wat betreft de noodzaak van unified hardware. Het ligt er net aan wat je definitie van noodzaak is.
Zoals ik elders al aangaf kun je unified code op non-unified hardware draaien. Maar het betekent dat je een zeer inefficiente gpu krijgt. Bovendien kan het niet op een huidige generatie gpu. Je moet namelijk allerlei extra opties inbouwen. Als je namelijk een unified shader hebt die afhankelijk is van zowel pixel als vertex data en berekeningen, dan moeten je pixel shaders je vertex data kunnen aanspreken, en je vertex shaders je pixel data. Dat betekent dus extra transistors in vergelijking met de huidige kaarten.
En dat was nou net de reden waarom je geen unified architectuur wilde. ("je" hier in de algemene vorm gebruikt)

m.a.w. het belangrijkste nadeel van een unified design moet je dus ook in gaan bouwen in je non-unified design. Maar zonder dat je er de voordelen van een unified design voor terug krijgt.