GF11x - GeForce-500-Serie (Q4 2010 - Q2 2011)

[Hugo78]

Ist höchstwahrscheinlich ein "Abfallprodukt" der Unterstützung virtuellen Speichers. Wie gut das ins OS bzw. DX/OGL integriert wird, ist allerdings auch noch so eine Frage.

Carmack meinte letztens im Interview, dass sein Megatexturing auf den Konsolen kein großes Ding sei,
man arbeite hier ja dichter an der HW und wenn man einen Pixel in den gemeinsamen Speicher schreiben will, ginge das fix.

Auf dem PC wäre das nicht so einfach, weil man sich hier durch die APIs durcharbeiten müsse und damit viel Leistung auf der Strecke bleibt.

Also könnte es sein das es dafür garkeine großartige Integration braucht,
wenn die kommenden Treiber schon Befehle für die Verwaltung des virtuellen Speicher mitbringen.

[Gipsel]

Carmack meinte letztens im Interview, dass sein Megatexturing auf den Konsolen kein großes Ding sei,
man arbeite hier ja dichter an der HW und wenn man einen Pixel in den gemeinsamen Speicher schreiben will, ginge das fix.

Auf dem PC wäre das nicht so einfach, weil man sich hier durch die APIs durcharbeiten müsse und damit viel Leistung auf der Strecke bleibt.

Also könnte es sein das es dafür garkeine großartige Integration braucht,
wenn die kommenden Treiber schon Befehle für die Verwaltung des virtuellen Speicher mitbringen.
Gemeinsam ist der Speicher bei Konsolen aber nur, weil das ganze System inklusive OS darauf ausgelegt ist. Virtuellen Speicher rein auf der GraKa hilft dir ja auch nicht so viel weiter, man will ja eine möglichst schnelle Ankopplung auch an den CPU-Speicher, optimalerweise mit Paging- und memory mapped file Support. Das löst man wahrscheinlich am besten über MMUs mitsamt TLB und direktem OS-Support (Win8/DX 12?). Dann muß man sich nämlich durch gar nichts mehr kämpfen. Wenn der Treiber das managen soll, sind ja auch immer wieder Aktionen dort nötig, weil der ständig irgendwas ummappen muß mitsamt den zugehörigen kernel mode switches und dem damit verbundenen Overhead.

[Hugo78]

Ich hab das Interview mit der besagten Stelle grad nochmal rausgesucht.
Also ja er redet nicht vom gemeinsamen Speicher, aber den Mehraufwand der auf dem PC für sein Megatexturing, durch die API Schichten entsteht, würde er doch gern vermeiden.

- http://www.pcper.com/reviews/Editorial/John-Carmack-Interview-GPU-Race-Intel-Graphics-Ray-Tracing-Voxels-and-more/Intervi

Ryan Shrout: That's an API issue, API software overhead. Have you seen any improvements in that with DX 11 and multi-threaded drivers? Are those improving that or is it still not keeping up?

John Carmack: So we don't work directly with DX 11 but from the people that I talk with that are working with that, they (say) it might [have] some improvements, but it is still quite a thick layer of stuff between you and the hardware. NVIDIA has done some direct hardware address implementations where you can bypass most of the OpenGL overhead, and other ways to bypass some of the hidden state of OpenGL. Those things are good and useful, but what I most want to see is direct surfacing of the memory. It’s all memory there at some point, and the worst thing that kills Rage on the PC is texture updates. Where on the consoles we just say “we are going to update this one pixel here,” we just store it there as a pointer. On the PC it has to go through the massive texture update routine, and it takes tens of thousands of times [longer] if you just want to update one little piece. You start to advertise that overhead when you start to update larger blocks of textures, and AMD actually went and implemented a multi-texture update specifically for id Tech 5 so you can bash up and eliminate some of the overhead by saying “I need to update these 50 small things here,” but still it’s very inefficient. So I’m hoping that as we look forward, especially with Intel integrated graphics [where] it is the main memory, there is no reason we shouldn't be looking at that. With AMD and NVIDIA there's still issues of different memory banking arrangements and complicated things that they hide in their drivers, but we are moving towards integrated memory on a lot of things. I hope we wind up being able to say “give me a pointer, give me a pitch, give me a swizzle format,” and let me do things managing it with fences myself and we'll be able to do a better job.

