nVidia GT300 (40nm) DirectX 11 [Speku-, News- & Diskussionsthread] [Part 1.1]

[PCZeus]

Wenn ich mir das Whitepaper nochmal genauer bzw. die Diagramme, dann muss ich irgendwie immer daran denken, dass nVidia mit dem G300 zwar paar "Altlasten" vom G80 weiter mitschleppt, sich dafür aber auf paar wesentliche Verbesserungen konzentriert hat. Für mich wirkt es wie ein Spagat zwischen GPU und CPU. Vllt. baut man auch auf RT-Raytracing auf bzw. arbeitet darauf hin?

 

[Der_ZockerMK]

Kann ich mir auch garnicht vorstellen. Einen Tesselator in Hardware zu gießen ist nicht aufwändig und kostet (vergleichsweise) auch nur wenig Transistoren. Das durch Geometry Shader zu emulieren, stelle ich mir deutlich aufwändiger (und langsamer) vor und wüsste folglich auch nicht, warum man das wollen sollte. Hull und Domain Shading sind tatsächlich eine Softwarefrage, aber das ist bei ATi ebenfalls so.

NAja, pb ein tesselator wirklich so einfach eben in silizium gegossen werden kann bezweifel ich mal, muss ja auch immer mit der restlichen architektur hamonieren usw.

Aber woher weißt du überhaupt das ein Tesselator grundsätzlich leicht zu entwickeln und in selizium zu integrieren ist?

 

[Lord]

Aber woher weißt du überhaupt das ein Tesselator grundsätzlich leicht zu entwickeln und in selizium zu integrieren ist?

Nun, ich weiß, wie leicht/schwer es ist, den restlichen Teil einer GPU zu bauen, und ich weiß, wie tesseliert wird. Daraus kann man durchaus Rückschlüsse darauf ziehen, ob das machbar ist oder nicht. Die Diskussion, ob es machbar ist, erübrigt sich natürlich, ATi hat es ja gezeigt. Es handelt sich jedenfalls nicht um Logik, die bei der Implementierung irgendwelche Probleme mit sich bringen würde, die der Rest der GPU nicht hat (was ich wiederum aus Erfahrung weiß). Es wäre jedenfalls mindestens ebenso aufwändig, eine Softwareimplementierung der Tesselierung zu implementieren (die auf einer GPU laufen kann), was aber den Nachteil hat, dass es deutlich langsamer läuft - insofern sollte klar sein, welche Lösung angepeilt wird.

Inwiefern soll das mit der restlichen Architektur "harmonieren"?

Vorstellbar ist meiner Ansicht nach lediglich, dass man so sehr an den Grenzen des Transistorbudgets arbeitet, dass man keine andere Wahl hatte, als die Tesselierung in Software zu realisieren. Das wäre möglich. Glücklich wäre eine solche Lösung aber nicht unbedingt. An der Stelle würde ich gern mal mr.dude fragen, warum das denn gegen die Spezifikation von DX11 sprechen würde? Entsprechende API-Calls werden ja trotzdem verarbeitet, nur eben nicht von dedizierter Hardware. Wichtig ist doch nur, dass die Grafiklösung (GPU + Treiber) die entsprechenden DX-Spezifikationen einhält, oder?

 

[mr.dude]

Es ist so ein zwischending. der modulare aufbau und die ganzen gpgpu features sind schon grundlegend neu!!

Das zählt nicht. Eyefinitiy ist zB auch grundlegend neu. Und das Instruction Set wurde bei der RV8xx Generation ebenfalls erweitert. Klar gibt es immer neue Sachen, die implementiert werden. Das ändert aber nichts an der eigentlichen Basis. Es ist und bleibt Evolution. Auch beim GT300. DX11, GDDR5 und 40 nm gibt und gab es bei der Konkurrenz genauso. Ist also auch kein Argument.

Vllt. baut man auch auf RT-Raytracing auf bzw. arbeitet darauf hin?

