GT400/GF100 - Q1/2010, DX11, CUDA 3.0

[Gast]

Du kannst mit einem Rasterizer nur ein Dreieck auf einmal bearbeiten, musst aber deine WARPs/Wavefronts füllen. Man kann aber nicht einfach die Anzahl der Fragmente beliebig erhöhen, wenn die Dreiecke nur noch 10 Pixel groß sind.


Meinst du damit, dass Fermi seine Warps mit Pixeln aus verschiedenen Dreiecken auffüllen kann?

[Gast]

Es geht bis 90% hoch. nVidia's max Frame liegt an einer anderen Stelle als der von AMD.

Respekt du schafft es noch aus den von NV ausgesuchten Beispielen noch mehr raus zu holen. Dann heißt es ab jetzt "Fermi 90% schneller als Cypress!!!"

[MorPheuZ]

Seid lieb zueinander. Ist doch klar dass die Infos noch mehr anheizen als vorher. Zumal man die Richtung doch langsam erkennen kann.

[Ailuros]

Also da wäre ich mir zum jetzigen Zeitpunkt nicht sicher. Man wird erst sehen müssen ob "up to 2x" dann am Ende mehr sein wird als 80% on average die man mit Cypress jetzt schon haben kann.

Cypress ist wohl nur fuer Dich durchschnittlich um 80% schneller als eine GTX285. Da Cypress eher +/- auf GTX295 liegt, muesste die letztere auch um ueber 80% durchschnittlich schneller sein als eine 295.

Tatsache ist dass sich KEINER vor dem eigentlichen Launch und einer Reihe an unabhaengigen Tests sicher sein wird und bis zu dem Punkt heisst es fuer den 0815 Leser den ueblichen PR/marketing Mist einer jeglichen Praesentation zur Seite zu schieben und sich nur aufs wichtigste zu konzentrieren im gegebenen Fall die architektur-bedingten Aenderungen.

Ich finde es erstaunlich wie nvidia es mit ein paar Slides schafft ihre Fangemeinde so lange (oder besser gesagt noch länger) bei der Stange zu halten obwohl man im Endeffekt nicht schlauer ist wie vor ein paar Tagen

Deine Provokationen helfen auf keinen Fall, da Du nicht gerade das beste Beispiel bist von jemand der zumindest versuchen wuerde selbst einen Blitz objektive zu sein. Es war uebrigens auch nicht anders vor der R600 Veroeffentlichung, was aber wiederrum zeigt dass man sich zuerst einen Spiegel besuchen sollte bevor man mit Fingern herumzeigt.

[BlackBirdSR]

Ich würde vorschlagen, dass man auf der Spielwiese einen Thread für Fan-Gerede erstellt und diesen Thread penibel auf gewollt hohem Niveau hält!
Ist nämlich sehr interessant und man hat doch durchaus Interesse daran, dies so beizubehalten oder?

[Spasstiger]

Respekt du schafft es noch aus den von NV ausgesuchten Beispielen noch mehr raus zu holen. Dann heißt es ab jetzt "Fermi 90% schneller als Cypress!!!"
Er hat aber schon recht. Momentane Frameraten sollte man eigentlich nur zu gleichen Zeitpunkten vergleichen. Wird aber auch bei Reviewseiten nie gemacht.
Aussagekräftiger wäre für den vorliegenden Fall: Die GF100-Karte ist zwischen 10% und 80% schneller als die Radeon HD 5870, im Mittel sind es 60%.

[Gast]

Ihr meint also, der Unigine Bench wäre gefaked? Da würde sich NVidia aber ins Bein schiessen. Auch wenns ne ausgesuchte Stelle ist, sagt das für mich viel aus.

[AnarchX]

Cypress ist wohl nur fuer Dich durchschnittlich um 80% schneller als eine GTX285.

In 2560x1600 8xAA/16xAF erreicht eine 5870 durchaus 180% bis 197% Avg. einer GTX 285:
http://www.hardware.fr/articles/770-23/dossier-amd-radeon-hd-5870-5850.html
http://www.computerbase.de/artikel/hardware/grafikkarten/2009/test_grafikkarten_2009/18/#abschnitt_performancerating_qualitaet
Da hat er recht.

Frag sich nur was Nvidia als "high resolution" definiert, bei 1920x1200 sieht es schon wieder etwas ander aus. Und Faktor 2 stellt auch nicht das Maximum für die Leistung unter 8xAA dar, wie man ja mit den 2,33 in HAWX zeigt.

[Gast]