[Gipsel]

Das Gute an einem gemeinsamen virtuellen Speichermodell wäre, daß man für die Megatextures (zumindest so wie ich das verstehe) gar keine API-Aufrufe mehr machen muß. Die sind ja dafür da, daß immer die richtigen Teile in das beschränkte Texturformat der heutigen GPUs reingemapped werden. Und dafür sind halt API-Aufrufe notwendig und der Treiber darf das dann jeweils vom CPU-Speicher in den GPU-Speicher schieben.

Für den in der Zukunft vielleicht mal eintretenden Fall daß direkt riesige Texturformate unterstützt werden (wäre im Moment ein Problem für die Adressierung mit floats, wenn man 256 Abstufungen [8 Bit Auflösung] zwischen den Texeln behalten will), ist im Prinzip gar kein Mapping mehr erforderlich (die GPU holt sich halt bei einem Zugriff automatisch die entsprechende Page in den GPU-Speicher). Es tritt also wie bei CPUs im Prinzip ein page fault auf, nur muß die nicht im GraKa-RAM befindliche Page nicht von der Platte nachgeladen werden, sondern über PCI-Express aus dem CPU-Speicher (der im Zweifelsfall auch auf der Platte steht ;)).

[Fetza]

Mal kurz eine frage, von jemanden, der von dem ganzen technikschnickschnack keine ahnung hat. :D

Lese ich das richtig, das die id-tech 5 engine schwierigkeiten auf dem pc hat, weil die api das megatextureverfahren erschwert? Und wenn ja, wird nvidia da irgendwas treiberseitig ändern können? Etwas, das auch den aktuellen fermimodellen noch zu gute kommen könnte?

[Hugo78]

@Gipsel
Sagen wir mal ich will garnicht riesige Texturen, sondern viele kleine laden für große Maps, wie zb. in ArmA2, was merklich von einer SSD profitiert, weils ja auch immer und immer wieder die Festplatte mit zugriffen quält.
Könnte der virtuellen Speicher hier nicht helfen, den ganzen Kram gleich in den RAM zu laden, so das man weitgehend unabhänig wird, vom Festplatten streaming?

@Fetza
Wie Carmack schon sagt, NV hat schon ein paar OGL "direct hardware address implementations", aber da muss sich wohl auch HW seitig noch was tun, damit Megatextures genauso easy auf dem PC zu proggen sind, wie auf den Konsolen.

Wobei Quake Wars ja schon eine erste Version der Technik genutzt hat, damals aber noch mit id-Tech 4.

[fondness]

Laut SemiAccurate kommt vor Kepler von eine ganze Armada an 28nm mobile-Chips auf Fermi-Basis:

http://img843.imageshack.us/img843/6246/nvidiamobilegpus.png (http://img843.imageshack.us/i/nvidiamobilegpus.png/)

Angeblich soll es sich dabei um Shrinks schon bekannter 40nm Chips handeln.

http://semiaccurate.com/2011/08/23/nvidias-28nm-mobile-lineup-leaked/

[MadManniMan]

Kann jemand die 3DMark-Regionen einordnen?

[AnarchX]

Sofern Vantage: GTX 460 Default ~ 15k.

Also dürfte die N13E-GTX auf GTX 560 Ti Niveau liegen.

[Ailuros]

Kann jemand die 3DMark-Regionen einordnen?

http://www.tomshardware.com/reviews/geforce-gtx-580-gf110-geforce-gtx-480,2781-5.html

[Spasstiger]

Also dürfte die N13E-GTX auf GTX 560 Ti Niveau liegen.
Mit 70-75 Watt TDP auf jeden Fall eine Hausnummer. Die GTX 580M wird von NV mit 16k in 3DMark Vantage angegeben und hat eine TDP von 100 Watt: http://laptoping.com/nvidia-geforce-gtx-580m-laptop-video-card-announced-benchmarked.html.

[LovesuckZ]

Das ist also eine 33% Reduzierung des Stromverbrauches.

[Ailuros]