Daran wird jeder der Grossen momentan arbeiten, AMD, Intel und nVidia.

Inwiefern soll das mit der restlichen Architektur "harmonieren"?

Der Tesselator ist Teil der Processing Pipeline. Man muss ihn also damit abstimmen, was davor und danach passiert. Soweit ich weiss, dürften das die Geometrie und Vertex Shader sein. Als trivial würde ich eine solche Implementierung daher auch nicht ansehen. Auch wenn ich mir immer noch nicht vorstellen kann, dass nVidia lediglich eine Softwarelösung bieten wird.

An der Stelle würde ich gern mal mr.dude fragen, warum das denn gegen die Spezifikation von DX11 sprechen würde? Entsprechende API-Calls werden ja trotzdem verarbeitet, nur eben nicht von dedizierter Hardware.

Das ist zwar richtig, aber Tesselation ist nun mal Bestandteil der DX11 Spezifikation. Und das sollte die Hardware dann natürlich auch unterstützen. Klar kann man für grundsätzliche Kompatibilität auch alles in Software emulieren. Aber dann brauche ich keine Grafikkarte mit zertifiziertem "DirectX kompatibel" Logo. Da möchte ich schon, dass die Hardware auch den vollen Umfang der Spezifikation unterstützt.

 

[Lord]

Der Tesselator ist Teil der Processing Pipeline. Man muss ihn also damit abstimmen, was davor und danach passiert. Soweit ich weiss, dürften das die Geometrie und Vertex Shader sein. Als trivial würde ich eine solche Implementierung daher auch nicht ansehen. Auch wenn ich mir immer noch nicht vorstellen kann, dass nVidia lediglich eine Softwarelösung bieten wird.

Ja, du hast Recht, Vertex ist vorher und Geometry ist nachher. Da die Tesselierung aber faktisch aus der Natur der Sache heraus genau dort dazwischenpasst, muss man da, denke ich jedenfalls, nicht viel abstimmen. Trivial ist Hardwareentwurf wohl nie, da weiß ich, wovon ich rede, aber ich hab das ja oben schon relativiert - es ist sicherlich nicht ungleich schwieriger als der Rest und mit ziemlicher Sicherheit einfacher als komplexe Logik für Scheduling oder Arbitrierung (wie zB der UTDP bei ATI).

Zur DX11-Sache stimm ich dir zu, hab ja oben auch schon geschrieben, dass das bestenfalls als Notlösung zu bezeichnen wäre.

 

[Haro]

Ich denk das Softwarelösungen nicht gegen DX11 verstoßen, denn somit wär der Intel Larrabee ja keine DX11 karte, da dieser bekanterweise alles über software realisiert.

Also wär der GT300 trotz software lösung DX11 fähig, da hier nicht die CPU einspringen muss , sondern es trotzdem über die GPU realisiert wird!

 

[PCZeus]

Ob die Karte nun DX11 konform ist oder nicht sehe ich als zweitrangig an. Eine viel interessantere Frage wäre: wie weit lässt sich die Tesselation per Software optimieren und verbessern? Oder treten ab einem bestimmten Punkt Faktoren auf, die die ganze Lösung limitieren? (Verwaltungsaufwand usw.).

 

[Affenkopp]

Tja die Frage wird man wohl erst in wenigen tagen/Wochen präzise beantworten können.
DX11 ist für mich auch kein Feature, dass ich brauche. Bis die ersten Spiele komplett unterstützen, habe ich wieder ne neue Karte im Gehäuse...

 

[Neurosphere]

Ich denk das Softwarelösungen nicht gegen DX11 verstoßen, denn somit wär der Intel Larrabee ja keine DX11 karte, da dieser bekanterweise alles über software realisiert.

Also wär der GT300 trotz software lösung DX11 fähig, da hier nicht die CPU einspringen muss , sondern es trotzdem über die GPU realisiert wird!