Nebenbei wird die Performance noch verbessert, es wurde in einem frühen Zeitpunkt gebencht. Ebenso ist der Fermi eine neue Architektur, ATI`S Design dürfte ausgelutscht sein. Also eher wächste der Abstand noch.

[Ailuros]

Ich würde vorschlagen, dass man auf der Spielwiese einen Thread für Fan-Gerede erstellt und diesen Thread penibel auf gewollt hohem Niveau hält!
Ist nämlich sehr interessant und man hat doch durchaus Interesse daran, dies so beizubehalten oder?

Hat schon B3D versucht die Threads zu trennen und es hat sich kein bisschen etwas daran geaendert. Die stoerenden Faktoren werden stets mit Absicht in allen Threads die am meisten besucht werden fuer nutzlose Sticheleien sorgen.

Ich moechte hiermit bitten dass die Debatte weiterhin so streng wie moeglich sachlich und beim Thema bleibt. Danke

Weiss jetzt jemand unser Gurus hier etwas zu dem merkwuerdigen Fall mit der 4 offset gather 4 Extension? Ich bin zwar kein Fan von Konspirations-Theorien aber wenn AMD nicht in naechster Zeit bestaetigt dass es M$ das Ganze nur schlecht dokumentiert haben koennte es eventuell schon ein kleiner Skandal sein.

[Dural]

In 2560x1600 8xAA/16xAF erreicht eine 5870 durchaus 180% bis 197% Avg. einer GTX 285:
http://www.hardware.fr/articles/770-23/dossier-amd-radeon-hd-5870-5850.html
http://www.computerbase.de/artikel/hardware/grafikkarten/2009/test_grafikkarten_2009/18/#abschnitt_performancerating_qualitaet
Da hat er recht.

Frag sich nur was Nvidia als "high resolution" definiert, bei 1920x1200 sieht es schon wieder etwas ander aus. Und Faktor 2 stellt auch nicht das Maximum für die Leistung unter 8xAA dar, wie man ja mit den 2,33 in HAWX zeigt.


das sind 97% und nicht 197% ;)

[Gast]

Wieviel werden davon wohl übrig bleiben bei unabhängigen Tests ohne Rosinen picken und bei geringerem Tesslationsgrad? Oder beim Großteil der Spiele die noch überhaupt kein DX11 und damit keine Tesslation verwenden?

Uniengine wurde auf ATI-Karten entwickelt, also Rosinen picken ist da was anderes.

[derguru]

Echt? "On Average"? Wo denn? 2.560x1.600 mit 8x MSAA?
ja was denkst du denn was in der pr folie von nv gemeint war ,bei HAWX bis zu 133% schneller unter 8AA oder nicht?

so hätte dann die pr folie von amd ausgesehen(bis zu 129% schneller als eine 285gtx),deswegen sag ich auch das man das nicht überbewerten soll.
http://www.abload.de/thumb/hawxkjky.gif (http://www.abload.de/image.php?img=hawxkjky.gif)

[Gast]

ja was denkst du denn was in der pr folie von nv gemeint war ,bei HAWX bis zu 233% schneller unter 8AA oder nicht?

so hätte dann die pr folie von amd ausgesehen(bis zu 229% schneller als eine 285gtx),deswegen sag ich auch das man das nicht überbewerten soll.
http://www.abload.de/thumb/hawxkjky.gif (http://www.abload.de/image.php?img=hawxkjky.gif)

Hm, schonmal daran gedacht, dass der Karte der Speicher ausgeht? Oder auch mal daran, dass in diesem Fall die GTX285 mit 4xMSAA mehr als doppelt so schnell ist und somit selbst die nVidia eigenen Zahlen falsch sind?
Hoffentlich wird die Moderation gegen solche Beiträge etwas machen: Das ist pures Trollen.

[Spasstiger]

Sorry für OT, aber Leute: Lernt Prozentrechnen!
200% von Etwas sind 100% mehr als Etwas.
Und 200% mehr als Etwas sind 300% von Etwas.
Außerdem sind 50% weniger immer die Hälfte von Etwas, 50% mehr dagegen nicht das Doppelte.

[Ailuros]

In 2560x1600 8xAA/16xAF erreicht eine 5870 durchaus 180% bis 197% Avg. einer GTX 285:
http://www.hardware.fr/articles/770-23/dossier-amd-radeon-hd-5870-5850.html
http://www.computerbase.de/artikel/hardware/grafikkarten/2009/test_grafikkarten_2009/18/#abschnitt_performancerating_qualitaet
Da hat er recht.

Frag sich nur was Nvidia als "high resolution" definiert, bei 1920x1200 sieht es schon wieder etwas ander aus. Und Faktor 2 stellt auch nicht das Maximum für die Leistung unter 8xAA dar, wie man ja mit den 2,33 in HAWX zeigt.

Durchschnittlich und nicht gleich die gleichen Rosinen picken wie NVIDIA in ihrem PR Zeug. Ich sagte durchschnittlich und nicht bis zu und er sagte auch klipp und klar "on average".

[Gipsel]

Aber wie hoch ist die Trefferrate in einem 8 KiByte-L1 gegenüber einem 12 KiB Textur- und bis zu 48 KiB L1 bei verteilten Zugriffen? Wir sprechen hier ja nicht über die regelmäßigen Muster bei normaler Texturfilterung.
Laß mich nachdenken .... Eventuell praktisch genauso hoch! ;)

Denn die 48kB GP-L1 sind ja von den 12kB Texture-L1 getrennt, im ersteren sind also keine Texturdaten drin, die Textureinheiten haben einfach keinen Zugriff darauf. Es läuft also auf den 12kB <-> 8kB Vergleich hinaus. Da kommt es dann darauf an, wie hoch die Assoziativität ist, wie die jeweiligen Architekturen die Texturen im Speicher anordnen (das ist ein Unterschied zwischen nv und ATI!) und dann natürlich, wieviele Pixel über den jeweiligen Cache texturiert werden müssen.

Nehmen wir mal die Variante mit 448 SPs, das sind also 14 SMs * 12 = 168kB Texture L1. Cypress hat 20*8 = 160kB. Das ist praktisch identisch. Berücksichtigt man noch, daß ATIs L1 voll assoziativ ist, kann sich nv da auch nicht absetzen, höchstens verlieren (weiß nicht, wie hoch die Assoziativität bei nv ist, der GP-L1 wird übrigens aus Latenzgründen eine niedrigere haben). Und das Hierchical-Z-Muster, was ATI für das Speicherlayout der Texturen benutzt, sieht für mich auch erstmal sehr optimal aus.

[Dural]

und der speicher scheint echt grenzwertig zu sein, siehe GTX295 die unter der GTX285 liegt!

aber hei, wenn da der GF100 sogar etwas vor der 5870 ist, ist das ja wohl sehr gut! Man sollte nicht vergessen das 2560 8AA das absolute ATI reich ist oder besser gesagt war... ;)

[Gast]

Hm, schonmal daran gedacht, dass der Karte der Speicher ausgeht?
Woran es genau liegt ist doch egal... hauptsache schneller, nur das interessiert PR.
Außerdem haben beide Karten 1GiB also fairer geht es kaum.

Hoffentlich wird die Moderation gegen solche Beiträge etwas machen: Das ist pures Trollen.
Was ist daran trollen?
Mmn ist das was guru geschrieben hat absolut korrekt.

[derguru]

und der speicher scheint echt grenzwertig zu sein, siehe GTX295 die unter der GTX285 liegt!

aber hei, wenn da der GF100 sogar etwas vor der 5870 ist, ist das ja wohl sehr gut! Man sollte nicht vergessen das 2560 8AA das absolute ATI reich ist oder besser gesagt war... ;)
das ist uninteressant ob der speicher ausgeht,in den folien von nv wird das mit sicherheit mit einkalkuliert,darum gehts.

[Gast]

Woran es genau liegt ist doch egal... hauptsache schneller, nur das interessiert PR.
Außerdem haben beide Karten 1GiB also fairer geht es kaum.

Soso. Das PR gibt also nur 60% schneller mit 4xMSAA gegenüber 8xMSAA an, wenn sie es gleich mit 150% machen könnte? Geniale PR Strategie. Vorallen, wenn GF100 mit 8xMSAA ja noch deutlich schneller wäre. Wie klingt 400%?

[Tarkin]

Es war uebrigens auch nicht anders vor der R600 Veroeffentlichung, was aber wiederrum zeigt dass man sich zuerst einen Spiegel besuchen sollte bevor man mit Fingern herumzeigt.

Wirklich? Ich kann mich nicht daran erinnern dass man damals 2x die Technik gelauncht hat und dann immer nocht nicht wusste was da eigentlich kommt.

[Gast]

Soso. Das PR gibt also nur 60% schneller mit 4xMSAA gegenüber 8xMSAA an, wenn sie es gleich mit 150% machen könnte? Geniale PR Strategie. Vorallen, wenn GF100 mit 8xMSAA ja noch deutlich schneller wäre. Wie klingt 400%?

Ergängzung: nVidia gibt an, dass GF100 60% schneller mit 4xMSAA ist. Brächte sie in diesem Benchmark auf 56 FPS. 8xMSAA soll nur 10% Leistung kosten - macht 50FPS. Und das entspricht Hemlock und wäre 3,6mal schneller als der GTX285 Wert.
Dafür müsste man nur eine Sekunde nachdenken.

[MoC]

das sind 97% und nicht 197% ;)

Das ist schlicht weg falsch.

AnarchX-Aussage ist richtig, er sagte:

"In 2560x1600 8xAA/16xAF erreicht eine 5870 durchaus 180% bis 197% Avg. einer GTX 285"

97% würde stimmen, wenn gesagt hätte:

"In 2560x1600 8xAA/16xAF erreicht eine 5870 durchaus 80% bis 97% Avg. höhere Performance einer GTX 285:"

^^

BTT: das mit der Extension würde mich auch brennend interessieren. Das ist eigentlich das interessanteste was gestern s bekannt wurde ^^

[BlackBirdSR]

Für mich wird interessant, wieviel Verbrauch eine durschnittliche OpenCL/CUDA-Anwendung erzeugt.

Es gibt durchaus einige Anwendungsbeispiele, wo der Einsatz zwar etwas mehr Leistung bringt, das aber bei vielen High-End-Karten in absolut keinem Zusammenhang zur zusätzlichen verbrauchssteigerung steht.

z.B. CoreAVC decoding mit CUDA.

[V2.0]

Man muss auch Fermi mal richtig einordnen. RV870 is t eine evolutionäre Entwicklung der letzten Generation, die an DX11 angepaßt wurde, der große Wurf bei ATI kommt mit der R900. Fermi ist die Architektur, die NV nun min. 2 Jahre einsetzen wird. Dafür finde ich die Ergebnisse arm, gerade auch weill sie gegen Eyefinity nicht anstinken können.

Wer die DX11-Architektur sehen will muss Fermi gegen R900 vergleichen.

[BlackBirdSR]

Man muss auch Fermi mal richtig einordnen. RV870 is t eine evolutionäre Entwicklung der letzten Generation, die an DX11 angepaßt wurde, der große Wurf bei ATI kommt mit der R900. Fermi ist die Architektur, die NV nun min. 2 Jahre einsetzen wird. Dafür finde ich die Ergebnisse arm, gerade auch weill sie gegen Eyefinity nicht anstinken können.

Wer die DX11-Architektur sehen will muss Fermi gegen R900 vergleichen.

Man muss differenzieren:
Architektur, Markt, Preis, Leistung und Attraktivität.. sie alle sind "einzelne" Vergleichsfaktorn. Den großen Fehler machen IMO die, welche alles zusammen gleichzeitig in einem vergleichen wollen. Das geht halt einfach nicht richtig.
Wird jeder bestätigen können, der sein Produkt mit dem der Konkurrenz vergleichen muss. Fragt mal die entsprechenden Leute.

[Gast]

Laß mich nachdenken .... Eventuell praktisch genauso hoch! ;)

Denn die 48kB GP-L1 sind ja von den 12kB Texture-L1 getrennt, im ersteren sind also keine Texturdaten drin, die Textureinheiten haben einfach keinen Zugriff darauf. Es läuft also auf den 12kB <-> 8kB Vergleich hinaus. Da kommt es dann darauf an, wie hoch die Assoziativität ist, wie die jeweiligen Architekturen die Texturen im Speicher anordnen (das ist ein Unterschied zwischen nv und ATI!) und dann natürlich, wieviele Pixel über den jeweiligen Cache texturiert werden müssen.
Ich glaube (=! wissen) nicht, dass für Gather der Texture-Filter-Cache genutzt wird, sondern der L1/SM. Denn die Filter dürften mMn in diesem Fall überhaupt nicht angesprochen werden: Man holt schließlich nur Speicheradressen.

-carsten

[Ailuros]

Wirklich? Ich kann mich nicht daran erinnern dass man damals 2x die Technik gelauncht hat und dann immer nocht nicht wusste was da eigentlich kommt.

Das war auch nicht gemeint. Aber Du persoenlich warst trotz enormer Verspaetung damals auch nicht weiser was wirklich mit R600 los war: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5182126&postcount=227

Ausser ich hab was verpasst hab ich von keinem NV-fan hier lesen koennen dass er etwas erwartet dass Fermi bis zu 50% schneller ist als 5870. Ergo Du wusstest auch nicht was auf Dich zukommt und nein eine jegliche PR Praesentation seitens ATI haette damals auch nichts geaendert. Deshalb sind Deine indirekten Sticheleien nicht nur unangebracht aber auch ziemlich tragische Ironie fuer Dich selber.

Und um es noch klarer zu machen: ich toleriere von jetzt ab keine weitere Provokationen oder Sticheleiren egal von welcher Fraktion sie kommen.

Man muss auch Fermi mal richtig einordnen. RV870 is t eine evolutionäre Entwicklung der letzten Generation, die an DX11 angepaßt wurde, der große Wurf bei ATI kommt mit der R900. Fermi ist die Architektur, die NV nun min. 2 Jahre einsetzen wird. Dafür finde ich die Ergebnisse arm, gerade auch weill sie gegen Eyefinity nicht anstinken können.

Wer die DX11-Architektur sehen will muss Fermi gegen R900 vergleichen.

Tja nur ist es mir als Endverbraucher auch ziemlich wurscht wie jeglicher IHV seine roadmap genau anlegt und wieso jeglicher sich hier und da verspaetet. Wenn ich eine Aufruestung brauche dann hol ich mir das was verfuegbar ist. Und nein NVIDIA Fermi ist nicht nur fuer 2 Jahre. Wenn Du den eingebetteten Markt noch mitrechnest streckt sich das Ganze womoeglich sogar ueber die 4-5 Jahre aus. Ein G9x Ableger fuer Tegra3 kommt erst in 2011 der ein G80/2006 Ableger eigentlich ist.

Bei AMD wird es auch nicht anders sein nur sieht es wohl eher danach aus dass ATI immer noch sehr gut die R600 Milchkuh ausmelken kann bevor man weitermacht. Und hier genau ist eben die wichtigste Kleinigkeit die viele nicht zu verstehen moegen: so wie sich die technologische roadmaps beider IHVs entwickelt haben wird NIE einer der beiden fuer die gesamten ~4 Jahre einer jeglichen Technologie-Generation den Vorsprung haben. Es wird stets eine Abwechslung geben und es ist auch zum absoluten Vorteil des Endverbrauchers.

[V2.0]

Da stimme ich Dir in allen Punkten zu. Mir ging es nur darum die "Begeisterung" gegenüber Fermi zu bremsen.

[Ailuros]

Da stimme ich Dir in allen Punkten zu. Mir ging es nur darum die "Begeisterung" gegenüber Fermi zu bremsen.

Es kann keine Begeisterung geben (ausserhalb rein technischen Aspekten) mit dem momentan vorliegendem Material aber auch keine Enttaeuschung da die wirklich wichtigen Einzelheiten fuer den Normalverbraucher noch nicht bekannt sind: http://forum.beyond3d.com/showpost.php?p=1382572&postcount=895

Man kann es wirlich nicht oft genug erwaehnen, dass wenn jemand heute eine DX11 GPU haben will diese bei ausgezeichneten Preisen heute erhaeltlich sind.

[Gast]

Ich persoenlich haette erwartet dass NVIDIA komplett die Klappe gehalten haette bis zum echten Launch, aber das bin natuerlich nur ich.Marketing ist bei NV mindestens ebenso wichtig wie die Technik selbst. Hast du das also ernsthaft erwartet, oder ist das nur ein Lippenbekenntnis?! OK, da du das Unternehmen schon seit langer Zeit gut kennst, kann meine Frage nur rein rhetorisch sein.

[Gast]

Marketing ist bei NV mindestens ebenso wichtig wie die Technik selbst. Hast du das also ernsthaft erwartet, oder ist das nur ein Lippenbekenntnis?! OK, da du das Unternehmen schon seit langer Zeit gut kennst, kann meine Frage nur rein rhetorisch sein.

nVidia hat etwas getan, was viele sogar von ihnen verlangt haben: Redet über den Gaming Aspekt von Fermi. Das plötzlich die selben Leute ihnen daraus einen Strick ziehen, zeigt nur, wie gut sie ihren Hals wenden können.
Ich jedenfalls freue mich über die neuen Aspekte. Wer mit dieser Art von Previews nicht leben kann, kauft sich einfach jetzt eine Karte oder vergisst es und wartet bis zum Launch.

[Ailuros]

Marketing ist bei NV mindestens ebenso wichtig wie die Technik selbst. Hast du das also ernsthaft erwartet, oder ist das nur ein Lippenbekenntnis?! OK, da du das Unternehmen schon seit langer Zeit gut kennst, kann meine Frage nur rein rhetorisch sein.

Es war lediglich eine Feststellung was ich gemacht haette und ja natuerlich passiert es aus gutem Grund. Es gibt aber einen Unterschied zwischen dem dementsprechenden Verstaendnis und ob man im Grund damit auch uebereinstimmt.

[igg]

Sagt Nvidia nichts, heißt es, sie haben Angst
Sagen sie etwas, heißt es sie teasern und halten die Performance aus Angst zurück
Machen sie einen Paperlaunch, wirft man ihnen das vor

[Menace]

Ich weiß gar nicht, was die kritischen Stimmen gegenüber Fermi (zu diesem Zeitpunkt) sollen. Ich selbst würde mich als Ati-affin bezeichnen (andere würden sogar mich als Ati-Fanboy beschimpfen, obwohl ich auch bis vor kurzem eine Nvidia hatte), aber ich muss der Fermi zu diesem Zeitpunkt trotzdem Respekt zollen. Anders als viele hier unkten, steht Fermi zukunftsicher da. Cuda, 3D, DX11 mit Tesselation, alles sieht soweit ich das einschätzen kann, ganz ordentlich aus. UND man muss der GraKa von Ati vergleichen, die momentan auf den Markt sind. Das AMD/Ati gesagt haben, dass es 2010 keine neue Generation gibt, braucht man auch nicht von einer R900 träumen. Ich finde es schwach, wenn man jetzt wieder sich darauf beruft, dass es bis zu einer imginären R900 eh nicht so viele Spiele gäbe. Vor kurzem wurde auf jeden DX11-Titel extra darauf hingewiesen. Nvidia muss seine GraKa jetzt endlich rausbringen und Ati muss sich was einfallen lassen.

Allerdings könnte mein Respekt ziemlich schnell verfliegen, falls der Ankündigung Pferdefüße folgen. :D

[Gast]

Sagt Nvidia nichts, heißt es, sie haben Angst
Sagen sie etwas, heißt es sie teasern und halten die Performance aus Angst zurück
Machen sie einen Paperlaunch, wirft man ihnen das vor
Du vergißt eines:
Bringen Sie ein Produkt auf den Markt, ist es verfrüht, Beta und generell eine Kundenverarsche.

-carsten

[Ailuros]

Du vergißt eines:
Bringen Sie ein Produkt auf den Markt, ist es verfrüht, Beta und generell eine Kundenverarsche.

-carsten

Hey Kritik ist eine schoene Sache :freak:

[MorPheuZ]

Vor kurzem wurde auf jeden DX11-Titel extra darauf hingewiesen. Nvidia muss seine GraKa jetzt endlich rausbringen und Ati muss sich was einfallen lassen.

Vor allem war es das Killerargument für ATI und auf einmal solls keine Rolle mehr spielen, ist klar:)

[desert]

Vor allem war es das Killerargument für ATI und auf einmal solls keine Rolle mehr spielen, ist klar:)

ist doch genauso mit den settings 2560 x 1560 und 8aa. Monate lang war es das beherrschende Thema und überall wurde als so wichtig dargestellt. Jetzt scheint es das nvidia die 8aa schwäche beseitig hat und plötzlich ist 8aa bei hohen auflösungen total unwichtig geworden, genauso wie tesselation und was ist jetzt?

Wie die fähnchen im wind wird hier seine Meinung geändert, denn plötzlich zählt für ati fraktion bildqualität ala ssaa. Jahrelang war es das unwichtigste feature von allen für sie, denn es gab ja 8aa und plötzlich ist es der neue heilsbringer.

Einfach lächerlich so etwas. Bis zu cebit sind ja auch nur noch 2 monate, die werden wir auch noch rumbringen.

[reunion]

Das AMD/Ati gesagt haben, dass es 2010 keine neue Generation gibt, braucht man auch nicht von einer R900 träumen.

Hat man das?

ist doch genauso mit den settings 2560 x 1560 und 8aa. Monate lang war es das beherrschende Thema und überall wurde als so wichtig dargestellt. Jetzt scheint es das nvidia die 8aa schwäche beseitig hat und plötzlich ist 8aa bei hohen auflösungen total unwichtig geworden, genauso wie tesselation und was ist jetzt?

Wie die fähnchen im wind wird hier seine Meinung geändert, denn plötzlich zählt für ati fraktion bildqualität ala ssaa. Jahrelang war es das unwichtigste feature von allen für sie, denn es gab ja 8aa und plötzlich ist es der neue heilsbringer.

Einfach lächerlich so etwas. Bis zu cebit sind ja auch nur noch 2 monate, die werden wir auch noch rumbringen.

Ja, und du bist mit Sicherheit der erste der plötzlich 8xAA für notwendig hält, nachdem er dies jahrelang für unnötig hielt. Das schönen ist ja dass das in beide Richtungen geht. Im übrigen habe ich hier noch niemanden gelesen der gesagt hat das Tesslation oder 8xAA jetzt mehr oder weniger wichtig geworden wäre. Deshalb verstehe ich jetzt auch nicht was diese Selbstbemitleidung bei den letzten Beiträgen hier soll.

[desert]

Hat man das?



Ja, und du bist mit Sicherheit der erste der plötzlich 8xAA für notwendig hält, nachdem er dies jahrelang für unnötig hielt. Das schönen ist ja dass das in beide Richtungen geht. Im übrigen habe ich hier noch niemanden gelesen der gesagt hat das Tesslation oder 8xAA jetzt mehr oder weniger wichtig geworden wäre. Deshalb verstehe ich jetzt auch nicht was diese Selbstbemitleidung bei den letzten Beiträgen hier soll.

Habe ich das geschrieben? noe denn für mich war 8aa noch nie wichtig, denn bevor ich 8aa anschalte, nutze ich lieber einen hybridmodi. Genauso wenig ist mir dx11 oder tesselation wichtig oder der verbrauch, alles nice to have aber nicht kaufentscheidend.

Für mich ist wichtig das ich selber entscheide wie ich das spiel spielen will, ob mit tmsaa oder tmssaa oder mit bester texturqualität oder nicht. Und das ist noch immer der grosse nachteil von ati, sie bevormunden ihre Käufer.

Was ist so schlimm an einem schalter für "profianwender" ? Mehr verlangt doch kein mensch

[Menace]

Hat man das?


Wenn ich mich nicht ganz arg täusche, ja, leider. 2010 beschränke man sich ausschließlich auf die Umstellung auf Global-Foundry. Hat es nicht sogar Dirk (Edit) Meyer gesagt? Vielleicht finde ich den Link noch.

[numb]

Dem entgegen steht die Aussage von AMD, dass sie sich sicher sind den Großteil des Jahres die schnellste Grafikkarte auf dem Markt zu haben ;)

[Gast]

dafür reicht es ja, wenn dual-GF100 erst in der 2. jahreshälfte kommt - und das wird so sein (whenever)

[Gast]

Dem entgegen steht die Aussage von AMD, dass sie sich sicher sind den Großteil des Jahres die schnellste Grafikkarte auf dem Markt zu haben ;)

Warum steht die entgegen die 5970 wir wahrscheinlich im Mittel schneller sein als die GTX 380 und wann und ob es eine X2 geben wird weis man nicht.

[numb]

Heißt es nicht momentan April-Mai für den Dual Fermi ?

- numb

[9*9=?]

Heißt es nicht momentan April-Mai für den Dual Fermi ?
so what? Wann sollte doch Fermi eigentlich gelaunched werden? Ich geb auf NVidia-Lauch-Ankündigungen genau garnix mehr.

[Gast]

Hat man das?
Ja, 2010 will AMD nutzen für den Umstieg auf GF und auch in jeder aktuellen Roadmap steht die kommenden Grafikkartengeneration erst für 2011 drin.

[Gast]

Arbeitest du bei nvidia an Fermi? Oder gibts vielleicht unanhängige Tests von denen keiner etwas weiß?

also bitte... manche wollen es halt nicht verstehen

Ich sehe anhand der Architektur wesentlich mehr Unterschiede zur Vorgängergeneration als es beim NV30 und r600 gab. Dazu kommt, dass nVidia einen Haufen von Transistoren und Zeit in eine bad-ass Tessellation-Implementierung investiert hat. GF100 wird dort verdammt schnell sein. Und dafür benötigt man nichtmal unabhängige Tests.

[V2.0]

Ich frage mich ja ob Ali, den Vergleich zum R600 aus Zufall gezogen hat. R600 war spät, hatte Probleme und war eine Enttäuschung.

GF100 ist spät, hat Probleme und ist ....

[reunion]

Wenn ich mich nicht ganz arg täusche, ja, leider. 2010 beschränke man sich ausschließlich auf die Umstellung auf Global-Foundry. Hat es nicht sogar Dirk (Edit) Meyer gesagt? Vielleicht finde ich den Link noch.

Ja, wäre nett, höre ich zum ersten mal.

Ja, 2010 will AMD nutzen für den Umstieg auf GF und auch in jeder aktuellen Roadmap steht die kommenden Grafikkartengeneration erst für 2011 drin.

Auch Evergreen stand auf jeder Roadmap für 2010 drinnen. Das schließt noch lange keine neue GPU Ende 2010 aus, das sind ja immer Plattformroadmaps.

[Gipsel]

Für mich wird interessant, wieviel Verbrauch eine durschnittliche OpenCL/CUDA-Anwendung erzeugt.

Es gibt durchaus einige Anwendungsbeispiele, wo der Einsatz zwar etwas mehr Leistung bringt, das aber bei vielen High-End-Karten in absolut keinem Zusammenhang zur zusätzlichen verbrauchssteigerung steht.

z.B. CoreAVC decoding mit CUDA.
Das ist im Einzelfall extrem verschieden, je nachdem welche Bereiche des Chips beansprucht werden. So kann durch eine perfekt die ALUs auslastende Anwendung die Temperaturen der Shadereinheiten in Furmark-Regionen oder auch darüber hinaus getrieben werden, gleichzeitig aber können z.B. die TMUs und das Speicherinterface fast unbeschäftigt sein. Andersrum führen einige Instruktionsmixe zu deutlich niedrigeren Stromverbräuchen (btw., bei exzessiven Integerrechnungen vertragen die meisten GPUs niedrigere Takte als bei floats bevor sie sich verrechnen, trotz niedrigerem stromverbrauch als bei fp-madds). Und bei speicherlimitierten Sachen verheizen hauptsächlich die Caches, das Speicherinterface und die ganzen Crossbars Energie, während die Shader Däumchen drehen (und Strom sparen). So eine richtig allgemeine Aussage kann man da nicht wirklich treffen, außer vielleicht daß die Texturfilter bei GPGPU doch etwas seltener genutzt werden (bietet sich aber eigentlich für die Interpolation von Werten aus Lookup-Tables an).

Ich glaube (=! wissen) nicht, dass für Gather der Texture-Filter-Cache genutzt wird, sondern der L1/SM. Denn die Filter dürften mMn in diesem Fall überhaupt nicht angesprochen werden: Man holt schließlich nur Speicheradressen.

-carsten
Hmm, Du meinst also, daß die Texturdaten, auf die mittels gather zugegriffen wird, in den GP-L1 gefetched werden? Das dürfte gar nicht so ganz einfach sein, weil Texturen nicht als normales Array im Speicher der Karten vorliegen, wie man das von CPUs kennt, sondern in einem wilden Zickzackmuster, damit man die räumliche Lokalität besser ausnutzen kann (um die Effizienz der Caches zu erhöhen). Nicht umsonst sitzt vor dem eigentlichen Texturefetch noch ein TA, der (unter anderem) die Texturkoordinaten entsprechend umrechnet. Außerdem hat Damien von nv zu hören bekommen, daß das gather4 nur "half rate" ist, also 128 Fetches pro Takt (welcher auch immer, Coda und ich meinen ja hot clock) kann. Aus dem GP-L1 kann man aber 256 Werte pro (hot clock) Takt laden. Eine Möglichkeit wäre natürlich, daß gerade diese kompliziertere Adressberechnung den möglichen Durchsatz einschränkt.

Andererseits ist dies aber auch eine Verkomplizierung des Designs, da Texturdaten (eventuell sogar mit unterschiedlichen Speicherlayouts!) in zwei verschiedenen L1-Caches gleichzeitig vorliegen können, wovon einer ein nur-Lese-Cache ist, der andere aber ein allgemeiner Schreib-Lese-Cache. Das Ganze dann für nur einen einzigen Anwendungsfall (point samples) auf sich zu nehmen, erschließt sich für mich jetzt nicht. Da hätte ich eher erwartet, daß man den Texture-L1 komplett spart und alles auf dem GP-L1 aufbaut. Dann wäre auch klar, daß die Filtereinheiten mit hot clock laufen. Zusätzlich dürften die Offsets z.B. beim "jittered sampling", was nv als Nutzung anführt üblicherweise klein sein, wodurch man mit dem für die Texture-Caches optimierten Layout wahrscheinlich bessere Hitraten erreicht.

[deekey777]

Für mich wird interessant, wieviel Verbrauch eine durschnittliche OpenCL/CUDA-Anwendung erzeugt.

Es gibt durchaus einige Anwendungsbeispiele, wo der Einsatz zwar etwas mehr Leistung bringt, das aber bei vielen High-End-Karten in absolut keinem Zusammenhang zur zusätzlichen verbrauchssteigerung steht.

z.B. CoreAVC decoding mit CUDA.
CoreAVC nutzt über eine spezielle API den Videoprocessor, der Verbrauch wird der gleiche wie mit DXVA sein.

[Palpatin]

Ich frage mich ja ob Ali, den Vergleich zum R600 aus Zufall gezogen hat. R600 war spät, hatte Probleme und war eine Enttäuschung.

GF100 ist spät, hat Probleme und ist ....
Ich hoffe ja auf nen starken GF 100 aber in der Vergangenheit wars leider nicht nur beim R600 so auch NV 30 war spät und hatte Probleme, VSA 100 war spät und hatte Probleme......

[Menace]

Ja, wäre nett, höre ich zum ersten mal.


http://ht4u.net/news/21385_2010_keine_neue_grafikkartengeneration_von_amd_-_switch_zu_globalfoundries_geplant/

Sorry für OT.

[Gast]

Ich hoffe ja auf nen starken GF 100 aber in der Vergangenheit wars leider nicht nur beim R600 so auch NV 30 war spät und hatte Probleme, VSA 100 war spät und hatte Probleme......

Naja wenn man zu spät ist hat man Probleme sonst wäre man ja nicht zu spät:)
Oft sind eben die Probleme so groß, dass man Sie nur noch notdürftig beheben kann.

[Spasstiger]

Wie Konfigurationsmöglichkeiten haltet ihr eigentlich für denkbar, wenn es um abgespeckte Varianten geht? Klar ist natürlich, dass man GPCs deaktivieren kann. Die GTX 360 könnte z.B. mit drei statt vier GPCs kommen, das wäre dann ähnlich wie bei G80 GTX und G80 GTS. Allerdings denke ich nicht, dass Nvidia den Unterschied zwischen der GTX 360 und GTX 380 so groß haben möchte, weil ja Gefahr in Form der Radeon HD 5870 lauert, die man vermutlich mit der GTX 360 direkt angehen möchte.
Jeweils einen SM pro GPC deaktivieren, führt in die gleiche Situation, dass nur 75% der Textur- und Recheneinheiten zur Verfügung stehen.
Sind unsymmetrische Konfigurationen denkbar? Z.B. ein GPC mit nur zwei SMs und drei GPCs mit vier SMs? Oder denkt ihr, dass diese Variante eher ineffizient ausfällt?

[AnarchX]

Sind unsymmetrische Konfigurationen denkbar? Z.B. ein GPC mit nur zwei SMs und drei GPCs mit vier SMs? Oder denkt ihr, dass diese Variante eher ineffizient ausfällt?
It is also worth mentioning that due to the load balancing architecture used in the GF100, it’s possible to eliminate multiple SPs from a single GPC without impacting the Raster Engine’s parallel communication with the other engines. So in theory, one GPC can have one to four SPs while all the other GPCs have their full amount without impacting performance one bit.
http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/27892-nvidia-s-geforce-gf100-under-microscope-6.html

Daneben gibt es ja schon die 448SPs Tesla und Andeutungen, dass in den Demos-Systemen auch nur eine 448SPs-Version lief.

Wenn die 375mm² für GF104 stimmen, dann hat dieser vielleicht sogar 4 GPCs mit je 2 SMs.

[Gast]

Wie Konfigurationsmöglichkeiten haltet ihr eigentlich für denkbar, wenn es um abgespeckte Varianten geht? Klar ist natürlich, dass man GPCs deaktivieren kann. Die GTX 360 könnte z.B. mit drei statt vier GPCs kommen, das wäre dann ähnlich wie bei G80 GTX und G80 GTS. Allerdings denke ich nicht, dass Nvidia den Unterschied zwischen der GTX 360 und GTX 380 so groß haben möchte, weil ja Gefahr in Form der Radeon HD 5870 lauert, die man vermutlich mit der GTX 360 direkt angehen möchte.
Jeweils einen SM pro GPC deaktivieren, führt in die gleiche Situation, dass nur 75% der Textur- und Recheneinheiten zur Verfügung stehen.
Sind unsymmetrische Konfigurationen denkbar? Z.B. ein GPC mit nur zwei SMs und drei GPCs mit vier SMs? Oder denkt ihr, dass diese Variante eher ineffizient ausfällt?

Es sollte alles denkbar sein. Einzelne SM bis zu GPC.

[Gipsel]

Wie Konfigurationsmöglichkeiten haltet ihr eigentlich für denkbar, wenn es um abgespeckte Varianten geht? Klar ist natürlich, dass man GPCs deaktivieren kann. Die GTX 360 könnte z.B. mit drei statt vier GPCs kommen, das wäre dann ähnlich wie bei G80 GTX und G80 GTS. Allerdings denke ich nicht, dass Nvidia den Unterschied zwischen der GTX 360 und GTX 380 so groß haben möchte, weil ja Gefahr in Form der Radeon HD 5870 lauert, die man vermutlich mit der GTX 360 direkt angehen möchte.
Jeweils einen SM pro GPC deaktivieren, führt in die gleiche Situation, dass nur 75% der Textur- und Recheneinheiten zur Verfügung stehen.
Sind unsymmetrische Konfigurationen denkbar? Z.B. ein GPC mit nur zwei SMs und drei GPCs mit vier SMs? Oder denkt ihr, dass diese Variante eher ineffizient ausfällt?
Bei B3D wurde die Meinung geäußert, daß die GPCs sowieso nur virtuell vorhanden sind (sprich Marketing), aber keine reale Gliederung des Chips darstellen. Es wurden ja auch schon Teslas mit 448 Einheiten, also 14 SMs, d.h. 3,5 GPCs angekündigt. Vielmehr wird vermutet, daß die 4 Setup/Rasterizer-Engines ihren Output wieder in eine globale Queue schreiben (natürlich mit genügend Ports, damit der Durchsatz dadurch nicht eingeschränkt wird), aus dem sich dann die vorhandenen SMs bedienen können, unabhängig von irgendwelchen Linien, die nvidia auf Blockdiagrammen für die Öffentlichkeit zieht ;)

[aths]

Das Rasterization-Bottleneck ist meiner Meinung nach das Problem warum wir in den letzten Jahren trotz steigender Rechenleistung keine ordentlichen Leistungssprünge mehr gesehen haben.Das ist natürlich richtig. In Dingen Tri-Setup zieht die 9800 GTX (oder GTS 250) eine GTX 285 ab, weil der Core-Takt höher ist. Da allerdings mit neuen Architekturen immer mehr in die Breite gegangen wird, kann man das Triangle-Setup nicht rein über den Takt steigern.


Dann müsste ja jetzt GF100 regelrecht explodieren mit der 8x Raserizerleistung einer GT200 wenn das schon lange der Bottleneck wäre. Laut Dave Baumann ist der Nutzen in aktuellen Spielen vernachlässigbar. Aktuelle Spiele nutzen auch noch vergleichweise große (und daher wenige) Dreiecke. Eine Tesselationseinheit ohne massiv gesteigerte Triangle-Setup-Leistung ergibt wenig Sinn.

Ich verkenne nicht die Reichweite, ist stelle nur die Frage ob sich das jetzt schon lohnt.Henne-Ei-Problem.

[Gast]

Hmm, Du meinst also, daß die Texturdaten, auf die mittels gather zugegriffen wird, in den GP-L1 gefetched werden? Das dürfte gar nicht so ganz einfach sein, weil Texturen nicht als normales Array im Speicher der Karten vorliegen, wie man das von CPUs kennt, sondern in einem wilden Zickzackmuster, damit man die räumliche Lokalität besser ausnutzen kann (um die Effizienz der Caches zu erhöhen). Nicht umsonst sitzt vor dem eigentlichen Texturefetch noch ein TA, der (unter anderem) die Texturkoordinaten entsprechend umrechnet. Außerdem hat Damien von nv zu hören bekommen, daß das gather4 nur "half rate" ist, also 128 Fetches pro Takt (welcher auch immer, Coda und ich meinen ja hot clock) kann. Aus dem GP-L1 kann man aber 256 Werte pro (hot clock) Takt laden. Eine Möglichkeit wäre natürlich, daß gerade diese kompliziertere Adressberechnung den möglichen Durchsatz einschränkt.

Andererseits ist dies aber auch eine Verkomplizierung des Designs, da Texturdaten (eventuell sogar mit unterschiedlichen Speicherlayouts!) in zwei verschiedenen L1-Caches gleichzeitig vorliegen können, wovon einer ein nur-Lese-Cache ist, der andere aber ein allgemeiner Schreib-Lese-Cache. Das Ganze dann für nur einen einzigen Anwendungsfall (point samples) auf sich zu nehmen, erschließt sich für mich jetzt nicht. Da hätte ich eher erwartet, daß man den Texture-L1 komplett spart und alles auf dem GP-L1 aufbaut. Dann wäre auch klar, daß die Filtereinheiten mit hot clock laufen. Zusätzlich dürften die Offsets z.B. beim "jittered sampling", was nv als Nutzung anführt üblicherweise klein sein, wodurch man mit dem für die Texture-Caches optimierten Layout wahrscheinlich bessere Hitraten erreicht.

Ja, das wäre mMn schon sinnvoll.

Eine andere Frage wäre noch, ob bei den Evergreens Gather-Fetches ohne Filterung überhaupt über die L2-Caches laufen oder direkt in den DRAM wie bei GT200 *urkgs* gehen.


-carsten

[reunion]

Ist das eigentlich schon offiziell? GF100 Whitepaper:
http://www.nvidia.com/object/IO_86775.html

[Gast]

Es gab weder beim R600 noch RV870 im Vorfeld Tech-Launches wie bei nVidia.
Was war das dann hier?

http://www.pcgameshardware.de/aid,689413/AMD-glaubt-DirectX-11-Radeons-erfreulich-schnell/Grafikkarte/News/

[aths]

Für mich ist Fermi ein Meilenstein. Hier wurde nicht einfach verdoppelt, für mich ist das eine neue Konstruktion.Für mich nicht. Die GT200/G80-Herkunft ist noch deutlich zu sehen. Nvidia hat die Architektur vor allem auf höhere Skalierbarkeit ausgelegt. Doch während von G92 zu GT200 vor allem Caches vergrößert wurden, hat Nvidia sich beim GF100 die Mühe gemacht, die Shader-Units neu zu gruppieren, den Scheduler zu verbessern und die TMUs in die Shader-Domain gelegt. Es wird der Tag kommen wo die TMU keine Fixed-Function-Unit mehr ist.

[IVN]

Für mich nicht. Die GT200/G80-Herkunft ist noch deutlich zu sehen. Nvidia hat die Architektur vor allem auf höhere Skalierbarkeit ausgelegt. Doch während von G92 zu GT200 vor allem Caches vergrößert wurden, hat Nvidia sich beim GF100 die Mühe gemacht, die Shader-Units neu zu gruppieren, den Scheduler zu verbessern und die TMUs in die Shader-Domain gelegt. Es wird der Tag kommen wo die TMU keine Fixed-Function-Unit mehr ist.
Und was bringt das dann, außer einem Verlust an Performance?

[Gast]

Für mich nicht. Die GT200/G80-Herkunft ist noch deutlich zu sehen.

Das einzige, was auf wirklich GT200 schließen lässt, ist das skalare Rechenwerk. Ansonsten giwurde das Design sowas von umgeändert, dass schon sehr beeindruckend erscheint - nv40 und r300 beeindruckend.

[Gast]

Und was bringt das dann, außer einem Verlust an Performance?

Das der komplette Platz der TMU (der vergleichsweise riesig ist) mit Streamprozessoren oder anderen Einheiten belegen kann.
Dadurch ist man flexibler(siehe vertex/pixelshader in früheren Architekturen) und hat nichtmehr das Problem dass man entweder Rechenleistungslimitiert (GPGPU) oder TMU limitiert (in manchen Spielen) ist

[reunion]

Das einzige, was auf wirklich GT200 schließen lässt, ist das skalare Rechenwerk. Ansonsten giwurde das Design sowas von umgeändert, dass schon sehr beeindruckend erscheint - nv40 und r300 beeindruckend.

Gerade NV40 od. R300 waren aus technologischer Sicht nicht wirklich beeindruckend, sondern eher Refreshes wo Fehler ausgebessert wurde. Bei G80 könnte man das behaupten. GF100 steht irgend wo in der Mitte, aber es ist ja noch lange nicht schlecht wenn nicht alles neu ist.

[Aquaschaf]

Es wird der Tag kommen wo die TMU keine Fixed-Function-Unit mehr ist.

An dem Tag esse ich einen Besen, oder auch zwei.

[reunion]

Und was bringt das dann, außer einem Verlust an Performance?

Derselbe Grund warum es überhaupt Rechenwerke gibt: Flexibilität.

[mrt]

Das einzige, was auf wirklich GT200 schließen lässt, ist das skalare Rechenwerk. Ansonsten giwurde das Design sowas von umgeändert, dass schon sehr beeindruckend erscheint - nv40 und r300 beeindruckend.
Das sind alles nur evolutionäre Schritte, wäre auch Wahnsinn immer wieder bei 0 zu beginnen. Ausnahmen gibt es und zwar wenn man sich mit der Architektur verrennt (zB nv1 oder aber auch G7x, da lohnte sich eine Neuentwicklung auch schon), sinnlos eine Revolution vom Zaun brechen kann auch nach hinten los gehn (siehe zB R400).
An dem Tag esse ich einen Besen, oder auch zwei.
Die Fotos stellst du dann aber hier rein. :)

[Gast]

Vielmehr wird vermutet, daß die 4 Setup/Rasterizer-Engines ihren Output wieder in eine globale Queue schreiben (natürlich mit genügend Ports, damit der Durchsatz dadurch nicht eingeschränkt wird), aus dem sich dann die vorhandenen SMs bedienen können, unabhängig von irgendwelchen Linien, die nvidia auf Blockdiagrammen für die Öffentlichkeit zieht ;)
Das braucht man doch gar nicht vermuten, denn es steht explizit im Whitepaper drin.
"The GigaThread Engine also redistributes work to the SMs when work expansion occurs in the graphics pipeline, such as after the tessellation and rasterization stages."


-carsten

[Aquaschaf]

Die Fotos stellst du dann aber hier rein. :)

Wenn bis dahin direkte Gedankenübertragung Internetforen als Kommunikationsform nicht bereits abgelöst hat, dann selbstverständlich ;)

[Gast]

Gerade NV40 od. R300 waren aus technologischer Sicht nicht wirklich beeindruckend, sondern eher Refreshes wo Fehler ausgebessert wurde. Bei G80 könnte man das behaupten. GF100 steht irgend wo in der Mitte, aber es ist ja noch lange nicht schlecht wenn nicht alles neu ist.

NV40 revidierte den kompletten NV30 Weg. Das war für nVidia-Verhältnisse ein Quantemsprung nach vorne. Quad-basierter Aufbau und pro Pixel-Pipeline eine Textureinheit.
R300 hat das 1 1/2 Jahre vorher eingeführt. Dazu gab es anscheinend schon die Trennung zwischen ALU und Textureinheiten.
R300 ist wie G80 technologisch heilig. NV40 ist genau wie GF100: Ein umkrempeln der Architektur auf sovielen Wegen.

[Gast]

Anscheinend ist es eher ein Ei - Henne Problem. ;)

-carsten

[Gast]

Das sind alles nur evolutionäre Schritte, wäre auch Wahnsinn immer wieder bei 0 zu beginnen. Ausnahmen gibt es und zwar wenn man sich mit der Architektur verrennt (zB nv1 oder aber auch G7x, da lohnte sich eine Neuentwicklung auch schon), sinnlos eine Revolution vom Zaun brechen kann auch nach hinten los gehn (siehe zB R400).


Nein, evolutionär ist Cypress. GF100 ist durch die Ausrichtung auf die Geometrie-Leistung und die Erhöhung von möglichen pro Takt bearbeiteten Dreiecken revolutionär.

[Gast]

Nein, evolutionär ist Cypress. GF100 ist durch die Ausrichtung auf die Geometrie-Leistung und die Erhöhung von möglichen pro Takt bearbeiteten Dreiecken revolutionär.

Was ist den eine Revolution in deinen Augen?

[Gast]

Und was bringt das dann, außer einem Verlust an Performance?
Also hättest du lieber wieder Fixed-Function Shader statt die aktuellen Unified Shaders? ;)

Man sollte nicht immer alles nachplappern, was bei Semiaccurate so erzählt wird.

[Gast]

Ich liebe es wenn Leute ohne technisches Basiswissen diskutieren...
Man kann von mir aus über die Definition ab wann man von einer neuen Arhitektur spricht diskutieren, aber nicht ob etwas eine Weiterentwicklung ist oder nicht.

Evolutionär bedeutet das stetige Verändern der Architektur. G70 war evolutionär zum NV40, aber dieser wohl kaum zum NV30. Genauso wie es GT200 zum G80, aber nicht G80 zum G71.
Mit GF100 haben wir einen neuen revolutionären Schritt: Das verstärke Betrachten von Eigenschaften der GPUs, das vorher nur in kleinen Schritten verbessert wurde.

[IVN]

Also hättest du lieber wieder Fixed-Function Shader statt die aktuellen Unified Shaders? ;)

Man sollte nicht immer alles nachplappern, was bei Semiaccurate so erzählt wird.
1) Ich kenne die Seite, lese sie aber nicht. Meine Zeit ist mir dafür zu kostbar.

2) Es sollte doch offensichtlich sein, das jede "Flexibilisierung", bei gegebenem Transistorbudget, in weniger Performance resultiert. Und da frage ich einfach, welche Verbesserungen in der Grafik/Effekten er (man) sich auf lange Sicht davon erhofft. Das ist alles.

[mrt]

Evolutionär bedeutet das stetige Verändern der Architektur. G70 war evolutionär zum NV40, aber dieser wohl kaum zum NV30. Genauso wie es GT200 zum G80, aber nicht G80 zum G71.
Mit GF100 haben wir einen neuen revolutionären Schritt: Das verstärke Betrachten von Eigenschaften der GPUs, das vorher nur in kleinen Schritten verbessert wurde.
Bedeutet die stätige Weiterentwicklung, damit sind auch Sprünge inkludiert.
Bei einer Revolution verwirft man die alten Konzepte und (teilweise) auch deren Implementierungen und fängt bei (fast) Null an. Sowas ist selten und das nicht ohne Grund.
NV40 ist "CineFX" genauso wie G70, NV30 hat auch noch so einges von NV2x und so weiter, wie gesagt, komplette Brüche sind selten (und das ist auch gut so).

[Gast]

2) Es sollte doch offensichtlich sein, das jede "Flexibilisierung", bei gegebenem Transistorbudget, in weniger Performance resultiert. Und da frage ich einfach, welche Verbesserungen in der Grafik/Effekten er (man) sich auf lange Sicht davon erhofft. Das ist alles.
Naja, du brauchst dich zum Beispiel beim Design deiner grundlegenden Chipelemente (SIMDs, GPCs) nicht mehr entscheiden, ob du viele TMUs auf Kosten der Shader oder andersrum einbauen willst. Skalierst du deinen gesamten Chip, skaliert die verfügbare Leistung für beide Betriebsarten automatisch mit.

-carsten

[aths]

Und was bringt das dann, außer einem Verlust an Performance?Performance-Steigerung, da man die Lerps (bzw. Mads) dann im Shader hat.

[Coda]

Eine lineare Performacesteigerung durch Parallelisierung rettet uns jetzt genau wie vor der Überlegenheit der logarithmischen Schranke beim RT (mit der da immer argumentiert wird / wurde)?
Die ist rein theoretischer Natur. Erstens gibt es Culling und zweitens braucht man ohnehin LOD.

Aber das ist jetzt wirklich brutal OT.

Es ging um die Skalierfähigkeit, die hat damit nichts zu tun.

NV40 revidierte den kompletten NV30 Weg. Das war für nVidia-Verhältnisse ein Quantemsprung nach vorne. Quad-basierter Aufbau und pro Pixel-Pipeline eine Textureinheit.
Auch NV30 war schon Quad-basiert. Sonst kann man überhaupt keine DDX/DDY-Instructions zur Verfügung stellen.

[aths]

NV40 revidierte den kompletten NV30 Weg. Das war für nVidia-Verhältnisse ein Quantemsprung nach vorne. Quad-basierter Aufbau und pro Pixel-Pipeline eine Textureinheit.
R300 hat das 1 1/2 Jahre vorher eingeführt. Dazu gab es anscheinend schon die Trennung zwischen ALU und Textureinheiten.
R300 ist wie G80 technologisch heilig. NV40 ist genau wie GF100: Ein umkrempeln der Architektur auf sovielen Wegen.NV40 streicht ausgehend vom NV30 eine TMU und fügt dafür ein MUL ein. Außerdem wurde das Registerfile verdoppelt.

Evolution.

[Gipsel]

Ja, das wäre mMn schon sinnvoll.Der ganze Extra-Aufwand für so wenig Vorteil?
Eine andere Frage wäre noch, ob bei den Evergreens Gather-Fetches ohne Filterung überhaupt über die L2-Caches laufen oder direkt in den DRAM wie bei GT200 *urkgs* gehen.

-carstenDas geht definitiv über die Caches (auch schon beim R600). Wieso sollten sie denn nicht? Die Daten müssten doch auch gefetched werden, wenn man die filtern wollte. Wieso sind die denn beim GT200 nicht im L2???
Das braucht man doch gar nicht vermuten, denn es steht explizit im Whitepaper drin.
"The GigaThread Engine also redistributes work to the SMs when work expansion occurs in the graphics pipeline, such as after the tessellation and rasterization stages."Jaja, die GigaThread-Engine, noch so eine Marketing-Bezeichnung ;)
An dem Tag esse ich einen Besen, oder auch zwei.
Na da würde ich sehr vorsichtig sein. Seitdem ATIs die Interpolation in den ALUs macht (das ist im Prinzip LERP + Offset), haben die diese entsprechend aufgebohrt, damit das effizient funktioniert. Eine einzige Cypress Einheit kann immerhin 2 LERPs für fp32-Komponenten pro Takt. Ein Texel hat 4 Komponenten und man benötigt 3 Lerps, um ein bilineare Filterung zu machen. Macht also 12 einkomponentige lerps für ein bilinear gefiltertes FP32-Texel, summa-summarum 6 Takte. Bei 320 Einheiten in Cypress sind das also maximal 53 bilinear gefilterte FP32-Texel pro Takt, macht theoretisch 45 GTexel/s für FP32 in den ALUs! Zum Vergleich, die TMUs können für FP32 nur 17 GTexel/s ;).

Real kommt dabei natürlich weniger bei rum (man bekommt gar nicht so viele Daten aus dem L1 ran), aber die Rechenleistung ist im Prinzip da.

@Coda: Wär das nicht mal was für Dich zu Ausprobieren von alternativen Filteralgorithmen?

[Coda]

Performance-Steigerung, da man die Lerps (bzw. Mads) dann im Shader hat.
I beg to differ.

Die Adresskalkulation usw. ist sehr komplex und kaum auf einem so hohen Takt zu machen. Das Filtering ist bei Fermi evtl. schon mit dem Shader-Core verwoben (deine LERPs).

Meinst du damit, dass Fermi seine Warps mit Pixeln aus verschiedenen Dreiecken auffüllen kann?
Das konnte auch G80 schon. Das Problem ist, dass der Rasterizer in einem Takt bei einem 1 Pixel großen Dreieck nur ein Quad erzeugen kann, bei einem 100 Pixel großen aber einen kompletten Warp.

Er kann nicht in einem Takt zwei Dreiecke bearbeiten die groß genug wären um einen Warp zu füllen.

[Gast]

Bedeutet die stätige Weiterentwicklung, damit sind auch Sprünge inkludiert.
Bei einer Revolution verwirft man die alten Konzepte und (teilweise) auch deren Implementierungen und fängt bei (fast) Null an. Sowas ist selten und das nicht ohne Grund.
NV40 ist "CineFX" genauso wie G70, NV30 hat auch noch so einges von NV2x und so weiter, wie gesagt, komplette Brüche sind selten (und das ist auch gut so).

Das sehe ich genauso.
Die einzig revolutionäre Architektur ist Larrabee (was rein gar nichts darüber aussagt ob Sie gut oder schlecht ist).
R900 wird sicher auch keine Revolution. Dazu besteht überhaupt kein Anlass.

[Coda]

Also ich finde es schon revolutionär was NVIDIA da gemacht hat mit der parallelen Rasterisierung. Wie gesagt wurde das seit dem Aufbruch der 3D-Chips nicht mehr verändert.

Das der Rest des Chips eher eine Evolution ist (vor allem die Streamprozessoren) ist klar.

[reunion]

Also ich finde es schon revolutionär was NVIDIA da gemacht hat mit der parallelen Rasterisierung. Wie gesagt wurde das seit dem Aufbruch der 3D-Chips nicht mehr verändert.


War wohl auch nicht wirklich nötig.

[Coda]

Das ist natürlich richtig. In Dingen Tri-Setup zieht die 9800 GTX (oder GTS 250) eine GTX 285 ab, weil der Core-Takt höher ist. Da allerdings mit neuen Architekturen immer mehr in die Breite gegangen wird, kann man das Triangle-Setup nicht rein über den Takt steigern.
Es geht nicht um das Tri-Setup. Wie oft noch?
Tri-Setup könnte man ohne weiteres parallelisieren. Aber das hilft nicht wenn der Rasterizer dahinter nur ein Dreieck/Takt "ansehen" kann.

War wohl auch nicht wirklich nötig.
Wird es aber immer mehr. Die Polygone werden kleiner und die sonstige Rechenleistung größer. Wenn das nicht in deinen Kopf will kann ich auch nichts dafür.

Und um das ganze mal mit Zahlen zu untermauern:
Quads translated by 1 pixel horizontally.
- size 64x64, 32x32, 16x16, 8x8 = 1.5s (ref time+~25%), 4x4=6.78, 1x1~=9.96 (8x ref time)
Bei 4x4 Pixel großen Dreiecken ist der Durchsatz noch 1/6 der eigentlichen möglichen Rate. Das ist alles schön aligned. Die Fälle passieren natürlich auch bei schmalen oder spitzen Polygonen.

Und die Raster-Rate muss weiter steigen um die ALUs zu füttern, das Problem ist seither also noch schlimmer geworden.

Hint: Crysis rastert 2 Mio. Polygone/Frame. Bei 1920x1200 entspricht das ziemlich genau einem Pixel/Dreieck (Milchmädchenrechnung; Durch Überdeckung sind sie wohl doppelt so groß). Aber das ist natürlich alles irrelevant. Klar.

[Gast]

Kann man eigentlich auch in den Streamprozessoren per Software rastern und wie langsam wäre das?

[Gipsel]

War wohl auch nicht wirklich nötig.
Bisher vielleicht nicht, aber es wird es immer mehr.

Ich bin auch der Meinung, daß sich ATI der Problematik natürlich ebenfalls vollkommen bewußt ist. Was man öffentlich dazu sagt, steht natürlich auf einem anderen Blatt. Im Prinzip hört man schon seit Jahren, daß die GPUs modularer werden müssen und das Problem der Skalierung mit einem Aufbau aus modularen, kleineren Einheiten gelöst werden soll.

Offensichtlich war die ATI-Lösung für Evergreen noch nicht fertig, dieser Dual-Rasterizer wirkt ein wenig wie ein spät dazugefügtes Addon, damit man überhaupt irgendwie unter bestimmten Bedingungen den Shadereinheiten genügend Pixel/Fragments anbieten kann. Aber das Skalierungsproblem des Rasterizers für kleine Dreiecke wurde damit natürlich überhaupt noch nicht gelöst. Für kleine Dreiecke sinkt die Rasterleistung eines Cypress auf Juniper-Niveau. Da darf man gespannt sein, wie Northern Islands das besser macht.

[Spasstiger]

Man kann in Software rastern, genau das war ja Intels Plan für Larabee. Aber ganz so gut kann dieser Plan nicht gewesen sein, denn Larabee wurde erstmal gestrichen und kommt - wenn überhaupt - erst in der zweiten Generation auf den Markt.

[Armaq]

Ich sehe halt keinen echten Vorteil in Tesselation/DX11 bei Nv und ATI. Wie immer hat die erste Generation der HW sowieso wenig Kontakt zu den Features die sie unterstützt. Allerdings sind längere Lebenszyklen natürlich ein dickes Plus für die Erstkäufer.

Wirklich gut finde ich bisher die Info zum Rasterizer. Auch wenn ich davon nicht viel verstehe, ist die Beseitigung eines Grundlagenproblems eine schwere und begrüßenswerte Entscheidung. Solche Dinge werden viel zu selten angefasst.

Allerdings finde ich es wirklich ärgerlich, dass keine Testhardware gezeigt wird. Wie soll die Karte aussehen, Eckdaten etc pp.

[PHuV]

Ich gehöre zu 3.) (wie Blaire, Don Vito etc auch ;)) und nicht zu 1.), wie du fälschlicherweise annimmst.
===

So, jetzt aber wieder zurück zu Fermi :)

Da hast Du mich auch vergessen, immerhin einer der wenigen hier, die auf 2560x1600 spielen, und aktuell zwangsmigriert auf eine 5970. :tongue:

Und weil manche hier so abfällig über die Neuerung und Leistung bei Tesslationn reden, bei der Geforce 256 wurde auch DDR und T&L neu eingeführt, und nach kurzer Zeit war es selbst verständlich. Von dem her müßte dieses Feature bei Stalker ja wohl reinhauen.

[Coda]

Womöglich Stand der Aufwand bei den beiden Chips noch in keinem Verhältnis zum Nutzen bei üblichen Anwendungen. Wir werden dann mit GF100 ja vermutlich sehr schön sehen wieviel das wo wirklich bringt. Ist ja nicht so das bsw. ein G92 irgendwo einem GT200 davon rennt deswegen, auch wenn der Chiptakt und damit dieses Limit höher ist. RV870 würde es bei Tesslation sicherlich was bringen, aber wenn ich deswegen bsw. 1/3 weniger Einheiten verbauen kann muss es auch noch lange nicht sinnvoll sein.
Natürlich, denn ATI (TM) weiß den einzig richtigen Weg!

Leuchtend mit der Laterne der Erkenntnis voran zeigen sie uns den Pfad der absolut einzig wahren Transistor/Performance-Effizienz. Heil AMD!

*facepalm*

[Gast]

Und weil manche hier so abfällig über die Neuerung und Leistung bei Tesslationn reden, bei der Geforce 256 wurde auch DDR und T&L neu eingeführt, und nach kurzer Zeit war es selbst verständlich. Von dem her müßte dieses Feature bei Stalker ja wohl reinhauen.

Wobei dies eher AMD's Cypress und Tessellation beschreibt. Vorhanden ja, aber nicht wirklich schnell. Scheint wohl, dass nVidia - warum auch immer - diesen Vorgang übersprungen und gleich zur "zweiten" Generation gegangen ist. Würde mich nicht wundern, wenn GF100 in aktuellen spielen nur irgendwas um 30% schneller ist, aber sobald Tessellation ins Spiel kommt, Kreise um Cypress fährt.

[Gast]

Du verstehst es nicht, würdigst aber AMD seit Jahren seine Tesselation Einheit als großen Sprung zu. Jetzt kommt etwas das dies bei weitem übertrifft, und nun stellst du den nutzen in Frage... Das ist unglaubwürdig.

[Armaq]

Natürlich, denn ATI (TM) weiß den einzig richtigen Weg!

Leuchtend mit der Laterne der Erkenntnis voran zeigen sie uns den Pfad der absolut einzig wahren Transistor/Performance-Effizienz. Heil AMD!

*facepalm*
Seine Aussage impliziert dies nicht. Er hat nur gesagt: Wir werden sehen.

[Armaq]

Bin ich der einzige Mensch, der das aus diesem einen Post nicht rausliest?

Edit:

Er windet sich raus, aber er argumentiert schon wieder den ganzen Thread lang so. Das hat er nicht einmal im RV870-Thread gemacht! DAS geht mir auf die Nüsse.

Diese einseitige Schlechtrederei. Vor nicht allzu langer Zeit war Tesselation noch das Wunderwerk der Technik bei RV870 und jetzt auf einmal ist das natürlich alles unwichtig.

Ich habe bestimmt 10 der letzten 20 Seiten wegen inhaltslosem Müll übersprungen, aber kannst du vll. kurz anreißen, was das bedeutet?
Die Lücke füllen reicht. ;)

Also Fermi ist schneller bei ... (Tesselation und ...), weil (rasterizer verbessert). Das ist seit 10 Jahren unangetastetes Gebiet.

[MadManniMan]

Hört mal kurz auf zu kindern und hört euch meine Frage an:

Es fällt wahnsinnig schwer, der ganzen Diskussion inhaltlich zu folgen, wenn man was den Aufbau eines Grafikchips anbelangt nicht auf dem aller aller neuesten Stand ist. Gibt es irgendwo einen Grundlagenartikel, der die aktuellen Entwicklungen/Probleme erklärt? Oder könnt gar ihr ganz kurz grob anreißen, was hier jetzt wie läuft?

Da wird von speziellen Caches geredet, speziellen Textureinheiten, Rasterizern, gfd4pfrecht8xpy (ich übertreib jetzt, aber kryptisch war es) und weiß der Geier was noch ... ohne Sekundärliteratur kommt man nicht mehr mit :(

[dargo]

Leute, jetzt hört doch bitte auf mit euren Sticheleien. Das ist echt Kindergarten-Niveau. :)

On-Topic:
Gibt es schon Informationen um welchen Faktor die gpu-basierte PhysX-Beschleunigung gegenüber dem GT200(b) gesteigert wurde? Bitte nicht gleich schlagen falls die Antwort im Threaddschungel schon vorhanden ist. :wink:

[Gast]

On-Topic:
Gibt es schon Informationen um welchen Faktor die gpu-basierte PhysX-Beschleunigung gegenüber dem GT200(b) gesteigert wurde? Bitte nicht gleich schlagen falls die Antwort im Threaddschungel schon vorhanden ist. :wink:
Ja, das umschalten zwischen CUDA und Grafik ist schneller geworden. Mit PhysX 3.0 (aber leider erst für Spiele, die das nutzen) werden auch die anderen Architekturvorteile des Fermis für PhysX genutzt.

[Gast]

On-Topic:
Gibt es schon Informationen um welchen Faktor die gpu-basierte PhysX-Beschleunigung gegenüber dem GT200(b) gesteigert wurde? Bitte nicht gleich schlagen falls die Antwort im Threaddschungel schon vorhanden ist. :wink:

Les das "Whitepaper" zu Fermi. Steigerung sind anscheinend deutlich.
Ansonsten hier erste Werte: http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/27892-nvidia-s-geforce-gf100-under-microscope-14.html

[dargo]

Ansonsten hier erste Werte: http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/27892-nvidia-s-geforce-gf100-under-microscope-14.html
Von dem Spiel habe ich zwar noch nichts gehört, die Werte überzeugen aber sehr. Gegenüber einem GT200 (ohne b) Faktor 2. :up:
Wenn man noch bedenkt in welchen Stadium sich die GF100-Treiber befinden und es eventuell sogar doch nur die "abgespeckte" GF100 Graka war... :)

Edit:
Ich hoffe nur, dass in diesem Test nicht 8xMSAA verwendet wurde. Das würde die neue Karte erheblich stärker ins bessere Licht rücken lassen.

[boxleitnerb]

Äh GTX285 ist doch GT200b, GT280 ist GT200???

[DrFreaK666]

Wann darf man mit vielen Spiele-Benches rechnen?

[Gast]

Wann darf man mit vielen Spiele-Benches rechnen?

Laut Charlie im März. ;)

[Gast]

Laut Charlie im März. ;)
Ab den Tag hat der nämlich plötzlich "Urlaub" :D

[DrFreaK666]

Ich meinte Benches vor dem launch

[DrFreaK666]

Paar Tage vorher.

Ist ja noch ewig hin :frown:
Ich will Benches und BQ-Vergleiche jetzt :-)

[IVN]

Ist ja noch ewig hin :frown:
Ich will Benches und BQ-Vergleiche jetzt :-)
Hier (http://www.benches.com/) und hier (http://www.vergleich.de/).

[master_blaster]

Äh GTX285 ist doch GT200b, GT280 ist GT200???
Ja!

Ab den Tag hat der nämlich plötzlich "Urlaub" :D
März ist ein Tag, :uponder:!?

[Ailuros]

Ich frage mich ja ob Ali, den Vergleich zum R600 aus Zufall gezogen hat. R600 war spät, hatte Probleme und war eine Enttäuschung.

GF100 ist spät, hat Probleme und ist ....

Ich sehe zumindest bis jetzt keine deutlichen falschen Design-Entscheidungen oder hoerte von hw bugs.

Bei B3D wurde die Meinung geäußert, daß die GPCs sowieso nur virtuell vorhanden sind (sprich Marketing), aber keine reale Gliederung des Chips darstellen. Es wurden ja auch schon Teslas mit 448 Einheiten, also 14 SMs, d.h. 3,5 GPCs angekündigt. Vielmehr wird vermutet, daß die 4 Setup/Rasterizer-Engines ihren Output wieder in eine globale Queue schreiben (natürlich mit genügend Ports, damit der Durchsatz dadurch nicht eingeschränkt wird), aus dem sich dann die vorhandenen SMs bedienen können, unabhängig von irgendwelchen Linien, die nvidia auf Blockdiagrammen für die Öffentlichkeit zieht ;)

Den Quark glaubt nichtmal AMD's competitive analysis. Ganz im Gegenteil.

Uebrigens sind es nicht 128 fetches in Deiner Rechnung vor einigen Seiten sondern 256 fetches/clock ergo ergibt es ~875MHz und nicht 1750.

[deekey777]

Les das "Whitepaper" zu Fermi. Steigerung sind anscheinend deutlich.
Ansonsten hier erste Werte: http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/27892-nvidia-s-geforce-gf100-under-microscope-14.html
This is one test where the GPU compute roots of the GF100 can really come into play by efficiently processing PhysX and rendering the scene at the same time. Performance is once again far beyond anything the GTX 285 can accomplish which should make things interesting come release.
Das ist eine sehr interessante Schlussfolgerung. Nur glaube ich dieser nicht. Denn:
Dark Void: Performance mit und ohne GPU-Physx
Die niedrigste Physx-Stufe steht auch Nutzern einer nicht GPU-Physx-tauglichen Grafikkarte zur Verfügung, "Mittel" und "Hoch" sind Geforce 8 oder besser vorbehalten. Laut Nvidia erfordert die mittlere Stufe bereits eine Geforce 9800 GTX+ und die hohe Stufe eine Geforce GTX 260-216 als dedizierten Physx-Beschleuniger!
Wenn eine GTX260 216 als PhysX-Beschleuniger empfohlen wird, dann liegt die GF100 eher deswegen vorn, weil sie doppelt so viele Einheiten wie eine GTX285 hat.

[horn 12]

Alles recht suspekt... Keine richtigen Spiele-Benchmarks und nur Timedemos, sprich Technologie Demos/ ausgewählte Games mit schneller, abgeknipster Framesanzeige, aber Keine Videos während dem Benchmark selbst, und auch etliche gar mit PyX und Co, welche die Werte um ein drastisches erhöht.

Zudem unternimt NV recht wenig die Kunden vor einem Kauf der Konkurrenz Produkte HD5750/5770 5850 5870 / 5970 fernzuhalten. Meiner Meinung sind sie selbst nicht soo überzeigt von Fermi,- denke die Rohleistung ist vorhanden, diese verpufft jedoch wenn Pysik-X/ andere Gegebenheiten nicht aktiv/ freigeschaltet werden/ sind.

Wäre der Fermi echt "Der Knaller schlechthin" würde man weitaus mehr präsentieren wollen und zudem AUCH TUN,- zumal die ATI Karten nun recht gut lieferbar sind.

Mit 20-30% über einer HD5870 kann man wohl langsam rechnen, aber der Preis der ATI Karte stinkt NV zum Himmel hinauf,- da die GTX nicht unter 550-600 Euro zu haben sein wird.
Und da sehe ich das Große Bangen bei NV,- und sie müssen alles daran setzen die GTX 360 schon über HD5870 Performance zu hiefen... dass es mit dem Preis hinhauen kann.

[Eggcake]

@horn

Mangelnde Infos/suspekte Benches zu kritisieren ist das eine, da bin ich ja noch einer Meinung (wobei man so viel vor dem Launch eigentlich nicht mehr erwarten sollte, warum auch), aber im gleichen Atemzug merkwürdige Gegentheorien aufzustellen (ohne was handfestes vorzuweisen) ist dann doch etwas unpassend ;)

Dass Fermi teuer wird, bestreitet aber wohl keiner. Die Frage ist, wieviel Mehrleistung man schlussendlich für den Aufpreis kriegt. Und das kann momentan nun wirklich keiner beantworten. Die einen sehen in den "Benches" von NV "die Wahrheit", andere ignorieren sie fast komplett, da "zu weit von der Realität entfernt".

Abgesehen von den technischen Details sind wir gleich unwissend wie zuvor.

[Gast]

Abgesehen von den technischen Details sind wir gleich unwissend wie zuvor.

Nein, das ist falsch. Man weiß wesentlich mehr als vor dem Fall des NDA. Das einige aufgrund mangelnden Interesse nicht verstehen wollen, ist etwas anderes.
Fakt ist, dass mit den vorhandenen Informationen hier vorallem eine DX11 GPU entstanden ist, die CS und Tessellation auf einem Niveau unterstützt, die jedem zufrieden stellen wird. Und das war es, was man als Gamer wissen wollte, oder?

[Eggcake]

Es ist also eine DX11 GPU entstanden. Okay.

Ich sagte ja: abseits von den technischen Infos gleich unwissend wie zuvor. Und bitte keine Korinthenk...erei, ich denke man versteht, was ich damit meine.

Edit: Damit nix falsches reininterpretiert wird, nochmals: ich will damit nicht sagen, dass es etwas "schlechtes" wäre, ich verlange zum jetzigen Zeitpunkt überhaupt nicht mehr. Meine nur, als "Gamer" bringen mir die jetzigen Infos genau 0 (auch wenn's für die Experten sehr interessant sein dürfte, wie man hier auch sehen kann).

[Gast]

Jetzt müsste man nur noch wissen ob Das in Zukunft entscheidend ist.

[Gast]

Es ist also eine DX11 GPU entstanden. Okay.

Ich sagte ja: abseits von den technischen Infos gleich unwissend wie zuvor. Und bitte keine Korinthenk...erei, ich denke man versteht, was ich damit meine.

Und ich sagte ja: Wenn man sich dafür nicht interessiert und unbedingt irgendwelche Zahlen sehen will, dann hat man natürlich nichts gelernt. Würde man auch nur ein paar Sekunden über die neuen Informationen nachdenken, dass sieht man, dass hier eine GPU entstanden ist, die sich eben auch an die Gamer richtet und für die erste Generation an DX11 GPUs schon fast ein Tessellationsbiest darstellt.
Und da Cypress kein Leistungswunder muss man sich um GF100 auch keine Sorgen machen.

[Ailuros]

Jeder darf seine Meinung vertreten so lange er sich innerhalb von logischen Grenzen bewegt.

Es ist ueberhaupt kein Spass zahllose irrelevante Posts zu loeschen. Im Gegensatz nervt es enorm. Ich werde zum letzten Mal bitten dass alle beteiligten so sachlich wie moeglich bleiben. Jemand bekam gerade Urlaub; wer der naechste sein will kann sich gerne an die Reihe stellen.

[Gipsel]

Den Quark glaubt nichtmal AMD's competitive analysis. Ganz im Gegenteil.Na dann sage doch mal, wie die 448SP-Versionen aussehen :rolleyes:. Für mich hört sich das ziemlich plausibel an. Was gefällt Dir denn daran nicht?

Uebrigens sind es nicht 128 fetches in Deiner Rechnung vor einigen Seiten sondern 256 fetches/clock ergo ergibt es ~875MHz und nicht 1750.256 fetches sind es aus dem GP-L1/shared memory. Ich zweifle ja noch daran, daß der auch für ungefilterte Zugriffe auf Texturen benutzt wird (statt des dedizierten Texture-Caches), da man dann entweder die Adressierungslogik duplizieren oder die Daten bei einem Fetch in den GP-L1 in ein anderes Layout umordnen müßte (oder nv schmeißt das angepaßte Textur-Layout komplett über Board, aber dann bräuchte man wohl keinen extra Texture-Cache mehr ;)). Allerdings hat laut Damien nvidia gesagt (wenn Du willst, suche ich das bei B3D raus), daß 4 offset gather 4 nur die Hälfte davon schafft. Das ergibt bei mir dann 128 fetches pro Takt ;)

[Coda]

Na dann sage doch mal, wie die 448SP-Versionen aussehen :rolleyes:. Für mich hört sich das ziemlich plausibel an. Was gefällt Dir denn daran nicht?
Ich glaube auch das du recht hast.

Das oder sie schalten wirklich einfach einen von 4 SMs ab die von einem Rasterizer gefüttert werden. Ist aber nicht so elegant.

[LuXon]

Folgendes ist mir aufgefallen:

Bei der GF100 reden die ja nicht mehr über ECC, DP usw.

Haben die jetzt zwei separate Masken erstellet?
Eine für Tesla mit ECC + DP usw.
Und für die GF100 dann ohne.

Oder sind es dann Teildefekte/Teildeaktivierte Tesla-GPU's?

[Gast]

Na dann sage doch mal, wie die 448SP-Versionen aussehen :rolleyes:. Für mich hört sich das ziemlich plausibel an. Was gefällt Dir denn daran nicht?
Mal dran gedacht, dass die Tesla für GPGPU gedacht ist und sich nicht an die bei Grafikkarten nötige Einteilungen halten muss?

[Gipsel]

Mal dran gedacht, dass die Tesla für GPGPU gedacht ist und sich nicht an die bei Grafikkarten nötige Einteilungen halten muss?
Das Silizium ist identisch. Und glaube mir, auf jeder Tesla wirst Du die normalen GPU-Fähigkeiten (Rasterizer, Texturing, ROPs usw.) auch nutzen können. Nvidia hat ja sogar extra betont, daß sie einen Displayanschluß an die Teslas bauen ;)

[Coda]

Die Teslas haben mit an Sicherheit grenzender Wahrscheinlichkeit den gleichen Chip wie die kommenden GeForces.

[Leonidas]

Hat das AMD mit ihren zwei Rasterizern nicht auch schon?


Das wäre so eine der großen Fragen. Ich sehe es derzeit so, daß ATI nur eine verdoppelte Raster-Einheit eingebaut hat (Coda sagte was von "verdoppelte Raster-Output-Leistung"), während nVidia mit faktisch vier getrennten, aber in sich kompletten Pipelines ankommt. Also der wesentlich umfassendere Ansatz und deswegen auch deutlich mächtiger als das, was ATI gebaut hat. Aber: All das basiert auf Vermutungen - schön wäre es, wenn sich das belegen lassen würde.



Bei B3D wurde die Meinung geäußert, daß die GPCs sowieso nur virtuell vorhanden sind (sprich Marketing), aber keine reale Gliederung des Chips darstellen. Es wurden ja auch schon Teslas mit 448 Einheiten, also 14 SMs, d.h. 3,5 GPCs angekündigt. Vielmehr wird vermutet, daß die 4 Setup/Rasterizer-Engines ihren Output wieder in eine globale Queue schreiben (natürlich mit genügend Ports, damit der Durchsatz dadurch nicht eingeschränkt wird), aus dem sich dann die vorhandenen SMs bedienen können, unabhängig von irgendwelchen Linien, die nvidia auf Blockdiagrammen für die Öffentlichkeit zieht ;)


Das wäre auch nochmal schön, wenn man dieser Sache auf den Grund gehen könnte.

[Ailuros]

Na dann sage doch mal, wie die 448SP-Versionen aussehen :rolleyes:. Für mich hört sich das ziemlich plausibel an. Was gefällt Dir denn daran nicht?

Weil ich mich eher vorstelle dass Fermi zwar 4 rasterizer Einheiten hat, aber mir nicht vorstellen kann dass es ohne Grund 4 insgesamt sind. Sie haben als Gegenbeispiel keine universale ff Tesselations-Einheit benutzt sondern haben das meisste auf bei relativ geringem Transistoren-budget auf 16 SMs verteilt (und etwas durch die programmierbare pipeline geschleusst blah blah blah).

Coda's Idee oben dass der raster stehen bleibt bei theoretischen 448SP mag zwar nicht elegant klingen aber mir hoeren sich diese oeden raster units auch nicht gerade nach Transistoren fressenden Monstern an. Ich wuerde sogar als Laie schaetzen dass jegliche der 4 kleiner ist als ein rasterizer der 16 SMs/bzw. 512SPs bedienen wuerde. Und ja kann sein dass ich spinne ;)

256 fetches sind es aus dem GP-L1/shared memory. Ich zweifle ja noch daran, daß der auch für ungefilterte Zugriffe auf Texturen benutzt wird (statt des dedizierten Texture-Caches), da man dann entweder die Adressierungslogik duplizieren oder die Daten bei einem Fetch in den GP-L1 in ein anderes Layout umordnen müßte (oder nv schmeißt das angepaßte Textur-Layout komplett über Board, aber dann bräuchte man wohl keinen extra Texture-Cache mehr ;)). Allerdings hat laut Damien nvidia gesagt (wenn Du willst, suche ich das bei B3D raus), daß 4 offset gather 4 nur die Hälfte davon schafft. Das ergibt bei mir dann 128 fetches pro Takt ;)

Nein brauchst Du nicht denn ich glaub Dir schon.

[Gast]

Das Silizium ist identisch. Und glaube mir, auf jeder Tesla wirst Du die normalen GPU-Fähigkeiten (Rasterizer, Texturing, ROPs usw.) auch nutzen können. Nvidia hat ja sogar extra betont, daß sie einen Displayanschluß an die Teslas bauen ;)
Wer sagt, dass die 3D können? Man muss doch gezielt die Teslas von den Quadros abgrenzen, also dürfen die im Grunde gar kein 3D können - zumindest nicht schnell ;)

[Leonidas]

Es ist ueberhaupt kein Spass zahllose irrelevante Posts zu loeschen. Im Gegensatz nervt es enorm. Ich werde zum letzten Mal bitten dass alle beteiligten so sachlich wie moeglich bleiben. Jemand bekam gerade Urlaub; wer der naechste sein will kann sich gerne an die Reihe stellen.


Ich unterstreich das mal. Ich hab jetzt 30 Seiten dieses Threads am Stück gelesen und was hier den Mods an Arbeit aufgebürdet wurde, geht über alles Maß drüber hinaus. Auf manchen Seiten musste jedes zweite Posting gekillt werden. Liebe Leute, die Mods haben auch andere Dinge zu tun, als so einen Wahnsinn dauerhaft bekämpfen zu müssen. Reisst euch zusammen!

[Gast]

Uebrigens sind es nicht 128 fetches in Deiner Rechnung vor einigen Seiten sondern 256 fetches/clock ergo ergibt es ~875MHz und nicht 1750.Ist das so ähnlich wie beim G80?
32 TAUs und 64 TMUs. Sprich 32 Texel können adressiert werden, aber 64 texturiert?

[Gast]

Ist das so ähnlich wie beim G80?
32 TAUs und 64 TMUs. Sprich 32 Texel können adressiert werden, aber 64 texturiert?

Das wäre Theorie 1.
Theorie 2 ist, dass die Filterunits auf Hot Clock laufen und die Address Units auf Hot Clock / 2.

[Gipsel]

Wer sagt, dass die 3D können?Ich! :D
Ist das so ähnlich wie beim G80?
32 TAUs und 64 TMUs. Sprich 32 Texel können adressiert werden, aber 64 texturiert?
So ähnlich, man hat (vielleicht) 64 bilineare Texturfilter, die auf der Shaderclock laufen und 64 TAs, die mit der halben Frequenz laufen.

[Gast]

Der Fermi ist ziemlich interessant, was die Spieleleistung angeht. Denn vergleichen wir eine Radeon HD 5870 und eine GTX 295 zu dem Zeitpunkt, als die Radeon HD5870 rauskam. Dabei stellt man in verschiedenen Benchmarks fest, dass die HD5870 zu Anfang noch um die 20-40% langsamer war als die GTX 295. Wenn man die HD5870 mit dem neusten Treiber gegen eine GTX295 antreten lässt, ist die 5870 meistens schneller. ALso: Beim Fermi könnte das gleiche passieren, denn ich glaube die Treiber sind noch nicht ausgereift und damit könnte man gleichauf mit der 5970 sein oder diese sogar schlagen.


mfg

[y33H@]

Wenn man die HD5870 mit dem neusten Treiber gegen eine GTX295 antreten lässt, ist die 5870 meistens schneller.Wie kommst du darauf? Seit dem v8.66 RC6 (Launch) hat sich bis heute iirc an den Fps der HD5k nichts getan, außer u.a. das CF-Profil für Dirt 2. Falls du Tests hast, die ein Plus durch Treiber bei der HD5870 erzielen - bitte her damit.

PS: Falls du dich auf CB-Tests beziehst, Vorsicht: der aktuelle Parcours ist mit DX11-SpeedUp, der alte ohne. Mit dem Treiber hat das imo aber nichts zu tun.

[Jake Dunn]

Die ~68% Mehrleistung im FC2 Bench ggü. der GTX285 sind im zu erwarteten Performancebereich von GF100, die ca. 100% in DarkVoid zeigen das man die gurkige GPU-PhysX-Performance der alten Grakas endlich in den Griff bekommt ^^

[y33H@]

PhysX = GGPU = Fermi-Paradedisziplin?

[Gast]

ist doch eh wurscht und vorallem viel zu langsam wenn man mit den "uralten 5000" von ATI vergleicht.

[BlackBirdSR]

PhysX = GGPU = Fermi-Paradedisziplin?


Na das will ich doch hoffen, immerhin hat Nvidia das Design extra dafür ausgelegt.


HW-PhysX schon von Beginn an das Problem, dass die Entwickler nicht so recht wussten, was sie machen sollen/können und das was sie gemacht haben, hat die Performance zu stark abgesenkt.

Das besserte sich nach der Übernahme durch Nvidia, gerade durch deren Support und Vorgaben, aber auch die pure Leistung der GPUs. Trotzdem war GPU-PhysX immer so ein Wackelkanditat....
Mit GF100 frage ich mich allerdings, ob jetzt plötzlich nicht so viel mehr Leistung zur Verfügung steht, dass GPU-PhysX sich langsam aber sicher ausbreitet. Vielleicht noch nicht 2010, aber sobald selbst Mainstreamkarten von Nvidia genug Leistung für sehr viele Effekte und eventuell sogar Spielmechanik haben, sollte sich AMD entschieden haben...

[mapel110]

PhysX = GGPU = Fermi-Paradedisziplin?
Inwiefern kann es Parade sein, wenn man die Shader-Einheiten von 240 auf 512 erhöht bei etwa gleichem Takt?! Irgendwie ist es da logisch, dass 100% oder gar mehr rausspringen, wenn diese limitieren.

[deekey777]

...
HW-PhysX schon von Beginn an das Problem, dass die Entwickler nicht so recht wussten, was sie machen sollen/können und das was sie gemacht haben, hat die Performance zu stark abgesenkt.

Das besserte sich nach der Übernahme durch Nvidia, gerade durch deren Support und Vorgaben, aber auch die pure Leistung der GPUs. Trotzdem war GPU-PhysX immer so ein Wackelkanditat....
Mit GF100 frage ich mich allerdings, ob jetzt plötzlich nicht so viel mehr Leistung zur Verfügung steht, dass GPU-PhysX sich langsam aber sicher ausbreitet. Vielleicht noch nicht 2010, aber sobald selbst Mainstreamkarten von Nvidia genug Leistung für sehr viele Effekte und eventuell sogar Spielmechanik haben, sollte sich AMD entschieden haben...
Für was soll sich AMD entschieden haben sollen? An Nvidia Lizentgebühren zu zahlen, damit Nvidia die Radeons als lizensierte PhysX-Plattformen auflistet?

Aber um deinen Gedanken weiterzuführen: Mit der Generation Fermi hat man eine "PhysX-Grafikkarte" geschaffen, die aufgrund ihrer Architektur einfach schnell ist. So schnell, dass es sich für Nvidia lohnt, PhysX für AMD über OpenCL zu öffnen, ohne eigene Position zu gefährden.

[Gast]

Na das will ich doch hoffen, immerhin hat Nvidia das Design extra dafür ausgelegt.


HW-PhysX schon von Beginn an das Problem, dass die Entwickler nicht so recht wussten, was sie machen sollen/können und das was sie gemacht haben, hat die Performance zu stark abgesenkt.

Das besserte sich nach der Übernahme durch Nvidia, gerade durch deren Support und Vorgaben, aber auch die pure Leistung der GPUs. Trotzdem war GPU-PhysX immer so ein Wackelkanditat....
Mit GF100 frage ich mich allerdings, ob jetzt plötzlich nicht so viel mehr Leistung zur Verfügung steht, dass GPU-PhysX sich langsam aber sicher ausbreitet. Vielleicht noch nicht 2010, aber sobald selbst Mainstreamkarten von Nvidia genug Leistung für sehr viele Effekte und eventuell sogar Spielmechanik haben, sollte sich AMD entschieden haben...Ist das nicht ein wenig sehr vorausschauend? Von welchem Zeitrahmen reden wir denn hier? Vielleicht 3 Jahre? Und solange es im gleichen Maße mehr CPU-Cores gibt, die kaum sinnvoll ausgelastet werden können und ihre FPU-Leistung auch mit AVX+mehr Kerne/HW-Threads vervielfachen, ist GPU-PhysX kaum ein MUSS und Havok noch immer eine gute alternative, die auf allen Rechnern funktioniert.

[Gast]

Zudem unternimt NV recht wenig die Kunden vor einem Kauf der Konkurrenz Produkte HD5750/5770 5850 5870 / 5970 fernzuhalten. Meiner Meinung sind sie selbst nicht soo überzeigt von Fermi,- denke die Rohleistung ist vorhanden, diese verpufft jedoch wenn Pysik-X/ andere Gegebenheiten nicht aktiv/ freigeschaltet werden/ sind.

Wäre der Fermi echt "Der Knaller schlechthin" würde man weitaus mehr präsentieren wollen und zudem AUCH TUN,- zumal die ATI Karten nun recht gut lieferbar sind.Fermi tritt ja nicht nur in Konkurrenz zu den ATIs, sondern auch zu NVs alter Garde. Es ist immer ein ziemlicher Tanz auf dem Drahtseil, die Kundschaft zwar von konkurrierenden Herstellern fernzuhalten aber nicht von seinen Auslaufmodellen. Schließlich will man die noch gut gefüllten Lager auf den Markt ausleeren, nicht auf den Sondermüll...

[Gast]

Inwiefern kann es Parade sein, wenn man die Shader-Einheiten von 240 auf 512 erhöht bei etwa gleichem Takt?! Irgendwie ist es da logisch, dass 100% oder gar mehr rausspringen, wenn diese limitieren.
Ich glaube nicht, dass die aktuell PhysX-Software 240 Shader ausnutzen kann. Die kommende ja, aber die aktuelle?!

[y33H@]

@ BlackBirdSR / mapel110

Das war eigentlich eine rhetorische Frage ;D

[Coda]

Ich glaube nicht, dass die aktuell PhysX-Software 240 Shader ausnutzen kann. Die kommende ja, aber die aktuelle?!
He? Natürlich kann sie das :freak:

CUDA skaliert transparent über die Anzahl der Cores.

[Gast]

He? Natürlich kann sie das :freak:

CUDA skaliert transparent über die Anzahl der Cores.
Cuda ja, aber die CUDA-Programme müssen natürlich entsprechend programmiert sein. Ein Singlethreading Programm bleibt Singlethreaded, egal wie oft du es durch CUDA jagst ;)

[Coda]

Cuda ja, aber die CUDA-Programme müssen natürlich entsprechend programmiert sein.
Klingt so als hättest du das noch nicht selber gemacht.

CUDA skaliert automatisch, es sei denn du hast viel Synchronisierung. Dann hat man halt einen geringer Speedup.

Man kann ein Programm aber nicht so entwickeln, dass es genau 240 Cores auslastet und keinen mehr.

[uweskw]

Es geht am Ende um Strategien, keiner von beiden war lange wirklich absolut Über oder Unterlegen, es geht um eine Handvoll FPS.
Alles nur Strategische Entscheidungen, einmal war die eine besser ein anderes Mal die andere

Nur dass NV eindeutig die bessere PR-Abteilung hat.
Wenn NV IRGENDWO nen leichten Vorteil hat, lassen die es so breittreten dass alle meinen ATI wär nur was für Billigheimer.

Saludos
U.S.

[Gast]

Klingt so als hättest du das noch nicht selber gemacht.

CUDA skaliert automatisch, es sei denn du hast viel Synchronisierung. Dann hat man halt einen geringer Speedup.

Man kann ein Programm aber nicht so entwickeln, dass es genau 240 Cores auslastet und keinen mehr.
Dennoch muss man ein Programm so schreiben, das es durch CUDA auf viele Cores aufgeteilt werden kann.

Beispiel:
Angenommen du fängst bei 0 an und zählst bis 1000 hoch durch Addition +1. Also 0,1,2,3,... etc.

Wie soll das CUDA auf 240 Cores aufteilen?

Wenn das alles so einfach wäre mit dem Parallelisieren, warum sind dann soviele Programm bis heute nicht in der Lage 2 oder mehr CPU Cores auszulasten? ;)

[Gast]

Es geht hier um reine Effektphysik. Da muss man doch nicht bis 3 zählen können;)

Bedenklich wird es erst, wenn HW-PhysX mit echter Physiksimulation gleichgesetzt wird, denn das machen immernoch CPUs.

[Coda]

Angenommen du fängst bei 0 an und zählst bis 1000 hoch durch Addition +1. Also 0,1,2,3,... etc.

Wie soll das CUDA auf 240 Cores aufteilen?
Ich weiß was du meinst, aber so schreibt kein Mensch einen Stream-Kernel.

Wenn das alles so einfach wäre mit dem Parallelisieren, warum sind dann soviele Programm bis heute nicht in der Lage 2 oder mehr CPU Cores auszulasten? ;)
Es gibt einen großen Unterschied zwischen Stream-Processing und CPU-Threads.

Stream-Processing ist darauf ausgelegt auf *große* Datenmengen immer wieder die gleiche Operation auszuführen. Z.B. 3D-Grafik oder Kollisionen zu überprüfen. Dafür ist CUDA (und GPGPU generell) ausgelegt, und für nichts anderes.

Das ganze wird dann auf tausende (!) Threads aufgeteilt um die Latenz zu verstecken und auf den ALUs ausgeführt. GT200 kann z.B. bis zu 30720 Threads gleichzeitig "im Flug" haben.

[Gast]

Ich! :D

So ähnlich, man hat (vielleicht) 64 bilineare Texturfilter, die auf der Shaderclock laufen und 64 TAs, die mit der halben Frequenz laufen.

Ist das Sinnvoll?

neliz hat ja mal eingeworfen, dass Fermi eigentlich 128 "TMUs" besitzt, aber die Hälfte abgeschaltet ist. Fand ich ziemlich verrückt. ABER:

Wäre es nicht sinnvoller, wenn Fermi nur 32 bilineare Texturfilter auf Shadertakt hat und 64 TA's auf der halben Frequenz? (spart Transistoren, Bandbreite und kostet fast(?) keine Leistung)

oder:

64 bilineare Texturfilter auf Shadertakt und dafür dann 128 TA's auf halben Takt?

Wenn das zweite zutrifft, würde ein "reparierter" Fermi im Bx Stepping, der in ~6 Monaten kommen soll ja noch wesentlich leistungsfähiger als der jetzige Fermi (nur 448 Shader, 64 TMUs, schlechter Takt).

Übrigens: Fermi = 4x MultiGPU on Die :) = krass

[MadManniMan]

Hört mal kurz auf zu kindern und hört euch meine Frage an:

Es fällt wahnsinnig schwer, der ganzen Diskussion inhaltlich zu folgen, wenn man was den Aufbau eines Grafikchips anbelangt nicht auf dem aller aller neuesten Stand ist. Gibt es irgendwo einen Grundlagenartikel, der die aktuellen Entwicklungen/Probleme erklärt? Oder könnt gar ihr ganz kurz grob anreißen, was hier jetzt wie läuft?

Da wird von speziellen Caches geredet, speziellen Textureinheiten, Rasterizern, gfd4pfrecht8xpy (ich übertreib jetzt, aber kryptisch war es) und weiß der Geier was noch ... ohne Sekundärliteratur kommt man nicht mehr mit :(

Könnte bitte darauf nochmal jemand zurückkommen? :usad:

[tombman]

Könnte bitte darauf nochmal jemand zurückkommen? :usad:
1+

:)

[Knuddelbearli]

Vielleicht noch nicht 2010, aber sobald selbst Mainstreamkarten von Nvidia genug Leistung für sehr viele Effekte und eventuell sogar Spielmechanik haben, sollte sich AMD entschieden haben...


naaj GTX 260 = mainstream und der letzte HW Physix titel brauch ne GTX 260 alleine für die Physikx Berechnung

[mapel110]

http://www.digitimes.com/news/a20100120PD204.html
TSMC has improved yield rates on its 40nm manufacturing process, with the quality now being about the same level as its 65nm node process, according Mark Liu, Senior VP of Operations at Taiwan Semiconductor Manufacturing Company (TSMC).

Dann steht ja Fermi nix mehr im Weg.

[Gast]

Ich weiß was du meinst, aber so schreibt kein Mensch einen Stream-Kernel.


Es gibt einen großen Unterschied zwischen Stream-Processing und CPU-Threads.

Stream-Processing ist darauf ausgelegt auf *große* Datenmengen immer wieder die gleiche Operation auszuführen. Z.B. 3D-Grafik oder Kollisionen zu überprüfen. Dafür ist CUDA (und GPGPU generell) ausgelegt, und für nichts anderes.

Das ganze wird dann auf tausende (!) Threads aufgeteilt um die Latenz zu verstecken und auf den ALUs ausgeführt. GT200 kann z.B. bis zu 30720 Threads gleichzeitig "im Flug" haben.
Dann frage ich mich wieder, warum Firmen wie Autodesk, Trapcode, etc. es nicht schaffen,
ihre Partikelsysteme auf mehrere Threads bzw. Kerne abarbeiten zu lassen?!

- ukl

[Ailuros]

OT: Leo danke fuer die Unterstuetzung.

Gipsel,

Fellix postete drei alternative Diagramme bei B3D:

http://forum.beyond3d.com/showpost.php?p=1382929&postcount=3543

http://users.otenet.gr/~ailuros/jp1a.jpg

http://users.otenet.gr/~ailuros/jp2a.jpg

http://users.otenet.gr/~ailuros/jp3a.jpg

Sind zwar nicht NV's Diagramme aber ich sehe keine Fehler bis jetzt in diesen.
Wie dem auch sei die Dinger helfen mir als Laien etwas besser zu illustrieren was ich meinte. Es hat zwar pro SM insgesamt 32SPs aber es sind eigentlich 2*16. Mir passt nur in den Kopf dass diese Aufteilung eine gewisse Logik hat was die generelle Datenverwaltung betrifft und viel anders kann ich es mir vereinfacht fuer die 4 GPCs auch nicht vorstellen. Noch ein Stueck weiter: je groesser die Anzahl der clusters wird desto groesser erscheint mir der Abstand von cluster 1 zu cluster 16 und hier jetzt auf 4 grosse "Mega-clusters" nochmal aufzuteilen sagt meiner einfachen Logik dass es helfen koennte die Abstaende zu verringern. Es ist ja auch so dass in gewissem Sinn jeglicher SM diesmal um ein bisschen "unabhaengiger" ist als bei GT200. Ein GPC sprich 4 SMs + raster sieht nach einem hoeherem Nivaeu dieser "Unabhaengigkeit" ab. 16 "many-core" kann man das Ding wohl schwer nennen, aber mit entsprechenden Seitenerlaeuterungen klingt mir 4 "many-core" gar nicht mal so daneben.

Eine so einfache wie moegliche Erklaerung fuer jeden Leser hier diesbezueglich wuerde helfen, wenn's Dir nicht zu viel Muehe macht. Irgendwie kann ich mir schwer vorstellen dass bei einem 448SP Fall 2SMs von einem (oder sogar 3) restlichen raster Einheiten bedient werden.

Uebrigens waren die GPUs in den Vorzeige-PC tatsaechlich nicht finale hw. Da dieses aber momentan gar nichts heissen kann (denn der Unterschied koennte zur finalen hw gering sein), moechte ich bitten dass keiner seine Hoffnungen zu hoch anschlaegt bis mehr bekannt wird. Es erklaert auf jeden Fall erstmal warum keine Frequenzen bzw. Stromverbrauch angegeben wurden und es sagt mir persoenlich auch dass finale Leistung auf jeden Fall nicht schlechter sein kann als illustriert. Bitte nuechtern aufnehmen.

[svenw]

Mit GF100 frage ich mich allerdings, ob jetzt plötzlich nicht so viel mehr Leistung zur Verfügung steht, dass GPU-PhysX sich langsam aber sicher ausbreitet. Vielleicht noch nicht 2010, aber sobald selbst Mainstreamkarten von Nvidia genug Leistung für sehr viele Effekte und eventuell sogar Spielmechanik haben, sollte sich AMD entschieden haben...
Glaub ich nicht so recht. PhysX auf der Fermi ist wie ein Ferrari in der 30er Zone. Heute werden fast nur noch Cross-Plattform Titel für den PC angeboten und für PhysX steht auf den heutigen Konsolen praktisch keine Leistung mehr bereit, die sind schon mit den "normalen" Berechnungen bis zum Letzten ausgereizt. Außerdem würden die spieleentwickler sich damit massiven Ärger der ATI-Spieler einhandeln (siehe Batmangate, egal wer da Schuld war). Es würde was bringen, wenn feststeht das die neue XBox eine NV-Graka bekommt, nur dann ist die Frage was man mit den Titeln auf der PS4 macht. Und Gameplayphysik nur auf NV REchnern halte ich für utopisch. Ich vermute das Nvidia sich mit der PhysX Politik selbst ins Knie geschossen hat. Hätten sie die Technik freigegeben oder die Lizenzen billig an ATI vertickt hätten sie von ihrer besseren Integration profitieren können aber so.... Irgendein offener Standart wird sich durchsetzen wobei es schade ist um die gute etablierte PhysX Engine.

Die Dual-Chip Lösung von Nvida sehe ich noch nicht als etwas Vernünftiges an. Nvidia wird kaum mehr Frames/Watt (maximal 10%) schaffen als ATI und somit wird die Leistung der X2 Karten nur durch die Leistungsaufnahme bestimmt. Kommt NV mit einer X2 Karte mit TDP 400W dann schmeißt ATI einfach eine ungedrosselte 5990 hinterher und die Leistung ist pari wobei die ATI dann aufgrund der billigeren Chips wesentlich billiger wäre. Nur wenn NV eine ungedrosselte X2 bringt hätten sie mit der Karte eine Chance.

[Gast]

Es erklaert auf jeden Fall erstmal warum keine Frequenzen bzw. Stromverbrauch angegeben wurden und es sagt mir persoenlich auch dass finale Leistung auf jeden Fall nicht schlechter sein kann als illustriert.
Um der Nüchternheit noch ein bisschen nachzuhelfen: Die Schlussfolgerung ist so nicht korrekt. Ich sag nur "3GHz Phenom" ...

[Gast]

Ich weiß was du meinst, aber so schreibt kein Mensch einen Stream-Kernel.
Und genau da ist der Knackpunkt, man muss den Stream-Kernel erstmal schreiben. Bzw: Eine Aufgabe haben, die man in einen vernünftigen Streamkernel packen kann.

Es gibt einen großen Unterschied zwischen Stream-Processing und CPU-Threads.

Stream-Processing ist darauf ausgelegt auf *große* Datenmengen immer wieder die gleiche Operation auszuführen. Z.B. 3D-Grafik oder Kollisionen zu überprüfen. Dafür ist CUDA (und GPGPU generell) ausgelegt, und für nichts anderes.

Das ganze wird dann auf tausende (!) Threads aufgeteilt um die Latenz zu verstecken und auf den ALUs ausgeführt. GT200 kann z.B. bis zu 30720 Threads gleichzeitig "im Flug" haben.
Natürlich, nur muss man diese 30720 Threads erstmal HABEN. Das ist längst nicht so einfach, auch Badaboom z.B. rennt schnell in ein Bottleneck und skaliert bei den GT200-Chips längst nicht so gut, wie es eigentlich müsste:
http://www.anandtech.com/video/showdoc.aspx?i=3374&p=5

[Exxtreme]

Mit GF100 frage ich mich allerdings, ob jetzt plötzlich nicht so viel mehr Leistung zur Verfügung steht, dass GPU-PhysX sich langsam aber sicher ausbreitet. Vielleicht noch nicht 2010, aber sobald selbst Mainstreamkarten von Nvidia genug Leistung für sehr viele Effekte und eventuell sogar Spielmechanik haben, sollte sich AMD entschieden haben...
PhysX hat IMHO nur dann eine Chance wenn AMD mitzieht. Tun sie das nicht dann wird wieder für den kleinsten gemeinsamen Nenner entwickelt. Und das sind Systeme ohne PhysX.

[Ailuros]

Um der Nüchternheit noch ein bisschen nachzuhelfen: Die Schlussfolgerung ist so nicht korrekt. Ich sag nur "3GHz Phenom" ...

Beim Umschwung zu einer neuen Architektur hat das Treiberteam eines Grafik-IHV's alle Haende voll. Die Treiber-updates stocken ja ziemlich schoen in letzter Zeit und es wuerde mich nicht wundern wenn GF100 zuerst seinen eigenen Treiber bekommt bis er wieder spaeter vom unifizierten Treiber-paket aufgenommen wird. Muss natuerlich nicht so sein. In solchen Faellen ist die hoechste Prioritaet Stabilitaet und eine so gut wie moegliche Minimalisierung der jeweiligen bugs. Dann koemmen erst mit der Zeit die jeweiligen Leistungsteigerungen.

So wie es jedoch aussieht zeigte NV weder finale hw noch finale Launch-Treiber vor. Vom Januar bis zum projezierten Maerz fuer den Launch gibt es noch einige Zeit bei den Treibern noch mehr bugs zu entfernen. Frequenz ist zwar ein Faktor, aber bei Variante X machen +/-50MHz (egal welches domain) keinen besonderen Unterschied mehr.

[Gast]

PhysX hat IMHO nur dann eine Chance wenn AMD mitzieht. Tun sie das nicht dann wird wieder für den kleinsten gemeinsamen Nenner entwickelt. Und das sind Systeme ohne PhysX.

Physx gibt's auf CPUs und allen wichtigeren Konsolen. Physx-Support an sich ist also eigentlich fast ein No-Brainer. Was Nvidias Devtech nur noch hinbekommen muss, ist die GPU-Nutzung. Auf einen IMO durchaus möglichen Automatismus werden sie IMO aber nicht setzen, das erhöht ja die GPU-Last und könnte Benchmark-Nachteile (*owehoweh*) bringen, wenn man grafiklimitierte Settings benutzt.

-carsten

[Gast]

PhysX hat IMHO nur dann eine Chance wenn AMD mitzieht. Tun sie das nicht dann wird wieder für den kleinsten gemeinsamen Nenner entwickelt. Und das sind Systeme ohne PhysX.

Falsch, es sind Systeme mit CPUs.
Deswegen sollten weitere solcher PhysX-Diskussionen doch bitte unterlassen werden, wenn man nicht versteht, was PhysX ist.

[Gast]

Physx gibt's auf CPUs und allen wichtigeren Konsolen.

-carsten

Genau, bloß zu welchem Preis?
http://www.xbitlabs.com/news/multimedia/display/20100119134616_AMD_Accuses_Nvidia_of_Disabling_Multi_Core_CPU_Support_in_PhysX_A PI.html

[Gast]

Genau, bloß zu welchem Preis?
http://www.xbitlabs.com/news/multimedia/display/20100119134616_AMD_Accuses_Nvidia_of_Disabling_Multi_Core_CPU_Support_in_PhysX_A PI.html

Frag mal die PR Abteilung von nVidia, was die über Multi-Core-Unterstützung von PhysX zu sagen haben.

[Schlammsau]

Wenn ich mir die Grafik auf der Main (http://www.3dcenter.org/) ansehe, muss ich meine Aussage zum Preis zurückziehen. 500-600€ triffts da wohl eher.

Aber um mich mal wieder selbst zu loben....ich hab vor Monaten schon gesagt, dass Fermi zwischen 5870 und 5970 sein wird, sogar näher an der 5970 und keiner wollte mir glauben. :)

Ich bin soooo gut. :)

[Ailuros]

Wenn ich mir die Grafik auf der Main (http://www.3dcenter.org/) ansehe, muss ich meine Aussage zum Preis zurückziehen. 500-600€ triffts da wohl eher.

Aber um mich mal wieder selbst zu loben....ich hab vor Monaten schon gesagt, dass Fermi zwischen 5870 und 5970 sein wird, sogar näher an der 5970 und keiner wollte mir glauben. :)

Ich bin soooo gut. :)

Wir danken Deiner PR Abteilung, aber Blumenstraeusse gibts keine :freak:

--------------------------------------------------------------------

Spass beiseite auf der Hauptseite folgender Paragraph:

Vermutlich ist damit der GF102-Chip gemeint, welcher allerdings eher dem Performance-Segment zuzuordnen wäre und auf 128 Shader-Einheiten samt 32 TMUs zu schätzen ist.

Wohl eher 256SPs fuer einen halben GF100 (codename ist hier momentan wurscht) und 32 TMUs. Bei theoretischen 128SPs waeren es 16 TMUs.

[Odal]

Also für mich als GPU Architektur Vollnap sieht die Architektur schon fast wie eine Multi-Multi Core CPU aus und irgendwie nach Comeback von GPU Pipelines auf höherer Ebene.
Der Controller für den L2 Cache scheint recht aufwendig zu sein ist das dann überhaupt noch durchgängig performant genug?

Dann frag ich mich was ist der nächste Schritt, ein grosser shared Cache irgendwo beim Crossbar switch anzuklatschen oder macht das gar keinen Sinn?

/GPU nap ende

Als Consumer muss ich sagen hinterlässt die Präsentation einen gespaltenen Eindruck.
Zum einen wirkt alles irgendwo inovativ aber zum anderen kommen schlechte Erinnerungen an den NV30 auf, welcher auch sehr verspätet kam, angeblich sehr innovativ war und wo vieles im Vorfeld gemunkelt wurde
am Ende blieb eine langsame GPU, stromhungrig, heiss und mit diversen Architekturschwächen, welche zwar viel konnte, ab er nur auf dem Papier.

Auf der anderen Seite wurde auch beim G80 vieles Spekuliert und dieser kam dann für viele überraschend anders, und hatte sehr nachhaltige Wirkung.

ATI hat den Vorteil das sie relativ performante und nicht zu komplexe chips schon am Markt haben, für den Consumer dank gutem Preis sicher ausgezeichnet, nur die schlechten Treiber und der fehlende Dev Support hinterlässt einen sehr üblen nachgeschmack

[tombman]

Naja, Zeit vergeht eh schnell- noch schlappe 2 Monate, dann ist Furby da :)

Witzig finde ich, als damals bei meiner Release-Umfrage nur ein oder zwei Voter "noch später als März" tippten, und ich mir dachte "wie krank, das wird sicher nicht eintreffen"- und wie das jetzt durchaus zutreffen kann :ugly:

[Palpatin]

nur die schlechten Treiber und der fehlende Dev Support hinterlässt einen sehr üblen nachgeschmack
Was ist schlecht an den Treibern der 5xxx Serie? Mir ist bisher nix aufgefallen?

[deekey777]

Und genau da ist der Knackpunkt, man muss den Stream-Kernel erstmal schreiben. Bzw: Eine Aufgabe haben, die man in einen vernünftigen Streamkernel packen kann.


Natürlich, nur muss man diese 30720 Threads erstmal HABEN. Das ist längst nicht so einfach, auch Badaboom z.B. rennt schnell in ein Bottleneck und skaliert bei den GT200-Chips längst nicht so gut, wie es eigentlich müsste:
http://www.anandtech.com/video/showdoc.aspx?i=3374&p=5
Gut, dass du Badaboom ansprichst: Auf eine Anfrage der c't für ihren Videokodierer-Artikel hat Nvidia geantwortet, dass Badaboom effektiv nur 64 SPs auslastet, der Geschwindigkeitvorteil der GTX280 beruht auf der deutlich höheren Bandbreite. Diese Aussage ist nicht einmal ein Jahr alt.
Das heißt nicht, dass zu kleine Grids erstellt sind (hallo? ein 1080p-Bild hat wieviele Pixel? Und nicht jeder Thread ist ein voller Pixel, sondern zB ein Viertel), sondern weil Videokodierung mit steigender Kompexität sich nicht so einfach "threaden" lässt.

[Gast]

Gut, dass du Badaboom ansprichst: Auf eine Anfrage der c't für ihren Videokodierer-Artikel hat Nvidia geantwortet, dass Badaboom effektiv nur 64 SPs auslastet, der Geschwindigkeitvorteil der GTX280 beruht auf der deutlich höheren Bandbreite. Diese Aussage ist nicht einmal ein Jahr alt.
Das heißt nicht, dass zu kleine Grids erstellt sind (hallo? ein 1080p-Bild hat wieviele Pixel? Und nicht jeder Thread ist ein voller Pixel, sondern zB ein Viertel), sondern weil Videokodierung mit steigender Kompexität sich nicht so einfach "threaden" lässt.
Genau und dasselbe könnte ich mir durchaus auch für PhysX vorstellen. Und es deckt sich auch mit der Aussage, dass erst PhysX 3.0 wirklich merh Geschwindigkeit bringen wird.

[Gaestle]

Ich würde an dieser Stelle eher auf CODA vertrauen.

Einen Geschwindigkeitsvorteil einer Anwendung kann man auch durch Code-Optimierung erreichen, die aber manchmal so tiefgreifend ist, dass eine neue Versionsnummer gerechtfertigt ist. Oder man baut bestimmte Zusatzfunktionen ein, die von Chips bis einschließlich GT200b nicht genutzt werden können, in Fermi aber implementiert sind. Oder man strukturiert den Workload in der Software so um, dass er der Konstruktion von Fermi stärker entgegen kommt. Das Versprechen "mit Fermi und PhysX(?) 3.0 wird alles schneller" kann viele Ursachen haben, es kann auch schlicht gelogen sein und der Speedup entsteht nur durch die stärkeren Hardware und hat gar nix mit der Software zu tun.

Wieso eigentlich PhysX 3.0? Meinst Du CUDA 3.0? PhysX war doch schon bei 6.irgendwas, als es von NV gekauft wurde. Oder haben die das umbenannt?

[Botcruscher]

Naja, Zeit vergeht eh schnell- noch schlappe 2 Monate, dann ist Furby da :)

Stellt sich nur die Frage welche Version. :tongue: Immerhin ist dann auch die ATI Refreshgeneration nicht mehr weit. Der zu erwartende Preiskampf Mitte des Jahres ist auf jeden Fall gut für die Kundschaft. Fehlt eigentlich nur noch das NV mal aufwacht und Intel mit einem freien PhysX eins rein wirkt. Mit ihrem Exklusiv-Konzept stehen sie sich im Moment echt selbst im Weg.

[deekey777]

Nvidia sagt, dass der GF100 mit PhysX (3.0) wegen der concurrent kernels schneller wird. Der Sinn davon ist, mehrere Kernels parallel auszuführen, wenn die Hardware nicht ausgelastet wird. Bisher kann die Grafikkarte entweder oder rechnen. Durch dieses "Hin-und-her" entsehen Latenzen. Und mit Concurrent Kernels wird dies gemindert, wenn Platz frei wird.
Das gilt nicht nur für PhysX.

[Gast]

Genau und dasselbe könnte ich mir durchaus auch für PhysX vorstellen. Und es deckt sich auch mit der Aussage, dass erst PhysX 3.0 wirklich merh Geschwindigkeit bringen wird.

Das liegt aber an der damit möglichen gemeinsamen Ausführung unterschiedlicher Physx-Kernel auf der GPU. Bei Badaboom (und anderen Videokonvertern) sollte ja eigentlich derselbe Kernel x-fach laufen.

-carsten

[Dural]

PhysX hat IMHO nur dann eine Chance wenn AMD mitzieht. Tun sie das nicht dann wird wieder für den kleinsten gemeinsamen Nenner entwickelt. Und das sind Systeme ohne PhysX.

jedes system kann PhysX

und wenn es NV schafft GPUs für die neuen Konsolen Generation zu liefern (technisch gesehe stehen sie da eigentlich richtig gut da, das gesamt paket stimmt) dürfte PhysX in Hardware so ziemlich sicher etablieren!

[MR2]

das passt doch dazu:-)
http://www.hartware.de/news_48294.html

Nvidia: PhysX bremst CPUs aus?
"Physik-Schnittstelle nicht für Mehrkern-CPUs optimiert"

"Huddy bemängelt: "Nvidia vermarktet PhysX als wäre es Gottes Antwort auf alle Probleme mit Physikberechnungen. In Wahrheit ist es eine Antwort, die erst auf der Suche nach Problemen entstand"."

:-)

[Gast]

und wenn es NV schafft GPUs für die neuen Konsolen Generation zu liefern (technisch gesehe stehen sie da eigentlich richtig gut da, das gesamt paket stimmt)
absolut! die sponsorverträge zwischen e.on und sony / microsoft stehen auch schon :D

[Botcruscher]

jedes system kann PhysX

Aber darf es, sogar aktiv unterstützt, nicht.


und wenn es NV schafft GPUs für die neuen Konsolen Generation zu liefern (technisch gesehe stehen sie da eigentlich richtig gut da, das gesamt paket stimmt) dürfte PhysX in Hardware so ziemlich sicher etablieren!


Dann fehlt immer noch der überwältigende Rest des Marktes. Ohne breite Unterstützung wird es bei ein paar gesponserten Exklusivtiteln bleiben. Bei Multiplattform ist an mehr gar nicht zu denken. Kein Spielehersteller kann es sich leisten mehr als etwas Eyecandy zu verbauen.

[Gast]

Kann bitte jemand die PhysX Diskussion splitten? Es fängt schon wieder von den selben Leuten an, die nicht verstehen, was PhysX ist.

[mrt]

ATI hat den Vorteil das sie relativ performante und nicht zu komplexe chips schon am Markt haben, für den Consumer dank gutem Preis sicher ausgezeichnet, nur die schlechten Treiber und der fehlende Dev Support hinterlässt einen sehr üblen nachgeschmack
Hat zwar nichts mit dem Thema zu tun, aber ich kanns schön langsam nicht mehr lesen. Sowohl die Treiber als auch die Entwicklerunterstützung sind auf Augenhöhe, nur weil einer der Beiden es vermarktet und der anderer nicht, ist es bei letzterem schlecht in den Augen eines Laien. Wenn man keine Ahnung hat einfach mal die...
Zur PhysX-Diskussion auf den letzten Seiten, breite Plattformunterstützung haben alle drei weit verbreiteten Engines (PhsyX, Havok und Bullet), alle haben spezifische Vorteile und Nachteile, aber ohne Nvidias starkes Engagement sehe es wohl nicht so gut für PhysX aus, dessen Zukunft relativ ungewiss ist. Eine Öffnung bringt wohl nicht mehr viel, solange Nvidia das ganze Framework unter der GPL lizensiert.
(Gilt sowohl für PhysX und GPU-PhysX)

[Exxtreme]

jedes system kann PhysX

und wenn es NV schafft GPUs für die neuen Konsolen Generation zu liefern (technisch gesehe stehen sie da eigentlich richtig gut da, das gesamt paket stimmt) dürfte PhysX in Hardware so ziemlich sicher etablieren!
Der Punkt ist, wenn die Spielehersteller davon ausgehen müssen, daß ein beträchtlicher Teil der Spieler PhysX auf der CPU ausführen muss dann werden sie die Vorteile davon nicht ausnutzen können bzw. für Nvidia eine Extrawurst braten müssen damit man das auch im Spiel sieht.

[Botcruscher]

die nicht verstehen, was PhysX ist.

In Software interessiert das ganze aber kein Schwein und künstlich, auf maximal 2 Cores, beschnitten ist es auch noch. Ohne Exklusivunterstüzung macht sich da kein Entwickler die Hände schmutzig. Die ganze Diskussion endet an dem Punkt Eyecandy, da mehr Plattformübergreifend nicht möglich ist. Ob es (in Software) sonst überall läuft ist völlig egal.

[Gast]

In Software interessiert das ganze aber kein Schwein und künstlich, auf maximal 2 Cores, beschnitten ist es auch noch. Ohne Exklusivunterstüzung macht sich da kein Entwickler die Hände schmutzig. Die ganze Diskussion endet an dem Punkt Eyecandy, da mehr Plattformübergreifend nicht möglich ist. Ob es (in Software) sonst überall läuft ist völlig egal.

PhysX ist eine Physik-Engine bzw API, die auf dem PC die #1 Engine darstellt. Sie läuft über zig CPU-Arten, ist Multi-Core fähig und wird von zig Spieleentwickler verwendet. Das PhysX auch über CUDA laufen kann, ist ein Feature des Paketes.
Solltest du es wirklich nicht verstehen, was PhysX ist, dann bitte ich einfach darum, dass du dich informierst oder deine falsche Meinung nicht mehr in diesem Forum kundtust.

Und nun wieder zurück zu GF100. Wir können gerne über die Verbesserungen von GF100 und Physik-Berechnungen reden. Aber wir müssen nicht dieses elendige Thema 100x wiederholen, weil gewisse Leute einfach im denial Modus verfallen.

[Dural]

was jammert ihr immer wegen nur einem/zwei Threads bei CPUs rum??? keine aktuelle CPU ist in der lage einem GT200 oder Fermi in irgend einer weisse das wasser zureichen, keine! siehe Vantage ergebnise wo bei Hardware PhysX sogar die CPU limitiert und nicht die GPU!!! Wie und wieso das Hardware PhysX limitiert weis ich nicht, aber es gibt ein Limit, wäre intressant das mal aus zu testen!

Zudem, ist wohl bis heute ein zwei Core CPU ganz klar standard, also für die meisten User würden davon null pofitieren... genau deswegen gibt es wohl auch diese beschränkung, als PhysX kamm gab es ja nur vereinzelt zwei Core CPUs... und ich glaube kaum das NV hier noch gross inverstieren wird, für was auch...

Die Entwickler würden mal lieber die CPUs mit einer vernünftigen KI auslasten!!!!

[Gipsel]

Gipsel,

Fellix postete drei alternative Diagramme bei B3D:

http://forum.beyond3d.com/showpost.php?p=1382929&postcount=3543



Sind zwar nicht NV's Diagramme aber ich sehe keine Fehler bis jetzt in diesen.
Wie dem auch sei die Dinger helfen mir als Laien etwas besser zu illustrieren was ich meinte. Es hat zwar pro SM insgesamt 32SPs aber es sind eigentlich 2*16. Mir passt nur in den Kopf dass diese Aufteilung eine gewisse Logik hat was die generelle Datenverwaltung betrifftDas ist im Prinzip nur dazu da, Instruktionen von 2 verschiedenen Warps gleichzeitig im SM abarbeiten zu können, was hilft a) die Instruktionslatenzen besser zu verstecken (effektive Latenzen werden halbiert) und b) es ermöglicht an der Anzahl der L/S-Einheiten und der SFUs zu sparen, da die nicht ganz so häufig von beiden Warps gleichzeitig genutzt werden.

und viel anders kann ich es mir vereinfacht fuer die 4 GPCs auch nicht vorstellen. Noch ein Stueck weiter: je groesser die Anzahl der clusters wird desto groesser erscheint mir der Abstand von cluster 1 zu cluster 16 und hier jetzt auf 4 grosse "Mega-clusters" nochmal aufzuteilen sagt meiner einfachen Logik dass es helfen koennte die Abstaende zu verringern. Es ist ja auch so dass in gewissem Sinn jeglicher SM diesmal um ein bisschen "unabhaengiger" ist als bei GT200. Ein GPC sprich 4 SMs + raster sieht nach einem hoeherem Nivaeu dieser "Unabhaengigkeit" ab. 16 "many-core" kann man das Ding wohl schwer nennen, aber mit entsprechenden Seitenerlaeuterungen klingt mir 4 "many-core" gar nicht mal so daneben. Eine so einfache wie moegliche Erklaerung fuer jeden Leser hier diesbezueglich wuerde helfen, wenn's Dir nicht zu viel Muehe macht.Wenn man davon ausgeht, daß nv Rasterengines und SMs unabhängig voneinander deaktivieren kann (wofür die Existenz von 448 SP Modellen spricht), dann sind die GPCs auch nicht wirklich existent. Nimm Dir das erste Schaubild und ziehe mal die 4 Rasterengines nach oben aus den GPCs heraus. Dann packe untendrunter eine zusätzliche "Crossbar" dazwischen, die die SMs füttert, und dann gibt es mit einem mal keine GPCs mehr. Nvidia gewinnt aber die Flexibilität, jeden SM oder Raster-Engine einzeln auszuknipsen (z.B. auch nur 2 Rasterengines mit vollen 512 SPs für Tesla-Karten denkbar). Den Begriff "Crossbar" sollte man hier vielleicht nicht zu ernst nehmen. Im Prinzip reicht da eine Queue mit 4 Writeports oben und unten bedienen sich die SMs daraus.

Irgendwie kann ich mir schwer vorstellen dass bei einem 448SP Fall 2SMs von einem (oder sogar 3) restlichen raster Einheiten bedient werden.Wenn Du 2 GPCs mit 4 SMs hast und 2 GPCs mit nur 3 SMs, mußt Du auch Loadbalancing zwischen den GPCs betreiben. Sonst wird der eine oder andere GPC öfter mal Däumchen drehen, wenn das nicht passiert.
Die "Gigathread-Engine" ist ja der Marketing-Begriff für die globale Taskverwaltung, die genau dieses erledigen sollte. Das als einen monolithischen Block ganz oben darzustellen, trifft es nicht wirklich. Irgendwie müssen ja die ganzen DirectX-Pipelinestufen verwaltet und der korrekte Ablauf sichergestellt werden. Da muß es also nach jeder Stufe eine Rückmeldung geben, sowie auch noch die Möglichkeit, die nächste Stufe z.B. auf einem anderen SM/GPC auszuführen (z.B. weil der erste noch beschäftigt ist). Insofern sollte man sich die SMs eher in die Gigathread-Engine eingebettet vorstellen ;)

Wenn das auf einem anderen SM ausgeführt werden soll, müssen die entsprechenden Daten sowieso über den L2 (oder Speicher wenn zu groß) transferiert werden. Da besteht kein Unterschied, ob das nun ein SM im gleichen GPC ist, oder nicht. Also auch hier ist die Aufteilung in GPCs nicht stichhaltig.

[deekey777]

Gibt es eigentlich irgendeine Kommunikation zwischen den einzelnen Rasterengines?

[Gipsel]

Gibt es eigentlich irgendeine Kommunikation zwischen den einzelnen Rasterengines?
Ja, die muß es eigentlich geben, um die Korrektheit des Ergebnisses zu sichern. Man kann nicht einfach die Geometrie in 4 gleiche Teile teilen und die dann völlig unabhängig voneinander rastern lassen, da würde bei so einem naiven Ansatz des Öfteren Müll bei rauskommen. Das macht die Parallelisierung etwas schwieriger und ist auch der Grund, warum man sich da lange nicht rangetraut hat.

[Botcruscher]

Solltest du es wirklich nicht verstehen, was PhysX ist, dann bitte ich einfach darum, dass du dich informierst oder deine falsche Meinung nicht mehr in diesem Forum kundtust.


Niemand spricht von der Engine ohne Hardwareunterstützung außer dir und wirfst du uns noch Unwissenheit vor.:freak: Fermi könnte hundert mal schneller sein, deswegen wirst du auf den Konsolen und sonstigen Geräten trotzdem nicht mehr sehen.

EDIT: Und genau deswegen wirst du bei den meisten Spielen auch mit einer NV Karte nichts sehen. Der Geforcebesitzer leidet am Ende genau so wie die anderen Kunden unter der festgefahrenen Situation. Schlußendlich wäre für die Kunden, die Entwickler und für NV wesentlich mehr drin.


Zudem, ist wohl bis heute ein zwei Core CPU ganz klar standard, also für die meisten User würden davon null pofitieren... genau deswegen gibt es wohl auch diese beschränkung, als PhysX kamm gab es ja nur vereinzelt zwei Core CPUs...
und ich glaube kaum das NV hier noch gross inverstieren wird, für was auch...

Die Beschränkungen gibt es also weil es keine CPUs mit mehr Kernen gibt... Junge, das ist schon hart. Und warum NV hier nicht "investieren" wird ist ja auch klar. Und ja, keine CPU hätte die pure Rohleistung der Grafikkarte. Leider können die meisten Programme die eh nicht nutzen und dann sieht es für die CPU wieder ganz gut aus. Das die Hardwareunterstützung zum PR-Instrument verkommt wäre nicht so schlimm wenn der Rest nicht auch schlafen würde.

PS: Wenn Intel nicht krampfhaft an X86 hängen würden hätten die eh schon alles platt gemacht. NV profitiert hier noch von den Fehlern der anderen. Die Situation könnte sich auch ganz schnell ändern.

[Exxtreme]

was jammert ihr immer wegen nur einem/zwei Threads bei CPUs rum??? keine aktuelle CPU ist in der lage einem GT200 oder Fermi in irgend einer weisse das wasser zureichen, keine! siehe Vantage ergebnise wo bei Hardware PhysX sogar die CPU limitiert und nicht die GPU!!!
Aber das ist genau die Krux an der Geschichte. Die Spiele werden meistens für den kleinsten gemeinsamen Nenner was die Hardwarebasis angeht entwickelt. Und der kleinste gemeinsame Nenner heisst in diesem Fall "PhysX auf CPU". Also wird der Content so entwickelt, daß ihn auch eine CPU ohne Probleme berechnen kann. Und somit kannst du dir PhysX gleich sparen wenn es nicht woanders große Vorteile bringt.

Aus dem Grund hatten irgendwelche Alleingänge der Grafikchiphersteller niemals Erfolg gehabt. ATis Truform ist genauso gescheitert wie irgendwelche speziellen Pixelshader-Versionen zu DirectX8/9-Zeiten. Da wurde immer die kleinste gemeinsame Basis genommen. ausnahmen sind dann meistens wenn der Grafichiphersteller Kohle rüberschiebt.

Und deshalb ist es IMHO so, daß wenn AMD PhysX nicht adaptiert dann braucht an es schlicht nicht da man keine Vorteile draus ziehen kann. Und warum AMD PhysX adaptieren sollte das erschliesst sich mir nicht. Man schwächt dadurch den Hauptkonkurrenten indem man seine Technologie obsolet macht.

[Ailuros]

Das ist im Prinzip nur dazu da, Instruktionen von 2 verschiedenen Warps gleichzeitig im SM abarbeiten zu können, was hilft a) die Instruktionslatenzen besser zu verstecken (effektive Latenzen werden halbiert) und b) es ermöglicht an der Anzahl der L/S-Einheiten und der SFUs zu sparen, da die nicht ganz so häufig von beiden Warps gleichzeitig genutzt werden.

Schoen. Angenommen sie wollen jetzt fuer Fall X 16 der SPs pro SM deaktivieren, wird es dann 1*16 oder 2*8?

Wenn man davon ausgeht, daß nv Rasterengines und SMs unabhängig voneinander deaktivieren kann (wofür die Existenz von 448 SP Modellen spricht), dann sind die GPCs auch nicht wirklich existent. Nimm Dir das erste Schaubild und ziehe mal die 4 Rasterengines nach oben aus den GPCs heraus. Dann packe untendrunter eine zusätzliche "Crossbar" dazwischen, die die SMs füttert, und dann gibt es mit einem mal keine GPCs mehr. Nvidia gewinnt aber die Flexibilität, jeden SM oder Raster-Engine einzeln auszuknipsen (z.B. auch nur 2 Rasterengines mit vollen 512 SPs für Tesla-Karten denkbar). Den Begriff "Crossbar" sollte man hier vielleicht nicht zu ernst nehmen. Im Prinzip reicht da eine Queue mit 4 Writeports oben und unten bedienen sich die SMs daraus.

So weit so gut :)

Wenn Du 2 GPCs mit 4 SMs hast und 2 GPCs mit nur 3 SMs, mußt Du auch Loadbalancing zwischen den GPCs betreiben. Sonst wird der eine oder andere GPC öfter mal Däumchen drehen, wenn das nicht passiert.
Die "Gigathread-Engine" ist ja der Marketing-Begriff für die globale Taskverwaltung, die genau dieses erledigen sollte. Das als einen monolithischen Block ganz oben darzustellen, trifft es nicht wirklich. Irgendwie müssen ja die ganzen DirectX-Pipelinestufen verwaltet und der korrekte Ablauf sichergestellt werden. Da muß es also nach jeder Stufe eine Rückmeldung geben, sowie auch noch die Möglichkeit, die nächste Stufe z.B. auf einem anderen SM/GPC auszuführen (z.B. weil der erste noch beschäftigt ist). Insofern sollte man sich die SMs eher in die Gigathread-Engine eingebettet vorstellen ;)

Das loadbalancing ist ja gerade das was mich zum Bedenken fuehrt, ueberhaupt wenn jeglicher raster dem (projeziertem) Arbeitsvolumen von 4 SMs angepasst ist.

Eigentlich haette ich erwartet dass Deaktivierungen bzw. Skalierung nach unten fuer kleinere chips flexibler sein koennte als bis jetzt, aber so wie ich es gerade herauslese scheint es nicht der Fall zu sein (ausser man geht streng auf 1/2, 1/4).

Nebenbei wurde ich gerade versichert dass sie nur fuer operative chips pro wafer bezahlen (Vorraussetzung es handelt sich um prozess-bedingte Fehler).

[IVN]

Wieviel kostet einen ISV die PhysX-Lizenz für ein Spiel?

[deekey777]

Wieviel kostet einen ISV die PhysX-Lizenz für ein Spiel?
Das SDK ist kostenlos, selbst für kommerzielle Projekte. Der Source-Code soll $50.000 kosten.

[Gast]

Nebenbei wurde ich gerade versichert dass sie nur fuer operative chips pro wafer bezahlen (Vorraussetzung es handelt sich um prozess-bedingte Fehler).

Alles andere macht auch keinen Sinn.
Wenn ich bei einen Online-Fotobilder-Shop 100 Bilder bestelle und die mir nur 30 liefern, dann können die wohl nicht verlangen, dass ich für 100 Bilder bezahle. Deswegen ist auch sehr unsinnig anzunehmen, dass AMD höhrere Yieldraten haben würde als nVidia. Dem bösen Fehler ist es nämlich egal, ob zwei Chips 3 Millionen Transistoren haben oder nur einer.

[V2.0]

Eigentlich haette ich erwartet dass Deaktivierungen bzw. Skalierung nach unten fuer kleinere chips flexibler sein koennte als bis jetzt, aber so wie ich es gerade herauslese scheint es nicht der Fall zu sein (ausser man geht streng auf 1/2, 1/4).

Nebenbei wurde ich gerade versichert dass sie nur fuer operative chips pro wafer bezahlen (Vorraussetzung es handelt sich um prozess-bedingte Fehler).

Mehr Stufen als 1/25, 1/4 und 1/8 machen aber auch wenig Sinn.

Beim zweiten wird Charlie aber ausflippen, wenn Du das sagst. ;D

[Gast]

Das liegt aber an der damit möglichen gemeinsamen Ausführung unterschiedlicher Physx-Kernel auf der GPU. Bei Badaboom (und anderen Videokonvertern) sollte ja eigentlich derselbe Kernel x-fach laufen.
Sollte. Wie man sieht ist in der Praxis aber längst nicht so einfach, auf 240 oder mehr Cores zu skalieren.

Auch das Problem, was speziell ATI bei ihren Karten schon im 3D hat. Man vergleiche mal Furmark (100% Auslastung) vs. Games. Meist liegt bei ATI 1/3 der Rechenleistung oder sogar noch mehr defakto brach.

PhysX ist eine Physik-Engine bzw API, die auf dem PC die #1 Engine darstellt.
Nicht nur auf dem PC, PhysX ist die #1 Physik-Engine. Merkt man nur nicht oft, weil sie natürlich auch CPU-only genutzt werden kann und das wird sie recht oft.

[Gast]

Nebenbei wurde ich gerade versichert dass sie nur fuer operative chips pro wafer bezahlen (Vorraussetzung es handelt sich um prozess-bedingte Fehler).
Hatte ich ja so schon gesagt ;) Damit erübrigt sich jede bisher erfolgte Rechnung der Chippreise über die Yieldrate, die bisher erfolgt waren.

Anders gesagt: Nvidia verdient trotz der großen Chips deutlich früher Geld, als bisher publiziert wurde. Einziges Problem ist höchstens die Quantität.

Aber das war im Grunde vorher doch schon klar. Die Nvidia-Finanzzahlen waren DEUTLICH besser als die von ATI.

[Gipsel]

Schoen. Angenommen sie wollen jetzt fuer Fall X 16 der SPs pro SM deaktivieren, wird es dann 1*16 oder 2*8?
Das wird nicht passieren. Selbst für den allerkleinsten integrierten Chipsatz irgendwo halte ich das für unwahrscheinlich. Da wird man immer mit ganzen SMs arbeiten. Schau Dir doch mal die Gurken mit 16SPs heutzutage an! Eine Mindestmenge von 32SPs halte ich zukünftig schon für angemessen. Aber falls nv das unbedingt will, würde ich eigentlich eher auf 1 x 16 tippen, da ansonsten die Scheduler doch deutlicher umgestellt werden müßten.
Aber bei größeren GPUs spielt das sowieso keine Rolle.

Das loadbalancing ist ja gerade das was mich zum Bedenken fuehrt, ueberhaupt wenn jeglicher raster dem (projeziertem) Arbeitsvolumen von 4 SMs angepasst ist.Ist es das? Und wenn ja wie? Kann man da auch nicht zu einem anderen Ergebnis bei der Abwägung kommen? 20% oder auch 30% weniger oder mehr Shader-Leistung für die gleichen Rastereinheiten wird das Gleichgewicht des Chips schon nicht umwerfen. Oder vergleiche mal den Verlauf von Cedar zu Cypress ;)
Eigentlich haette ich erwartet dass Deaktivierungen bzw. Skalierung nach unten fuer kleinere chips flexibler sein koennte als bis jetzt, aber so wie ich es gerade herauslese scheint es nicht der Fall zu sein (ausser man geht streng auf 1/2, 1/4).Wieso? Momentan sieht es doch so aus, als wenn nvidia einzelne SMs ausknipsen könnte (siehe 448SP-Versionen). Die ROP-Partionen mit dranhängendem Speichercontroller sind ja unabhängig davon, eventuell auch die Raster-Einheiten (wobei es für GF100 aus meiner Sicht keinen wirklichen Sinn macht, eine Raster-Einheit zu deaktivieren, dann hätte man 24px/Takt maximale Rasterleistung, aber 48 ROPs). Wieviel flexibler soll es denn werden?
Nebenbei wurde ich gerade versichert dass sie nur fuer operative chips pro wafer bezahlen (Vorraussetzung es handelt sich um prozess-bedingte Fehler).Ich dachte eigentlich, das wären meist mehr oder weniger Mischverträge, wo sich beide Parteien das Risiko teilen. Zumindest wenn ein erhebliches Risiko besteht (d.h. 5mm² Chips werden wohl rein pro Wafer bezahlt). Sprich, man bezahlt entweder viel pro funktionierendem Die bzw. wenig pro Wafer (egal was drauf ist) mit einem fließenden Übergang dazwischen. Aber wie der Übergang genau aussieht, ist dann Verhandlungssache, wo man mit entsprechendem Gewicht als Kunde wahrscheinlich etwas besser bei wegkommt ;)

[Ailuros]

Mehr Stufen als 1/2, 1/4 und 1/8 machen aber auch wenig Sinn.

448 bzw. 384SPs passen aber nicht oben rein ;)

Beim zweiten wird Charlie aber ausflippen, wenn Du das sagst. ;D

Ich hab keinen Bock zu einer direkten Konfrontation mit jemand zu kommen der um sein Einkommen kaempft.

[Nightspider]

Ich erinnere mich noch wie sogar ein PhysX-Co-Prozessor für die Nintendo Wii spekuliert wurde. :D

Falls die Fermi Architektur in der nächsten Konsolengeneration verbaut wird, und dafür stehen die Chancen recht gut, dann könnte jene Konsole mit PhysX schon einige Vorteile erhaschen.

Es gibt sehr viele Konsolenspiele mit Software-PhysX (Mafia2 wird zum Beispiel auch so eins), welche auf einer Konsole mit Nividia teils ne Ecke schneller laufen könnten, wenn die Programmierer die Last besser verteilen.

Man Darf auch gespannt sein ob die Unreal Engine 4 wieder auf PhysX bzw. eine neue Version derer benutzt (PhysX3.0 ? 4.0 ?) oder ob Epic sich diesmal eine eigene komplette Physik-Bibiliothek zusammenschustert.

Dank DX11 und Compute Shader werden in Zukunft wohl alle "hochwertigen" Physik-Engines von den GPUs berechnet.

(OT: Weiß jemand ob Firmen, welche die UE3 Engine lizensieren automatisch PhysX mit drin haben oder ob die da nochmal extra zahlen dürfen? Ich glaube PhysX bzw. die Novodex-Physik-Engine ist drin. [Ist ja das gleiche oder?])

[Gib "Hallo" ein!]

Nebenbei wurde ich gerade versichert dass sie nur fuer operative chips pro wafer bezahlen (Vorraussetzung es handelt sich um prozess-bedingte Fehler).
Wenn dem so ist: warum sollte TSMC Nvidia solche angenehmen Bedingungen einräumen, wenn sie ATI nicht ebenfalls erhält? Außer natürlich, sie wissen eh schon sicher, daß ATI komplett zu GloFo gehen wird, und wollen bis dahin noch etwas melken?

Oder andersrum: warum sollte TSMC sich für NVidia anstrengen, wenn bei ATI (angenommen die bezahlen die 5k$ pro Wafer, unabhängig von Defekten) viel mehr zu verdienen ist?

Cherry

[Gast]

Oder andersrum: warum sollte TSMC sich für NVidia anstrengen, wenn bei ATI (angenommen die bezahlen die 5k$ pro Wafer, unabhängig von Defekten) viel mehr zu verdienen ist?
Vielleicht weil Nvidia deutlich mehr Volumen und daher mehr Umsatz macht?

Und wer sagt, dass ATI pro Wafer bezahlt?

[Gast]

Wenn dem so ist: warum sollte TSMC Nvidia solche angenehmen Bedingungen einräumen, wenn sie ATI nicht ebenfalls erhält? Außer natürlich, sie wissen eh schon sicher, daß ATI komplett zu GloFo gehen wird, und wollen bis dahin noch etwas melken?

Oder andersrum: warum sollte TSMC sich für NVidia anstrengen, wenn bei ATI (angenommen die bezahlen die 5k$ pro Wafer, unabhängig von Defekten) viel mehr zu verdienen ist?

Cherry

1. Weil Nvidia in der Vergangenheit der größere Abnehmer war und wahrscheinlich vorerst auch noch bleiben wird

2. Weil AMD/ATI durch Global Foundries mehr oder minder ein Konkurent ist und TSMC sich nicht sicher sein kann, dass zukünftig nicht die ein oder andere Produktreihe wegverlagert wird. Bei Nvidia besteht diese Konkurenzsituation nicht außer, dass Sie mit Vergabe an andere Foundries drohen könnten.

Im übrigen ist diese Klausel bei Nvidia's High End Chips nichts neues. Das gabs auch bei NV30 und ich meine auch G80 schonmal.

[Ailuros]

Das wird nicht passieren. Selbst für den allerkleinsten integrierten Chipsatz irgendwo halte ich das für unwahrscheinlich. Da wird man immer mit ganzen SMs arbeiten. Schau Dir doch mal die Gurken mit 16SPs heutzutage an! Eine Mindestmenge von 32SPs halte ich zukünftig schon für angemessen. Aber falls nv das unbedingt will, würde ich eigentlich eher auf 1 x 16 tippen, da ansonsten die Scheduler doch deutlicher umgestellt werden müßten.
Aber bei größeren GPUs spielt das sowieso keine Rolle.

Ich bin mir sicher dass Du es schon erwaehnt hast, aber wie sieht die moeglichste These aus wenn man DP nicht mehr unterstuetzen will bei kleinen Varianten?

Ist es das? Und wenn ja wie? Kann man da auch nicht zu einem anderen Ergebnis bei der Abwägung kommen? 20% oder auch 30% weniger oder mehr Shader-Leistung für die gleichen Rastereinheiten wird das Gleichgewicht des Chips schon nicht umwerfen. Oder vergleiche mal den Verlauf von Cedar zu Cypress ;)

Ehrliche Fragezeichen mit ehrlichen Gedanken meinerseits ;)

Wieso? Momentan sieht es doch so aus, als wenn nvidia einzelne SMs ausknipsen könnte (siehe 448SP-Versionen). Die ROP-Partionen mit dranhängendem Speichercontroller sind ja unabhängig davon, eventuell auch die Raster-Einheiten (wobei es für GF100 aus meiner Sicht keinen wirklichen Sinn macht, eine Raster-Einheit zu deaktivieren, dann hätte man 24px/Takt maximale Rasterleistung, aber 48 ROPs). Wieviel flexibler soll es denn werden?

Wenn die TMUs diesmal nicht an die SMs gekoppelt waeren, warum nicht 16SPs beispielsweise aus 2 SMs deaktivieren als einen ganzen SM?

Moment jetzt bin ich total verwirrt: schlaegst Du jetzt vor dass sie bei 448 bzw. 384 SPs z.B. den vierten raster eingeschaltet behalten oder deaktivieren?

Es sind doch nebenbei 8 pixel/clock/raster und die uebrigen 16ROPs klingen eher eine "dekorative" Existenz fuer rasterizing zu haben, aber wohl nicht fuer >4x MSAA (deshalb ist die angebliche Behauptung dass andere FB Komprimierung fuer 8xMSAA Leistung wohl eher Humbug als einziger "fix" fuers letztere...)

Wenn ich jetzt als normalsterblicher theoretische 48 pixel/clock sehe dank 48 ROPs, aber dann sehe dass jedem raster nur 4*8=32pixel zustehen, dann stell ich mir auch vor dass jeder raster vielleicht seinem eigentlichem Arbeitsvolumen angepasst sein koennte.

Ich dachte eigentlich, das wären meist mehr oder weniger Mischverträge, wo sich beide Parteien das Risiko teilen. Zumindest wenn ein erhebliches Risiko besteht (d.h. 5mm² Chips werden wohl rein pro Wafer bezahlt). Sprich, man bezahlt entweder viel pro funktionierendem Die bzw. wenig pro Wafer (egal was drauf ist) mit einem fließenden Übergang dazwischen.

Ich hab offensichtlich keinen Einblick in ihre Vertraege. Ein 300mm 40G wafer duerfte wohl um die $5000 kosten. Wenn man jetzt irrsinnig niedrige yields wie im letzten Oktober/November hat und nur eine handvoll oder etwas mehr operativer chips/wafer dann ist wohl kein einziger IHV so bloed und bezahlt $2500 fuer so etwas. Wenn dem so waere haette AMD seit letztem Oktober die Grafiksparte gleich dicht machen koennen.


Und wer sagt, dass ATI pro Wafer bezahlt?

Eben.

[Gast]

Nebenbei wurde ich gerade versichert dass sie nur fuer operative chips pro wafer bezahlen (Vorraussetzung es handelt sich um prozess-bedingte Fehler).

Armer Charlie.

-carsten

[pervert]

Was ist schlecht an den Treibern der 5xxx Serie? Mir ist bisher nix aufgefallen?
Und das soll uns jetzt wundern?
Dir fällt ja nicht einmal auf, dass das hier OFF TOPIC ist!!

Das gilt aber auch für die mal wieder breitgetretene Physx Diskussion...

[Gast]

Und deshalb ist es IMHO so, daß wenn AMD PhysX nicht adaptiert dann braucht an es schlicht nicht da man keine Vorteile draus ziehen kann. Und warum AMD PhysX adaptieren sollte das erschliesst sich mir nicht. Man schwächt dadurch den Hauptkonkurrenten indem man seine Technologie obsolet macht.
So in etwa.

Ich kann diese PhysX(@GPU) Diskussion nicht wirklich nachvollziehen... vor allem sind es immer wieder die gleichen Member die sich da reinsteigern.

Da mit DX11 Compute Shader im Anmarsch sind, womit man theoretisch in der Lage ist die Berechnungen wie in PhysX durchzuführen (oder auch OpenCL), wird Physx@GPU wohl mittelfristig Geschichte sein.

Oder warum sollte ein Entwickler mit PhysX@GPU einen großen Teil der Spieler ausschließen, wenn er mit OpenCL oder CS@DX11 einen viel größeren Teil des Marktes abdecken kann?
Das wäre totall unlogisch und unwirtschaftlich.

Also erspart uns doch bitte wenigstens in diesem Thread die PhysX@GPU Diskussion. :)

[Gast]

Oder warum sollte ein Entwickler mit PhysX@GPU einen großen Teil der Spieler ausschließen, wenn er mit OpenCL oder CS@DX11 einen viel größeren Teil des Marktes abdecken kann?
Das wäre totall unlogisch und unwirtschaftlich.

Weil sie mit PhysX eine fertige Engine bekommen die sie über OpenCL/DirectCompute erst selbst programmieren müssten und damit jede Menge Geld sparen.

[Gast]

Das loadbalancing ist ja gerade das was mich zum Bedenken fuehrt, ueberhaupt wenn jeglicher raster dem (projeziertem) Arbeitsvolumen von 4 SMs angepasst ist.

Das sollte kein Problem sein, im zweifelsfall ist eben die Raster-unit des GPC mit dem deaktivierten SM etwas unterbeschäftigt.

[Coda]

Könnte bitte darauf nochmal jemand zurückkommen? :usad:
Was willst du denn genau wissen?

[Gast]

Oder warum sollte ein Entwickler mit PhysX@GPU einen großen Teil der Spieler ausschließen, wenn er mit OpenCL oder CS@DX11 einen viel größeren Teil des Marktes abdecken kann?
Aus dem gleichen Grund, aus dem sich viele Entwickler für eine Lizenz-Engine ud diverse Middlewares entscheiden: Es nimmt ihnen eigene Entwicklungsarbeit ab und spart ggf. dadurch Kosten.

Es ist ja nun nicht so, dass durch GPU-Physx irgendjemand ein Spiel wie Batman:AA oder Dark Void nicht zocken könnte.

Das wäre totall unlogisch und unwirtschaftlich.

Im Gegenteil - siehe oben.

-carsten

[Gipsel]

Ich bin mir sicher dass Du es schon erwaehnt hast, aber wie sieht die moeglichste These aus wenn man DP nicht mehr unterstuetzen will bei kleinen Varianten?Ehrlich gesagt, habe ich keine Ahnung. Die breiten Multiplier aus den Shader-Einheiten rauszureißen würde zwar eine Menge Transistoren sparen, aber das wäre doch schon ein sehr deutliches Redesign mit entsprechendem Aufwand. Aber ein Gang zu 1x16 SPs pro SM (und gleichzeitig auch nur noch 2 statt 4 TMUs) würde den Effekt wohl auch erreichen, allerdings auf Kosten einer etwas schlechteren Einheitenauslastung (man brächte wohl weiterhin die vollen 16 L/S-Einheiten und 4 SFUs oder am Scheduler muß auch was geändert werden, obwohl das vielleicht überschaubar bleibt).

In dem Zusammenhang möchte ich auch noch einmal sagen, daß es mir auch komplett unverständlich ist, warum Juniper kein DP kann. Der kann ja alles was Cypress kann (SP-FMAs, 24bit integer multiplies in jeder ALU, die erforderlichen multiplier für DP mit 4:1 Rate zu DP sind also da), nur eben kein DP. Ich wüßte nicht, was man da jetzt eingespart haben könnte. Zudem hat ja sogar der Dave Baumann auf B3D gesagt, daß Juniper sehr genau ein halbierter Cypress ist (bis auf Setup, Display engines, UVD und so ein Kleinkram), der sollte eigentlich dann auch die gleichen ALUs haben. Insofern möchte ich da eine künstliche Beschränkung aus mir unverständlichen Marketinggründen auch nicht ausschließen.

Wenn die TMUs diesmal nicht an die SMs gekoppelt waeren, warum nicht 16SPs beispielsweise aus 2 SMs deaktivieren als einen ganzen SM?Geht es jetzt nur um das Deaktivieren, oder das physische Einsparen in einem kleineren Chip? Beim Deaktivieren geht beides (wenn von nv vorgesehen und der Rest dann nicht durcheinander kommt), beim physischen Einsparen ist das Weglassen eines ganzen SMs natürlich für die Die-Fläche viel effizienter. Außerdem wüßte ich nicht, was es die TMUs stören sollte, wenn man 16 SPs in einem SM deaktiviert. Also denkbar wäre es schon.

Moment jetzt bin ich total verwirrt: schlaegst Du jetzt vor dass sie bei 448 bzw. 384 SPs z.B. den vierten raster eingeschaltet behalten oder deaktivieren?Ich würde alle Raster-Einheiten behalten (wenn das kein Defekt-Schwerpunkt ist), insbesondere da 24pixel/Takt sich jetzt nicht nach soo viel anhören, insbesondere bei 32 (256bit), 40 (320bit) oder gar 48 ROPs (volles 384bit Speicherinterface). Die Chips mit defekten Raster-Einheiten kann man ja immer noch als Teslas verkaufen (z.B. nur 2 Raster-Einheiten aktiv).
Es sind doch nebenbei 8 pixel/clock/raster und die uebrigen 16ROPs klingen eher eine "dekorative" Existenz fuer rasterizing zu haben, aber wohl nicht fuer >4x MSAA (deshalb ist die angebliche Behauptung dass andere FB Komprimierung fuer 8xMSAA Leistung wohl eher Humbug als einziger "fix" fuers letztere...)Daß es keine 12Pixel sind, war ja eigentlich klar (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7786546#post7786546) ;). Aber die zusätzlichen ROPs können bei AA schon helfen, das stimmt.

Wenn ich jetzt als normalsterblicher theoretische 48 pixel/clock sehe dank 48 ROPs, aber dann sehe dass jedem raster nur 4*8=32pixel zustehen, dann stell ich mir auch vor dass jeder raster vielleicht seinem eigentlichem Arbeitsvolumen angepasst sein koennte.
Auf diese Anpassung würde ich erstmal nicht sooo viel geben. Die ATIs sind zwar zugegebenermaßen in dem Bereich unbalancierter, aber für halbwegs kleine Dreiecke machen wohl von Redwood (vielleicht sogar Cedar, es sei denn, die haben dort nur einen 8 pixel Rasterizer drin) bis Cypress alle Chips 16 Pixel/Takt bei 8 (Cedar nur 4!) bis 32ROPs dafür. Das ist sicherlich nicht das Optimum, aber ein kleinerer Mismatch (+-50%) macht da jetzt offensichtlich nicht soo viel aus.
Ich hab offensichtlich keinen Einblick in ihre Vertraege. Ein 300mm 40G wafer duerfte wohl um die $5000 kosten. Wenn man jetzt irrsinnig niedrige yields wie im letzten Oktober/November hat und nur eine handvoll oder etwas mehr operativer chips/wafer dann ist wohl kein einziger IHV so bloed und bezahlt $2500 fuer so etwas. Wenn dem so waere haette AMD seit letztem Oktober die Grafiksparte gleich dicht machen koennen.
Aber TSMC wäre auch blöd, die Kosten komplett auf die eigene Kappe zu nehmen. Ergo wird man sich da irgendwo treffen müssen.

Nehmen wir mal der Einfachheit halber 5000$ pro Wafer und 100 Dies darauf an. Bei 100% Yield würde NV brennend gerne nur die Waferkosten zahlen und kommt somit auf 50$ pro Die. Dies ist für TSMC auch akzeptabel.
Ist jetzt der Yield nur 50%, kommen also nur 50 funktionsfähige Dies vom Wafer, tut sich nv schon deutlich schwerer damit 5000$ dafür abzudrücken, erhöht dies doch die Kosten pro Die auf 100$. Andererseits wird sich TSMC auch nicht erlauben können, den funktionsfähigen Die für 50$ das Stück, also nur noch 2500$ pro Wafer abzugeben. Der Kompromiß könnte so aussehen, daß man sich in der Mitte trifft, also nvidia 75$ pro Die bezahlt, TSMC also 3750$ pro Wafer bekommt.

Das ist natürlich stark vereinfacht, der Preis wird yieldabhängig sein, wobei sowohl so etwas wie ein endlicher Maximalpreis (bei yield ~0) als auch ein Minimalpreis für optimale yields definiert ist. Dazwischen gibt es dann (wahrscheinlich nichtlinear verlaufende) yieldabhängige Preise. Aber die genauen Bedingungen wird natürlich niemand herausrücken.
Zusammengefaßt dürfte sich aus so einem Vertragswerk meistens für beide Parteien ein großes Interesse an hohen yields ergeben. Den Auftraggeber möchte sein bestelltes Volumen haben und wenig Geld pro Die bezahlen und TSMC möchte möglichst viel Geld für den Wafer bekommen und die Kunden nicht verärgern.

Also technisch gesehen mag der nv-Mann recht haben, wenn er sagt, es werde pro funktionierendem Die bezahlt. Allerdings dürfte der Preis pro Die vom Yield abhängen ;)

[Ailuros]

Das sollte kein Problem sein, im zweifelsfall ist eben die Raster-unit des GPC mit dem deaktivierten SM etwas unterbeschäftigt.

So viel kann ich mir auch bis jetzt vorstellen. Ich versuche ja ueber die letzten paar Zeiten zu verstehen warum man bei der Deaktivierung von 2 SMs im vierten GPC auch den raster deaktivieren muesste, gerade damit die anderen 3 rasters nicht ueberbeschaeftigt sein koennten.

Wenn jetzt das obrige Sinn macht dann wuerde man unter normalen Umstaenden den vierten raster auch nicht deaktivieren und damit faellt es mir auch schwer zu verstehen dass die 4 GPC Aufteilung <-> dank 4 rasterizers u.a. nur eine "virtuelle" Aufteilung sein sollte.

[Gipsel]

Das sollte kein Problem sein, im zweifelsfall ist eben die Raster-unit des GPC mit dem deaktivierten SM etwas unterbeschäftigt.
Oder die 3 SMs in dem GPC bremsen den ganzen Chip im Zweifelsfall auf 3/4 der Gesamtleistung herunter, auch wenn nur 1/16 der SMs deaktiviert wurde ;)
Das Loadbalancing sollte schon mit GPCs (falls die überhaupt real sind) mit einer unterschiedlichen Anzahl von SMs entsprechend zurechtkommen. Die bei B3D vorgeschlagene Lösung (Raster-Einheiten sitzen oberhalb der SMs und sind eigentlich unabhängig) ist aus meiner Sicht auch einfach genug, daß erstmal nichts gegen sie spricht.

[aths]

naaj GTX 260 = mainstream und der letzte HW Physix titel brauch ne GTX 260 alleine für die Physikx BerechnungMainstream ist wohl eher 9400 GT oder GT 220.

PhysX hat IMHO nur dann eine Chance wenn AMD mitzieht. Tun sie das nicht dann wird wieder für den kleinsten gemeinsamen Nenner entwickelt. Und das sind Systeme ohne PhysX.Nvidia dürfte mit der jetzigen Lage recht zufrieden sein: PhysX ist zwar GeForce-only, aber einer der alles haben will, muss dann eben die GeForce kaufen. Auch wenn es kaum Titel gibt, die das unterstützen. Es ist einfach für den Highend-Gamer ein ungutes Gefühl, dass die eigene Hardware irgendwas nicht unterstützt.

Wie rational dieses Verhalten ist, sei dahingestellt.

[Ailuros]

Gipsel,

Siehe oben. Ich hab das Gefuehl dass wir uns irgendwo einander vorbei reden.


Aber TSMC wäre auch blöd, die Kosten komplett auf die eigene Kappe zu nehmen. Ergo wird man sich da irgendwo treffen müssen.

Wenn mich aber jemand versichert dass Jensen es deutlich beim den letzten paar editor's days bestaetigt hat, dann sieht es nicht nach einem einfachem Geruecht aus. Das dumme ist dass ich nichts ueber 2009 finden kann im Netz.

Nehmen wir mal der Einfachheit halber 5000$ pro Wafer und 100 Dies darauf an. Bei 100% Yield würde NV brennend gerne nur die Waferkosten zahlen und kommt somit auf 50$ pro Die. Dies ist für TSMC auch akzeptabel.
Ist jetzt der Yield nur 50%, kommen also nur 50 funktionsfähige Dies vom Wafer, tut sich nv schon deutlich schwerer damit 5000$ dafür abzudrücken, erhöht dies doch die Kosten pro Die auf 100$. Andererseits wird sich TSMC auch nicht erlauben können, den funktionsfähigen Die für 50$ das Stück, also nur noch 2500$ pro Wafer abzugeben. Der Kompromiß könnte so aussehen, daß man sich in der Mitte trifft, also nvidia 75$ pro Die bezahlt, TSMC also 3750$ pro Wafer bekommt.

Das ist natürlich stark vereinfacht, der Preis wird yieldabhängig sein, wobei sowohl so etwas wie ein endlicher Maximalpreis (bei yield ~0) als auch ein Minimalpreis für optimale yields definiert ist. Dazwischen gibt es dann (wahrscheinlich nichtlinear verlaufende) yieldabhängige Preise. Aber die genauen Bedingungen wird natürlich niemand herausrücken.
Zusammengefaßt dürfte sich aus so einem Vertragswerk meistens für beide Parteien ein großes Interesse an hohen yields ergeben. Den Auftraggeber möchte sein bestelltes Volumen haben und wenig Geld pro Die bezahlen und TSMC möchte möglichst viel Geld für den Wafer bekommen und die Kunden nicht verärgern.

Also technisch gesehen mag der nv-Mann recht haben, wenn er sagt, es werde pro funktionierendem Die bezahlt. Allerdings dürfte der Preis pro Die vom Yield abhängen ;)

Eine ausgezeichnete Illustration wie es sein koennte, aber ich sagte ja mit Absicht dass ich keinen Einblick auf solche Vertraege habe (und koennte auch keineswegs haben). Der einzige und natuerlich vereinfachte Punkt hier ist dass die Herstellungskosten auf keinen Fall so tragisch sind wie sich so mancher vorstellen will oder kann.

[Gast]

Auf diese Anpassung würde ich erstmal nicht sooo viel geben. Die ATIs sind zwar zugegebenermaßen in dem Bereich unbalancierter, aber für halbwegs kleine Dreiecke machen wohl von Redwood (vielleicht sogar Cedar, es sei denn, die haben dort nur einen 8 pixel Rasterizer drin) bis Cypress alle Chips 16 Pixel/Takt bei 8 (Cedar nur 4!) bis 32ROPs dafür. Das ist sicherlich nicht das Optimum, aber ein kleinerer Mismatch (+-50%) macht da jetzt offensichtlich nicht soo viel aus.

Soweit ich weiß, rastert Cypress 32 Pixel pro Takt. Ob das jedoch von der Dreiecksgröße abhängig ist: k.A.

-carsten

[Gipsel]

Soweit ich weiß, rastert Cypress 32 Pixel pro Takt. Ob das jedoch von der Dreiecksgröße abhängig ist: k.A.

-carsten
Nun, bei einem auf 1Tri/clock limitiertem Setup können es maximal so viele Pixel sein, wie das Dreieck groß ist ;). Sprich, die 32 Pixel/Takt erreicht man nur unter speziellen Bedingungen mit Dreiecken >=32 Pixel (bzw. >16 Pixel, damit man überhaupt >16 Pixel/Takt erreichen kann).
Wie das genau funktioniert, hat meines Wissens noch keiner herausbekommen. Aber es existieren wohl noch weitere Bedingungen, damit die beiden Rastereinheiten simultan an 2 Dreiecken arbeiten können. Jawed bei B3D hat da wohl mal mal rumprobiert. Ich habe das so verstanden, daß die Dreiecke in unterschiedliche Tiles für den Hierarchical-Z-Test fallen müssen.

[aths]

I beg to differ.

Die Adresskalkulation usw. ist sehr komplex und kaum auf einem so hohen Takt zu machen. Das Filtering ist bei Fermi evtl. schon mit dem Shader-Core verwoben (deine LERPs).Bei komplexen TA-Rechnungen für anisotrope Filterung brauchen auch die Filter-Units länger. Die Latenzen müssten sich verstecken lassen. Ob die TA-Rechnungen mal in die SFU wandern oder separat bestehen bleiben, kann ich nicht absehen. Möglicherweise erlauben zukünftige GPUs, eine Art TA-Shader zu nutzen der entweder auf fest installierte Standard-Filterberechnungen zurückgreift oder einen eigenen Filter implementiert.

Beim Filtern ist die Frage ob die Shaderleistung im Vergleich zur Filterleistung so zunimmt dass im Vergleich die paar Fixed-Function-TMUs auch nicht ins Gewicht fallen, oder ob man dazu übergeht, die Filterung von den Shadern machen zu lassen. Damit wäre man auch flexibler im Load-Balancing. Ich weiß nicht wie aufwändig es ist, Schaltungen so zu entwerfen dass sie bei FP32 in "full speed" laufen und bei FP16 oder FX8 "double pumped" arbeiten.

[Gast]

Aber TSMC wäre auch blöd, die Kosten komplett auf die eigene Kappe zu nehmen. Ergo wird man sich da irgendwo treffen müssen.
Warum nicht? Macht doch jede andere Firma genauso. Wenn bei VW nur jeder 2. vom Band rollende Golf funktioniert, können die doch nicht auch einfach die kaputten weiterverkaufen und wer einen bekommt ist selbst schuld.

Wie die Yields aussehen ist nunmal Sache von TSMC und nicht desjenigen, der die Chips bestellt. Wenn TSMC nicht genug Geld an den Chips verdient, könnten sie ja die Fertigung des Chips verweigern. Da sie es nicht tun, kannst du dir denken, ob da ne schwarze oder rote Zahl am Ende steht ;)

[Coda]

Bei komplexen TA-Rechnungen für anisotrope Filterung brauchen auch die Filter-Units länger.
Der Filter ist rein bilinear, natürlich ist da eine Control-Unit davor die entsprechend loopt.

[Odal]

Warum nicht? Macht doch jede andere Firma genauso. Wenn bei VW nur jeder 2. vom Band rollende Golf funktioniert, können die doch nicht auch einfach die kaputten weiterverkaufen und wer einen bekommt ist selbst schuld.

Wie die Yields aussehen ist nunmal Sache von TSMC und nicht desjenigen, der die Chips bestellt. Wenn TSMC nicht genug Geld an den Chips verdient, könnten sie ja die Fertigung des Chips verweigern. Da sie es nicht tun, kannst du dir denken, ob da ne schwarze oder rote Zahl am Ende steht ;)

eben das wird auch der Grund für das Verfügbarkeitsproblem der R870 sein und einer der Gründe warum sich die GF100 noch solang hinzieht.

TSMC könnten sicher schon was liefern nur zu welchem preis (auf dem sie dann sitzen bleiben)


Wäre mal interessant was für mindest Margen für welchen Zeitraum (bzw. ob überhaupt welche festgelegt sind) gesetzt sind und was es da für Konvenstionalstrafen gibt (bzw. ob überhaupt)

[Gast]

Wirklich amüsant wie einige hier meinen Yields wären völlig irrelevant, nur weil angeblich Nvidia pro funktionierendem Chip bezahlt und nicht pro Wafer.

Glaubt Ihr eigentlich das TSMC dämlich ist? Natürlich werden die pro Chip Preise wiederspiegeln das Fermi ein riesiger und damit schwierig mit guten Yields zu fertigender Chip ist!

Desweiteren wird keineswegs ATI sofort und komplett zu GF wechseln, genauso wenig wie NV darauf verzichten wird zu GF zu gehen, nachdem AMD die letzten Reste an GF an die Araber verkauft hat.

Es ist also Blödsinn anzunehmen das hier NV gegenüber ATI in irgendeiner weise bevorteilt würde. TSMC hat keinerlei Interesse die Produktion von NV mit der von ATI querzusubventionieren. Wenn sich die Fermi Produktion nicht lohnt dann bekommt halt NV auch keine Wafer, so einfach ist das.

Die wirtschaftliche Realität ist nunmal ganz einfach Chipgrösse und Yield = Produktionskosten. Die Suppe muss NV alleine auslöffeln.

Ein Wafer, egal was drauf ist, kostet TSMC so ziemlich das gleiche. Somit ist es auch sinnvoll das letztlich der Kunde für jeden Wafer zahlt und nicht für funktionierende Chips. Wenn schlechte Yields aber rein auf das Konto von TSMC gehen, müssen die natürlich das ganze ausgleichen, läuft bei AMD aber auch sicherlich nicht anders.

[Dural]

Wirklich amüsant wie einige hier meinen Yields wären völlig irrelevant, nur weil angeblich Nvidia pro funktionierendem Chip bezahlt und nicht pro Wafer.

Glaubt Ihr eigentlich das TSMC dämlich ist? Natürlich werden die pro Chip Preise wiederspiegeln das Fermi ein riesiger und damit schwierig mit guten Yields zu fertigender Chip ist!

Desweiteren wird keineswegs ATI sofort und komplett zu GF wechseln, genauso wenig wie NV darauf verzichten wird zu GF zu gehen, nachdem AMD die letzten Reste an GF an die Araber verkauft hat.

Es ist also Blödsinn anzunehmen das hier NV gegenüber ATI in irgendeiner weise bevorteilt würde. TSMC hat keinerlei Interesse die Produktion von NV mit der von ATI querzusubventionieren. Wenn sich die Fermi Produktion nicht lohnt dann bekommt halt NV auch keine Wafer, so einfach ist das.

Die wirtschaftliche Realität ist nunmal ganz einfach Chipgrösse und Yield = Produktionskosten. Die Suppe muss NV alleine auslöffeln.

Ein Wafer, egal was drauf ist, kostet TSMC so ziemlich das gleiche. Somit ist es auch sinnvoll das letztlich der Kunde für jeden Wafer zahlt und nicht für funktionierende Chips. Wenn schlechte Yields aber rein auf das Konto von TSMC gehen, müssen die natürlich das ganze ausgleichen, läuft bei AMD aber auch sicherlich nicht anders.

Wenn TSMC die 40nm fertigung nicht vernüftig hinbekommt zahlt NV garantiert keinen Cent mehr als normal, du musst schon komplett naiv sein wenn du wirklich glaubst das NV die vollen Wafer bezahlt auch wenn die ausbeute nur z.b. 10% ist! Genau so wenig wie es AMD machen würde....

TSMC hat gar keine andere wahl, erstens sind es gute kunden und zweiten müssen die anlagen auch ausgelastet werden für 3. den prozess zu verbessern, zudem wohl TSMC kaum irgend ein verlust fahren wird, da man an den kleinen chips sicher gut genug verdient.

am ende wird es immer ein kompromis sein, wie die verträge genau ausschauen weis KEINER im www und das wird man auch nie erfahren...

[Gast]

Es ist also Blödsinn anzunehmen das hier NV gegenüber ATI in irgendeiner weise bevorteilt würde. TSMC hat keinerlei Interesse die Produktion von NV mit der von ATI querzusubventionieren. Wenn sich die Fermi Produktion nicht lohnt dann bekommt halt NV auch keine Wafer, so einfach ist das.
Ach so, TSMC verscherzt es sich also lieber mit einem der größten Kunden und versorgt stattdessen den Kunden, der bald von ihnen weggeht? Wers glaubt wird seelig ;)

Wenn man wissen will wieviel NVidia oder ATI für ihre Chips bezahlen und wieviele Marge sie haben muss man sich nur mal die Finanzzahlen anschauen. Das Nvidia über die Laufzeit des GT200 draufgezahlt hat ist völliger Bullshit, wie sollte man über die Zeit hunderte Millionen verdienen, wenn man bei jedem Chip draufzahlt?

[V2.0]

448 bzw. 384SPs passen aber nicht oben rein ;)



Das wären aber teil deaktvierte Chips.

[Gast]

Die wirtschaftliche Realität ist nunmal ganz einfach Chipgrösse und Yield = Produktionskosten. Die Suppe muss NV alleine auslöffeln.

Ein Wafer, egal was drauf ist, kostet TSMC so ziemlich das gleiche. Somit ist es auch sinnvoll das letztlich der Kunde für jeden Wafer zahlt und nicht für funktionierende Chips. Wenn schlechte Yields aber rein auf das Konto von TSMC gehen, müssen die natürlich das ganze ausgleichen, läuft bei AMD aber auch sicherlich nicht anders.

Meinst du, TSMC verzichtet auf Mischkalkulation? Insbesondere angesichts des finanziell grandiosen Jahrs 2009 würde ich davon ausgehen, dass die einem großen Kunden schon gute Preise machen, wenn der sich verpflichtet, später zu bestellende bzw. anders belichtete Wafer dann entsprechend ein wenig höher zu bezahlen?

-carsten

[GastStoffel]

Die Waferdisskusion ist doch sinnlos weil keiner die Verträge kennt und alles andere interessante wurde inzwischen Xmal durchgekaut.

Das was ich bis jetzt gesehen und verstanden habe hat mich deutlich positiver gestimmt bezüglich des Fermi.Ich hab auch bedenken so wenig Benchmarks mit realen Spielen gesehen zu haben aber gut warum auch immer hatten wir auch schon.
Wenn das alles funktioniert wie spekuliert ist wie so schön gesagt "Das Fahrwerk für die nächsten Jahre" fertig mal sehen ob der Motor stimmt oder erst bei 28nm ;-)

[Bucklew]

Fudzilla behauptet, dass die bisher gezeigten Benchmarks eine langsamere Fermi (entweder 448SP oder 512SP mit weniger Taktung) gezeigt haben, als geplant ist:

http://www.fudzilla.com/content/view/17325/1/

[Gast]

Fudzilla behauptet, dass die bisher gezeigten Benchmarks eine langsamere Fermi (entweder 448SP oder 512SP mit weniger Taktung) gezeigt haben, als geplant ist:

http://www.fudzilla.com/content/view/17325/1/

Nö, tut Fudzilla nicht. Sie wiederholen nur, dass es Gerüchte darum gibt und vermuten, dass die gezeigten Werte, davon unabhängig, trotzdem verbesserungswürdig sind, wegen: "as with driver and clock tweaking, Nvidia could pull few more frames per second from this beast."

[Botcruscher]

Was zur CES gezeigt wurde wird schlicht nicht die Version gewesen sein welche ein paar Wochen vorher aus der Fabrik gekommen ist. Deswegen gab es einfach noch nix finales zu vermelden. Deswegen gibt es auch keine brauchbaren Leistungswerte in Spielen.

Das ganze wird uns jetzt natürlich als "News" verkauft...

[Odal]

Fudzilla behauptet, dass die bisher gezeigten Benchmarks eine langsamere Fermi (entweder 448SP oder 512SP mit weniger Taktung) gezeigt haben, als geplant ist:

http://www.fudzilla.com/content/view/17325/1/

das glaub ich nicht, das würde heissen das die GTX3x0 wahre Overclock Krüppel werden, wenn es nvidia nichtmal schafft für kontrollierte Techsessions "kurz" vorher selektierte chips zu verteilen welche die geplanten final takte schaffen

[AnarchX]

Oder die 60-70% der 448SPs-Version gegenüber einer GTX 285, sind schon so beindruckend genug für ein kurze Demonstration und das gesamte Potential, sofern es für 512SPs vernünftige Yields geben wird, hebt man sich für den finalen Launch auf.

In der Raytracing-Demo erreicht man auch "nur" einen Faktor 2,7, wo das Whitepaper von 3,5 bzw. Faktor 4 spricht.

[Gast]

Ich erwarte für Fermi im Übrigen immer noch "nur" 15 % Leistungsplus overall (bzgl. HD 5870) bei > 200 Watt TDP + 400 € Straßenpreis. Die Rosinenpickerbenchmarks deute ich so. Gerade die Far Cry 2-Ergebnisse sehen für mich danach aus. Bei FC 2 kann RV870 nicht so gut punkten (schon gegenüber einer GTX 285 bringt eine HD 5870 nur etwa 25 % Geschwindigkeitsvorteile, obwohl es bei Crysis z. B. 50 % sind, bei Risen fast 60 %). Ganz ok sicherlich, aber nicht revolutionär. Wenn Fermi im April erhältlich sein sollte, kann AMD im Mai sicherlich mit einer "HD 5890 2 GB" kontern.

Viel interessanter ist für mich (und die Masse) aber sowieso, was im Bereich 200 € und dadrunter geschehen wird. Ich sehe die HD 5850 für längere Zeit unangreifbar. Oder irre ich mich?

[mapel110]

Viel interessanter ist für mich (und die Masse) aber sowieso, was im Bereich 200 € und dadrunter geschehen wird. Ich sehe die HD 5850 für längere Zeit unangreifbar. Oder irre ich mich?
Nö, du irrst nicht. 5850 wird durch Fermi zu unterem Mid Range degradiert(ala Geforce GTS 250) und da wird nvidia noch ein paar weitere Monate nichts bieten. (eigene Einschätzung(tm)).

[Gast]

Wenn Fermi im April erhältlich sein sollte, kann AMD im Mai sicherlich mit einer "HD 5890 2 GB" kontern.

Und was soll das bringen? 10% mehr Leistung für 500€uro?

[Gast]

das glaub ich nicht, das würde heissen das die GTX3x0 wahre Overclock Krüppel werden, wenn es nvidia nichtmal schafft für kontrollierte Techsessions "kurz" vorher selektierte chips zu verteilen welche die geplanten final takte schaffen


Das hat nichts mit können zu tun.

Die Frage ist wie schnell die GPU nun wirklich ist. Wenn der kastrierte Fermi wirklich so schnell wie gezeigt ist, ist es durchaus sinnvoll diesen erstmal herzuzeigen um am Launchtag noch eine Überraschung in der Hinterhand zu haben.

Wenn die beschnittene Karte nur knapp oder garnicht schneller als eine 5870 ist, ist es natürlich sinnvoll unbedingt eine selektierte Karte zu wählen die besonders schnell ist.

Egal wie schnell die schnellste Fermi wird, es ist nicht wirklich sinnvoll jetzt schon eine schnellere Karte zu zeigen.

[Gast]

Und was soll das bringen? 10% mehr Leistung für 500€uro?

Warum 500 €? Die HD 5870 kostet jetzt schon 330 €. Im Mai für 370 € eine HD 5890 wäre doch denkbar, wobei HD 5850 auf 200 € und HD 5870 auf 300 € fallen würden.

[Odal]

Und was soll das bringen? 10% mehr Leistung für 500€uro?

naja bei karten dieser Leistungsklasse sind 1024 mb schon eine ziemliche Spaarausführung, selbst für eine 5870 halte ich das zu wenig

fragt sich nur "falls" fermi die 5870 in die Tasche steckt und schon fast richtung 5890 orientiert ist ob da die 1.5xxGB vram reichen...weil die logische Steigerung davon wären dann >3GB vram was irgendwie unbezahlbar klingt


Viel interessanter ist für mich (und die Masse) aber sowieso, was im Bereich 200 € und dadrunter geschehen wird. Ich sehe die HD 5850 für längere Zeit unangreifbar. Oder irre ich mich?

Auf der einen Seite erhoffe ich das (5850<200€ wär ne nette karte für mich und endlich mal wieder ATI seit der 3850) aber anererseits befürchte ich eben auch das man keine Alternative von NV bekommt und der "Software" (Treiber, PhysX, AA) seitens ATI dann hilflos ausgeliefert ist.
Ich hab leider weder sowohl G3 noch BatmanAA schon durch :( und wer weiss was für Dinge noch auf meine Liste kommen

[Plutonix]

Hmm, ich brauche schnell eine GPU, und des heißt warten und warten..
Jedes Jahr wechsle ich mal von nVidia zu ATI oder andersum :)
Je nach dem was sich grad lonnt ;)

Aber alles über 250€ ist nicht mehr "normall"

[Knuddelbearli]

Mainstream ist wohl eher 9400 GT oder GT 220.

Nvidia dürfte mit der jetzigen Lage recht zufrieden sein: PhysX ist zwar GeForce-only, aber einer der alles haben will, muss dann eben die GeForce kaufen. Auch wenn es kaum Titel gibt, die das unterstützen. Es ist einfach für den Highend-Gamer ein ungutes Gefühl, dass die eigene Hardware irgendwas nicht unterstützt.

Wie rational dieses Verhalten ist, sei dahingestellt.


naja ging jetzts chon von fermi aus aber darauf wollte ich ja hinaus für Physikx game wird bereits ne GTXC260 nur für die Physikx berechnung empfohlen wie willste da auf ner mainstream beides zugleich haben ...