Mit 70-75 Watt TDP auf jeden Fall eine Hausnummer. Die GTX 580M wird von NV mit 16k in 3DMark Vantage angegeben und hat eine TDP von 100 Watt: http://laptoping.com/nvidia-geforce-gtx-580m-laptop-video-card-announced-benchmarked.html.

Eine Hausnummer nicht unbedingt, wenn man bedenkt dass 32nm zwischen 40 und 28nm ausgefallen ist. Ja fuer die 580M aber sie wurde auch auf 40G hergestellt.

[AnarchX]

Bei 560M auf N13P-GT mehr als 50%. Beide ~10k in Vantage.

[Spasstiger]

Das ist also eine 33% Reduzierung des Stromverbrauches.
Bei einer Verbesserung der Performance um 25%. Leider Release erst Q2/2012.

Eine Hausnummer nicht unbedingt, wenn man bedenkt dass 32nm zwischen 40 und 28nm ausgefallen ist. Ja fuer die 580M aber sie wurde auch auf 40G hergestellt.
Klar, aber insgesamt 60-70% gestiegene Energieeffizienz (bei gleichzeitig höheren Taktraten) lässt doch auf einen guten 28-nm-Prozess bei TSMC hoffen.

[LovesuckZ]

Bei einer Verbesserung der Performance um 25%. Leider Release erst Q2/2012.

Nein, die Leistungssteigerung ist mit einberechnet.

[Ailuros]

Bei einer Verbesserung der Performance um 25%. Leider Release erst Q2/2012.

Muss aber nicht so sein, denn das angebliche GS1 und GTX betreffen offensichtlich den gleichen chip. Bevor sie in die Massenproduktion gehen bezweifle ich dass sie schon jetzt wissen ob man bei chip X Einheiten deaktivieren muss um binning yields zu verbessern. Ist so oder so nur spekulatives Zeug, sonst gaebe es auch kein Fragezeichen beim GS1.

Das schoene an der Geschichte ist dass es sich hier um maximal mainstream handelt; performance 28nm chips duerften um einiges leckerer sein.


Klar, aber insgesamt 60-70% gestiegene Energieeffizienz (bei gleichzeitig höheren Taktraten) lässt doch auf einen guten 28-nm-Prozess bei TSMC hoffen.

Wo steht etwas von Frequenzen? (nicht dass man nicht gute Frequenzen von 28nm erwarten sollte aber trotzdem...). Gut 28nm scheint keine so brutalen leakage Probleme zu haben wie 40G (rein spekulativ); bei so beschissenen yields wie es konstant herumschwirrt was soll gerade "gut" an 28nm momentan sein?

Ich hatte gestern eine live Debatte mit einem Intel und einem NV engineer und sie wollten beide eine Besen fressen wenn AMD es noch dieses Jahr mit einem SI chip schafft. Da jemand gleich sagte dass AMD aber optimistisch sei dass sie es noch dieses Jahr schaffen war die Antwort dass es die eigentliche Aufgabe von PR ist stets optimistisch zu sein. Es haette auch keiner rausgehen koennen und behaupten dass Larabee ein absoluter Stinker ist. Ich forderte ihn auf eine offizielle Aussage zu machen wie toll LRB ist und hab ihm einen freien Urlaub in Tripoli versprochen *evilgrin*

[Spasstiger]

Wo steht etwas von Frequenzen? (nicht dass man nicht gute Frequenzen von 28nm erwarten sollte aber trotzdem...).
Ich gehe davon aus, dass N13E-GTX wie GF114 (GTX 580M) ebenfalls mit 384 SPs daherkommt. Dafür spricht imo das 256-Bit-SI. Und 20k in Vantage bedeuten dann logischerweise höhere Taktraten als bei der GTX 580M (620 MHz). Wird wohl auf 750-800 MHz Chiptakt bei N13E-GTX hinauslaufen.

bei so beschissenen yields wie es konstant herumschwirrt was soll gerade "gut" an 28nm momentan sein?
Ich hab die Yield-Diskussion zu 28 nm noch nicht verfolgt. Aber ist natürlich klar, dass erstmal die Wirtschaftlichkeit stimmen muss, bevor man sich über andere Vorteile eines neuen Prozesses freuen kann. Der Antrieb für einen neuen Fertigungsprozess ist stets die mögliche Fertigungskostensenkung. Ist ein neuer Prozess teurer als der alte Prozess, dann bleibt man beim alten Prozess und benennt lieber alte Produkte in neue Produkte um, um den Markt am Leben zu halten.