Stimmt zwar schon, aber soviel mir bekannt ist muss sich das ganze in Hardware widerspiegeln um DX konform zu sein.

LRB bzw G300 könnten in einem solchen Fall zwar das ganze unterstützen, wären aber trotzdem nicht DX11 kompatibel.

Ich denke in einem solchen Fall liegt es bei Microsoft wie das ganze ausgelegt werden soll. Schnell kann ich mir aber die Realisierung per Software auch nicht vorstellen.

 

[Motkachler]

Wenn das stimmt dann gute nacht NV.

the GT300 will take a performance nosedive, the R870 won't.
GT300 is basically Larrabee done wrong for the wrong reasons. Amusingly though, it misses both of the attempted targets. R870 should pummel it in DX10/DX11 performance, but if you buy a $400-600 GPU for ripping DVDs to your Ipod, Nvidia has a card for you. Maybe. Yield problems notwithstanding.
GT300 will be quarters late, and without a miracle, miss back to school,
http://www.theinquirer.net/inquirer/news/1137331/a-look-nvidia-gt300-architecture

 

[Duplex]

Der GT300 wird schon sehr stark werden, aber 2010 hat ATI eine neue Generation wieder http://www.radeon3d.org/index/ati_grafikkarten/oktober_2009/radeons_fuer_2010_sind_neuentwicklungen/

 

[Der_ZockerMK]

Wenn das stimmt dann gute nacht NV.

the GT300 will take a performance nosedive, the R870 won't.
GT300 is basically Larrabee done wrong for the wrong reasons. Amusingly though, it misses both of the attempted targets. R870 should pummel it in DX10/DX11 performance, but if you buy a $400-600 GPU for ripping DVDs to your Ipod, Nvidia has a card for you. Maybe. Yield problems notwithstanding.
GT300 will be quarters late, and without a miracle, miss back to school,
http://www.theinquirer.net/inquirer/news/1137331/a-look-nvidia-gt300-architecture

Das stimmt nicht, der artikel ist von charlie, dem größten NV hasser überhaupt. Er macht immer solche Untergangsszenarien für Nvidia, das ist sein hobby. Nvidia ist kein amateur, die wissen was sie bringen müssen und worauf es ankommt.

 

[PCZeus]

Eben, der eine schreibt das, der andere bringt total gegensätzliche News, das ist doch immer wieder das selbe

 

[Dampfkanes]

diese Nachricht ist vom 14. Mai 2009.
Ich glaub ich nehm mir erst gar nicht die Zeit um sie zu lesen.
edit
Ok, diesen Artikel kannte ich schon.

 

[Lord]

Jau, gabs schon vor Ewigkeiten und wurde auch schon vor Ewigkeiten als Mumpitz abgetan.

 

[Motkachler]

Komisch ist halt das er bisher recht hatte. Wenn man die Provokationen nicht beachtet.
Er sagte Der kommt nicht 2009 ist wohl so.
Er sagte der G200 wir noch 2009 eingestellt ist wohl so.
Aber wir werden sehen
Wenn er wirklich so rockt in Games wird halt der gekauft. Bis der kommt ist die 5870 wohl eh schon alt für Karten verhältnisse.

 

[Der_ZockerMK]

Komisch ist halt das er bisher recht hatte. Wenn man die Provokationen nicht beachtet.
Er sagte Der kommt nicht 2009 ist wohl so.
Er sagte der G200 wir noch 2009 eingestellt ist wohl so.
Aber wir werden sehen
Wenn er wirklich so rockt in Games wird halt der gekauft. Bis der kommt ist die 5870 wohl eh schon alt für Karten verhältnisse.

Noch ist garnicht so. Momentan geht ende November als releasetermin um, warum auch nicht. aber um die karte auch in ausreichenden stückzahlen parrat zu haben müsste NV mitte diesen monta, also nächste woche mit der massenproduktion anfangen, ob das klappt.

Nunja, NV wird wissen was sie da machen, also wird man sehen.

 

[Affenkopp]

Ende November glaube ich nicht...

Dann sicher nur ein paar Wenige zu Apothekerpreisen, um den Termin zu halten.

Die schüren bestimmt nur Gerüchte, damit die Leute nicht alle zu ATI überlaufen.
Ich werde jedenfalls brav abwarten und dann vergleichen!

 

[Der_ZockerMK]

NUNja, den G300 hat noch niemand gesehen, vllt. kann man den schon produzieren, soll ja auch kleiner als der GT300 sein, dank weniger GPGPU balllast. Volker aus dem CB-forum hat auch schon angedeuet das sie bereits testsamples von Nvidia erhalten haben.

Man hat ihn noch nocht präsentiert um es vor ATI zu verstecken, um aber gegen ATI anzustenkern den noch nicht marktreifen GT300 präsentiert. Dieser kommt wohl wie immer etwas später. DAs hat auch den vorteil das ati nicht direkt in die karten von nvidia im desktopbereich gucken konnte und man die tesla-karten gut in szene setzen konnte, ohne von den spiele-benchmarks überlagert zu werden.

war also durchaus geschickt von nvidia.

 

[mr.dude]

Also wär der GT300 trotz software lösung DX11 fähig, da hier nicht die CPU einspringen muss , sondern es trotzdem über die GPU realisiert wird!

Na dann ist es doch keine Softwarelösung mehr, wenn die GPU die Berechnung übernimmt. Auf welche Art und Weise sie das tut, ist wieder ein anderes Thema.
"Softwarelösung" heisst, dass die CPU die notwendige Berechnung übernimmt. Und das ist letztendlich eine Frage der Performance.

 

[Edgecrusher86]

NUNja, den G300 hat noch niemand gesehen, vllt. kann man den schon produzieren, soll ja auch kleiner als der GT300 sein, dank weniger GPGPU balllast. Volker aus dem CB-forum hat auch schon angedeuet das sie bereits testsamples von Nvidia erhalten haben.

Man hat ihn noch nocht präsentiert um es vor ATI zu verstecken, um aber gegen ATI anzustenkern den noch nicht marktreifen GT300 präsentiert. Dieser kommt wohl wie immer etwas später. DAs hat auch den vorteil das ati nicht direkt in die karten von nvidia im desktopbereich gucken konnte und man die tesla-karten gut in szene setzen konnte, ohne von den spiele-benchmarks überlagert zu werden.

war also durchaus geschickt von nvidia.

Wäre ein guter Schritt von NV eine Version mit Priorität auf den professionellen Markt (also cGPU und Double Precision) und eine für den Gamermarkt rauszubringen (eventuell mit höheren Taktraten, da ja "entschlackt").

 

[Haro]

Na dann ist es doch keine Softwarelösung mehr, wenn die GPU die Berechnung übernimmt. Auf welche Art und Weise sie das tut, ist wieder ein anderes Thema.
"Softwarelösung" heisst, dass die CPU die notwendige Berechnung übernimmt. Und das ist letztendlich eine Frage der Performance.

Ich mein ja auch software seitig im vergleich zum RV870, also GPU intern nicht Hardwareseitig sondern softwareseitig über die CUDA-Cores gelöst.

So stand es auf einigen News Seiten

 

[Lord]

Na dann ist es doch keine Softwarelösung mehr, wenn die GPU die Berechnung übernimmt. Auf welche Art und Weise sie das tut, ist wieder ein anderes Thema.
"Softwarelösung" heisst, dass die CPU die notwendige Berechnung übernimmt. Und das ist letztendlich eine Frage der Performance.