[Ailuros]

Ich gehe davon aus, dass N13E-GTX wie GF114 (GTX 580M) ebenfalls mit 384 SPs daherkommt. Dafür spricht imo das 256-Bit-SI. Und 20k in Vantage bedeuten dann logischerweise höhere Taktraten als bei der GTX 580M (620 MHz). Wird wohl auf 750-800 MHz Chiptakt bei N13E-GTX hinauslaufen.

Ist auch durchaus logisch; es bleibt aber trotz allem eher spekulativ ueberhalb einer gewissen Chip-komplexitaet. Bis zu 45W zeigt sich wer auch immer die Tabelle geschrieben hat ziemlich sicher was die Massenproduktion betrifft. Ab 70W geht es mit Fragezeichen los und es ist auch bei allen ein von bis zu wert eben weil weder Frequenzen noch TDP fest gesetzt sind. Dafuer sind die Leistungswerte genauso spekulativ. Wie dem auch sei ob jetzt 19 oder 20k z.B. ist auch ziemlich wurscht wenn der TDP theoretisch zwischen 70 und 75W schwankt. Es sind eigentliche Ziele in der Tabelle und noch keine reale Daten; um das geht es mir nur.

[Dural]

sogar GF114 in 28nm hmmm interessant! die quelle stört mich aber... :rolleyes:

wenn das stimmt darf man auf die kleinen kepler aber noch lange warten :rolleyes:

[LovesuckZ]

sogar GF114 in 28nm hmmm interessant! die quelle stört mich aber... :rolleyes:

wenn das stimmt darf man auf die kleinen keplar aber noch lange warten :rolleyes:

Naja, wenn man davon ausgeht, dass der 28nm Prozeß diesmal eine frühere Verfügbarkeit der Testchips verhindert, wird wohl zwischen Kepler/2 und Gf114 in 28nm ca. 6 Monate liegen.
Zwischen G92 als 9800GTX und G92b lagen ebenfalls 6 Monate.

[Ailuros]

Ich hab die Yield-Diskussion zu 28 nm noch nicht verfolgt. Aber ist natürlich klar, dass erstmal die Wirtschaftlichkeit stimmen muss, bevor man sich über andere Vorteile eines neuen Prozesses freuen kann. Der Antrieb für einen neuen Fertigungsprozess ist stets die mögliche Fertigungskostensenkung. Ist ein neuer Prozess teurer als der alte Prozess, dann bleibt man beim alten Prozess und benennt lieber alte Produkte in neue Produkte um, um den Markt am Leben zu halten.

TSMC projezierte vor dem Anlauf von 40G dass es 4% ihres Umsatzes betragen wird. Fuer 28nm projezieren sie heute 1%.

[Skysnake]

Das Gute an einem gemeinsamen virtuellen Speichermodell wäre, daß man für die Megatextures (zumindest so wie ich das verstehe) gar keine API-Aufrufe mehr machen muß. Die sind ja dafür da, daß immer die richtigen Teile in das beschränkte Texturformat der heutigen GPUs reingemapped werden. Und dafür sind halt API-Aufrufe notwendig und der Treiber darf das dann jeweils vom CPU-Speicher in den GPU-Speicher schieben.

Für den in der Zukunft vielleicht mal eintretenden Fall daß direkt riesige Texturformate unterstützt werden (wäre im Moment ein Problem für die Adressierung mit floats, wenn man 256 Abstufungen [8 Bit Auflösung] zwischen den Texeln behalten will), ist im Prinzip gar kein Mapping mehr erforderlich (die GPU holt sich halt bei einem Zugriff automatisch die entsprechende Page in den GPU-Speicher). Es tritt also wie bei CPUs im Prinzip ein page fault auf, nur muß die nicht im GraKa-RAM befindliche Page nicht von der Platte nachgeladen werden, sondern über PCI-Express aus dem CPU-Speicher (der im Zweifelsfall auch auf der Platte steht ;)).
Dem kann ich mal ein 100% /sign geben :biggrin:

Mit dem gemeinsamen kohärenten Adressraum mit Paging etc. blabla wird das halt echt alles sehr trivial. Ich bin gespannt, was davon aber wirklich kommt, und vor allem, wie gut es funktioniert. Die Marschrichtung ist aber definitiv klar :D

Bzgl.: Der Tabelle von Charlie, das kann durchaus so richtig sein. Vor allem, das nVidia selbst noch nicht richtig weiß, was da kommt. Auf der ISC haben Sie ja den Stream abdrehen lassen, da einige Sachen wohl noch nicht fix seien.... :rolleyes:

Ganz ehrlich, vor Q2 rechne ich nicht mehr mit einem Chip in 28nm von nVidia, und bei AMD nicht wirklich vor Q1, außer die machen einen auf Paperlaunch am 31.12 :freak:

[Spasstiger]

Und Intel haut dieses Jahr eventuell schon IGPs in 22 nm raus. Vielleicht sollte sich Intel mal mit NV zusammentun für eine neue IGP-Architektur.

[LovesuckZ]

Intel hat für $1,5 Mrd nVidia-Technologie lizenziert. Und wer mehr will, der soll halt eine dGPU von nVidia kaufen. :D

[Raff]

Ich gehe davon aus, dass N13E-GTX wie GF114 (GTX 580M) ebenfalls mit 384 SPs daherkommt. Dafür spricht imo das 256-Bit-SI. Und 20k in Vantage bedeuten dann logischerweise höhere Taktraten als bei der GTX 580M (620 MHz). Wird wohl auf 750-800 MHz Chiptakt bei N13E-GTX hinauslaufen.

750 MHz sind mit einer GTX 580M übrigens schon machbar (manuelles OC). Das ist bereits fast GTX-560-Ti-Niveau. Für einen Mobilchip durchaus beachtlich.

MfG,
Raff

[Skysnake]

Und Intel haut dieses Jahr eventuell schon IGPs in 22 nm raus. Vielleicht sollte sich Intel mal mit NV zusammentun für eine neue IGP-Architektur.

IB wird definitiv erst Ende Q1 Anfang Q2 2012 kommen, und was die KANN! muss sich erst noch zeigen. Wenn man da gerade die Sachen bzgl. Atom und iGPU hört, dann bekommt man das Grausen....

Das Intel auf Anhieb also direkt Hardware+Treiber für DX11 hin bekommt, und dann auch noch Leistung bei rum kommt, muss sich erst noch beweisen!

[Ronny145]

Wenn man da gerade die Sachen bzgl. Atom und iGPU hört, dann bekommt man das Grausen....



Naja das hat miteinander nichts zu tun. Das sind PowerVR Chips, die Treiber kommen da jetzt nicht mehr von Intel.

[LovesuckZ]

Jedenfalls hat Intel bewiesen, dass sie eine wesentlich engere Integration durchführen können als AMD. Und das empfand ich als sehr überraschend. Intel wird viel zu sehr kritisiert für das, was sie erreichen. Immerhin müssen sie zum Großteil alles selbst entwickeln und bauen.

[Ailuros]

Ist ja alles schoen und gut, aber Intel ist nicht das Thema hier

[Ronny145]

Gut, stellt sich aber dennoch die Frage, warum sie es nicht selbst machen


Die Frage ist komisch. Dass sie es jetzt nicht selber machen ist völlig normal, es stellt sich eher die Frage warum sie es beim Vorgänger selber gemacht haben. Wenn der Chip von Hersteller X kommt, sollen die gefälligst für die Treiber sorgen.

[Ailuros]

Die Frage ist komisch. Dass sie es jetzt nicht selber machen ist völlig normal, es stellt sich eher die Frage warum sie es beim Vorgänger selber gemacht haben. Wenn der Chip von Hersteller X kommt, sollen die gefälligst für die Treiber sorgen.

Macht bitte einen Intel thread auf oder diskuttiert das Thema im Cedarview Thread. Ich bitte nicht nochmal dass es zum eigentlichen Thema zurueckkommt.

[Dural]