Jain. Die GPU kann ebenso die Tesselierung nur durch ein zusätzliches Softwarelayer realisieren (bspw. Umweg über GS für Kontrollpunkte, Volumendatengenerierung, VS fürs Vertex Setup, ...). Eine Softwarelösung ist es dann deshalb, weil die notwendige Hardware, um nativ zu tesselieren, nicht vorhanden ist, sondern der Ablauf durch Software realisiert wird. Die GPU macht natürlich trotzdem die Arbeit, nur eben langsamer als mit einem in Hardware gebastelten Tesselator, weil die ganze GPU okkupiert wird anstatt dedizierter HW.
Allerdings bilde ich mir ein, dass man das ohne diverse Bypasses und kapazitiv umgebastelte Shader wohl kaum so einfach realisieren kann, jedenfalls nicht mit bisherigen Designs.

 

[Neurosphere]

Die Frage bleibt aber stehen, warum sollte NV den Weg über Software wählen wenn die hardwareseitige Unterstützung effizienter und scheinbar auch einfacher zu realisieren wäre?

 

[Thrawn.]

Die Frage bleibt aber stehen, warum sollte NV den Weg über Software wählen wenn die hardwareseitige Unterstützung effizienter und scheinbar auch einfacher zu realisieren wäre?

weil bei der entwicklung darauf warum uch immer keinen wert gelegt wurde und es nun die einzige möglcihkeit ist ?

 

[Neurosphere]

weil bei der entwicklung darauf warum uch immer keinen wert gelegt wurde und es nun die einzige möglcihkeit ist ?

Bezweifel ich eigentlich ziemlich stark. Normalerweise war NV meines Wissens nach immer Dingen Pro eingestellt die die Entwicklungsarbeit von Programmierern vereinfacht.

 

[Lord]

Bezweifel ich eigentlich ziemlich stark. Normalerweise war NV meines Wissens nach immer Dingen Pro eingestellt die die Entwicklungsarbeit von Programmierern vereinfacht.

Wie weiter oben schon gesagt, mir fällt als einziger eventuell plausibler Grund auch nur ein, dass man das Transistorbudget auch ohne die entsprechende HW für die Tesselierung schon absolut ausgereizt hat. Das spräche allerdings nicht gerade für den Chip.

 

[fdsonne]

PhysX braucht aber heute auch schon leistung , siehe Badman:AA tests.

Einige seite haben es berichtet, feste aussagen gibt es dazu seitens NV noch nicht.


Aber NV geht jetzt eher den weg des intel larrabee, alles frei programmiertbar und meiste neue sachen über software laufen lassen.


hier von FiringSquad zu Badman:AA

GeForce GTX 275
Kein PhysX:119
Low PhysX:55
High PhysX:46

Also ich find das frisst ordentlich an leistung ^^

Um das nochmal kurz aufzugreifen...
Diese FPS Einbrüche bei zugeschaltetem PhysX sind ganz normal und auch erklärbar...

Wenn kein PhysX berechnet werden muss, steht quasi die komplette Power der 3D Berechnung zur verfügung.
Beim zuschalten von PhysX entsteht neben der eigentlichen Last des Shadercodes noch die Last für die Zusatzeffekte und obendrein muss der PhysX Code noch über Cuda abgearbeitet werden.

Sprich man verliert bei GPU basierten PhysX auf einer Karte quasi "doppelt" Leistung... hat dafür aber auch bessere Effekte...

Es ging aber da eher um die Möglichkeit, die dedizierten Units für doppelte Prezision wegzulassen oder deutlich zu dezimieren.
Denn eben diese Units spielen im Gamingbereich sogut wie keine Rolle, da diese wärend des Gamens nix machen, sondern brach liegen...

Baut man diese bei der Gamingversion aus, spart man Platz auf dem Wafer und büst nur in Wissenschaftlichen Anwendungen (oder besser, wo DP gefragt ist) Leistung ein, der Rest sollte identisch laufen, sofern nicht noch irgendwo was weg rationalisiert wird...

ich finds je mal wieder richtig lustig

man erinnere sich mal an Nvidias G80 launch und die zeit danach als AMD seinen R600 so hochgehypet hat und er dann als Highendkarte grad mal mit ne G80 GTS mithalten konnte

wie hier schon steht. der breit wird langenicht so heis gefuttert wie er gekocht wird. die zeit wird zeigen ob die gerüchte wahr sind oder nicht

und ja ich benutze NV und ATI

Moment...
AMD hat den R600 in keinster Weise hochgelobt oder ähnliches... Das kam alles von der Community, welche anhand von Unwissenheit die möglichen Spezifikationen der Karte viel zu gut interpretiert hat... (Wohl einfach, weil bis dato nix über die Leistungsfähigkeit von 5D ALUs bekannt war)

Aber man muss auch hier sagen, NV gibt sich sehr bedeckt, was die Leistung des neuen anbelangt... Sprich wenn dann hypt hier wieder die Community, und genau diese wird als erstes Enttäuscht, wenns anders (schlechter) kommt...

 

[mr.dude]

Eine Softwarelösung ist es dann deshalb, weil die notwendige Hardware, um nativ zu tesselieren, nicht vorhanden ist, sondern der Ablauf durch Software realisiert wird. Die GPU macht natürlich trotzdem die Arbeit, nur eben langsamer als mit einem in Hardware gebastelten Tesselator, weil die ganze GPU okkupiert wird anstatt dedizierter HW.

Ok, dann haben wir anscheinend eine andere Auffassung von "Softwarelösung". Aus Sicht von DirectX bedeutet das ausschliesslich CPU. Es gibt dafür extra eine Initialisierung, die die vorhandene Hardware (GPU) ausblendet. ZB 3dmark06 wird diesen Modus beim CPU Rendering sicherlich auch nutzen. Wobei ich nicht sagen kann, inwiefern das für DirectX 10 und aufwärts noch gültig ist. Diese Schnittstellen kenne ich zu wenig.
Wenn die GPU die Berechnung übernimmt, egal wie es realisiert wird, ist das für mich immer noch eine Hardwarelösung. Wie effizient das ganze letztendlich ist, ist wiederum ein anderes Thema. AA wurde zB beim R600 auch anderes gehandhabt als bei den Nachfolgern. Trotzdem würde hier wohl niemand von einer Softwarelösung sprechen wollen.

 

[fdsonne]

Ok, dann haben wir anscheinend eine andere Auffassung von "Softwarelösung". Aus Sicht von DirectX bedeutet das ausschliesslich CPU. Es gibt dafür extra eine Initialisierung, die die vorhandene Hardware (GPU) ausblendet. ZB 3dmark06 wird diesen Modus beim CPU Rendering sicherlich auch nutzen. Wobei ich nicht sagen kann, inwiefern das für DirectX 10 und aufwärts noch gültig ist. Diese Schnittstellen kenne ich zu wenig.
Wenn die GPU die Berechnung übernimmt, egal wie es realisiert wird, ist das für mich immer noch eine Hardwarelösung. Wie effizient das ganze letztendlich ist, ist wiederum ein anderes Thema. AA wurde zB beim R600 auch anderes gehandhabt als bei den Nachfolgern. Trotzdem würde hier wohl niemand von einer Softwarelösung sprechen wollen.

Beim R600 gabs Treiber, die AA über die Shader realisieren, aber ich glaub mich erinnern zu können, das das nur im Anfangsstadium der Treiber so gemacht wurde...
Dabei war die Qualität nicht ganz so gut, wie bei der ROP basierten Version, und das bild hat einen starken blur-Effekt gezeigt, aber es war deutlich schneller...

Aber zum anderen, was wäre das dann für dich?
Eine Hardwarelösung ist ja nicht, weil die dedizierte Einheit dazu fehlt, aber eine Softwarelösung im Sinne von, die CPU berechnet, ist es auch nicht...
Man könnte von Hardware basierter Lösung sprächen.
Ähnlich dem Raid 5 von Controllern ohne XOR Einheit... Ist weder in Hardware, noch komplett in Software...