also GF114 in 28nm @ ~1200MHz bei rund 150Watt Real Verbrauch hört sich für ein Lückenfülle doch sehr gut an, ich bezweifle aber das wir jemals Desktop Karten damit sehen werden :(

das sind mal auf die schnelle 1,85TF SP mit einem rund 200mm2 DIE :freak:

[Undertaker]

1200MHz sind für den reinen Shrink des GF114 imho etwas zu optimistisch. Wie sieht es allerdings bzgl. der Gefahr einer Pad-Limitierung eines solchen Chips aus? Ist eine 256Bit-Anbindung bei vmtl. <200mm² noch machbar?

[Hugo]

so optimistisch sind 1200MHz vielleicht garnicht. Jetzt gibt es doch auch GTX560 Ti Karten mit 950 und 1000MHz.
Nur ob 150Watt Verbrauch da reichen werden? ;)

[Dural]

na stock vieleicht nicht gerade 1200MHz... aber mit OC müsste bei dieser GPU locker 1200MHz drin liegen sonst wäre ich richtig entäuscht da schon der GF114 meisten locker 1000MHz packt :wink:

aber ja da kommt es halt auch auf die qualität des shrink an...

[Skysnake]

1200MHz sind für den reinen Shrink des GF114 imho etwas zu optimistisch. Wie sieht es allerdings bzgl. der Gefahr einer Pad-Limitierung eines solchen Chips aus? Ist eine 256Bit-Anbindung bei vmtl. <200mm² noch machbar?

Kommt wohl drauf an, was er an Leistung verbrät. Wenn er wenig verbraucht, brauch man ja auch nicht so viele Pins für die Stromversorgung. Zudem passt bei AMD ja auch das 256 Bit Interface auf die 255mm² DIE-Size eines Barts. Also das sehe ich jetzt nicht das Unmöglich an, solange der Stromhunger nicht zu groß wird.

[Knuddelbearli]

1200 ? eher nicht 54nm auf 40nm hat doch nicht wirklich was gebracht schon gar keine 40%

[Dural]

und noch mal...

meine GTX560 macht mit stock kühler 1050MHz, alles unter 1200MHz wäre eine Entäuschung für 28nm.


von 55nm auf 40nm keinen grossen unterschid?!?

GTX285 650MHz
GTX580 775MHz

wer rechnen kann ist klar im vorteil... die 40nm fertigung zusammen mit fermi hat das erste mal seit 90nm (!!!) eine grössere takt erhöhung beschert.


Und nur zur erinnerung, laut der liste soll dieser Chip bei ca. 800MHz rund 70Watt verbrauchen :rolleyes:

[VooDoo7mx]

und noch mal...

meine GTX560 macht mit stock kühler 1050MHz, alles unter 1200MHz wäre eine Entäuschung für 28nm.


Und meine schafft nicht mal 950MHz bei fetter Spannungszugabe. Was sagt uns das jetzt?

von 55nm auf 40nm keinen grossen unterschid?!?

GTX285 650MHz
GTX580 775MHz

wer rechnen kann ist klar im vorteil... die 40nm fertigung zusammen mit fermi hat das erste mal seit 90nm (!!!) eine grössere takt erhöhung beschert.


Lerne erst mal die Grundzüge und Aufbau der Chips.
GT200 hat 80TMUs@648MHz, GF100 nur noch 64TMUs, dafür aber mehr Mhz.
Diese mehr MHz kommen also durch weglassen von Einheiten zu Stande.
Eine GTX 285 hat heute immer noch eine größere Texturing Leistung als GTX 480 und 580.
Desweiteren war bei der ganzen GT200 Serie das Verhältnis von Shaderclock zur TMU Domäne anders. Shaderclock war höher als 2x TMU wie man es von Fermi kennt.
GTX 285 hat 1476 vs 1544 MHz GTX 580. Also nicht mal 5% Takterhöhung durch 40nm. Wahnsinn!

Ich find es auch immer wieder Klasse wie Leute von ihren bis an den Rand übertakteteten Grafikkarten auf fertige Serienprodukte schließen. :ugly:

[Knuddelbearli]

jup alles 4 stellige würde mich stark überraschen wobei sie eventuell versuchen werden 1k hinzukriegen bei der 760TI die 780 dürfte da aber nicht raufkommen wäre immerhin 25% mehr takt ...