Archiv verlassen und diese Seite im Standarddesign anzeigen : GF100: Seine Architektur und Technologie
deekey777
2010-01-30, 20:00:19
Es wurde Zeit für einen reinen(!) Technologie-Thread für den GF100. Er hat es verdient; was der GF100 definitiv nicht verdient hat, sind nutzlose Flamewars, Fanboys und sinnlose Fragen, wer sich was kauft.
Die wichtigsten Artikel:
GF100 graphics architecture unveiled (http://www.techreport.com/articles.x/18332)
Inside Fermi: Nvidia's HPC Push (http://www.realworldtech.com/page.cfm?ArticleID=RWT093009110932)
NVIDIA’s GF100: Architected for Gaming (http://www.anandtech.com/video/showdoc.aspx?i=3721)
Hier mit den hübschen Folien:
NVIDIA's Fermi GF100 Facts & Opinions (http://www.hardocp.com/article/2010/01/17/nvidias_fermi_gf100_facts_opinions/)
In Deutsch:
Fermi GF100 im Technik-TÜV: Kommentare zu Architekturdetails, Bildqualität und Benchmarks (http://www.pcgameshardware.de/aid,703239/Fermi-GF100-im-Technik-TUeV-Kommentare-zu-Architekturdetails-Bildqualitaet-und-Benchmarks/Grafikkarte/Test/)
Nvidia GF100: Technische Details (http://www.computerbase.de/artikel/hardware/grafikkarten/2010/bericht_nvidia_gf100_technische_details/)
Nachzügler
Nvidias kommender DirectX-11-Grafikchip GF100 (http://www.heise.de/ct/artikel/Nachzuegler-914582.html) :|
Fermi-Whitepaper (http://www.nvidia.com/content/PDF/fermi_white_papers/NVIDIA_Fermi_Compute_Architecture_Whitepaper.pdf)
GF100 Graphics Architecture White Paper (http://www.nvidia.com/object/IO_86775.html)
Der GF100 ist eine Quad-GPU. Nein, ist er nicht.
Wir haben: 4 GPCs mit je Tri-Setup und Rasterizer. Der RV870 hat nur ein Tri-Setup, aber zwei Rasterizer. Jeder GPC hat seine vier SMs. Jeder Streaming-Multiprocessor hat 2x16 ALUs, vier SFUs, vier TMUs, 16 L/S-Einheiten, L1/Shared-Memory (16/48 KB oder 48/16 KB) und eine zwei Polymorph-Engines. Was'n das? Das ist eigentlich das, was der RV870 nur einmal hat. Also 8 PEs gegen eine Evergreen-PE.
Und jetzt kommt die Frage: Hat der GF100 im vollen Ausbau wirklich acht Tessellatoren?
Die Frage hätte ich gar nicht gestellt, hätte die c't nicht das geschrieben (http://www.heise.de/ct/artikel/Prozessorgefluester-914629.html):
Zudem können nach seinen Informationen die kleineren und erheblich kostengünstigeren Radeons Tessellation in Hardware ausführen, wogegen Nvidias GF100 diesen von DirectX 11 geforderten Fliesenlegerjob weitgehend per Software in den Shadern ausführen muss.
Das machte mich ziemlich stützig. Ok, man zittiert Charlie D., aber die c't hat selbst einen Artikel zum GF100 geschrieben. Gibt es einen bestimmten Grund, warum die c't seine Aussage übernimmt?
Das mit der Tesselation in Software ist Blödsinn.
Label
2010-01-30, 21:29:53
In Hinsicht auf den Fleisenlegerjob hätten sich Andreas Stiller (c't 4/10 S.18; "Prozessorgeflüster") und Martin Fischer (c't 4/10 S.26; "Nachzügler") mal besser gegenseitig konsultiert. Im zweiten Artikel wird geschreiben:
"Da die 16 Tessellation-Engines geometrische Daten parallel bearbeiten, soll die Tessellation-Leistung der GF100-GPU bis zu sechsmal höher sein als die des RV870-Chips der AMD Konkurenzkarte Radeon HD5870, der auf lediglich eine Tessellator-Einheit setzt."
Label
2010-01-30, 21:35:07
...man hätte ich garnicht abtippen brauchen, der Artikel ist auch online verfügbar...
http://www.heise.de/ct/artikel/Nachzuegler-914582.html
LovesuckZ
2010-01-30, 22:19:51
Und jetzt kommt die Frage: Hat der GF100 im vollen Ausbau wirklich acht Tessellatoren?
Die Frage hätte ich gar nicht gestellt, hätte die c't nicht das geschrieben (http://www.heise.de/ct/artikel/Prozessorgefluester-914629.html):
Das machte mich ziemlich stützig. Ok, man zittiert Charlie D., aber die c't hat selbst einen Artikel zum GF100 geschrieben. Gibt es einen bestimmten Grund, warum die c't seine Aussage übernimmt?
GF100 hat 16 Geometrieeinheiten mit 16 dedizierten Tessellationseinheiten. Und zwei der drei Arbeitsschritte werden "per Software in den Shadern" ausgeführt. Das ist durch D3D so vorgesehen. AMD macht nichts anderes.
Technik_Gast
2010-01-30, 22:37:37
Um nochmal die Diskussion über die Anzahl und Frequenz der Textureinheiten aus dem Speku-Thread aufzugreifen:
64 TA und 64 TFs bei 1/2 hot clock fuer den groessten 512SP chip.Dann verschwenden sie ihre Load-Leistung. Irgendwas stimmt da nicht Ail
Könntest Du, Coda, vielleicht nochmal (falls nicht zu aufwendig) den Zusammenhang zwischen den Load/Store-Einheiten und den Textureinheiten herstellen?
Und warum verschenken sie bei den Specs von Ailuros die halbe Load-Leistung?
Weil die Load-Store-Einheiten auf Hot-Clock arbeiten, nicht auf der Hälfte.
Könntest Du, Coda, vielleicht nochmal (falls nicht zu aufwendig) den Zusammenhang zwischen den Load/Store-Einheiten und den Textureinheiten herstellen?
Ich bin zwar nicht Coda, aber ich versuch es trotzem mal.
Für bilineare Filterung braucht es 4 Texel aus der Textur.
Pro SM hat GF100 16 Load/Store-Einheiten die mit vollem Shader-Takt laufen (was auch in den Nvidia-Papers bestätigt ist), also 16 Texel pro Takt liefern können.
Damit könnte man pro Shadertakt 4 Filtereinheiten mit Texel beliefern.
Nun hat der GF100 pro SM 4 TMUs, die aber angeblich mit halbem Shadertakt laufen (in den Nvidia-Papers lässt sich dazu nichts finden, laut einigen Hardware-Websites ist das aber von Nvidia bestätigt)
Man könnte also nur 8 Loads pro Shadertakt auch verarbeiten, die restlichen wären umsonst.
Die Idee wäre nun, dass entweder die TF-Einheiten mit vollem Shadertakt (TA mit dem halben Takt) laufen oder aber pro TMU 2 vorhanden sind. Damit hätten wir wieder ein TA:TF-Verhältnis von 1:2, ähnlich wie beim G80.
Damit hätte GF100 zwar höchstwahrscheinlich (je nach Taktrate) weniger bilineare Füllrate als G200, Trilinear und Anisotrop sind es aber je nach Takt ~60-70% mehr.
Der Wert würde auch recht gut zu den Nvidia-Benchmarks in Texturlimitierten Szenen passen, die angeblich eine Performancesteigerung von 40-70% aufweisen.
Mit nur 64TF auf halbem Shadertakt wäre das auf keinen Fall möglich, da könnte man maximal annähernd G200-Performance halten.
Ailuros
2010-01-30, 22:59:30
GF100 hat 16 Geometrieeinheiten mit 16 dedizierten Tessellationseinheiten. Und zwei der drei Arbeitsschritte werden "per Software in den Shadern" ausgeführt. Das ist durch D3D so vorgesehen. AMD macht nichts anderes.
Attribute setup units (falls Du diese meinen solltest) sind eigentlich fuer Tesselation gedacht. Es wird ueberhaupt nichts in sw ausgefuehrt. Wenn ein Redakteur nicht den Unterschied zwischen programmierbarer und fixed function hw verstehen kann dann sollte er auch die Finger von GPUs gleich ganz lassen.
Wie dem auch sei nochmal die Aussage eines NV engineers zum Dilemma programmierbare gegen fixed function Tesselations-Einheit:
As always, this is an area vs performance play. It depends on what the area of a fixed-function unit is, times its (expected) utilization, vs the performance (and perhaps complexity) of not using fixed-function.
The Tessellation unit (however implemented) needs to do 4 things:
- Read the inputs.
- Determine the topology (how many vertices and where they are).
- Collect the vertices into batches.
- Schedule the batches on the SMs.
Some of those tasks are better suited to fixed-function, and some are better suited to a programmable environment. Note that after the "hull shader" (what a terrible name), the specified LODs can make generate a patch that has 100-1000x more vertices than the input patch.
Ultimately, however tessellation is done matters a lot less than the final performance achieved. Even between 2 fixed-function unit designs, the performance characteristics can be wildly different.
Was Du jetzt bei der Polymorph engine eigentlich hast ist dass die Aufgaben die mehr Sinn machten auf programmierbarer hw auf die programmierbare pipeline verschickt wurden und die paar Aufagen die mehr Sinn auf fixed function Einheiten in eine relativ kleine Summe an Transistoren pro SM verschleusst.
Und ja AMD macht es anders da sie lediglich eine fixed function Tesselations-Einheit zwischen den hull und domain shader calls einlegen.
Um es anders zusammenzufassen es wird gar nichts in software oder "software" ausgefuehrt auf GF100 fuer Tesselation (ausser man bezeichneit neuestens auch pixel shader als "software") und diese Behauptung ist genauso idiotisch als zu behaupten dass GF100 um 16x Mal schneller ist mit Tesselation als ein RV870.
1. Limitieren andere Faktoren bis ein heutiger chip je so eine Hoehe erreichen koennte.
2. Quote oben sehr vorsichtig durchlesen; NV hat auf jeden Fall nicht 16x Mal so viel Transistoren wie AMD fuer Tesselation gewidmet.
***edit: damit ich nicht falsch verstanden werde: Cypress hat 2 raster units die jeweils bis zu 16 pixels/Takt bearbeiten koennen, waehrend GF100 4 rasters units die jeweils bis zu 8 pixels/Takt bearbeitet koennen. Auf Papier 2 Tris/clock beim ersten, 4 Tris/clock beim zweiten. Echtzeit 1 Tri/clock vs. 2-3 Tris/clock.
*****edit Nr.2: deekey777 danke Du bist uns Mods einen Schritt voraus da wir genau ein solches Projekt vorhatten.
Technik_Gast
2010-01-30, 23:45:30
Ich bin zwar nicht Coda, aber ich versuch es trotzem mal.
Für bilineare Filterung braucht es 4 Texel aus der Textur.
Pro SM hat GF100 16 Load/Store-Einheiten die mit vollem Shader-Takt laufen (was auch in den Nvidia-Papers bestätigt ist), also 16 Texel pro Takt liefern können.
Damit könnte man pro Shadertakt 4 Filtereinheiten mit Texel beliefern.
Nun hat der GF100 pro SM 4 TMUs, die aber angeblich mit halbem Shadertakt laufen (in den Nvidia-Papers lässt sich dazu nichts finden, laut einigen Hardware-Websites ist das aber von Nvidia bestätigt)
Man könnte also nur 8 Loads pro Shadertakt auch verarbeiten, die restlichen wären umsonst.
Besten Dank! Das war genau die Info, die mir für das Verständnis noch gefehlt hat.
Allerdings ist mir immer noch nicht ganz klar, was die TAs dann eigentlich noch machen?
Zuerst kommen also die Load/Store-Einheiten und liefern die Texel für die TFs, in denen das (bilineare) Filtern stattfindet. Und dann kommen die TAs?
Welche Berechnungen müssen denn dann noch gemacht werden?
Die TAs berechnen aus Texturkoordinate und lokaler Verzerrung die nötigen Speicherposition an denen dann gefilert werden muss.
Technik_Gast
2010-01-30, 23:58:43
OK. Also liegen die TAs (bildlich gesprochen) noch vor den TFs und auch vor den L/S-Einheiten?
Also vom Ablauf her: TA->L/S-Einheiten->TF
=Floi=
2010-01-31, 05:43:55
Der GF100 sollte doch die Quadro und damit den CAD bereich revolutionieren, weil er einen so hohen dreiecksdurchsatz hat?!
robbitop
2010-01-31, 11:10:19
Womit werden eigentlich Objekte in CAD gerendert? Rasterizing / Raycasting ist das doch sicher nicht oder?
Und wie wird das Ganze von einer GPU beschleunigt? Wenn ich in ProEngineer an detailierten 3D Modellen sitze (z.B unsere komplette Windenergieanlage mit allen Komponenten in 3D) wird es total ruckelig. Mir ist nicht klar warum und was genau der Flaschenhals darstellt. CPU Leistung scheint auf jeden Fall was zu bringen. Toll skalieren scheint es aber nicht mit 4 Kernen.
Avalox
2010-01-31, 12:06:31
Andreas Stiller schreibt im letzten Prozessorgeflüster "ausdrücklich" einige gefundene Webschnippsel.
"Auch Nvidia will diese TSMC-Technik für zukünftige Fermi-Chips nutzen. Nvidias „Lieblingsjournalist“ Charlie Demerjian von semiaccurate.com berichtet jedoch, dass das jüngste Fermi-A3-Stepping die Erwartungen nicht erfülle und mit geringeren Taktfrequenzen laufe als geplant.
Zudem können nach seinen Informationen die kleineren und erheblich kostengünstigeren Radeons Tessellation in Hardware ausführen, wogegen Nvidias GF100 diesen von DirectX 11 geforderten Fliesenlegerjob weitgehend per Software in den Shadern ausführen muss. Schwere Zeiten also für Nvidia – und eine CPU (außer Tegra) zur Integration mit dem Grafikprozessor, so wie AMD mit Fusion, hat man auch nicht, jedenfalls noch nicht. " http://www.heise.de/ct/artikel/Prozessorgefluester-914629.html
Wird dort die Welt auf die Nichteinhaltung der Performanceerwartung zum Fermi eingestimmt, oder ist dort der Sachverhalt weniger schwerwiegend? Welche Auswirkung wird dieses denn für den Massenmarkt der billigen Chips haben? Kann dort nVidia mit Shader abgespeckten Varianten noch mithalten?
Zudem können nach seinen Informationen die kleineren und erheblich kostengünstigeren Radeons Tessellation in Hardware ausführen, wogegen Nvidias GF100 diesen von DirectX 11 geforderten Fliesenlegerjob weitgehend per Software in den Shadern ausführen muss.
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7814337#post7814337
Avalox
2010-01-31, 12:22:54
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7814337#post7814337
Ich denke die Antwort passt dort nicht, auf dem Aspekt den Herr Stiller dort zumindest in den Raum führt.
Zum einen meint der Autor natürlich die Programme der Pixel Shader als Software. Was den sonst?
Zum anderen geht dieser ja gezielt auf die DIE Größe ein und meint damit natürlich die Möglichkeit, die Lösungen zu skalieren ohne, dass die Tessellationsperformance in das bodenlose stürzt, weil an der Anzahl der Shader dann zwangsläufig gespart werden muss.
Es ist also ein wirtschaftlicher Aspekt, nicht ein Performanceaspekt. Die Frage war "Kann nVidia den Fermi so weit abspecken, dass er von der DIE Größe ein konkurrenzfähiges Produkt darstellt?
Aber darauf geht die Antwort nicht ein.
Aquaschaf
2010-01-31, 12:29:48
Womit werden eigentlich Objekte in CAD gerendert? Rasterizing / Raycasting ist das doch sicher nicht oder?
Zumindest für die "Echtzeit"-Darstellung schon. Das Problem ist ja bei solchen Anwendungen dass du die Daten bearbeitest, unter anderem dann auch eine History der Änderungen behalten musst und eben alles auch für die CPU verfügbar sein muss. Mit Sicherheit weiß ich es nicht, aber ich gehe davon aus dass deswegen bei CAD oder 3D-Modellierungssoftware die CPU und die Hauptspeicherbandbreite den Flaschenhals darstellt, und eventuell die Bandbreite zwischen CPU und GPU.
LovesuckZ
2010-01-31, 12:33:44
Ich denke die Antwort passt dort nicht.
Zum einen meint der Autor natürlich die Programme der Pixel Shader als Software. Was den sonst?
Zum anderen geht dieser ja gezielt auf die DIE Größe ein und meint damit natürlich die Möglichkeit, die Lösungen zu skalieren ohne, dass die Tessellationsperformance in das bodenlose stürzt, weil an der Anzahl der Shader dann zwangsläufig gespart werden muss.
Es ist also ein wirtschaftlicher Aspekt, nicht ein Performanceaspekt. Die Frage war "Kann nVidia den Fermi so weit abspecken, dass er von der DIE Größe ein konkurrenzfähiges Produkt darstellt?"
Aber darauf geht die Antwort nicht ein.
Da nVidia und AMD eine zusammengefasste Rechenarchitektur haben, laufen neben Pixel-, Vertex- und Geometrieshader auch die Domain- und Hullshader darüber. Der Unterschied zwischen nVidia und AMD ist, dass GF100 eine wesentlich höhrere Geometrieleistung erreicht und durch das Aufbrechen einer Setup-Engine mit der Geometrieeinheit in viele kleinere, parallelarbeitende Engines die kleineren Ableger natürlich weniger Leistung haben werden. Das heißt aber auch für AMD, dass Cypress gegenüber Juniper aufgrund der sehr ähnlichen Geometrieleistung sich mit Tessellation nicht um das doppelte absetzen wird. nVidia's kleinere Ableger skalieren dagegen stärker mit der Reduzierung, da alles weniger wird. Nur daraus zu schließen, dass die kleineren Ableger langsamer wären, ist ziemlich lächerlich. Immerhin hätte ein 1/4 GF100 noch 4 Geometrieeinheiten und eine Setup-Engine. Also genausoviel wie Cypress...
Nighthawk13
2010-01-31, 13:25:40
Noch 2 interessante Artikel:
http://www.behardware.com/articles/782-1/nvidia-geforce-gf100-the-geometry-revolution.html
http://www.behardware.com/articles/772-1/nvidia-fermi-the-gpu-computing-revolution.html
Verständnisfrage zu den Textureinheiten:
Benutzen die tatsächlich die Load/Store-Units des Multiprozessors? Oder haben die eigene Load-Units? Da es sowohl L1 als auch Texturcache gibt, dachte ich letzteres.
Es ist also ein wirtschaftlicher Aspekt, nicht ein Performanceaspekt. Die Frage war "Kann nVidia den Fermi so weit abspecken, dass er von der DIE Größe ein konkurrenzfähiges Produkt darstellt?
Das sollte zumindest theoretisch wesentlich einfacher möglich sein, als mit früheren Architekturen.
Da nun große Teile des Chips skaliert werden können, sollte 1/2er Fermi eigentlich kaum mehr als die Hälfte der Transistoren benötigen, im gegensatz zu früheren Architekturen, wo der halbe Highend-Chip in der Regel ca. 2/3 der Transistoren benötigt.
Wenn man dann auch noch die DP-Fähigkeit weglässt könnte man noch mehr einsparen, ohne dass die 3D-Leistung beeinträchtigt wird.
Nevermore4ever
2010-01-31, 18:27:57
Wenn ich mich nicht irre, waren ja die letzten Chips von nVidia auch immer etwas größer als die von ATI, was die Ausbeute verschlechtert.
Gerade bei solchen Aufbauten, die intern die gleichen Strukturen mehrfach wiederholen, frage ich mich aber immer, warum man dann nicht gleich kleinere Chips kreiert und sie "zusammenklebt" - also die "Ableger" zum Hauptchip macht (so ein Konzept war ja bei ATI auch mal im Gespräch).
Woran mag es liegen? Meine Ideen:
Es ist nicht möglich, so kleine Strukturen so zu verbinden, dass die Latenzen ins Unermessliche steigen (warum?)
Es ist egal, weil nVidia Chips, die nicht funktionieren, nicht bezahlen muss
...
Was stimmt, was stimmt nicht, was fehlt?
Wilhelm
2010-01-31, 18:48:41
Ich denke dass das nicht so einfach ist. Du würdest mehr Fehlerquellen an den Verbindungen schaffen und du brauchst dann ja auch z.B. auch eine Technik die genügend Bandbreite zwischen den Chips bringt.
Avalox
2010-01-31, 18:51:26
Es ist egal, weil nVidia Chips, die nicht funktionieren, nicht bezahlen muss
Dieser Grund wird es bestimmt nicht sein. Weil nVidia diese Fehlproduktionen immer entweder direkt, oder eben mit den funktionierenden Bausteinen indirekt bezahlt.
Natürlich kann das Risiko auf dem Hersteller übertragen werden, aber wenn dieser nichts mehr verdient muss er zumachen und kann keine Bausteine mehr für nVidia fertigen. Das Risiko wird nur auf alle Kunden verteilt. NVidia profitiert von einer hohen Ausbeute auch bei einer Auftragsproduktion.
Spasstiger
2010-01-31, 19:32:36
Bezahlt werden ganze Wafer, nicht einzelne Chips. Aber gehört die Fertigungsdiskussion wirklich hier rein? Ich denke, hier geht es um die Prozessorarchitektur des GF100/Fermi.
Gipsel
2010-01-31, 19:53:56
OK. Also liegen die TAs (bildlich gesprochen) noch vor den TFs und auch vor den L/S-Einheiten?
Also vom Ablauf her: TA->L/S-Einheiten->TF
Jup.
Verständnisfrage zu den Textureinheiten:
Benutzen die tatsächlich die Load/Store-Units des Multiprozessors? Oder haben die eigene Load-Units? Da es sowohl L1 als auch Texturcache gibt, dachte ich letzteres.
@Nighthawk:
So sehe ich das auch. Die L/S-Einheiten machen wahrscheinlich nur die (einfache) Adressierung im L1/global memory für Compute Shader. Da das einfacher linearer Speicher ist und die eigentlichen Koordinaten sowieso vom Shadercode selbst berechnet werden, ist da praktisch kaum was zu tun (weswegen ein SM auch 16 x 4 Byte pro Takt im L1 adressieren kann).
Für Grafikanwendungen und Zugriff auf Texturdaten reichen die L/S-Einheiten aber die Anforderungen an die TAs weiter. Nach der dort erfolgten (deutlich aufwendigeren) Adressberechnung für Texturdaten (für 4offset_gather4 mit doppelter Rate) werden dann durch die Texture-Sampler (oft auch Texture-Fetch genannt, wodurch es zu Verwechselungen mit den Filtereinheiten bei Verwendung der Abkürzung TF kommt) die Samples aus dem Texture-L1 gelesen (oder eben L2/Speicher), an die Filtereinheiten gegeben und schließlich über die L/S-Einheiten in die entsprechenden Register des SMs geschrieben.
Das sieht also schematisch so aus:
L/S (Anforderung eines gefilterten Texels für Koordinaten u,v) -> TA (Berechnung der Speicheradresse/Gradienten für diese Texturkoordinaten) -> Sampler (Lesen der benötigten Samples) -> Filter (Verrechnen der Samples zu einem gefilterten Texel) -> L/S (Schreiben des Wertes in ein Register)
Die Load-Store-Einheiten "sehen" also nur die Anzahl der angeforderten (gefilterten) Texel und nicht die dafür notwendigen Samples. Alles andere macht nicht wirklich Sinn in meinen Augen.
Dann hätte man in den Block-Diagrammen auch irgendwo separate TMUs eingezeichnet Gipsel. Es ist ja nicht so als wäre das unwichtig.
Separate Load-Store-Einheiten nur um Daten zu laden macht bei einer 3D-Architektur einfach keinen Sinn. In einem Shader werden praktisch nur Texturen gesampled.
Gipsel
2010-01-31, 23:28:28
Dann hätte man in den Block-Diagrammen auch irgendwo separate TMUs eingezeichnet Gipsel. Es ist ja nicht so als wäre das unwichtig.Hmm, also ich sehe da welche in nvidias Fermi graphics architecture whitepaper (Seite 16). Ganz klar TMUs dort zu sehen. Der Text dazu lautet dann:
Each SM has four texture units. Each texture unit computes a texture address and fetches four texture
samples per clock. Results can be returned filtered or unfiltered. Bilinear, trilinear, and anisotropic filtering modes are supported.Die TAs sind also ganz offensichtlich Teil der extra eingezeichneten TEX-Einheiten und nicht der L/S-Einheiten. Wie gesagt, was anderes würde aus meiner Sicht vom Design her auch keinen Sinn machen.
Separate Load-Store-Einheiten nur um Daten zu laden macht bei einer 3D-Architektur einfach keinen Sinn. In einem Shader werden praktisch nur Texturen gesampled.
Tja, man hat ja sogar einen separaten Texture-Cache. Wenn das alles über die gleichen Einheiten laufen würde, hätte man auch nur einen einzigen L1-Cache. Ein Compute-Shader lädt praktisch immer ungefilterte Daten. Es macht dort also aus nvs Sicht offensichtlich Sinn 16 einzeln adressierbare Fetches (pro hot clock Takt) nur für diesen Zweck zuzulassen. Das ist aus den erwähnten Gründen ja auch einfacher als 16 Textur-Adressen pro Takt aufzulösen. Fermi kann also 16 Adressen pro (hot clock) Takt aus dem linearen Speicherbereich (GP-L1) ansprechen, 4 gefilterte Texel pro Takt oder 8 ungefilterte Texel pro Takt (4offset_gaher4) oder wahrscheinlich vier 2x2 Blöcke ungefilterte Texel (das normale gather4 mit nur 4 individuellen Adressen) pro Takt getrennt adressieren. Wie hoch dann der Takt fürs Filtern und die TAs ist, das ist noch eine Frage.
Ich hab's mir auch mal angeschaut.
Trotzdem bin ich da noch nicht sicher an dem Punkt. Blockdiagramme können Schall und Rauch sein, das weißt du auch. Aber der separate Texture-Cache ist natürlich ein wunder Punkt meiner These ;)
Kommt dir Frage auf ob Texturen auch mit globalen Adressen angesprochen werden können.
Woran mag es liegen? Meine Ideen:
Fermi kann intern wohl mehrere TB/s hin und herschieben. Über mehrere DIEs wird diese Bandbreite kaum verfügbar sein.
Gipsel
2010-02-01, 00:10:43
Kommt dir Frage auf ob Texturen auch mit globalen Adressen angesprochen werden können.
Also ich weiß nicht, wie das mit CUDA 3.0 wird, aber bisher ist das strikt getrennt. Ich bezweifle auch ein wenig, daß das gehen wird, da auf die Texturdaten eigentlich nur mit den Textureinheiten zugegriffen werden kann, da die ja auch noch die Dekomprimierung beim Zugriff durchführen müssen. Die komprimierten Texturformate sind ja praktisch transparent für den eigentlichen Shadercode. Obwohl sowas prinzipiell nur eine Optimierungsaufgabe für den Treiber/Shadercompiler ist (wenn nur Pointsampling und unkomprimierte Textur -> ab in den globalen Speicher). Dazu kommt dann noch das andere Layout der Texturen im Speicher, also gleichzeitiger Zugriff über Textur und globalen Speicher wird meiner Meinung nach vielleicht schwierig (obwohl nv sowas mit dem Speichermanagement Fermis eigentlich im Prinzip versprochen hat), aber das wird man sehen müssen.
Ich bezweifel es auch. Hilft wohl nur noch abwarten was das Thema angeht.
Nighthawk13
2010-02-01, 00:46:31
Kommt dir Frage auf ob Texturen auch mit globalen Adressen angesprochen werden können.
In Cuda 2.3 kann man 1D Texturen aus einem linearen Speicherabschnitt erstellen und diese mit int oder float adressiert auslesen(Und profitiert so vom Textur-Cache).
Den zugrunde liegenden Speicherbereich kann man weiterhin lesen und schreiben, aber die Textur-Caches werden nicht geflusht!
D.h. Kernel0 schreibt die Daten ins Speicher, Kernel1 liest via Textur geht.
Das Speicherlayout von 2D-Texturen ist nicht offen gelegt, jedenfalls sind die Texturen nicht einfach zeilenweise hinterlegt wie ich schon feststellen musste :redface:
Nachtrag zum Texturmapping:
http://www.slideshare.net/Mark_Kilgard/sigraph-asia-2008-modern-opengl-presentation
(Slides 146-169)
Ailuros
2010-02-01, 05:31:08
Bezahlt werden ganze Wafer, nicht einzelne Chips. Aber gehört die Fertigungsdiskussion wirklich hier rein? Ich denke, hier geht es um die Prozessorarchitektur des GF100/Fermi.
Gehoert tatsaechlich nicht hier in diese Debatte rein aber beide IHVs bezahlen im strengen Sinn weder pro wafer noch pro chip. Pro wafer waere wohl alles zu Gunsten TSMC und pro chip alles zu Gunsten IHVs.
Ich denke die Antwort passt dort nicht, auf dem Aspekt den Herr Stiller dort zumindest in den Raum führt.
Zum einen meint der Autor natürlich die Programme der Pixel Shader als Software. Was den sonst?
Programmierbare hardware ist unter keinem verdrehtem Konzept oder Perspektive "software". Wenn es sich wirklich um eine echte sw Emulation handeln wuerde haette man auch nicht fuer 4 (ff) raster Einheiten mit theoretisch bis zu 4 Tris pro Takt gesorgt.
Zum anderen geht dieser ja gezielt auf die DIE Größe ein und meint damit natürlich die Möglichkeit, die Lösungen zu skalieren ohne, dass die Tessellationsperformance in das bodenlose stürzt, weil an der Anzahl der Shader dann zwangsläufig gespart werden muss.
Eine 5770 verliert heute mit Tesselation "on" weniger Leistung als ohne im Vergleich zu einer 5870. Es waere ein netter Anhaltspunkt wenn aber mit Tesselation die 5870 nicht trotzdem um einiges schneller waere am Ende oder anders beim kleineren Modell limitieren zuerst andere Faktoren lange bevor die Tesselation erstmal limitiert. Wenn dann die 5870 knapp unter 60fps liegt ohne Tesselation und die 5770 knapp unter 30fps, dann ist zwar der geringe Leistungsverlust durch Tesselation fuer die 5770 interessant aber es bringt wohl in Echtzeit nicht besonders viel.
***edit: zwar ein synthetisches techdemo aber es illustriert sehr schoen die obrige Logik: http://www.pcgameshardware.com/aid,698077/Unigine-Heaven-with-DirectX-11-Tessellation-Graphics-card-benchmarks-Top-article-of-October-2009/Practice/
Und nein dieses ist nicht die "Entschuldigung" fuer das architektur-Layout von Fermi. GF100 hat 4 raster Einheiten, wobei jede raster Einheit jeweils 4 SMs/clusters zusteht.
Enthusiast:
5970 = 2*2 raster units, 2*1 ff Tesselations-Einheiten, 2*334mm2
GF380 = 4 raster units, 16 "mini" Tesselations Einheiten auf jeden SM verteilt, ~550mm2
Von da ab skalieren nun beide nach unten. Ein "halber GF100" mit 256SPs soll sich irgendwo leicht unter 58x0 Nivaeu platzieren koennen und es sind dann 2 raster units, 8 mini Tesselations Einheiten und eine eingeschaetzte die area von 350-380mm2. Cypress aka 58x0 hat dann auch 2 raster units bei 334mm2 und kann in Echtzeit nicht mehr als 1Tri/Takt bearbeiten eben weil manche andere Faktoren wie z.B. trisetup limitieren.
Es ist also ein wirtschaftlicher Aspekt, nicht ein Performanceaspekt. Die Frage war "Kann nVidia den Fermi so weit abspecken, dass er von der DIE Größe ein konkurrenzfähiges Produkt darstellt?
Aber darauf geht die Antwort nicht ein.
Selbst mit 1/4 GF100 oder noch kleiner wird stets zumindest 1 Tri/Takt moeglich sein genauso wie auf allen kleinen Evergreen Varianten. Da das trisetup auf allen GF100 auf 1/2 hot clock laeuft rechne mal mit 1, 2, 3 oder sogar 4 Dreiecken pro Takt mit einem verdammt konservativen hot clock von zumindest 1.4GHz (GF100 bei theoretischen 1.4GHz dann 2.8B Tris/clock, 1/2 GF100 bei gleicher Frequenz 1.4B Tris/clock wobei je kleiner die Variante desto hoeher die Frequenzen). Evergreen's momentane hoechste Frequenz liegt bei 850MHz und von da ab muss man Echtzeit-Leistung von der theoretischen Maximal-leistung trennen und was und wieso jeweils limitieren koennte. Bei einem mini GF100 limiert das trisetup erstmal fuer Tesselation nicht, was erstmal keine gute Indizie ist dass bei diesem die Tesselations-Leistung ungewoehnlich niedrig sein koennte.
One of the possible limiting factors on tessellation was the rasteriser, since one could imagine that beyond a certain amplification factor triangle setup/raster rate would become a bottleneck. To ensure this was not the case, it initially seemed like ATI had chosen a rather simple solution: the addition of another setup and raster unit! This would have allowed them to (theoretically) fetch 32 vertex attributes from memory per cycle and setup 2 full triangles per cycle for a theoretical rate of 1.7GTris/s at the 5870's clock rate of 850Mhz. Practically, things proved to be slightly different: after banging our heads against an ~830 MTris/s rate, which we couldn't surpass irrespective of how simple our triangles were, or how we fed the hardware, we checked back and it appears that triangle setup rate hasn't been bumped up, remaining at the good old 1 triangle/cycle (we can see certain reasons for it). So, in practice, we're dealing with a fatter rasteriser with doubled scan conversion rate, but constant triangle setup rate.
http://www.beyond3d.com/content/reviews/53/6
Aber wenn man so etwas einem Charlie sagen wuerde, wuerde mich eine Antwort in der Art dass auch trisetup und rasters in "sw" laufen nicht wundern. Alles was Charlie versucht in neueren Artikeln ist den Quark hier vom Mai 2009 zu gerechtfertigen: http://www.theinquirer.net/inquirer/news/1137331/a-look-nvidia-gt300-architecture
Um Missverstaendnissen zu entgehen: es gibt stets sehr grosse Unterschied zwischen theoretischen maximalen Papierzahlen und Echtzeit-Effizienz. Cypress "verspricht" auf Papier eigentlich nicht mehr als 850M Tris/clock (obwohl man auf ersten Blick schnell auf 1.7 Mrd Tris/clock schliessen koennte) und bei erreichten 830M Tris ist man verdammt nahe am theoretischem Maximum. Fermi wird wohl nie dank anderer Limitierungen in Echtzeit die 4 Tris/Takt erreichen koennen; selber geben sie eine maximal erreichbare Rate von ca. 3,2x Tris/clock an. Und ja natuerlich fehlen uns noch die realen unabhaengige Tests dafuer. Fuer adaptive Tesselation braucht man jedoch eine sehr gute Effizienz fuer sehr viele und sehr kleine Dreiecke und gerade dort soll Fermi gut positioniert sein und nicht dass die nicht tesselierte Dreieckrate in kommenden Spielen auf irgendwelche abnormale Hoehen skaliert.
Das Trisetup ist eh nicht das Problem. Das würde erst dann limitieren wenn man sehr viele Dreiecke rendert die gar nicht sichtbar sind. Ich schreib gerade an einem Artikel der es hoffentlich etwas verständlicher macht.
Es ist auch mit einer Trisetup-Rate von 1 Tri/Clock keine schlechte Idee mehrere Rasterizer zu haben. Zwischen Trisetup und Rasterisierung steckt ja noch ein FIFO.
Bucklew
2010-02-01, 20:39:19
Eine 5770 verliert heute mit Tesselation "on" weniger Leistung als ohne im Vergleich zu einer 5870. Es waere ein netter Anhaltspunkt wenn aber mit Tesselation die 5870 nicht trotzdem um einiges schneller waere am Ende oder anders beim kleineren Modell limitieren zuerst andere Faktoren lange bevor die Tesselation erstmal limitiert. Wenn dann die 5870 knapp unter 60fps liegt ohne Tesselation und die 5770 knapp unter 30fps, dann ist zwar der geringe Leistungsverlust durch Tesselation fuer die 5770 interessant aber es bringt wohl in Echtzeit nicht besonders viel.
***edit: zwar ein synthetisches techdemo aber es illustriert sehr schoen die obrige Logik: http://www.pcgameshardware.com/aid,698077/Unigine-Heaven-with-DirectX-11-Tessellation-Graphics-card-benchmarks-Top-article-of-October-2009/Practice/
50% Chip, aber dennoch 66% der Leistung. Was schon sehr stark für ein Tessellator-Bottleneck spricht. Ist halt das völlig logische Problem eines "nachgerüsteten" chips. Das Problem einer neuen Architektur sehen wir ja an der "Verzögerung" des Fermis.
deekey777
2010-02-01, 21:03:21
50% Chip, aber dennoch 66% der Leistung. Was schon sehr stark für ein Tessellator-Bottleneck spricht. Ist halt das völlig logische Problem eines "nachgerüsteten" chips. Das Problem einer neuen Architektur sehen wir ja an der "Verzögerung" des Fermis.
Wie genau spricht das für einen Tessellator-Bottleneck?
Er meint wohl Rasterisierung.
Ailuros
2010-02-02, 05:49:19
Das Trisetup ist eh nicht das Problem. Das würde erst dann limitieren wenn man sehr viele Dreiecke rendert die gar nicht sichtbar sind. Ich schreib gerade an einem Artikel der es hoffentlich etwas verständlicher macht.
Moment in einer Szene mit einem logischen Grad von Tesselation kann es wohl nicht vorkommen dass man keine nicht sichtbare Dreiecke hat oder? Was verpass ich gerade?
Es ist auch mit einer Trisetup-Rate von 1 Tri/Clock keine schlechte Idee mehrere Rasterizer zu haben. Zwischen Trisetup und Rasterisierung steckt ja noch ein FIFO.
Ich verstehe bisher dass bei Cypress eben gerade die dual rasterizer bei ueberdeckter Geometrie helfen. Und hiermit bin ich natuerlich im Zusammenhang zum obrigen total verwirrt. Ein Artikel waere schoen.
Moment in einer Szene mit einem logischen Grad von Tesselation kann es wohl nicht vorkommen dass man keine nicht sichtbare Dreiecke hat oder? Was verpass ich gerade?
Och man rendert schon ein paar Dreiecke die gar nicht im Sichtbereich sind oder so klein dass sie kein Sample treffen.
Bucklew
2010-02-02, 19:12:34
Wie genau spricht das für einen Tessellator-Bottleneck?
Weil ohne Tessellation der Vorsprung zwischen 50% und 100% Chip plötzlich da ist:
http://www.pcgameshardware.de/aid,697176/Ati-Radeon-HD-5770-im-Test-DirectX-11-Mittelklasse/Grafikkarte/Test/?page=10
Das Tesselation die Sache verschlimmert ist nur ein Symptom, aber nicht die Ursache.
Das Tesselation die Sache verschlimmert ist nur ein Syndrom, aber nicht die Ursache.
du meintest Symptom oder?
Dingens
2010-02-02, 21:26:06
Hab mal ne Frage, wie genau soll sich denn das Speichermanagement beim GF100 verändern und wo liegt eigentlich der Unterschied aktuell zwischen NV und Ati bei der Speicherverwaltung. Nv Karten benötigen ja anscheinend mehr Speicher als die Ati Karten...
Dingens
2010-02-02, 21:45:35
Und jetzt bitte eine korrekte, technische Antwort xD
Hab irgendwo mal gelesen dass Nv ab dem G80 Texturen immer in den Speicher vor lädt und Ati hier eher ein Streaming Verfahren hat, stimmt das?
y33H@
2010-02-02, 21:57:37
Da ist idR ähnlich viel im Speicher, alles ab G80 bis GT200(b) kann aber im Gegensatz zu R600 bis RV870 und GF100 nicht direkt ins RAM adressieren usw.
Da ist idR ähnlich viel im Speicher, alles ab G80 bis GT200(b) kann aber im Gegensatz zu R600 bis RV870 und GF100 nicht direkt ins RAM adressieren usw.
Ist es gesichert dass das wieder geht bei GF100? Zu erwarten wäre es.
Dingens
2010-02-02, 22:23:16
Da ist idR ähnlich viel im Speicher, alles ab G80 bis GT200(b) kann aber im Gegensatz zu R600 bis RV870 und GF100 nicht direkt ins RAM adressieren usw.
Sprich man hat hier Vorteile bei AA und hohen Auflösungen?
y33H@
2010-02-02, 22:43:08
@ Coda
Japp, per doppelter DMA-Engine.
http://www.abload.de/thumb/2010-02-02_224216u6nq.png (http://www.abload.de/image.php?img=2010-02-02_224216u6nq.png)
EDIT
Was heißt wieder? Alles ab G80 konnte es iirc nicht ("VRAM-Bug"), G70 liegt zu weit zurück, als das ich dieses Detail noch wüsste :usad:
Sprich man hat hier Vorteile bei AA und hohen Auflösungen?Sofern dies zum Überlaufen des VRAMs führt - ja. Das wird recht gut gepuffert.
pervert
2010-02-03, 00:09:03
Sofern dies zum Überlaufen des VRAMs führt - ja. Das wird recht gut gepuffert.
Kannst Du das genauer ausführen?
Wie will man sowas puffern? Fände ich aber toll, wenn der GF100 weniger Speicherprobleme haben würde.
y33H@
2010-02-03, 01:52:53
@ pervert
Simpel ausgedrückt ist es schneller die Daten direkt im RAM zu adressieren usw., als diese erst per PCI-E in den VRAM zu schaufeln und dann damit weiter zu arbeiten.
@ Coda
Japp, per doppelter DMA-Engine.
Das hat damit aber sehr wenig zu tun. Vor allem das Bild passt überhaupt nicht zu einer möglichen Lösung.
y33H@
2010-02-03, 10:01:14
Ja, das Bild taugt nicht :usad: Carsten fragen *hust*
EDIT
OK, Carsten meint, er hats wohl erfragt.
y33H@
2010-02-03, 15:03:12
BT: GForce laden erstmal ihren Vram voll und müssen dann "Auslagern" ins normale RAM.Ehem - nein. Tools und Architekturdetails sprechen dagegen. Falls du Quellen hast, die das Gegenteil behaupten - die würde ich gerne sehen.
Dural
2010-02-03, 15:20:50
hmmm das macht doch jede karte so, wie soll es den sonst anders gehen...
Die daten können ja nicht einfach verschwinden wenn der speicher voll ist.
Die ATI "leiden" darunter genau so zb. in Crysis bei bestimmten Einstellungen hast du regelmässig ein schönes ruckeln mit einer 512MB Karte (zb. 4870)
Wie schonmal gesagt, ist das Problem, dass Chips auf Basis der G80-Architektur nicht eigenständig aus dem PCIe-Aperture-Memory lesen können.
Stattdessen muss der Treiber wenn der Speicher volläuft die Daten austauschen, oder wenn es nicht geht abstürtzen.
Es ist deutlich schneller Texturen die nicht mehr ins VRAM passen in den Hauptspeicher auszulagern und es den Chip übernehmen zu lassen darauf zuzugreifen anstatt jedes Mal kostspielig Speicher umzukopieren.
dildo4u
2010-02-03, 15:37:39
hmmm das macht doch jede karte so, wie soll es den sonst anders gehen...
Die daten können ja nicht einfach verschwinden wenn der speicher voll ist.
Die ATI "leiden" darunter genau so zb. in Crysis bei bestimmten Einstellungen hast du regelmässig ein schönes ruckeln mit einer 512MB Karte (zb. 4870)
Jo oder gerade bei der BFBC2 Beta von 4 auf 8XAA total Zusammenbruch.(4850 512mb)
Der Effekt ist aber tatsächlich bei weitem nicht so schlimm.
Wie schonmal gesagt, ist das Problem, dass Chips auf Basis der G80-Architektur nicht eigenständig aus dem PCIe-Aperture-Memory lesen können.Trifft das nicht nur auf die TMUs zu? Meine mich im Zusammenhang mit Downsampling + AA an Fälle zu erinnern, in denen bereits Backbuffer + Zbuffer das VRAM sprengen. IIRC Screenshots von Raff aus Jedi Knight 2?
Es ist deutlich schneller Texturen die nicht mehr ins VRAM passen in den Hauptspeicher auszulagern und es den Chip übernehmen zu lassen darauf zuzugreifen anstatt jedes Mal kostspielig Speicher umzukopieren.
So machen das Ati-Karten und der GF100 zukünftig auch?
Der Performancevorteil (bei aktiviertem AA) bei Ati kommt also aktuell durch die Möglichkeit den Hauptspeicher direkt anzusprechen.
Wie kommt es dann eigentlich das die Nv Karten, z.B. der G92, von doppeltem Grafikspeicher (z.B. 512Mb auf 1GB) mehr profitieren als Ati-Karten?
So machen das Ati-Karten und der GF100 zukünftig auch?
ATIs machen das so, bei GF100 muss ich mich auf andere Aussagen verlassen.
Der Performancevorteil (bei aktiviertem AA) bei Ati kommt also aktuell durch die Möglichkeit den Hauptspeicher direkt anzusprechen.
Jain. Wenn der VRAM dadurch ausgeht ja, aber es ist auch so schneller.
Wie kommt es dann eigentlich das die Nv Karten, z.B. der G92, von doppeltem Grafikspeicher (z.B. 512Mb auf 1GB) mehr profitieren als Ati-Karten?
Na weil der VRAM eben nicht ausgeht und deshalb die Kopiererei entfällt.
Ahh, danke schonmal :-)
Und wie kommt es das bei Ati der Speicher nicht so schnell voll ist? Bereinigt hier Ati schneller den Speicher oder wird dieser einfach effektiver genutzt?
Weil wenn, nach y33H@, der Speicher immer ähnlich voll ist, müsste die Skalierung doch bei höhere Speichermenge auch ähnlich sein, oder verstehe ich hier was falsch?
Und wie kommt es das bei Ati der Speicher nicht so schnell voll ist? Bereinigt hier Ati schneller den Speicher oder wird dieser einfach effektiver genutzt?
Er wird ähnlich schnell voll, nur ist der Einbruch bei vollem VRAM eben geringer.
Und wie kommt es das bei Ati der Speicher nicht so schnell voll ist? Bereinigt hier Ati schneller den Speicher oder wird dieser einfach effektiver genutzt?Meinem Laienverständnis nach siehts folgendermaßen aus:
Aus einer relativ selten benutzten Textur werden ein paar Texel aus dieser oder jener Mipmap gebraucht. Eine ATI parkt selten genutzte Texturen im Hauptspeicher, weil ihre HW direkt darauf zugreifen und nur die benötigten Texel übertragen kann. Die momentan aktuellen NVs können das nicht, also müssen sie zuerst Platz im VRAM freischaufeln, dann die komplette Textur mitsamt Mipmaps dorthin kopieren und können sie erst dann nutzen.
Und wie kommt es das bei Ati der Speicher nicht so schnell voll ist? Bereinigt hier Ati schneller den Speicher oder wird dieser einfach effektiver genutzt?
Er ist genauso schnell voll, aber das überlaufen macht weniger Probleme.
ATI hat wohl eine Art Cache-Strategie und wechselt damit die Texturen je nach Zugriffsmuster einmal pro Frame. Wenn eine Textur dann nicht im VRAM ist und trotzdem gebraucht wird, dann wird direkt aus dem PCIe-Speicher texturiert. NVIDIA kann das aber nicht und hat damit das Problem dass sie während des Renderns andauernd Texturen tauschen müssen, wenn der VRAM nicht ausreicht.
Der Witz ist, dass das eigentlich uralter Tobak ist. Das war eines der am meisten beworbenen Features von AGP. Alte NVIDIA-Karten vor der GeForce 8 haben das Problem nicht.
pervert
2010-02-03, 18:24:28
Ist das nicht der Grundgedanke von "DMA" im Allgemeinen?
D. h. Geforce 8 kann kein DMA?
Warum nur??
AnarchX
2010-02-03, 18:26:36
Vielleicht ein Grund, weshalb kein Hersteller eine >=G8x mit AGP-Bridge verbaut hat?
Mit einem solch optimierten Speichermanagement, wäre wohl auch eine 192-Bit 768MiB SKU für >=2010 interessant.
Ist das nicht der Grundgedanke von "DMA" im Allgemeinen?
Mit DMA meinen sie wohl eher den Zugriff auf Host-Speicher, nicht auf Aperture-Speicher.
Der Witz ist, dass das eigentlich uralter Tobak ist. Das war eines der am meisten beworbenen Features von AGP. Alte NVIDIA-Karten vor der GeForce 8 haben das Problem nicht.Hehe, kann mich noch gut daran erinnern wie G-Police hochgejubelt wurde weil es als erstes Spiel ausgiebig davon Gebrauch machte.
Welchen technischen Sinn könnte es haben, dass anscheinend nicht die TMUs, dafür aber die ROPs direkten Zugriff auf den Hauptspeicher haben?
Nighthawk13
2010-02-03, 21:06:05
Wie schonmal gesagt, ist das Problem, dass Chips auf Basis der G80-Architektur nicht eigenständig aus dem PCIe-Aperture-Memory lesen können.
Seit Cuda 2.3 kann man aus einem Kernel heraus direkt den Hauptspeicher lesen/schreiben(zerocopy in NV-Marketingslang). Es ist schneller als memcpy und dann aus dem VRam lesen, zumindest wenn im Kernel auch viel gerechnet wird.
Also der (G80/G92/G200)-Chip muss prinzipiell dazu in der Lage sein. Evtl. kann das nur der Multiprozessor direkt, und die Textureinheiten haben ein Problem damit:
http://forums.nvidia.com/index.php?showtopic=157092 (ggf. Google-Cache benutzen)
Also der (G80/G92/G200)-Chip muss prinzipiell dazu in der Lage sein. Evtl. kann das nur der Multiprozessor direkt, und die Textureinheiten haben ein Problem damit
Nutzt G80-G200 nicht die Textureinheiten für den Speicherzugriff (logischerweise ohne Filterung)
Nighthawk13, ich denke es liegt an den TMUs. Texturen im Aperture-Speicher sind nämlich nicht im nativen Format die die GPU gerne hätte.
Die Info hab ich von den Nouveau-Leute, ich denke die sollten das wissen. Außerdem erklärt es das Verhalten einfach sehr gut das man sieht.
Gipsel
2010-02-04, 14:41:54
Seit Cuda 2.3 kann man aus einem Kernel heraus direkt den Hauptspeicher lesen/schreiben(zerocopy in NV-Marketingslang). Es ist schneller als memcpy und dann aus dem VRam lesen, zumindest wenn im Kernel auch viel gerechnet wird.
Also der (G80/G92/G200)-Chip muss prinzipiell dazu in der Lage sein. Evtl. kann das nur der Multiprozessor direkt, und die Textureinheiten haben ein Problem damit:
http://forums.nvidia.com/index.php?showtopic=157092 (ggf. Google-Cache benutzen)
Bei dem Link steht doch nur, daß es nicht funktioniert (wohl irgendein ein Bug). Ich habe zwar mit CUDA nicht viel am Hut, aber wenn ich das richtig sehe, kann man Texturen nur mit device-Pointer verbinden. Der gewünschte Ausweg könnte sich dadurch ergeben, daß man Host-Memory in den Device-Adressraum mappen kann (dies heißt dann auch pinned memory). Allerdings geht das laut Doku nicht mit allen GPUs:
On some devices, page-locked host memory can be mapped into the device’s address space, ...Dummerweise schweigt sich nv beharrlich aus, auf welchen GPUs das geht und auf welchen nicht. Es ist zumindest nirgendwo dort oder bei der Beschreibung der verschiedenen Compute Capabilities beschrieben, wenn ich nichts übersehen habe. Allerdings soll bei einem SDK-Sample noch Genaueres dazu stehen. Wenn Du das bei Dir rumliegen hast, kannst Du ja mal in die Doku zum "zero-copy sample" reinschauen, vielleicht wird man da schlauer.
Nighthawk13
2010-02-04, 20:26:26
Der gewünschte Ausweg könnte sich dadurch ergeben, daß man Host-Memory in den Device-Adressraum mappen kann (dies heißt dann auch pinned memory). Allerdings geht das laut Doku nicht mit allen GPUs:[...]
Ich arbeite an einem Projekt mit mapped hostmem und es funktioniert definitiv auf Geforce8800 und GTX260/275/285 Karten unter XP32 und Win7/64bit.
Kenne keine Konstellation wo es nicht geht, hab aber z.B. keine lowend Karten getestet.
Die Aussage im Nvidia-Forum verstehe ich so, dass Texturzugriffe auf gemappten Hostspeicher evtl. mit Cuda 3.0 gehen werden. Das würde heissen dass das ganze nur ein Treiberproblem ist.
Andererseits, nur das es geht heisst nicht, dass es schneller ist als memcpy und samplen aus dem device-mem;)
@topic: Ich geh mal stark davon aus, das Fermi den "VRAM-Bug" nicht mehr haben wird. Wenn die Nvidia-Entwickler das Problem bei einem Architekturwechsel nicht angehen, wann dann?
Wer sagt, dass es ein Bug war. Es kann auch ein NAchteil der Architektur sein. Allerdings haben sie an Texturekompression etc. ja gearbeitet.
y33H@
2010-02-05, 09:10:33
Daher Bug in Anführungszeichen. De facto ist es ein Nachteil im Sinne eines nicht (vollständig?) unterstützten Features, welches sich umgangssprachlich als "VRAM-Bug" etabliert hat. Warum NV das bei G80 bis heute so gemacht hat - kA. Ärgerlich aber ists imo.
Wer sagt, dass es ein Bug war. Es kann auch ein NAchteil der Architektur sein. Allerdings haben sie an Texturekompression etc. ja gearbeitet.
Man kann davon ausgehen, dass es ein Designfehler ist.
Sonst hätte man Das schon früher gefixt.
Ich glaube nicht das Das beim GF100 wieder der Fall sein wird, da man ja sowieso größere Änderungen im Design vorgenommen hat.
Da ist idR ähnlich viel im Speicher, alles ab G80 bis GT200(b) kann aber im Gegensatz zu R600 bis RV870 und GF100 nicht direkt ins RAM adressieren usw.Ich dachte, das wäre Voraussetzung für D3D10-Compliance?
Man kann davon ausgehen, dass es ein Designfehler ist.
Kein Fehler, eher ein gewollter Tradeoff. Es betrifft ja nur Texturen. Vertexdaten können durchaus aus dem Aperture-Speicher kommen.
Man spart dadurch Logik, weil man nur noch native Texturformate unterstützen muss. Falls es ein Bug gewesen wäre, hätte man ihn in späteren Revisionen der Architektur auch behoben.
y33H@
2010-02-06, 17:15:36
@ aths
Ob dem so ist, weiß ich nicht aus dem Kopf, muss ich erst schauen.
Ich dachte, das wäre Voraussetzung für D3D10-Compliance?
D3D10 schreibt nicht vor wie etwas umgesetzt werden muss.
Wenn es für die Software so aussieht als könne direkt auf den Speicher zugegriffen werden, der Treiber aber in Wirklichkeit herumkopiert ist es immer noch in Ordnung.
Kein Fehler, eher ein gewollter Tradeoff. Es betrifft ja nur Texturen. Vertexdaten können durchaus aus dem Aperture-Speicher kommen.
Man spart dadurch Logik, weil man nur noch native Texturformate unterstützen muss. Falls es ein Bug gewesen wäre, hätte man ihn in späteren Revisionen der Architektur auch behoben.
könnte da nicht der Treiber animiert werden alle Texturen im "nativen" Format in den Hauptspeicher zu klatschen, wenn das nur ein "formatproblem" ist?
oder belastet das die PCIe 16x bandbreite zu stark?
deekey777
2010-02-22, 23:08:37
Das Trisetup ist eh nicht das Problem. Das würde erst dann limitieren wenn man sehr viele Dreiecke rendert die gar nicht sichtbar sind. Ich schreib gerade an einem Artikel der es hoffentlich etwas verständlicher macht.
Es ist auch mit einer Trisetup-Rate von 1 Tri/Clock keine schlechte Idee mehrere Rasterizer zu haben. Zwischen Trisetup und Rasterisierung steckt ja noch ein FIFO.
http://www.beyond3d.com/content/reviews/54/9
Moving onwards from the domain shader, we find that, on average, for 15% of the render time the pipeline is stalled by rasterisation (setup included here), meaning that the domain shader can output processed vertices and the primitive assembler can assemble them faster than they can be setup and rasterised. This is a consequence of having numerous small triangles in the scene (just look at something like the dragon's leg or the roof), and is one of the cases where upping setup rate beyond 1 triangle/clock could have helped (we're pretty sure the rasteriser itself isn't the one causing the stalls, given pixel/triangle ratios).
Und hier ein Seitenhieb:
One thing worth noting is that between 60 and 80(!)% of these primitives get culled, which doesn't strike us as terribly efficient: you've just hammered the GPU with some heavy tessellation, generated a sea of triangles out of which a huge portion won't be used since they're back facing, or 0 area for example. It's a clear indication that performance must be traded for final image quality with tessellation, as with any other facet of real-time graphics.
Das Heaven-Demo verwendet soweit ich weiß auch kein Shadowmapping sondern nur SSAO (was auch seine Zeit braucht und wobei gar nicht rasterisiert wird - geschenkt). Da wäre das Problem ohne Shading sehr viel schlimmer. Wenn schon im Fall mit Shading 15% Stalling bei so einem Polycount auftritt, dann geht das eigentlich ziemlich mit dem konform was ich so gerechnet habe.
Sagen wir sie brauchen 10 Takte (und das wäre wenig) pro schattiertem Pixel, was glaubst du wie das dann bei Shadowmapping aussieht mit 1 Takt in den ALUs?
Und das ist ein serielles Bottleneck, d.h. wenn man das Frontend weiter so lässt, dann würden bei einer sonst doppelt so breiten Architektur statt 15% schon 26% ins Nichtstun verschwenden. Bei einer 8x so breiten sogar 58%.
Crysis hat auch Polycounts (sieht man auch im Wireframe) die darauf schließen lassen dass die Dreiecke sogar oft noch kleiner sind als bei der Heaven-Demo. Und das *macht* Shadow-Mapping mit dem vollen Polycount, d.h. dieser Teil des Renderings ist wohl auch auf einer GTX285 schon äußerst brutal raster-limitiert. Der Chip könnte theoretisch 128 Zixel/Takt rausklatschen, aber das macht der Rasteriser bei Crysis nie. Da kann man wohl in Durchschnitt mit 10 Pixel/Takt aus dem Frontend rechnen - weil Buffer auch einiges auffangen wenn mal größere Dreiecke dazwischen sind.
Ob bei Fermi der Schritt mit mehreren Rasierern err Rasterisierern schon unbedingt nötig war, oder es die Geeks einfach unbedingt wollten sei dahingestellt. Aber das ist wichtig für die nächsten Jahre.
Ailuros
2010-03-03, 13:33:48
Ich will keinen getrennten Thread dazu aufmachen aber was haltet Ihr von dem hier?:
http://graphics.stanford.edu/papers/mprast/
Coda, Gipsel oder Demi? ;)
Chris Lux
2010-03-03, 14:30:31
Ich will keinen getrennten Thread dazu aufmachen aber was haltet Ihr von dem hier?:
http://graphics.stanford.edu/papers/mprast/
Coda, Gipsel oder Demi? ;)
das ganze ist super interessant. leider ist das paper und auch der vortrag letztes jahr sehr von larrabee propaganda durchsetzt. leider nur sehr theoretisch
Geht's da um sowas wie Reyes?
Chris Lux
2010-03-03, 14:49:50
im grunde um die rasterisierung der durch REYES entstehenden sub-pixel großen polygone.
Muss ich mir mal genauer durchlesen.
Ailuros
2010-03-03, 14:59:26
das ganze ist super interessant. leider ist das paper und auch der vortrag letztes jahr sehr von larrabee propaganda durchsetzt. leider nur sehr theoretisch
Research (ueberhaupt von einer Uni wie Standford) ist doch Theorie so oder so ;)
deekey777
2010-03-17, 12:17:58
Frage:
Ist die Tri-Setup-Rate immer gleich, oder nur bei Tessellation ~ 4 Tris/Takt?
Dürfte ziemlich sicher immer gleich sein.
mal reine Spekulation an die Experten.
Ist es großer Aufwand die Recheneinheiten wieder um das "fehlende" MUL aufzurüsten oder gar gegen ein weiteres MADD?
Spasstiger
2010-03-23, 21:12:16
Was willst du da aufrüsten? Wenn man mehr Rechenleistung haben will, baut man mehr GPCs dran. Alles andere würde die neue Architektur ad absurdum führen.
die CUDA-Cores oder wie auch immer NV sie jetzt nennt.
G80,G92,GT200 hatten doch ein MADD+MULL GF100 hat nur noch ein MADD.
Jetzt meine Frage könnte man wieder die Kombination MADD+MUL einführen oder gar MADD+MADD?
http://www.hexus.net/content/item.php?item=23008
Hexus hat vielleicht mit MADD+MUL gerechnet oder?
Ist es großer Aufwand die Recheneinheiten wieder um das "fehlende" MUL aufzurüsten oder gar gegen ein weiteres MADD?
Wird nicht passieren. Das funktioniert nicht mehr zusammen mit dem neuen Dual Warp-Scheduling. Ist aber auch nicht weiter schlimm, weil es sowieso so gut wie nichts gebracht hat.
Was NVIDIA braucht ist einfach entweder eine vernünftige Die-Size oder den angestrebten hohen Takt.
Spasstiger
2010-03-23, 22:39:42
Das MUL war vom G80 bis zum GT200 auch nur extra drin, weil man es für Special Functions brauchte. Aus der Not hat man dann eine Tugend gemacht und es als General-Purpose-ALU zur Verfügung gestellt (mit dem Nachteil, dass dann an dem entsprechenden Port keine Special Function möglich ist, solange ein General-Purpose-MUL berechnet wird).
Mal zum Thema Tessellation: Manche User wie LovesuckZ glauben ja, dass die Tessellations-Implementierung von ATI so unglaublich rückständig ist und der GF100 mit seinen vier 16 Tessellatoren leistungstechnisch in anderen Sphären schwebt. Aber die Tessellatoren alleine nützen einem recht wenig, denn den optischen Gewinn gibts erst durch den programmierbaren Anteil, der in den Streamprozessoren abgearbeitet wird.
So sieht es z.B. aus, wenn man einfach nur ein Drahtgittermodell durch den Tessellator jagt:
http://www.abload.de/img/tess0l53k.png -> http://www.abload.de/img/tess1fu9e.png
Wenn man die Texturen dazu rendert, besteht faktisch kein Unterschied zwischen den Bildern. Erst mit Displacement Mapping in den Streamprozessoren (Domain Shader Stage) wird die ganze Aktion sinnig:
http://www.abload.de/img/tess2u5oz.png
Man könnte auch Displacement Mapping ohne Tessellation durchführen, was aber recht bescheiden aussieht, wenn das Grundmesh nicht genug Eckpunkte hat:
http://www.abload.de/img/tess3y65x.png
deekey777
2010-03-23, 23:02:22
Es sind 16 Tessellatoren.
Das MUL war vom G80 bis zum GT200 auch nur extra drin, weil man es für Special Functions brauchte. Aus der Not hat man dann eine Tugend gemacht und es als General-Purpose-ALU zur Verfügung gestellt (mit dem Nachteil, dass dann an dem entsprechenden Port keine Special Function möglich ist, solange ein General-Purpose-MUL berechnet wird).
Könnte man sonst irgendwie mehr Flops aus den ALUs holen? außer den Takt zu erhöhen?
AnarchX
2010-03-23, 23:11:46
Könnte man sonst irgendwie mehr Flops aus den ALUs holen? außer den Takt zu erhöhen?
Wozu mehr FLOPs, die ALU-Leistung ist im Vergleich zum Rest schon ziemlich hoch. Wie Coda sagt muss Nvidia es bei der 28nm Generation schaffen, die Einheiten deutlich dichter zu packen und gleichzeitig aber auch den Takt erhöhen.
Noch weiter in der Zukunft scheint man wohl die Zahl der FPUs auf 3 pro CUDA Core zu erhöhen wollen:http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7623791#post7623791
LovesuckZ
2010-03-23, 23:15:42
Das MUL war vom G80 bis zum GT200 auch nur extra drin, weil man es für Special Functions brauchte. Aus der Not hat man dann eine Tugend gemacht und es als General-Purpose-ALU zur Verfügung gestellt (mit dem Nachteil, dass dann an dem entsprechenden Port keine Special Function möglich ist, solange ein General-Purpose-MUL berechnet wird).
Mal zum Thema Tessellation: Manche User wie LovesuckZ glauben ja, dass die Tessellations-Implementierung von ATI so unglaublich rückständig ist und der GF100 mit seinen vier 16 Tessellatoren leistungstechnisch in anderen Sphären schwebt. Aber die Tessellatoren alleine nützen einem recht wenig, denn den optischen Gewinn gibts erst durch den programmierbaren Anteil, der in den Streamprozessoren abgearbeitet wird.
So sieht es z.B. aus, wenn man einfach nur ein Drahtgittermodell durch den Tessellator jagt:
http://www.abload.de/img/tess0l53k.png -> http://www.abload.de/img/tess1fu9e.png
Wenn man die Texturen dazu rendert, besteht faktisch kein Unterschied zwischen den Bildern. Erst mit Displacement Mapping in den Streamprozessoren (Domain Shader Stage) wird die ganze Aktion sinnig:
http://www.abload.de/img/tess2u5oz.png
Man könnte auch Displacement Mapping ohne Tessellation durchführen, was aber recht bescheiden aussieht, wenn das Grundmesh nicht genug Eckpunkte hat:
http://www.abload.de/img/tess3y65x.png
Und? Was denkst du, kommt nach den Hull und Domain-Shadern? Wie denkst du, kommen die Daten von der Geometie- und Tessellatoreinheit zu den Recheneinheiten? Was glaubst du, wie schnell sind 4 Setup-Engines mit 4 Tris/Takt gegenüber einer mit 1 Tri/Takt?
Oder anders ausgedrückt: Was bringen mir viele Recheneinheiten, wenn die Daten weder schnell genug zu ihnen gelangen noch die Dreiecke schnell gezug zusammengesetzt und gerastert werden?
Ich bin mich das alles bewusst. Aber so, wie man dieses "FF-Tessellator" Sache vereinfacht hat, scheinst du jetzt die Problematik "DX11 Tesellation" zu vereinfachen.
Wozu mehr FLOPs, die ALU-Leistung ist im Vergleich zum Rest schon ziemlich hoch. Wie Coda sagt muss Nvidia es bei der 28nm Generation schaffen, die Einheiten deutlich dichter zu packen und gleichzeitig aber auch den Takt erhöhen.
Noch weiter in der Zukunft scheint man wohl die Zahl der FPUs auf 3 pro CUDA Core zu erhöhen wollen:http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7623791#post7623791
hmm ich dacht es mangelt an ALU Leistung. Effizient ist das Design von NV ja schon immer
Spasstiger
2010-03-23, 23:29:48
Der GF100 ist gegenüber dem GT200 ganz klar ALU-lastiger geworden. Was ja auch nicht verkehrt sein muss, die Anforderungen an die programmierbaren Einheiten steigen ja mit DX11 (Tessellation, Compute Shader).
Das Problem des GF100 ist, dass er zu klein ist und mit zu niedrigen Taktraten läuft. Würde man das Design auf 5-6 Mrd. Transistoren skalieren und das aktuelle Design von ATI auf 3,5-4 Mrd. Transistoren, dann läge Nvidia wohl deutlicher in Front.
Nighthawk13
2010-03-24, 00:03:27
Noch weiter in der Zukunft scheint man wohl die Zahl der FPUs auf 3 pro CUDA Core zu erhöhen wollen:http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7623791#post7623791
Denke das hängt damit zusammen, dass Nvidias aktuelles Skalardesign nicht so (Flops/Watt) effizient sein kann wie ein paralleles Design(VLIW bei AMD).
Zumindest fällt mehr Overhead in Form Scheduling/Instruction Decoding/Register File update an.
Aktuell führt jede Instruktion von Nvidia zu max 64 Flops(Eine Instruktion je Warp => Warpsize(32) * FMA(2Flops) ).
Bei 3D-VLIW wären es dann pro Instruktion bis zu 3*64=192 Flops.
Könnte denn Nvidia einfach eine VLIW-Architektur ähnlich zu RV870 verwenden oder verhindern das z.B. Patente?
Das MUL war vom G80 bis zum GT200 auch nur extra drin, weil man es für Special Functions brauchte. Aus der Not hat man dann eine Tugend gemacht und es als General-Purpose-ALU zur Verfügung gestellt (mit dem Nachteil, dass dann an dem entsprechenden Port keine Special Function möglich ist, solange ein General-Purpose-MUL berechnet wird).
Die Not ist auch bei GT200 natürlich noch vorhanden und es gibt weiterhin eine SFU. Sie wird nur nicht mehr für Multiplikationen genutzt, weil sowieso kein Co-Issue möglich ist.
Das heißt es kann eh nur entweder SFU oder ALU gefüttert werden, also kann man das MUL auch gleich in der ALU lassen.
Noch weiter in der Zukunft scheint man wohl die Zahl der FPUs auf 3 pro CUDA Core zu erhöhen wollen:
Das Dual-Issue ist eine Konsequenz aus dem konsequenten DP-Support. Drei SP-WARPs pro SM ergeben null Sinn :)
Der GF100 ist gegenüber dem GT200 ganz klar ALU-lastiger geworden.
Das kommt darauf an wie sich die TMUs letztendlich verhalten.
Zumindest fällt mehr Overhead in Form Scheduling/Instruction Decoding/Register File update an.
ATI hat sogar noch zusätzlich den Vorteil dass sie breitere SIMDs haben.
Könnte denn Nvidia einfach eine VLIW-Architektur ähnlich zu RV870 verwenden oder verhindern das z.B. Patente?
Wohl eher nicht. VLIW ist nichts neues.
Nighthawk13
2010-03-24, 00:50:24
ATI hat sogar noch zusätzlich den Vorteil dass sie breitere SIMDs haben.
Breite der SIMT-Ausführungeinheiten=16Threads bei RV870 und GF100 würde ich sagen => Sprich Gleichstand.
Das die Warpsize/Wavefront bei AMD=64 und bei Nvidia=32 ist, würde ich jetzt nicht unbedingt als Vorteil bei AMD sehen: Bei unregelmässigen Branches ist der AMD-Ansatz anfälliger.
Ohne Branches hat man natürlich einen weiteren Effizienz-Vorteil: Doppelt soviele Flops je Instruktion.
Was jetzt wichtiger ist, hängt wahrscheinlich davon ab ob man GPGPU oder Shader priorisiert ;)
Ailuros
2010-03-24, 01:25:33
Der GF100 ist gegenüber dem GT200 ganz klar ALU-lastiger geworden.
=/>D3D10.1 TMUs sind verdammt teuer und 48 ROPs auch nicht gerade billig.
Das Problem des GF100 ist, dass er zu klein ist und mit zu niedrigen Taktraten läuft. Würde man das Design auf 5-6 Mrd. Transistoren skalieren und das aktuelle Design von ATI auf 3,5-4 Mrd. Transistoren, dann läge Nvidia wohl deutlicher in Front.
Was haette ein Unterschied von 40 auf 50% in den Transistoren-Anzahlen genau besonderes geaendert?
IHVs skalieren mit jeglicher neuen Generation etwas mehr als 2x Mal die Transistoren-Anzahl des Vorgaengers. GF100 liegt mit seinem 3.08 Mrd. Transistoren gerade noch am Rand der theoretischen maximalen Toleranz von 40G. Ich will ernsthaft bezweifeln dass mehr als dieses moeglich gewesen waere.
Wie dem auch sei weder NV noch AMD haben bei der >Verdoppelung der Transistoren keine hoeheren Frequenzen mit 40nm im Vergleich zu 55nm erreicht.
RV790@55nm = 850MHz
RV870@40nm = 850MHz
GT200b@55nm = 648/1476MHz
GF100@40nm = 700/1400MHz
Breite der SIMT-Ausführungeinheiten=16Threads bei RV870 und GF100 würde ich sagen => Sprich Gleichstand.
Nö. 8 Threads bei NVIDIA pro Kontrolllogik. Es sind zwei Warp-Dispatcher pro SM.
Nighthawk13
2010-03-24, 10:19:41
Nö. 8 Threads bei NVIDIA pro Kontrolllogik. Es sind zwei Warp-Dispatcher pro SM.
Aber es sind 32 Cuda-Cores je Dispatcherpaar(SM) => 16 Cores pro Dispatcher => 16Threads parallel
Beim GT200 war's noch anders: 8 Cuda-Cores für ein Dispatcher => 8Threads parallel
AnarchX
2010-03-28, 10:28:28
http://img210.imageshack.us/img210/2342/image002u.gif
http://www.pcinlife.com/article/graphics/2010-03-26/1269573687d844_4.html
Da fehlt wohl in bestimmten Fällen das zusätzliche MUL als SFU?
deekey777
2010-03-28, 10:56:58
http://img210.imageshack.us/img210/2342/image002u.gif
http://www.pcinlife.com/article/graphics/2010-03-26/1269573687d844_4.html
Da fehlt wohl in bestimmten Fällen das zusätzliche MUL als SFU?
Wie meinst du das? Weil der GT200 die GTX400 beim "Wurzelziehen" überholt?
=Floi=
2010-03-28, 12:28:50
wie sieht der GF100 bei TSAA und 8xAA aus? sind hier steigerungen gegenüber dem G200 zu erwarten?
CB hat ja absolute werte angwegeben, aber die nützen nichts, wenn fermi auf einmal 4x schneller wäre wie der G200. :rolleyes: Da kann die karte dann auch wieder um 50% einbrechen...
Da fehlt wohl in bestimmten Fällen das zusätzliche MUL als SFU?
Das MUL in der SFU ist vorhanden, es kann nur nicht mehr separat genutzt werden. Es gibt allerdings nur mehr 4SFUs pro 32 CUDA-Cores bzw. 64 am ganzen CHIP (wovon bei der 480 60 und bei der 470 56 aktiv sind)
http://img210.imageshack.us/img210/2342/image002u.gif
http://www.pcinlife.com/article/graphics/2010-03-26/1269573687d844_4.html
Da fehlt wohl in bestimmten Fällen das zusätzliche MUL als SFU?
Hmm viel mehr als, dass man beim rv870 den passenden Datentyp benutzen muss um schneller als GF100 zu sein, sieht man da auch nicht.
AnarchX
2010-03-28, 14:02:13
Das MUL in der SFU ist vorhanden, es kann nur nicht mehr separat genutzt werden. Es gibt allerdings nur mehr 4SFUs pro 32 CUDA-Cores bzw. 64 am ganzen CHIP (wovon bei der 480 60 und bei der 470 56 aktiv sind)
OK, danke.
Wie man das wohl deuten kann:
http://hothardware.com/articleimages/Item1477/san.png
http://hothardware.com/Articles/NVIDIA-GeForce-GTX-480-GF100-Has-Landed/?page=15
Dass CUDA und Stream nicht unbedingt vergleichbar sind, ist denkbar. Aber warum ist GF100 so massiv schneller als G200?
LovesuckZ
2010-03-28, 14:04:04
GF100 hat ein komplett anderes Speicher-Management und 3x soviel Shared Memory gegenüber GT200. Dazu kommt es zu einer besseren Ausnutzung der Einheiten.
OK, danke.
Wie man das wohl deuten kann:
http://hothardware.com/articleimages/Item1477/san.png
http://hothardware.com/Articles/NVIDIA-GeForce-GTX-480-GF100-Has-Landed/?page=15
Das CUDA und Stream nicht unbedingt vergleichbar sind, ist denkbar. Aber warum ist GF100 so massiv schneller als G200?
Irgendetwas stimmt da nicht.
Warum ist die double Leistung des GF100 fast genauso schlecht, wie die des GT200.
Und dass die float Leistung gleichauf mit dem rv870 ist, ist auch eher nicht glaubhaft genau so wie das Verhältnis zum GT200.
AnarchX
2010-03-28, 14:06:50
Irgendetwas stimmt da nicht.
Warum ist die double Leistung des GF100 fast genauso schlecht, wie die des GT200.
GeForce 400 ist auf 1/4 des Durchsatzes limitiert bei DP.
Irgendetwas stimmt da nicht.
Warum ist die double Leistung des GF100 fast genauso schlecht, wie die des GT200.
Und dass die float Leistung gleichauf mit dem rv870 ist, ist auch eher nicht glaubhaft genau so wie das Verhältnis zum GT200.
Edit: sind ja 2xrv870 alles klar...
Spasstiger
2010-03-28, 14:08:28
GeForce 400 ist auf 1/4 des Durchsatzes limitiert bei DP.
Im Artikel steht, dass der GF100 noch kein Double-Precision unter OpenCL unterstützt und deshalb fp64 mit fp32 emuliert wird.
GeForce 400 ist auf 1/4 des Durchsatzes limitiert bei DP.
1/2
Das MUL in der SFU ist vorhanden, es kann nur nicht mehr separat genutzt werden. Es gibt allerdings nur mehr 4SFUs pro 32 CUDA-Cores bzw. 64 am ganzen CHIP (wovon bei der 480 60 und bei der 470 56 aktiv sind)
Es waren bei G80 und GT200 zwei pro SM, da hat sich nix geändert am Verhältnis.
_DrillSarge]I[
2010-03-28, 14:09:11
OK, danke.
Wie man das wohl deuten kann:
http://hothardware.com/articleimages/Item1477/san.png
http://hothardware.com/Articles/NVIDIA-GeForce-GTX-480-GF100-Has-Landed/?page=15
Dass CUDA und Stream nicht unbedingt vergleichbar sind, ist denkbar. Aber warum ist GF100 so massiv schneller als G200?
sandra ist relativ wertlos, da sich die werte mit jedem update stark verändern. vielleicht liegt gf100 beim nächsten update noch weiter vorne oder die radeons oder ganz anders :ueye:
GeForce 400 ist auf 1/4 des Durchsatzes limitiert bei DP.
Selbst dann hält man die Versprechungen nicht ein und liegt weit hinter rv870.
Im float aber mit 2xrv870 gleich auf *scheibenwischer*.
AnarchX
2010-03-28, 14:13:42
1/2
Gab es dazu schon ein Update? Die letzte Info war jedenfalls bei GeForce 400 nur 64 DP-FMAs. (http://techreport.com/articles.x/18332/5)
Man braucht nicht immer FMAs, schon gar nicht mit DP. MADs, ADDs und MULs werden auf 1/2 laufen.
Gab es dazu schon ein Update? Die letzte Info war jedenfalls bei GeForce 400 nur 64 DP-FMAs. (http://techreport.com/articles.x/18332/5)
Zumindest in den Launchberichten habe ich nichts mehr davon gelesen, ich geh also eher davon aus, dass es eine Falschmeldung ist.
Nighthawk13
2010-03-28, 16:17:17
Wie meinst du das? Weil der GT200 die GTX400 beim "Wurzelziehen" überholt?
In Real-Word-Anwendungen(gemischte Befehle) dürfte der GF100 besser mit Wurzelrechnungen u.ä. zurechtkommen:
- Die beide FMA-Ausführungseinheiten eines SMs können weiterhin Instruktionen entgegennehmen, während im "Hintergund" die SFU vor sich hinrechnet.
- Beim GT200 war das Extra-MUL des SM in der Zeit belegt.
Wenn man den Chip nur mit Wurzelberechnungen bombardiert(wie in dem Benchmark) funktioniert das "im-Hintergrund-Rechnen" Konzept natürlich nicht mehr.
- Die beide FMA-Ausführungseinheiten eines SMs können weiterhin Instruktionen entgegennehmen, während im "Hintergund" die SFU vor sich hinrechnet.
Das ging bei G80 und GT200 auch.
LovesuckZ
2010-03-28, 16:38:01
Das ging bei G80 und GT200 auch.
Wir hatten das schonmal, aber: Gibt es dazu auch Belege? Laut nVidia ist dies nicht möglich.
Natürlich ist das auch "laut NVIDIA" möglich. Die SFUs und ALUs werden bei G80 vom WARP-Dispatcher abwechselnd mit Aufgaben versorgt und laufen unabhängig voneinander.
Gipsel
2010-03-28, 23:00:51
http://img210.imageshack.us/img210/2342/image002u.gif
http://www.pcinlife.com/article/graphics/2010-03-26/1269573687d844_4.htmlWas man am ersten Test sieht, ist daß der Shader-Compiler für Cypress noch Reserven hat. Alle anderen Tests sind recht nahe am theoretischen Maximum, nur der erste (abhängige MADDs) liegt bei der Hälfte. Ich hatte schon länger die Vermutung, daß der für Cypress erzeugte Code oft praktisch dem für RV770 entspricht und die neuen Features des Cypress bisher noch suboptimal genutzt werden.
Cypress hat 320 VLIW-Einheiten mit 0,85GHz, macht theoretisch 272 BIPs (VLIW-Instruktionen mit je 5 Slots). Neu bei Cypress ist allerdings die Fähigkeit für bestimmte Instruktionen zwei abhängige davon (sogar 2 Paare von zwei abhängigen Instruktionen) in eine VLIW-Instruktion packen zu können, und MADDs zählen dazu. Wenn der Compiler auf Draht wäre, würden also beim ersten Test nicht 268 BIPs stehen, sondern das Doppelte (~535 BIPs). Also um mal ein Beispiel zu nennen, zwei abhängige MADDs sind etwa
x = A*B+ (C*D+E)
und das schafft Cypress definitiv pro VLIW-Einheit pro Takt.
Edit:
DOT4 hätten die mal testen sollen (A*B + C*D + E*F + G*H). Da macht Cypress ganze 272 BIPs, eine GTX480 aber nur 168, trotz der skalaren ALUs bei der GTX und den ganzen Abhängigkeiten ;)
Wie man das wohl deuten kann:
http://hothardware.com/articleimages/Item1477/san.png
http://hothardware.com/Articles/NVIDIA-GeForce-GTX-480-GF100-Has-Landed/?page=15Daß man nicht weiß, was die da überhaupt machen. Ohne den Code zu sehen, kann man da wahrscheinlich schwer was Genaues sagen.
Es waren bei G80 und GT200 zwei pro SM, da hat sich nix geändert am Verhältnis.2 SFUs für 8 SPs, jetzt 4 SFUs für 32 SPs. Also bei mir ist das eine Halbierung des Verhältnisses von 1/4 auf 1/8.
Oder anders ausgedrückt, GT200 hatte 60 SFUs, eine GTX480 hat auch nur 60 bei allerdings verdoppelter Zahl der SPs.
Man braucht nicht immer FMAs, schon gar nicht mit DP. MADs, ADDs und MULs werden auf 1/2 laufen.Und die sind nicht reduziert? Würde mich sehr wundern, wenn nur FMAs auf ein Viertel der Teslas reduziert werden (ist das eigentlich sicher?) und die anderen Operationen nicht auch.
deekey777
2010-03-28, 23:11:54
Im Artikel steht, dass der GF100 noch kein Double-Precision unter OpenCL unterstützt und deshalb fp64 mit fp32 emuliert wird.
Das Bild sagt ganz klar, dass CUDA bzw. ATi Stream benutzt wurden. Und da wird DP sehr wohl unterstützt.
Irgendwie ergibt der Text des Artikels keinen Sinn.
1/2
.
Also bei iXBT steht, dass die DP-Performance auf ein Viertel im Vergleich zu Tesla begrenzt wurde.
2 SFUs für 8 SPs, jetzt 4 SFUs für 32 SPs. Also bei mir ist das eine Halbierung des Verhältnisses von 1/4 auf 1/8.
Jup, hast recht:
According to Nvidia, in the Fermi architecture, the transcendental ops and texture interpolation hardware are actually separated now (guess you didn't know that). There are now four transcendental units per 32 ALUs (that you knew), which is a 2:1 ratio change vs the previous generation. Nvidia said, they felt this was a reasonable balance given that the more decoupled nature of the Fermi design would allow them to use the units more efficiently. Now, if this separate from transcendental TEX interpolation means they're carrying it out in the normal shader-ALU like AMD does or if there's extra hardware involved, we cannot tell just yet.
Irgendwie scheint es als würde NVIDIA nicht die ganze Wahrheit der Fermi-SMs rausrücken bisher.
Und die sind nicht reduziert? Würde mich sehr wundern, wenn nur FMAs auf ein Viertel der Teslas reduziert werden (ist das eigentlich sicher?) und die anderen Operationen nicht auch.
Ich ging einfach davon aus, dass die FMAs auch bei den Teslas auf 1/4 laufen. Falls das tatsächlich nur eine künstliche Limitierung der GeForces ist, dann sieht die Sache wohl anders aus.
Gipsel
2010-03-28, 23:27:24
Ich ging einfach davon aus, dass die FMAs auch bei den Teslas auf 1/4 laufen. Falls das tatsächlich nur eine künstliche Limitierung der GeForces ist, dann sieht die Sache wohl anders aus.Nun, die wollen mit den billigen Geforce-Karten den Teslas wohl nicht den Markt abgraben.
Aber ich weiß nicht, ob SiSoft nun wirklich der beste Test dafür ist, denn nicht nur der große Sprung der GTX480 dort ist eigenartig, auch, daß die ATIs in single precision angeblich nur zwei Mal so schnell sind wie in double precision. Wer weiß, was die da machen :rolleyes:
Übrigens will Theo Valich die Woche mal ein paar BOINC-Projekte mit einer GTX480 testen. Mal sehen, ob Milkyway@home (double precision) und Collatz@home (Integer-Operationen, insbesondere Multiplikationen) dabei sind. Das sind nämlich genau die beiden Bereiche, in denen GF100 ja zugelegt haben soll und die momentan von ATIs massiv dominiert werden (Milkyway: HD5870 gut 6 mal so schnell wie GTX285; Collatz: HD5870 etwa 3,5 mal so schnell wie GTX285).
deekey777
2010-03-28, 23:36:32
Aber ich weiß nicht, ob SiSoft nun wirklich der beste Test dafür ist, denn nicht nur der große Sprung der GTX480 dort ist eigenartig, auch, daß die ATIs in single precision angeblich nur zwei Mal so schnell sind wie in double precision. Wer weiß, was die da machen :rolleyes:
.
Wie es so schön heißt: Traue keiner Statistik, die du nicht selbst gefälscht hast.
Mit Stream erreicht meine HD4850 (675/993) in Sandra 2010.1636 etwa 385 MPixel/s, unter OpenCL dagegen 644 MPixel/s (SP alles). Die DP-Leistung unter Stream ist dagegen 190 MPixel/s.
Und das Beste:
5870 CF @ 1020/1200
STREAM:
http://www.abload.de/img/2010-03-27_1824408mjc.jpg (http://www.abload.de/image.php?img=2010-03-27_1824408mjc.jpg)
CS:
http://www.abload.de/img/2010-03-27_183517okfg.jpg (http://www.abload.de/image.php?img=2010-03-27_183517okfg.jpg)
OpenCL:
http://www.abload.de/img/2010-03-27_183913h8f9.jpg (http://www.abload.de/image.php?img=2010-03-27_183913h8f9.jpg)
Der OpenCL-Wert ist naja, :freak: nen bisschen buggy.
Ok, die Bilder gehen nicht. Mist.
Ailuros
2010-03-29, 08:38:27
Ich weiss das Thema wurde schon oefters diskuttiert aber mir ist leider immer noch nicht klar wie es mit TF genau auf GF100 aussieht. Anand behauptet hier wieder 256 TF (bei 16SMs): http://www.anandtech.com/video/showdoc.aspx?i=3783&p=3
Ich frag nochmal nach um auf Nummer Sicher zu gehen, aber es klingt mir nicht nach 1 TA / 4 TF pro SM.
***edit: Anand hat wohl auch etwas falsch verstanden mit Transparenz AA:
http://www.anandtech.com/video/showdoc.aspx?i=3783&p=7
The bad news is that it’s not quite complete. Oh as you’ll see in our screenshots it works, but the performance hit is severe. It’s currently super-sampling too much, resulting in massive performance drops. NVIDIA is telling us that this should be fixed next month, at which time the performance hit should be similar to that of the old TrSS mode under DX9. We’ve gone ahead and taken screenshots and benchmarks of the current implementation, but keep in mind that performance should be greatly improving next month.
With the exception of NVIDIA’s new TrSS mode, very little has changed. Under DX10 all of the cards produce a very similar image. Furthermore once you reach 4x MSAA, each card producing a near-perfect image. NVIDIA’s new TrSS mode is the only standout for DX10.
We’ve also include a few DX9 shots, although we are in the process of moving away from DX9. This allows us to showcase NVIDIA’s old TrSS mode, along with AMD’s Adapative AA and Super-Sample AA modes. Note how both TrSS and AAA do a solid job of anti-aliasing the foliage, which makes it all the more a shame that they haven’t been available under DX10.
Transparency Multisampling != Transparency Supersampling and den Quark mit dem "old TrSS" und "new TrSS" haette er sich sparen koennen. Wenn die GTX480 unter DX9 von 4xMSAA= 43,9fps auf 4xMSAA + 4x"SS"= 42,6 fps liegt dann kann es nicht transparency supersampling sein sondern transparency multisampling. Die 5870 scores im gleichen modus sind:
5870 =
4xMSAA = 40.7 fps, 4x+4"SS" = 39,4 fps, 4x+SSAA = 28,9 fps
Es sieht wohl danach aus als ob NV immer noch nicht die Kombination von CSAA + TMAA geschafft hat unter =/>DX10 und momentan nur CSAA+ TSAA moeglich ist. Hat wohl nichts mit "old" und "new" zu tun sondern eher der Unfaehigkeit des reviewers den Unterschied zwischen TMAA und TSAA zu verstehen und das in 2010.....*seufz*
Ein ähnliches Spielchen wie die 80 Texture-Fetches beim R600. Natürlich können 256 TFs durchgeführt werden: 16 L/S pro SM*16 = 256. Allerdings gilt das nicht für's normale Texturing: Dafür werden die TFs der TMUs verwendet, die können zwar wohl auch 256x samplen, aber eben nur "klassisch".
-carsten
Ailuros
2010-03-29, 09:28:18
Ein ähnliches Spielchen wie die 80 Texture-Fetches beim R600. Natürlich können 256 TFs durchgeführt werden: 16 L/S pro SM*16 = 256. Allerdings gilt das nicht für's normale Texturing: Dafür werden die TFs der TMUs verwendet, die können zwar wohl auch 256x samplen, aber eben nur "klassisch".
-carsten
Ergo im Klartext mit AF 1 TA / 1 TF pro SM oder?
Gast23
2010-03-29, 09:33:31
Transparency Multisampling != Transparency Supersampling and den Quark mit dem "old TrSS" und "new TrSS" haette er sich sparen koennen. Wenn die GTX480 unter DX9 von 4xMSAA= 43,9fps auf 4xMSAA + 4x"SS"= 42,6 fps liegt dann kann es nicht transparency supersampling sein sondern transparency multisampling.
Ja, es sollte ja angeblich ein neuer TMSAA-modus (zusammen mit 32x CSAA) kommen, der auch die transparenten Texturen glätten sollte.
Über einen neuen TMSAA hab ich aber bisher nirgendwo was gelesen oder davon Bilder gesehen, war wohl eine Fehlinformation.
Der TSSAA ist noch genauso wie vorher, nur dass man jetzt die TSSAA Stufe unabhängig von der MSAA Stufe wählen kann (z.b. 4x MSAA + 2x TSSAA oder 8x MSAA + 4xTSSAA). Da hätte ich eigentlich mehr erwartet.
Ailuros
2010-03-29, 09:52:40
Ja, es sollte ja angeblich ein neuer TMSAA-modus (zusammen mit 32x CSAA) kommen, der auch die transparenten Texturen glätten sollte.
Über einen neuen TMSAA hab ich aber bisher nirgendwo was gelesen oder davon Bilder gesehen, war wohl eine Fehlinformation.
Nicht unbedingt; wenn man Anand's falsches Verstaendnis von Transparenz AA zur Seite legt, sagt er selber dass der angebliche DX9 TrSS modus (welches aber wohl klar TMAA ist) in spaeteren Treibern nachgeladen wird. Es heisst eigentlich lediglich - wenn ich es nicht falsch verstanden habe - dass TMAA erst in neueren Treibern kommen wird. Und wenn NV das einhalten will was sie versprochen haben dann muesste man auch fuer jedes coverage sample ein TMAA sample einschalten koennen (16xCSAA + 16xTMAA) als Beispiel.
Der TSSAA ist noch genauso wie vorher, nur dass man jetzt die TSSAA Stufe unabhängig von der MSAA Stufe wählen kann (z.b. 4x MSAA + 2x TSSAA oder 8x MSAA + 4xTSSAA). Da hätte ich eigentlich mehr erwartet.
Das GF100 whitepaper zur Hand:
Current games are constrained by the limitations of API and GPU horsepower in the amount of geometry they can render. Foliage is a particular challenge. A common technique for foliage is to create an alpha textured billboard containing many leaves, using alpha-to-coverage to eliminate the gaps between the leaves. The quality of the edge is determined by the number of coverage samples. In cases with only four or even eight coverage samples available, aliasing and banding become very obvious, especially when the texture is close to the screen. With 32x CSAA, the GPU has 32 coverage samples available, minimizing banding effects and improving overall image quality.
Transparency Multisampling (TMAA) also benefits from CSAA. TMAA benefits DirectX 9 games that are unable to use alpha-to-coverage directly because it is not exposed in the DirectX 9 API. Instead they use a technique called “alpha test” which produces hard edges for transparent textures. TMAA automatically converts old shader code in the DirectX 9 applications to use alpha-to-coverage, which combined with CSAA, produces greatly improved image quality.
The image on the left shows the TMAA using 16xQ antialiasing (8 multisamples, 8 coverage sample) on older GPUs. The image on the right shows TMAA using 32x antialiasing (8 multisamples, 24 coverage samples) on GF100. Because coverage samples are used as part of GF100’s TMAA evaluation, much smoother gradients are produced.
Ergo im Klartext mit AF 1 TA / 1 TF pro SM oder?
Jo. Ob man allerdings noch parallel mit den L/S evtl. Shadowmaps samplen kann, weiß ich nicht.
-Carsten
Ailuros
2010-03-29, 10:12:45
Jo. Ob man allerdings noch parallel mit den L/S evtl. Shadowmaps samplen kann, weiß ich nicht.
-Carsten
Stimmt auch nicht ganz. Scheint komplizierter zu sein als ich dachte. Ich brauch lediglich das gruene Licht ob ich mit der genauen Erklaerung in die Oeffentlichkeit darf.
***edit:
pro SM hat GF100 folgendes:
16 texture addressing Einheiten
4 texture filtering Einheiten
16 sampling Einheiten
Wenn nichts gefiltert wird koennen die 16 samples die fuer die 16 addresses aufgerufen werden direkt an die shaders weitergeleitet werden in dem man die Filterungs-Logik umgeht. Hauptsaechlich wurde es so fuer DX11 gather4 angelegt.
Mit bilinearer bzw. trilinear Filterung werden 4 addresses berechnet fuer 4*(2*2) samples die dann von den 4 filter units gefiltert werden.
Nichts fundamental Neues aber ich hab es leider erst jetzt geschnallt.
Oh und ja kommende Treiber = fuer jedes coverage sample ein TMAA sample, ergo maximal bis zu 32xCSAA + 32xTMAA.
LovesuckZ
2010-03-29, 11:54:47
Laut Herrn Spille ist die Pixelleistung abhängig von der Anzahl der SM und nicht von den GPC. Das ist ziemlich interessant.
Gast23
2010-03-29, 12:01:39
Nicht unbedingt; wenn man Anand's falsches Verstaendnis von Transparenz AA zur Seite legt, sagt er selber dass der angebliche DX9 TrSS modus (welches aber wohl klar TMAA ist) in spaeteren Treibern nachgeladen wird. Es heisst eigentlich lediglich - wenn ich es nicht falsch verstanden habe - dass TMAA erst in neueren Treibern kommen wird. Und wenn NV das einhalten will was sie versprochen haben dann muesste man auch fuer jedes coverage sample ein TMAA sample einschalten koennen (16xCSAA + 16xTMAA) als Beispiel.
Ja stimmt, das hatte ich vergessen. Hab unüberlegt geschrieben, da ich heute etwas durch'n Wind bin (wenig geschlafen).
Das neue am TMAA ist laut Anandtech-artikel, dass man mit 32x CSAA + TMAA bei den transparenten Texturen jetzt bis zu 33 Abstufungen hat.
Da bin ich mal auf ausführliche Tests mit Vergleichsbildern, besonders im Vergleich zu 4x MSAA + 4x TSSAA gespannt. Auf den Anandtech-Vergleichsbildern wurde ja scheinbar bei der GTX 480 kein TMAA aktiviert, jedenfalls verändern sich die transparenten Texturen nicht, nur bei TrSS verändern sie sich.
Es kommt halt auch auf das Spiel, den eigenen Geschmack und Monitor an. Mir gefällt 4x MSAA + 4x TSSAA am besten, da ich lieber weichere transparente Texturen habe, anstatt schärfere die flimmern.
Durch ein weicheres Bild bekommen die Spiele mehr einen Filmlook. Die Teile des Bildes wirken zusammenhägender und das Spiel wirkt flüssiger.
Ailuros
2010-03-29, 12:38:17
Ja stimmt, das hatte ich vergessen. Hab unüberlegt geschrieben, da ich heute etwas durch'n Wind bin (wenig geschlafen).
Das neue am TMAA ist laut Anandtech-artikel, dass man mit 32x CSAA + TMAA bei den transparenten Texturen jetzt bis zu 33 Abstufungen hat.
Da bin ich mal auf ausführliche Tests mit Vergleichsbildern, besonders im Vergleich zu 4x MSAA + 4x TSSAA gespannt. Auf den Anandtech-Vergleichsbildern wurde ja scheinbar bei der GTX 480 kein TMAA aktiviert, jedenfalls verändern sich die transparenten Texturen nicht, nur bei TrSS verändern sie sich.
Es kommt halt auch auf das Spiel, den eigenen Geschmack und Monitor an. Mir gefällt 4x MSAA + 4x TSSAA am besten, da ich lieber weichere transparente Texturen habe, anstatt schärfere die flimmern.
Durch ein weicheres Bild bekommen die Spiele mehr einen Filmlook. Die Teile des Bildes wirken zusammenhägender und das Spiel wirkt flüssiger.
Wo immer TMAA erstmal einen Unterschied macht, reicht es mir persoenlich voll aus fuer Transparenzen. In dem Fall schaetze ich dass 16xCSAA + 16xTMAA der goldene Schnitt auf einer GF100 sein wird. Man verliert ein bisschen an Leistung im Vergleich zu einfachem 4xMSAA, hat aber dann schon 16xTMAA auf alpha tests.
TSAA ist bei gleicher Sample-anzahl zweifellos nach wie vor besser als TMAA. Bei so hohen moeglichen TMAA Anzahlen bezweifle ich aber dass TSAA noch der Rede sein wird.
Laut Herrn Spille ist die Pixelleistung abhängig von der Anzahl der SM und nicht von den GPC. Das ist ziemlich interessant.
Bei näherem Nachdenken erscheint das durchaus logisch, oder? 4x8 Pixel in den vier Rastern der GPCs, aber nur 15/14 aktive SMs - dann bleiben halt 30/28 Pixel übrig, die parallel durch die virtuelle Pipeline weiterrutschen können.
"Unten" an den ROPs hätten sie dann mehr Platz, aber naja... Bringt nur was mit 8xAA.
-Carsten
Gipsel
2010-03-30, 19:43:19
Stimmt auch nicht ganz. Scheint komplizierter zu sein als ich dachte. Ich brauch lediglich das gruene Licht ob ich mit der genauen Erklaerung in die Oeffentlichkeit darf.
***edit:
pro SM hat GF100 folgendes:
16 texture addressing Einheiten
4 texture filtering Einheiten
16 sampling Einheiten
Wenn nichts gefiltert wird koennen die 16 samples die fuer die 16 addresses aufgerufen werden direkt an die shaders weitergeleitet werden in dem man die Filterungs-Logik umgeht. Hauptsaechlich wurde es so fuer DX11 gather4 angelegt.
Mit bilinearer bzw. trilinear Filterung werden 4 addresses berechnet fuer 4*(2*2) samples die dann von den 4 filter units gefiltert werden.
Nichts fundamental Neues aber ich hab es leider erst jetzt geschnallt.Hmm. Also ich habe das etwas anders verstanden. Mit 4offset_gather4 erreicht man auf GF100 laut nvidia nur die doppelte Performance als mit dem normalen gather. Man kann pro Takt also nur von 8 Adressen Texturen lesen, nicht von 16. Zudem ist der "zusätzliche" TA dafür wohl auch ein wenig abgespeckt, da nur begrenzte Offsets (+-256, Texturen dürfen aber bis zu 16k groß sein) zu der eigentlichen Adresse angegeben und nicht beliebig adressiert werden kann. Ein Fermi-SM hat also:
4 (+4) TA (die weiteren vier nur für den gather-Kram)
4 Filter
und natürlich 16 Sampler (das was Anand als TF also texture fetch bezeichnet).
Nur wenn der Treiber absolut sicher weiß, daß etwas exklusiv mit point sampling (also ohne Filtering) benutzt wird, kann er das vielleicht im globalen Speicher ablegen (nicht als Textur, da Datenformat anders!) und direkt über die L/S-Einheiten aus dem GP-L1 mit 16 Samples (von 16 Adressen) pro Takt laden, der Texture-Cache und die dazugehörigen TAs würden das nicht hergeben. Sobald darauf über die Textur-Einheiten zugegriffen wird ist es Essig damit. Nvidia sagt ausdrücklich, daß die Nutzung von Texturen für point sampled Lookups langsamer ist (ein Viertel oder maximal die Hälfte an Speed) als über den GP-L1 aus dem globalen Speicher.
@Carsten:
Achja, wenn Fermi nicht aus dem GP-L1 parallel zum Texture-L1 lesen kann, hätten nvidia was verbockt, das wird sich schon nicht blockieren.
Gipsel
2010-03-30, 19:53:20
Bei näherem Nachdenken erscheint das durchaus logisch, oder? 4x8 Pixel in den vier Rastern der GPCs, aber nur 15/14 aktive SMs - dann bleiben halt 30/28 Pixel übrig, die parallel durch die virtuelle Pipeline weiterrutschen können.
Wenn dort wirklich 4 8 Pixel breite Raster-Units sitzen würden, macht das eigentlich keinen Sinn. Die Rasterizer erzeugen ja Warps aus 32 Pixeln (würde also minimal 32/8=4 Takte dazu benötigen), die dann ein einziger SM abarbeitet. Die Granularität auf der Ebene sind die Warps.
Ich habe ja schon länger den Verdacht, daß es in Wirklichkeit gar keine GPCs gibt, sondern daß das nur virtuelle Blöcke sind, die irgendein halber PR-Mensch dort in einem Diagramm eingemalt hat. Eigentlich machen die keinen Sinn, da nvidia ja einzelne SMs ausknipsen kann. Ein Warp eines Rasterizers kann vermutlich auf jedem SM landen, nicht nur auf den SMs im GPC des Rasterizers.
Eine Möglichkeit, die mir dazu spontan einfällt, ware ein kleiner 2 Pixel/Takt mini-Rasterizer pro SM (1 Warp alle 16 Takte). Damit wäre man dann übrigens perspektivisch auch für sehr kleine Dreiecke gut gerüstet. Alternativ kann ein SM maximal nur 2 Pixel pro Takt an die ROPs rausschreiben kann. Wer weiß, vielleicht lohnte sich der Aufwand für mehr einfach nicht?
"Unten" an den ROPs hätten sie dann mehr Platz, aber naja... Bringt nur was mit 8xAA.
Oder wenn Farbformate benutzt werden, die die ROPs nicht mit voller Geschwindigkeit können.
Triskaine
2010-03-30, 21:36:25
Nachdem ich mir jetzt reihenweise Theoretische Tests zu Gemüte geführt habe, kann ich meine persönlichen Vermutungen vortragen. Der ROP/L2-Takt (wenn es ihn wirklich gibt) liegt bei einer GTX 480 bei ca. 620-630 MHz, also innerhalb der von Ailuros genannten 11-13 % unterhalb vom halben Hotclock. Ich denke auch das der Pixeldurchsatz von den SM's unabhängig ist. Die 4 Rastereinheiten laufen dann auch mit diesem "Core"-Takt.
Ailuros, wenn du schon dabei bist deine Quelle anzuzapfen, könntest du diese ROP/L2/Raster-Takt Sache endgültig abklären?
Gipsel
2010-03-30, 22:27:13
Nachdem ich mir jetzt reihenweise Theoretische Tests zu Gemüte geführt habe, kann ich meine persönlichen Vermutungen vortragen. Der ROP/L2-Takt (wenn es ihn wirklich gibt) liegt bei einer GTX 480 bei ca. 620-630 MHz, also innerhalb der von Ailuros genannten 11-13 % unterhalb vom halben Hotclock.Mal abgesehen von Ailuros' Informationen, wie kommst Du auf 620-630 MHz? Warum nicht sagen wir mal genau 2/3 der 700 MHz Raster-/Schedulertakt, also 467 MHz? Gibt es da einen Grund?
Triskaine
2010-03-30, 22:41:19
Ja, denn sie passen sehr gut zu den Ergebnissen der Theoretischen Tests. Ich habe vorallem die Ergebnisse betrachtet, wo die anderen Architekturen besonders nahe an ihren Theoretischen Werten sind und daraus dann die wahrscheinlichen Taktraten bestimmt. Das ist zwar keine wirklich sichere Methode, aber gerade weil die Taktraten sich so nah am Bekannten einorden, halte ich es fü realistisch, dass sie stimmen.
Gipsel
2010-03-30, 22:57:44
Ja, denn sie passen sehr gut zu den Ergebnissen der Theoretischen Tests. Ich habe vorallem die Ergebnisse betrachtet, wo die anderen Architekturen besonders nahe an ihren Theoretischen Werten sind und daraus dann die wahrscheinlichen Taktraten bestimmt. Das ist zwar keine wirklich sichere Methode, aber gerade weil die Taktraten sich so nah am Bekannten einorden, halte ich es fü realistisch, dass sie stimmen.
Na dann erkläre mal die Füllratentests mit RGB9e5 (FP10) oder FP16 Farbformat (http://www.hardware.fr/articles/787-5/dossier-nvidia-geforce-gtx-480.html)!
Wenn die SMs auf 2 Pixel pro Takt limitiert sind, die ROPs 32bit int Pixel mit voller Datenrate, FP16 und RGB9e5 mit halber Rate machen, dann ist eine GTX480 auf 21 GPixel/s durch die SMs limitiert. Die 48 ROPs limitieren hier nicht.
Nehmen wir jetzt die anderen Formate (half rate in den ROPs), so limitieren die ROPs (oder auch die Speicherbandbreite mit Blending) auf eine Füllrate von 48*f/2. Bei 600 MHz wären dies 14,4 GPixel/s. Eine GTX480 schafft aber nur 10,0 bzw. 10,1 GPixel/s, exakt die Hälfte des 32Bit-Integer-Wertes. Die größere Zahl der ROPs scheint sich also überhaupt nicht zu rentieren, vielmehr ist die Frequenz scheinbar so gewählt, daß die Limitierung für Int32 praktisch gleichzeitig einsetzt. Nehmen wir also 10,5 GPixel/s an, kommt man auf:
10,5 GPixel/s / 48 ROPs * 2 Takte = 437,5 MHz
Oder nehmen wir an, daß das Frequenzverhältnis auf den vollen GF100 mit 16 SMs ausgelegt ist:
32 Pixel/Takt von den SMs auf 48 ROPs verteilt ergibt ein Verhältnis von 1,5, die ROPs müssen also mit 700 MHz / 1,5 = 467 MHz laufen, um mit Int32 nicht zu limitieren.
Sollte des Rausschreiben von den SMs an die ROPs schon auf halbe Rate limitiert sein (Warum? Ein RGB9e5 Pixel ist auch nur 32Bit genau wie 4*8Bit Integer.), sollte man nvidia mal fragen, wozu die dann eigentlich 48 ROPs verbaut haben, da 32 dann genau so schnell wären.
Außerdem gab es mal im Januar ein paar Gerüchte über ROPs unter 500 MHz.
Also ich persönlich habe noch keine Messungen gesehen, die gegen ROPs im Bereich um 450 MHz sprechen würden. Hast Du welche?
Gipsel
2010-03-30, 23:24:43
Oder um das mal zusammenzufassen, die Meßergebnisse sprechen dafür, daß GF100 drei Taktdomänen hat, die in einem fixen Verhältnis zueinander stehen.
Hotclock: Shader
Hotclock/2: Rasterizer, Scheduler, TMUs
Hotclock/3: ROPs/Colorcache, (L2?)
Ailuros
2010-03-31, 08:17:47
Nachdem ich mir jetzt reihenweise Theoretische Tests zu Gemüte geführt habe, kann ich meine persönlichen Vermutungen vortragen. Der ROP/L2-Takt (wenn es ihn wirklich gibt) liegt bei einer GTX 480 bei ca. 620-630 MHz, also innerhalb der von Ailuros genannten 11-13 % unterhalb vom halben Hotclock. Ich denke auch das der Pixeldurchsatz von den SM's unabhängig ist. Die 4 Rastereinheiten laufen dann auch mit diesem "Core"-Takt.
Ailuros, wenn du schon dabei bist deine Quelle anzuzapfen, könntest du diese ROP/L2/Raster-Takt Sache endgültig abklären?
Rasters duerften auf 1/2 hot clock laufen. Mir wurde in der Vergangenheit lediglich gesagt dass der ROP/L2 domain niedriger ist als 1/2 hot clock ohne es deutlich anzusetzen. Nach dem Zeug hier:
We have another nice hint that running the texturing hardware at half the speed of the shaders rather than on a separate core clock will impart a 12-14% frequency boost.
http://www.techreport.com/articles.x/18332/5
....dachte ich natuerlich dass der Unterschied bei 12-14% liegen koennte.
Ich frag natuerlich mal nach weil mir so oder so die ueberall benutzten 700MHz fuer ROPs/L2 nicht richtig sitzen.
Uebrigens hat es bis jetzt wohl keiner bemerkt dass Damien eine Pixelfuellrate von 22,4GPixels angibt:
http://www.hardware.fr/articles/787-2/dossier-nvidia-geforce-gtx-480-470.html
22400 / 48 = 467MHz und hier hat Gipsel wohl wieder den Nagel auf den Kopf getroffen weil es genau hot clock/3 ist, ergo:
1400 / 3 = 467MHz (aufgerundet in beiden Faellen da 466.6666666....)
22400 / 48 = 467MHz und hier hat Gipsel wohl wieder den Nagel auf den Kopf getroffen weil es genau hot clock/3 ist, ergo:
Das würde auch erklären, warum man unbedingt 48 ROPs braucht.
Triskaine
2010-03-31, 15:50:49
Uebrigens hat es bis jetzt wohl keiner bemerkt dass Damien eine Pixelfuellrate von 22,4GPixels angibt:
http://www.hardware.fr/articles/787-2/dossier-nvidia-geforce-gtx-480-470.html
22400 / 48 = 467MHz und hier hat Gipsel wohl wieder den Nagel auf den Kopf getroffen weil es genau hot clock/3 ist, ergo:
1400 / 3 = 467MHz (aufgerundet in beiden Faellen da 466.6666666....)
Nein, ein GF100 kann 32 Pixel pro Takt durchbringen, 32 * 700 MHz = 22,4 GPixel/s. Damien hat hier nicht mit einem "Super-Secret-ROP-Clock" gerechnet sondern mit dem normalen halben Hotclock. Gipsels 466 MHz für die ROP's passen auch bei weitem nicht in allen Tests, ebensowenig wie meine vermuteten 620-630 MHz. Daher rührt die Verwunderung über diese Sache, da weder die eine noch die andere Spekulation überall passt.
Deswegen wäre ich dir sehr verbunden wenn du diesen Streitpunkt mit deinem nVidia Kontakt abklären könntest.
Gipsel
2010-03-31, 15:57:45
Gipsels 466 MHz für die ROP's passen auch bei weitem nicht in allen Tests,Bei welchen paßt es nicht?
Damiens Füllratentests (http://www.hardware.fr/articles/787-5/dossier-nvidia-geforce-gtx-480.html) erklären sie perfekt. Er selbst schrieb bei B3D, daß eine Frequenz um 450 MHz eigentlich die logische Schlußfolgerung wäre und er eigentlich nach seinen Tests davon überzeugt war. Nur daß nvidia das nicht bestätigen will, läßt ihn daran zweifeln.
Allerdings würde ich nvidias Worte dazu nicht unbedingt auf die Goldwaage legen, solange sie keine klare Aussage dazu treffen sondern eher nur ausweichend antworten.
Triskaine
2010-03-31, 17:08:10
Wir beziehen uns ja auf diese Tabelle:
http://www.abload.de/img/hwfr_testsfr3j.png (http://www.abload.de/image.php?img=hwfr_testsfr3j.png)
Wie wir sehen, erreichen bei 4x INT8 sowohl Cypress als auch GT200 ihre jeweiligen Peak Raten. Wenn wir davon ausgehen das dies bei GF100 ebenso ist, was ich für sehr wahrscheinlich halte, da die Effizienz wohl kaum im Vergleich zum GT200 gesunken ist, und die ROPs mit Hotclock/3 laufen, müsste die GTX 480 ca. 22,4 GPixel/s erreichen schafft aber bloss 19,6 was 13% darunter liegt, die GTX 470 erreicht 15,7 von möglichen 16,2. Perfekt passen tut es also nicht. In den Chinesen Tests ist die Skalierung auch nicht grade Ideal, aber im großen und ganzen scheint diese Hotclock/3 Vermutung richtig liegen zu können.
Eine Frage noch, in welchen Situationen kommt die Limitierung des GF100 auf 32 Pixel pro Takt den genau zum tragen?
Gipsel
2010-03-31, 17:32:57
Wir beziehen uns ja auf diese Tabelle:
http://www.abload.de/img/hwfr_testsfr3j.png (http://www.abload.de/image.php?img=hwfr_testsfr3j.png)
Wie wir sehen, erreichen bei 4x INT8 sowohl Cypress als auch GT200 ihre jeweiligen Peak Raten. Wenn wir davon ausgehen das dies bei GF100 ebenso ist, was ich für sehr wahrscheinlich halte, da die Effizienz wohl kaum im Vergleich zum GT200 gesunken ist, und die ROPs mit Hotclock/3 laufen, müsste die GTX 480 ca. 22,4 GPixel/s erreichen schafft aber bloss 19,6 was 13% darunter liegt, die GTX 470 erreicht 15,7 von möglichen 16,2. Perfekt passen tut es also nicht. In den Chinesen Tests ist die Skalierung auch nicht grade Ideal, aber im großen und ganzen scheint diese Hotclock/3 Vermutung richtig liegen zu können.
Eine Frage noch, in welchen Situationen kommt die Limitierung des GF100 auf 32 Pixel pro Takt den genau zum tragen?Bei 4*Int8 limitieren die 2 Pixel pro SM, und das sind dann bei GTX480 nur 30 Pixel/Takt und somit nur noch 21 GPixel/s, womit man wieder recht nahe (6,7% drunter) am theoretischen Maximum liegt ;)
Die ROPs limitieren dann z.B. bei FP10, da die nur half rate abgearbeitet werden können, aber bei 48 ROPs mit 700MHz eben 16,8 GPixel schaffen müßten und nicht nur ~10.
Wenn die SMs FP10 Pixel schon nur half rate an die ROPs weitergeben können (??? Sind doch auch nur 32bit wie 4*Int8. Macht überhaupt keinen Sinn, das dort zu beschränken.), frage ich mich, wozu denn überhaupt 48 ROPs verbaut wurden, 32 hätten dann auch gereicht (und eben drei 64 Bit Controller pro 16 ROPs statt einer pro 8, wenn man die Speicherbandbreite haben will, die Crossbars dazwischen wären bestimmt billiger als 16 zusätzliche ROPs).
In der Tabelle sieht man sehr schön, daß RV870 1xFP32 nur mit halber Rate abarbeitet, und bei 4xFP16 und 4xFP32 die Speicherbandbreite limitiert (18,2 GPixel/s * 8 Byte = 145,6 GB/s, theoretischer Peak 153,6 GB/s). An diese Grenzen stößt der GF100 ja noch lange nicht an.
Na dann erkläre mal die Füllratentests mit RGB9e5 (FP10) oder FP16 Farbformat (http://www.hardware.fr/articles/787-5/dossier-nvidia-geforce-gtx-480.html)!FP10 gibt es so nicht, nur Fixpoint 10. Das ist dann aber nicht RGB9e5, sondern RGB-10-10-10 im Fixpoint-Format.
frage ich mich, wozu denn überhaupt 48 ROPs verbaut wurdenLastenverteilung.
Gipsel
2010-03-31, 17:43:43
FP10 gibt es so nicht, nur Fixpoint 10. Das ist dann aber nicht RGB9e5, sondern RGB-10-10-10 im Fixpoint-Format.Wurde das rgb9e5-Format nicht mit DX11 eingeführt? 3*9 Bit Mantisse für RGB und dann 5 bit gemeinsamer Exponent für alle Komponenten? Zumindest als Texturformat gibt es das doch.
Lastenverteilung.
Lastverteilung auf 48 Einheiten, obwohl 30 das auch schaffen würden? Welchen Sinn soll das denn haben außer die Anzahl der nötigen Transistoren und die Diegröße zu erhöhen?
Wurde das rgb9e5-Format nicht mit DX11 eingeführt? 3*9 Bit Mantisse für RGB und dann 5 bit gemeinsamer Exponent für alle Komponenten? Zumindest als Texturformat gibt es das doch.DX10.
RGB9e5 oder RGB-11-11-10 mit jeweils 6e5 für R und G und 5e5 für B.
Lastverteilung auf 48 Einheiten, obwohl 30 das auch schaffen würden? Welchen Sinn soll das denn haben außer die Anzahl der nötigen Transistoren und die Diegröße zu erhöhen?Jede ROP-Unit hängt direkt an bestimmten Speichern. Es ist sinnvoll, hier etwas überzudimensionieren, um möglichst schnell die Rasteroperationen für die gewünschte Speicheradresse zu gewährleisten.
Was man an Logik reinballert, spart man an Cache.
Gipsel
2010-03-31, 18:09:32
Jede ROP-Unit hängt direkt an bestimmten Speichern. Es ist sinnvoll, hier etwas überzudimensionieren, um möglichst schnell die Rasteroperationen für die gewünschte Speicheradresse zu gewährleisten.
Was man an Logik reinballert, spart man an Cache.Schon klar, allerdings müßte dann eine GTX480 16 GPixel/s in FP16 oder FP10 schaffen ;)
deekey777
2010-03-31, 20:47:26
(FP10 gibt es nur beim Xenos, oder?)
(FP10 gibt es nur beim Xenos, oder?)
Nein, das ist FX10.
deekey777
2010-03-31, 23:19:19
Nein, das ist FX10.
http://www.beyond3d.com/content/articles/4/4
The ROP's can handle several different formats, including a special FP10 mode. FP10 is a floating point precision mode in the format of 10-10-10-2 (bits for Red, Green, Blue, Alpha). The 10 bit colour storage has a 3 bit exponent and 7 bit mantissa, with an available range of -32.0 to 32.0.
http://www.beyond3d.com/content/articles/4/4Danke für die Aufklärung. Es gibt also doch einen FP10-Modus mit Floating Point.
=Floi=
2010-04-01, 15:16:05
kann mal jemand nachfragen, warum NV tatsächlich die texelleistung so drastisch reduziert hat? ging man hier den ati-weg?
ich bin auch gespannt, ob man diesen bereich bei den nächsten chips überproportional aufbohren wird.
kann mal jemand nachfragen, warum NV tatsächlich die texelleistung so drastisch reduziert hat? Weil sich nichts mehr ändern ließ als sich herausstellte, dass sich die TM-Units doch nicht so hoch takten lassen. Mit 64 TMUs und 810 MHz wäre man bereits auf GTX-285-Niveau.
Ailuros
2010-04-01, 18:47:55
Nein, ein GF100 kann 32 Pixel pro Takt durchbringen, 32 * 700 MHz = 22,4 GPixel/s. Damien hat hier nicht mit einem "Super-Secret-ROP-Clock" gerechnet sondern mit dem normalen halben Hotclock. Gipsels 466 MHz für die ROP's passen auch bei weitem nicht in allen Tests, ebensowenig wie meine vermuteten 620-630 MHz. Daher rührt die Verwunderung über diese Sache, da weder die eine noch die andere Spekulation überall passt.
Deswegen wäre ich dir sehr verbunden wenn du diesen Streitpunkt mit deinem nVidia Kontakt abklären könntest.
Ich hab das Gefuehl Du hast Recht. Ich hab Gipsel privat die entgueltige Antwort weitergetragen nur lass ich ihn es entziffern fuer uns damit ich nicht wieder auf die Nase falle.
Gipsel
2010-04-01, 20:13:24
Ich hab das Gefuehl Du hast Recht. Ich hab Gipsel privat die entgueltige Antwort weitergetragen nur lass ich ihn es entziffern fuer uns damit ich nicht wieder auf die Nase falle.
Leider führt aber der Verweis nvidias auf die AA samples im Moment auch nicht weiter. Damien hat das mit AA für Z-only samples gemessen, und davon können nvidias ROPs 8 Stück pro Takt durchführen. Er mißt maximal 157,6 Gsample/s:
157,6 / 48 / 8 = 410 MHz minimal nötiger Takt dafür.
Zum Vergleich eine HD5870 erreicht 107,2 GSample/s, ATIs ROPs können aber nur 4 Z-Samples pro Takt:
107,2 / 32 / 4 = 838 MHz minimal nötiger Takt, also sehr nah an den wirklichen 850MHz.
Die Frage, die nvidia beantworten müßte ist, warum eine GF100 keine 16 GPixel/s mit den nicht bandbreitenlimitierten Formaten (außer 4*Int8) schafft, also mit FP16 oder FP10. Daß die SMs die schon nur mit halber Rate an die ROPs geben können, wäre aus meiner Sicht extrem verwunderlich und keine sinnvolle Transistor-Sparmaßnahme (dadurch dürfte man kaum bis gar nicht sparen und "verschwendet" zusätzlich 16 ROPs).
=Floi=
2010-04-01, 20:44:34
ist denn das 285er niveau hoch?! ich finde nicht. der chip wurde teils massiv aufgebohrt und da hätte man schon wesentlich mehr erwarten können.
kann mal jemand nachfragen, warum NV tatsächlich die texelleistung so drastisch reduziert hat?
Vermutlich um Transistoren zu sparen, TMUs sind nicht gerade billig.
Die 64TMUs in GF104 zeigen wohl, dass GF100 mit 128 geplant war.
Als der Chip damit zu groß wurde, hat man diese wohl reduziert.
Ailuros
2010-04-02, 08:08:25
Leider führt aber der Verweis nvidias auf die AA samples im Moment auch nicht weiter. Damien hat das mit AA für Z-only samples gemessen, und davon können nvidias ROPs 8 Stück pro Takt durchführen. Er mißt maximal 157,6 Gsample/s:
157,6 / 48 / 8 = 410 MHz minimal nötiger Takt dafür.
Zum Vergleich eine HD5870 erreicht 107,2 GSample/s, ATIs ROPs können aber nur 4 Z-Samples pro Takt:
107,2 / 32 / 4 = 838 MHz minimal nötiger Takt, also sehr nah an den wirklichen 850MHz.
Die Frage, die nvidia beantworten müßte ist, warum eine GF100 keine 16 GPixel/s mit den nicht bandbreitenlimitierten Formaten (außer 4*Int8) schafft, also mit FP16 oder FP10. Daß die SMs die schon nur mit halber Rate an die ROPs geben können, wäre aus meiner Sicht extrem verwunderlich und keine sinnvolle Transistor-Sparmaßnahme (dadurch dürfte man kaum bis gar nicht sparen und "verschwendet" zusätzlich 16 ROPs).
Keine direkte Antwort bedeutet wohl schon dass irgendwo irgend etwas limitiert. Sie lassen aber auch keinen Zweifel dass die ROPs tatsaechlich auf 700MHz laufen, anders kann ich das nicht interpretieren.
Dumme Frage die ich vielleicht schon mal gestellt habe und nicht relevant zum obrigen ist: wieso berarbeitet eigentlich jeder raster nur 8 pixels/clock und nicht 12?
Triskaine
2010-04-02, 12:44:27
Ein ROP Takt von 700 MHz (also Hotclock/2) passt aber gar nicht zu den ermittelten Werten, oder nVidia hat irgendwas bei den ROPs verbockt und 16 von 48 drehen die meiste Zeit Däumchen. Also etwas ist da im Busch, nur was genau, ist bei der knappen Informationsmenge die wir besitzen, nicht feststellbar.
Ein ROP Takt von 700 MHz (also Hotclock/2) passt aber gar nicht zu den ermittelten Werten, oder nVidia hat irgendwas bei den ROPs verbockt und 16 von 48 drehen die meiste Zeit Däumchen.
Ohne MSAA machen sie das wohl auch.
The Jackal
2010-04-02, 15:10:10
Was haltet ihr davon das es noch ein Fehler im Treiber ist und das das Zusammenspiel der Latenzen zwischen SP's und ROP's nicht passt. Vieleicht ist ein delay zwischen HotClock und HalfClock schuld das die daten zu lange im Cache verweilen müssen. Man verbaut ja schließlich keine 48 ROP's wenn man nicht mehr als 32 ROP's braucht. Schließlich wenn man durch 16 teilt, kriegt man mit 32 ROP's auch eine Normalzahl raus.
Was noch sein kann, dass ein grober Designfehler drin ist und deshlab der GF100 nicht auf Leistung kommt. Das der GTX480 die 32 CudaCore's so sehr fehlen würden kann ich mir nicht vorstellen.
Gipsel
2010-04-02, 15:19:22
Dumme Frage die ich vielleicht schon mal gestellt habe und nicht relevant zum obrigen ist: wieso berarbeitet eigentlich jeder raster nur 8 pixels/clock und nicht 12?Weil Du damit nicht so leicht Warps aus 32 Pixeln bilden kannst. Das Argument habe ich schon genannt, als Du irgendwann letztes Jahr von 4x12 Pixel Rasterizern sprachst ;)
Ohne MSAA machen sie das wohl auch.Scheinbar auch mit MSAA. Genauso wie bei Farbformaten, für die die ROPs doppelt solange brauchen (FP10, FP16), wo man also auf 48/2=24 Pixel pro Takt begrenzt sein sollte, aber aus irgendeinem Grund trotzdem nicht 700 MHz * 24 = 16,8 GPixel/s rauskommen sondern nur ~10 GPixel/s.
Irgendwas paßt da noch nicht zusammen.
Irgendwas paßt da noch nicht zusammen.
Stimmt, wobei es möglicherweise teilweise einfach an Bandbreite fehlt.
=Floi=
2010-04-02, 20:51:36
testet doch erstmal mit transparentem AA. wenn da alle rops arbeiten, dann passt es ja.
ausgerechnet TAA ist extrem teuer gerade hier wünsche ich mir eine erhebliche steigerung.
testet doch erstmal mit transparentem AA. wenn da alle rops arbeiten, dann passt es ja.
ausgerechnet TAA ist extrem teuer gerade hier wünsche ich mir eine erhebliche steigerung.
Die Supersampling-Variante braucht immer viel Leistung und die MS-Variante hat noch nie wirklich Leistung gekostet, und wird es wohl auch bei GF100 nicht tun.
Gipsel
2010-04-02, 21:08:29
Stimmt, wobei es möglicherweise teilweise einfach an Bandbreite fehlt.Ich habe nicht umsonst FP10 und FP16 erwähnt, weil gerade da eben nicht die Bandbreite begrenzen kann :rolleyes:
Zum Vergleich, mit FP10 (benötigt nicht mehr Bandbreite als 4*Int8, also die ganz normale 32bit Farbtiefe) macht eine HD5870 mit 32 ROPs volle 27 GPixel/s und mit FP16 immer noch 18,2 GPixel/s (entspricht bei 8 Byte pro Pixel 145,6 GB/s von theoretischen 153,6 GB/s, die sollte eine GTX480 aber auch schaffen), eine GTX480 macht bei beiden nur 10 GPixel/s, das ist sogar noch etwas unter einer GTX285 mit nur 32 ROPs@648MHz. Das ist definitiv nicht die Bandbreite und auch bei halber Geschwindigkeit der ROPs (wie bei GTX285) für diese Formate definitiv zu wenig für 48 ROPs@700MHz.
Wir beziehen uns ja auf diese Tabelle: ... wo die GTX 480 im Vergleich zur 285 lediglich bei 1x FP32 besser abschneidet. Erstaunlich was die Karte in Spiele-Benchmarks rausholt.
Triskaine
2010-04-04, 22:02:34
Erstaunlich was die Karte in Spiele-Benchmarks rausholt.
In der Tat, relativ zu seiner mickrigen Rohleistung schlägt sich der Fermi sehr gut gegen die Konkurrenz. Vergleiche man die Rohleistung einer 5870 und einer GTX 470:
Rechenleistung: 150% Vorteil für die 5870 (2720 vs 1089 GFlops)
Texturleistung: 100% Vorteil für die 5870 (68 vs 34 GTexel/s)
Pixelleistung: 73% (?) Vorteil für die 5870 (27,2 vs 15,7 (?) GPixel/s)
Speicherbandbreite: 15% Vorteil für die 5870 (153,6 vs 134 GB/s)
Trotz dieser enormen Unterschiede, ist eine GTX 470 im Leistungsrating so schnell wie eine 5870 (plus/minus 5%). Entweder ist die Fermi-Architektur sehr effizient in ihrer Ressourcenausnutzung und/oder die 5870 sehr ineffizient. Ich denke das vor allem Fermi's ausgeklügeltes Cachesystem und das gute Geometrie-Subsystem den Ausschlag geben.
Die Evergreen-Architektur hat hingegen unter Tesselation nur einen Durchsatz von 1/3-Triangle pro Takt und hat mit Chache Misses und Bank-Conflicts im LDS zu kämpfen. Ich hoffe doch sehr das AMD hier bei der nächsten Architektur ansetzen. Rohleistung ist nicht das Problem der 5870, sondern sie auf die Straße zu bringen.
y33H@
2010-04-04, 22:04:23
Das Problem ist - die theoretischen Daten sind mittlerweile ziemlich nutzlos im Vergleich dieser Architekuren.
LovesuckZ
2010-04-04, 22:12:42
Leider führt aber der Verweis nvidias auf die AA samples im Moment auch nicht weiter. Damien hat das mit AA für Z-only samples gemessen, und davon können nvidias ROPs 8 Stück pro Takt durchführen. Er mißt maximal 157,6 Gsample/s:
157,6 / 48 / 8 = 410 MHz minimal nötiger Takt dafür.
Zum Vergleich eine HD5870 erreicht 107,2 GSample/s, ATIs ROPs können aber nur 4 Z-Samples pro Takt:
107,2 / 32 / 4 = 838 MHz minimal nötiger Takt, also sehr nah an den wirklichen 850MHz.
Die Frage, die nvidia beantworten müßte ist, warum eine GF100 keine 16 GPixel/s mit den nicht bandbreitenlimitierten Formaten (außer 4*Int8) schafft, also mit FP16 oder FP10. Daß die SMs die schon nur mit halber Rate an die ROPs geben können, wäre aus meiner Sicht extrem verwunderlich und keine sinnvolle Transistor-Sparmaßnahme (dadurch dürfte man kaum bis gar nicht sparen und "verschwendet" zusätzlich 16 ROPs).
Die Pixelleistung ist von der Anzahl der aktiven SM abhängig. So kann GF100 auch nur maximal 256 Z-Samples pro Takt berechnen - und somit GTX480 nur 240. 156,7 entsprechen somit zu 94% der theoretischen Möglichkeit.
Das Problem ist - die theoretischen Daten sind mittlerweile ziemlich nutzlos im Vergleich dieser Architekuren.
Richtig: nVidia muss mit ihrer Arch meisten immer auf 100% laufen, um eine Chance zu haben. Das wird wohl auch den Stromverbrauch mit erklären, da immer fast alle Transistoren öfters schalten müssen.
Richtig: nVidia muss mit ihrer Arch meisten immer auf 100% laufen, um eine Chance zu haben. Das wird wohl auch den Stromverbrauch mit erklären, da immer fast alle Transistoren öfters schalten müssen.
Die Armen! Wofür wird denn diese Riesenmenge an Transistoren gebraucht? Eben: Genau UM möglichst auf 100% zu laufen. Das ist der Sinn von 3 statt 2 Mrd. Schaltkreisen.
-Carsten
Die Armen! Wofür wird denn diese Riesenmenge an Transistoren gebraucht? Eben: Genau UM möglichst auf 100% zu laufen. Das ist der Sinn von 3 statt 2 Mrd. Schaltkreisen.
-Carsten
Falsche Designentscheidungen, wie die Skalaren ALUs können nun mal sehr sehr teuer werden.
Falsche Designentscheidungen, wie die Skalaren ALUs können nun mal sehr sehr teuer werden.
Natürlich sind sie teuer. Das sieht man an GT200/RV770 und jetzt an GF100/Cypress - beide Nvidia-Chips belegen wesentlich mehr zusätzliche Siliziumfläche als sie an zusätzlicher Performance bringen. Doch ob's wirklich falsch ist mag ich nicht beurteilen. Es ist eine Investition in die Zukunft, die sich auszahlen kann, aber nicht muss.
-Carsten
Natürlich sind sie teuer. Das sieht man an GT200/RV770 und jetzt an GF100/Cypress - beide Nvidia-Chips belegen wesentlich mehr zusätzliche Siliziumfläche als sie an zusätzlicher Performance bringen. Doch ob's wirklich falsch ist mag ich nicht beurteilen. Es ist eine Investition in die Zukunft, die sich auszahlen kann, aber nicht muss.
-Carsten
Mir fehlt eben etwas die Vorstellungskraft, warum gerade (pseudo)skalare und (versucht) hochgetakte Einheiten die Zukunft sein sollen.
Zusätzliche Zeit für Tools/Compilerentwicklung spricht eigentlich für VLIW und die Anforderungen an die Taktrate der skalaren ALUs dagegen.
Mir fehlt eben etwas die Vorstellungskraft, warum gerade (pseudo)skalare und (versucht) hochgetakte Einheiten die Zukunft sein sollen.
Das habe ich versucht, weiter oben zu erklären. Zumindest war das meine Interpretation dessen, warum Nvidia diesen Schritt gegangen sein könnte.
Man möchte Otto Normalentwickler dazu bringen, sich mit GPU-Computing zu beschäftigen. Und Otto Normalentwickler ist es, soweit ich weiß, nicht gewohnt, sich mit Vektorisierung usw. zu beschäftigen, sondern programmiert traditionell eher seriell. Neben der zu schaffenden Compiler-Infrastruktur, bei der du sicherlich recht hast, ist gerade bei Multi-Plattform-Entwicklung die Zeit, die für die Optimierung auf einzelne Architekturen zur Verfügung steht, ziemlich gering - das möchte man mMn auf Hardware-Ebene angehen und zumindest den Schritt der Vektorisierung entfernen.
-Carsten
Falsche Designentscheidungen, wie die Skalaren ALUs können nun mal sehr sehr teuer werden.
Die skalaren ALUs selbst sind überhaupt nicht besonders teuer, eher umgekehrt.
Durch deren Einfachheit lassen sie sich recht hoch Takten, wodurch man wieder ziemlich wenig braucht um auf eine gute Leistung zu kommen, was wieder Platz einspart.
Das drumherum bei GF100 (und teilweise auch schon bei G200) ist allerdings relativ teuer und bringt zumindest in den meisten heutigen Anwendungen nicht die notwendige Mehrleistung im Verhältnis zum Platzverbrauch.
Die skalaren ALUs selbst sind überhaupt nicht besonders teuer, eher umgekehrt.
Durch deren Einfachheit lassen sie sich recht hoch Takten, wodurch man wieder ziemlich wenig braucht um auf eine gute Leistung zu kommen, was wieder Platz einspart.
Das drumherum bei GF100 (und teilweise auch schon bei G200) ist allerdings relativ teuer und bringt zumindest in den meisten heutigen Anwendungen nicht die notwendige Mehrleistung im Verhältnis zum Platzverbrauch.
Um hohe Taktraten zu erreichen, sind ebenfalls zusätzliche Transistoren notwendig. Zusätzlcih benötigt man eine verhältnismäßig geringe Packdichte in diesem Bereich.
Wenn man dann nicht einmal ein 2:1 Verhältnis zum Takt der restlichen Einheiten erreicht, ist das kein besonders gelungenes Design.
Um hohe Taktraten zu erreichen, sind ebenfalls zusätzliche Transistoren notwendig.
Könnte sein, muss es aber nicht. Um hohe Taktraten zu erreichen kann man entweder die Pipeline verlängern, was natürlich Transistoren kostet, oder die einzelnen Pipelinestufen so einfach machen, dass sie extrem schnell werden, was eher noch Transistoren spart. Ich vermute mal, dass Nvidia eher den 2. Weg gewählt hat. Wenn man einen DIE-Shot ansieht, sind die ALUs bei NV immer noch verdammt klein (und das mit DP@ half rate), vor G200 waren sie sogar winzig.
Zusätzlcih benötigt man eine verhältnismäßig geringe Packdichte in diesem Bereich.
Stimmt, das ist aber weniger schlimm, da für die ALUs selbst recht wenig Transistoren benötigt werden. Um das skalare Design, welches ja eigentlich gar kein skalares ist sondern mit 8-way-SIMDs aufgebaut ist, braucht man relativ viele Zwischenspeicher, welches sich bekanntermaßen sehr dicht packen lassen.
Wenn man dann nicht einmal ein 2:1 Verhältnis zum Takt der restlichen Einheiten erreicht, ist das kein besonders gelungenes Design.
Man erreicht ja auch ein 2:1-Verhältnis. Das Design würde wahrscheinlich sogar noch mehr zulassen, nur ist die Fertigung so schlecht, dass der eh schon verdammt hohe Stromverbrauch noch mehr ausufern würde.
Ich beziehe mich allerdings nicht auf ein spezifisches Produkt sondern auf den Vergleich (pseudo)skalar gegenüber VLIW und wehre mich gegen die Aussage, dass eines grundsätzlich besser als das andere ist.
Wenn es um (Spiele)Performance/Transistor geht, hat das Ur G80/G92-Design die Nase immer noch deutlich vorne, gegen beide Designs, von ATI und NV. Und dieses war bereits ein (pseudo)skalares Design.
Nachdem die damaligen kleineren GPUs relativ viele Transistoren für doch recht starke Abspeckungen gebraucht hat kann man eher davon ausgehen, dass das Verhältnis mit einer Skalierung nach oben eher noch besser geworden wäre.
Richtig: nVidia muss mit ihrer Arch meisten immer auf 100% laufen, um eine Chance zu haben. Das wird wohl auch den Stromverbrauch mit erklären, da immer fast alle Transistoren öfters schalten müssen.
Teilweise.
Nvidia hat wesentlich weniger Rohleistung, die dafür aber auch wesentlich besser ausgelastet wird.
Allerdings hat Nvidia dafür auch wesentlich weniger "Arbeitstransistoren" und dafür wesentlich mehr die aufpassen, dass diese auch wirklich immer arbeiten. Deshalb müssen auch nicht zwangsweise immer wirklich alle Transistoren schalten.
Gipsel
2010-04-05, 15:33:31
Leider führt aber der Verweis nvidias auf die AA samples im Moment auch nicht weiter.
[..]
Die Frage, die nvidia beantworten müßte ist, warum eine GF100 keine 16 GPixel/s mit den nicht bandbreitenlimitierten Formaten (außer 4*Int8) schafft, also mit FP16 oder FP10.
Die Pixelleistung ist von der Anzahl der aktiven SM abhängig. ...
Da sagst Du nichts Neues. Am besten liest Du Dir nochmal die Posts auf den letzten paar Seiten vorher durch ;)
Zu der von mir formulierten Frage hast Du ja offensichtlich nichts Aufhellendes beitragen können, da ist man nämlich weit von der Limitierung auf 2 Pixel/SM und Takt entfernt. :rolleyes:
In der Tat, relativ zu seiner mickrigen Rohleistung schlägt sich der Fermi sehr gut gegen die Konkurrenz. Vergleiche man die Rohleistung einer 5870 und einer GTX 470:
Rechenleistung: 150% Vorteil für die 5870 (2720 vs 1089 GFlops)
Texturleistung: 100% Vorteil für die 5870 (68 vs 34 GTexel/s)
Pixelleistung: 73% (?) Vorteil für die 5870 (27,2 vs 15,7 (?) GPixel/s)
Speicherbandbreite: 15% Vorteil für die 5870 (153,6 vs 134 GB/s)
Trotz dieser enormen Unterschiede, ist eine GTX 470 im Leistungsrating so schnell wie eine 5870 (plus/minus 5%). Entweder ist die Fermi-Architektur sehr effizient in ihrer Ressourcenausnutzung und/oder die 5870 sehr ineffizient. Ich denke das vor allem Fermi's ausgeklügeltes Cachesystem und das gute Geometrie-Subsystem den Ausschlag geben.GF100 hat immerhin mehr als doppelt so viele Transistoren wie GT200, aber ist keineswegs doppelt so schnell. So gesehen ist die Effizienz nur pro Rechenwerk gut, aber nicht pro Transistor. Die 5870 hat mit nur rund 40% mehr Transistoren als GT200 auch vergleichbar mehr Leistung plus DirectX11-Support.
Beim GT200 war ich erst skeptisch ob der Weg einer großen Einzel-GPU sinnvoll ist. Diese GPU hat ungefähr doppelt so viele Transistoren wie G92, aber ist keineswegs doppelt so schnell. Betrachtet man den GT200 oder GF100 als GPU welche SLI (für die meisten User) überflüssig machen, ergibt es aber Sinn: Man hat die Leistung die man hat wirklich, ohne Mikroruckler.
Bei der GTX 470 erwarte ich dass mit Treiber-Updates ein echter Gleichstand zur 5870 hergestellt werden kann. Möglicherweise gibt es davon noch Spezialversionen von den Herstellern mit besonders leiser Kühlung.
Gipsel
2010-04-05, 15:52:51
Man möchte Otto Normalentwickler dazu bringen, sich mit GPU-Computing zu beschäftigen. Und Otto Normalentwickler ist es, soweit ich weiß, nicht gewohnt, sich mit Vektorisierung usw. zu beschäftigen, sondern programmiert traditionell eher seriell. Neben der zu schaffenden Compiler-Infrastruktur, bei der du sicherlich recht hast, ist gerade bei Multi-Plattform-Entwicklung die Zeit, die für die Optimierung auf einzelne Architekturen zur Verfügung steht, ziemlich gering - das möchte man mMn auf Hardware-Ebene angehen und zumindest den Schritt der Vektorisierung entfernen.
-Carsten
Die Vektorisierung ist auch gar nicht nötig. Die VLIW-Einheiten sind ja gerade keine Vektoreinheiten, jeder der Slots kann was anderes machen. Der Compiler ist nicht schlecht darin, Parallelität im Code zu finden. Man muß sich fast schon anstrengen, um weniger als 50% Füllrate der Slots zu erreichen. Und das ist ja schon der Break-Even beim Vergleich zu nvidia.
Im Prinzip kann mann es so wie die superskalaren CPUs sehen, die haben ja auch mehrere parallele Pipelines für einen Thread. Dabei fallen bei GPUs häufig noch Operationen an (z.B. Adressberechnungen), die die normalen ALUs übernehmen müssen, so daß typischerweise etwas höherer ILP und (wegen der guten Möglichkeiten Latenzen zu verstecken) auch ein höherer IPC als bei CPUs herauskommt.
Eine explizite Vektorisierung hilft auf ATIs zwar oft, ist aber je nach Problem nicht nötig (z.B. sind MW@home aber auch Collatz@home *nicht* vektorisiert und man vergleiche mal die Performance von ATI zu nv ;)). Dabei sollte man im Hinterkopf behalten, daß GPUs sowieso vom Prinzip her Vektorrechner sind, auch nvidia-GPUs arbeiten mit einer Vektorlänge von mindestens 32 Werten (meist noch mehr, eine Workgroup bzw. Threadblock ist die logische Vektorlänge). Wenn ein Problem also prinzipiell nicht vektorisierbar ist, läuft das sowieso grottig und ist für GPUs nicht geeignet. ATIs bieten jetzt praktisch 4 bzw. 5 parallele Vektorpipelines, nvidia-GPUs eben nur eine. Das ist der eigentliche Unterschied. Wenn nvidia "skalare" Vektoreinheiten bietet (:rolleyes:), dann hat ATI "superskalare" Vektoreinheiten :lol:
Gipsel,
50% Auslastung IST evil. Was Milkyway und Collatz machen, muss ich dir mal glauben, davon habe ich keine Ahnung. (Viele?) andere Programme werden aber offenbar lange nicht mit zufriedenstellender oder gar voller Effizienz ausgeführt. Der Compiler ist da noch nicht so auf Zack, wie du es hier beschreibst:
http://www.golubev.com/blog/?p=35
Ist aber vielleicht auch nur die Ausnahme? Schön wär's ja.
-Carsten
Eine explizite Vektorisierung hilft auf ATIs zwar oft, ist aber je nach Problem nicht nötig (z.B. sind MW@home aber auch Collatz@home *nicht* vektorisiert und man vergleiche mal die Performance von ATI zu nv ;)). Dabei sollte man im Hinterkopf behalten, daß GPUs sowieso vom Prinzip her Vektorrechner sind, auch nvidia-GPUs arbeiten mit einer Vektorlänge von mindestens 32 Werten (meist noch mehr, eine Workgroup bzw. Threadblock ist die logische Vektorlänge). Wenn ein Problem also prinzipiell nicht vektorisierbar ist, läuft das sowieso grottig und ist für GPUs nicht geeignet. ATIs bieten jetzt praktisch 4 bzw. 5 parallele Vektorpipelines, nvidia-GPUs eben nur eine. Das ist der eigentliche Unterschied. Wenn nvidia "skalare" Vektoreinheiten bietet (:rolleyes:), dann hat ATI "superskalare" Vektoreinheiten :lol:
Vektorisierbar != Parallelisierbar. Ich denke das muss man schon unterscheiden.
Aber ja, ATIs VLIW-Einheiten sind superskalar. Da brauchst du nichtmal drüber lachen ;)
Gipsel
2010-04-05, 17:52:23
Vektorisierbar != Parallelisierbar. Ich denke das muss man schon unterscheiden.Genau darauf wollte ich hinweisen. Parallele Einheiten machen eben auch bei nicht vektorisiertem Code Sinn ;)
Aber ja, ATIs VLIW-Einheiten sind superskalar. Da brauchst du nichtmal drüber lachen ;)Nun, da ist eigentlich gar nichts skalar. Nvidia hat Vektoreinheiten, ATI hat mehrere parallele Vektorlanes. Wenn man will, kann man das in Analogie zu superskalaren Prozessoren als supervektoriell bezeichnen. Aber das ist sowieso alles nur Semantik. Ich habe mich über das Oxymoron der "skalaren Vektoreinheiten" amüsiert, was auch nur ein Ausdruck der Begriffsverwirrung ist, sobald es um Threads, Cores usw. bei GPUs geht.
Genau darauf wollte ich hinweisen. Parallele Einheiten machen eben auch bei nicht vektorisiertem Code Sinn ;)
Nein du verstehst mich nicht.
Threadparallität ist etwas anderes als Instruction-Level-Parallalität. Nur letzteres hat etwas mit Vektorisierbarkeit zu tun.
Nun, da ist eigentlich gar nichts skalar. Nvidia hat Vektoreinheiten, ATI hat mehrere parallele Vektorlanes. Wenn man will, kann man das in Analogie zu superskalaren Prozessoren als supervektoriell bezeichnen. Aber das ist sowieso alles nur Semantik. Ich habe mich über das Oxymoron der "skalaren Vektoreinheiten" amüsiert, was auch nur ein Ausdruck der Begriffsverwirrung ist, sobald es um Threads, Cores usw. bei GPUs geht.
Das ist dein Nomenklatur-Problem, weil du Thread-Level-Parallelität mit Vektorisierung bezeichnest. Das machen aber weder ATI noch NVIDIA in ihren Dokumenten.
Ich sage nicht, dass die Begriffe auch schonmal anders verwendet wurden, aber zur Klarheit sollten wir uns daran halten.
Gipsel
2010-04-05, 18:15:08
Gipsel,
50% Auslastung IST evil.Nein. Wenn Du doppelte Rohleistung auf zwei Dritteln der Die-Fläche hast, kann man damit in meinen Augen ziemlich gut leben ;)
Was Milkyway und Collatz machen, muss ich dir mal glauben, davon habe ich keine Ahnung. (Viele?) andere Programme werden aber offenbar lange nicht mit zufriedenstellender oder gar voller Effizienz ausgeführt. Der Compiler ist da noch nicht so auf Zack, wie du es hier beschreibst:
http://www.golubev.com/blog/?p=35
Ist aber vielleicht auch nur die Ausnahme? Schön wär's ja.
Was ist denn bei dem Link zu sehen, was gegen eine passable Ausnutzung der Parallelität durch den Compiler spricht? Ich sehe da nämlich gerade nichts. Übrigens lautet die Schlußfolgerung aus Deinem Link:
With all above notes in mind — HD 5770/512MB currently is most cost efficient GPU for MD5/SHA1 hashing.
Übrigens läuft Collatz auf ATIs auch nur bei um die 50% Auslastung (zwischen 45 und 60%, je nach GPU-Generation) der Slots und ist trotzdem auf einer HD5870 etwa dreieinhalb mal so schnell wie mit einer GTX285. Wäre mal nett, das mit Fermi zu testen, da die nvidias bisher an ihrer grottigen Integer-Multiplikations-Performance scheitern. Und gerade die soll doch bei Fermi ordentlich aufgebessert worden sein.
Bei Milkyway (ATIs mit mehr als Faktor 6 Vorsprung zu einer GTX285 bei >80% Auslastung ohne Vektorisierung, aber die ist bei DP auch nicht notwendig, da dann die VLIW-Einheiten praktisch wie skalare arbeiten) wird es ja eher nichts werden, da die Geforce-Karten ja wohl auf ein Viertel ihrer theoretischen DP-Geschwindigkeit eingebremst werden, also selbst eine GTX480 nur 90% schneller als eine GTX285 wird.
Gipsel
2010-04-05, 18:23:37
Nein du verstehst mich nicht.Doch ;)
Threadparallität ist etwas anderes als Instruction-Level-Parallalität. Nur letzteres hat etwas mit Vektorisierbarkeit zu tun.Nur ist ein "Thread" eben kein wirklicher Thread, sondern auch nur ein Vektor-Slot. OpenCL nennt das mit "work item" viel treffender.
Das ist dein Nomenklatur-Problem, weil du Thread-Level-Parallelität mit Vektorisierung bezeichnest. Das machen aber weder ATI noch NVIDIA in ihren Dokumenten.
Ich sage nicht, dass die Begriffe auch schonmal anders verwendet wurden, aber zur Klarheit sollten wir uns daran halten.Weswegen nicht ich ein Nomenklatur-Problem habe (ich weiß genauso wie Du, was was ist), sondern die beiden Hersteller durch Verwendung schwammiger Begriffe oder auch Umdefinition bereits bestehender und etablierter Bezeichnungen zur Verwirrung beitragen.
Ich habe schon mal gesagt, daß man sich vielleicht auf die OpenCL-Nomenklatur einigen sollte ;)
Nur ist ein "Thread" eben kein wirklicher Thread, sondern auch nur ein Vektor-Slot.
Nach außen verhält es sich wie ein Thread, wie es intern in der GPU gelöst ist und wie die Granularität ist, spielt doch keine Rolle.
"Work Item" finde ich übrigens überhaupt nicht gut. Es geht nicht um einen "Gegenstand" sondern um einen unabhängigen Programmfluss.
Nein. Wenn Du doppelte Rohleistung auf zwei Dritteln der Die-Fläche hast, kann man damit in meinen Augen ziemlich gut leben ;)
Ein schlankes Design ist trotzdem was anderes.
Was ist denn bei dem Link zu sehen, was gegen eine passable Ausnutzung der Parallelität durch den Compiler spricht? Ich sehe da nämlich gerade nichts. Übrigens lautet die Schlußfolgerung aus Deinem Link:
In meinem Link ist unter anderem das zu sehen:
"4. ATI Stream SDK quality is still very questionable, it’s much harder to program ATI GPUs to get peak performance"
Und genau das ist das Problem. Wer viel Zeit hat oder von Natur aus ein begabter Programmierer ist, kann das sicher alles lösen. Der Durchschnitts-Coder jedoch kann oder will oder darf (Arbeitgeber, Zeitbudget etc.) sich nicht allzu viel mit sowas beschäftigen.
Was die 5770 zur "effizientesten" GPU macht, sind unter anderem die Bitshifts und die INT-Performance. Ich bin auch gespannt, wie sich Fermi schlägt, leider liefen Globulevs Programme noch nicht, da er wohl nicht PTX zur JIT-Erzeugung nutzt, sondern die GPUs direkt anspricht (noch so ein winziger Nachteil von handoptimiertem Code, wenn er auch dieses Mal Nvidia betrifft).
Übrigens läuft Collatz auf ATIs auch nur bei um die 50% Auslastung (zwischen 45 und 60%, je nach GPU-Generation) der Slots und ist trotzdem auf einer HD5870 etwa dreieinhalb mal so schnell wie mit einer GTX285. Wäre mal nett, das mit Fermi zu testen, da die nvidias bisher an ihrer grottigen Integer-Multiplikations-Performance scheitern. Und gerade die soll doch bei Fermi ordentlich aufgebessert worden sein.
INT-MUL ist bei Fermi ziemlich gut. In AMDs Shadertest für DX10 ist sie sowohl bei skalarem als auch vierfach parallelem Code deutlich fixer als die Radeon. Die T-Unit kann IIRC auch keine INT-MULs, oder?
Bei Milkyway (ATIs mit mehr als Faktor 6 Vorsprung zu einer GTX285 bei >80% Auslastung ohne Vektorisierung, aber die ist bei DP auch nicht notwendig, da dann die VLIW-Einheiten praktisch wie skalare arbeiten) wird es ja wohl eher nichts werden, da die Geforce-Karten ja wohl auf ein Viertel ihrer theoretischen DP-Geschwindigkeit eingebremst werden, also selbst eine GTX480 nur 90% schneller als eine GTX285 wird.
Wie gesagt: Keine Ahnung von Milkyway, aber DP der aktuellen Radeon-Generation gegen DP der vorigen NV-Generation sollte um mehr als Faktor 6 auseinandergehen (ok, nachgerechnet: 6,14272…).
Gegen eine GTX 480 sind's dann nur noch Faktor 3,23809… ;D
-Carsten
Gipsel
2010-04-05, 18:36:52
Nach außen verhält es sich wie ein Thread, wie es intern in der GPU gelöst ist und wie die Granularität ist, spielt doch keine Rolle.
"Work Item" finde ich übrigens überhaupt nicht gut. Es geht nicht um einen "Gegenstand" sondern um einen unabhängigen Programmfluss.
Und der unabhängige Programmfluß ist eben genau das, was bei einer SIMD-Lösung (wie bei GPUs) nicht wirklich funktioniert. Nur für bestimmte einfache Strukturen geht das (üblicherweise mit Performance-Verlust), aber nicht allgemein. Genau der unabhängige Programmfluß würde nämlich den echten Thread vom Vektor-Slot einer SIMD-Maschine (GPU-Thread) unterscheiden.
Und der unabhängige Programmfluß ist eben genau das, was bei einer SIMD-Lösung (wie bei GPUs) nicht wirklich funktioniert.
Natürlich funktioniert es. Und zwar völlig transparent. Bei einem echten Vektorrechner musst du manuell dafür programmieren und Branch-Divergenzen auflösen, etc.
Performance spielt doch für Bezeichnungen überhaupt keine Rolle.
Gipsel
2010-04-05, 19:05:12
Ein schlankes Design ist trotzdem was anderes.Wieso? Eine HD5870 ist doch schlank gegenüber einer GTX480 ;)
In meinem Link ist unter anderem das zu sehen:
"4. ATI Stream SDK quality is still very questionable, it’s much harder to program ATI GPUs to get peak performance"
Das war aber nicht mein Punkt. Peak-Performance wäre ja zwei mal so viel wie die Konkurrenz. 50% davon reichen doch ;)
Und genau das ist das Problem. Wer viel Zeit hat oder von Natur aus ein begabter Programmierer ist, kann das sicher alles lösen. Der Durchschnitts-Coder jedoch kann oder will oder darf (Arbeitgeber, Zeitbudget etc.) sich nicht allzu viel mit sowas beschäftigen.Und wie gesagt, benötigt der aber auch nur 50% der Peak-Performance, um mit nvidias Shaderperformance gleichzuziehen. Dazu bedarf es meist keiner speziellen Optimierung.
Über die Qualität der von nvidia bereitgestellten Tools müssen wir nicht diskutieren. Aber dies ist immer noch ein "Architektur und Technologie"-Thread, wir diskutieren also die Hardware.
INT-MUL ist bei Fermi ziemlich gut. In AMDs Shadertest für DX10 ist sie sowohl bei skalarem als auch vierfach parallelem Code deutlich fixer als die Radeon. Die T-Unit kann IIRC auch keine INT-MULs, oder?*Nur* die t-unit kann momentan 32bit Integer-MULs (xyzw nur 24 bit bei HD5000er, vorher gar keine). Theoretisch können xyzw mit ihren je 24 bit Multis kombiniert werden (wie für DP) um zusätzlich (zur t-Einheit) eine zweite 32bit Integer-Multiplikation auszuführen. Allerdings ist dies bisher weder dokumentiert noch im Compiler freigeschaltet.
Für Collatz gibt es mehrere Faktoren, die kritisch sind. Bei nvidia ist es wie gesagt momentan die reine Multiplikations-Performance. Bei den HD2000/3000ern ist es insgesamt der Durchsatz der T-Einheit, da auch Bitshifts (wie auch Multiplikationen) nur dort ausgeführt werden können. Die HD4000er können dann Bitshifts in allen ALUs, dort limitiert die Latenz der Carry-Berechnung für die großen Integer-Zahlen (192 Bit). HD5000er haben einen zusätzlichen ADDCARRY-Befehl, der diesen Flaschenhals wirksam eliminiert. Zusätzlich können die HD5000er effektiv Bitshifts von 64 Bit-Werten ausführen (nur eine Instruktion statt drei dafür nötig), so daß dann schlußendlich bei den HD5000ern die reine Multiplikationsperformance limitiert. Es ist nicht gesagt, daß dies bei Fermi genau so ist (also die Steigerung der Int-MULs sich 1:1 wiederfinden), oder der nicht an einer der anderen Hürden hängen bleibt.
Dazu kommt noch, daß stark auf den Speicher zugegriffen wird. Eng wird es hier bei pseudo-zufälligen Zugriffen auf eine 16MB große Lookup-Table (16 Byte pro Zugriff werden gelesen). Hier kommt es also auch auf die Güte des Speichercontrollers an. Eine HD5870 schafft hier schon um die 100 GB/s genutzte Speicherbandbreite (die Hitrates der Cache dürften ziemlich mies sein). Damit sich Fermi deutlich absetzen kann, muß also auch dieser Teil stimmen.
Gipsel
2010-04-05, 19:10:36
Natürlich funktioniert es. Und zwar völlig transparent. Nein. Bestimmte Kontrollstrukturen funktionieren eben nur zwischen Hardware-Threads (oder was machen die Befehle zum Synchronisieren von thread blocks bzw. work groups?) bzw. sogar nur zwischen verschiedenen Kerneln. Ein Thread in einem Warp kann eben nicht einfach unabhängig von den anderen weiterlaufen, ein Producer-Consumer Modell innerhalb einer Workgroup z.B. führt deswegen außer für ganz simple Konstrukte auf GPUs sicher zu einem deadlock.
Da gab es auf B3D vor ein paar Monaten mal eine ausführliche Diskussion zu.
Gipsel
2010-04-05, 19:31:34
Natürlich funktioniert es. Und zwar völlig transparent. Bei einem echten Vektorrechner musst du manuell dafür programmieren und Branch-Divergenzen auflösen, etc.
Performance spielt doch für Bezeichnungen überhaupt keine Rolle.
Da fällt mir noch ein, hast Du Dir mal den ISA-Code für irgendwas mit Branches angesehen? Der Kontrollfluß für die SIMD-Lanes (üblicherweise das Aus- und Wiederanknipsen der betreffenden Lane) wird doch auch explizit gemacht. Daß das der Compiler für einen macht, heißt doch nicht, daß die traditionellen Einschränkungen deswegen aufgehoben wären. Das Programmiermodell mag oberflächlich anders aussehen, die Grundlage, auf der der Code ausgeführt wird, ist es aber nicht.
Spasstiger
2010-04-05, 19:33:33
Fermi bricht bei AA+AF net so ein wie die ATI`S.
Der GF100 bricht mit AF stärker ein als der Cypress: http://www.computerbase.de/artikel/grafikkarten/2010/test_nvidia_geforce_gtx_480/5/#abschnitt_skalierungstests
AA liegt allerdings dem GF100 etwas besser. Hohe Auflösungen kommen wiederum dem Cypress zu Gute.
LovesuckZ
2010-04-05, 19:34:52
Der GF100 bricht mit AF stärker ein als der Cypress: http://www.computerbase.de/artikel/grafikkarten/2010/test_nvidia_geforce_gtx_480/5/#abschnitt_skalierungstests
AA liegt allerdings dem GF100 etwas besser. Hohe Auflösungen kommen wiederum dem Cypress zu Gute.
Hohe Auflösungen kommen Cypress nicht zu gute.
Spasstiger
2010-04-05, 19:43:03
Hohe Auflösungen kommen Cypress nicht zu gute.
Doch, weil der Abstand zwischen dem GF100 und dem Cypress mit zunehmender Auflösung schrumpft. ATI hat SGSSAA und Eyefinity zum richtigen Zeitpunkt in die Featureliste reingepackt. Bei niedrigen Auflösungen verpufft die hohe Rechenleistung und Texelfüllrate.
=Floi=
2010-04-05, 21:50:37
Nein. Wenn Du doppelte Rohleistung auf zwei Dritteln der Die-Fläche hast, kann man damit in meinen Augen ziemlich gut leben ;)
ist das denn wirklich gut? ich finde eine ausgewogene und brauchbare architektur wesentlich besser, als eine nicht ausgewogene. was nützt mir die theoretische rechenleistung, wenn ich sie nicht nutzen kann? die shadereinheiten bei ati kann ich quasi nur in techdemos auslasten und ansonsten?! kein physx und auch durch die shaderlast werden diese karte nicht ausgelastet. es gibt kein wirkliches GPGPU und sonst schafft es der sheduler auch nicht alle einheiten auszulasten. tja wofür dann das ganze?
was nützen mir 500ps, wenn ich nur ein dreigang-getriebe habe?
über die shaderleistung des RV670 spricht quasi keiner mehr... :rolleyes:
ist das denn wirklich gut? ich finde eine ausgewogene und brauchbare architektur wesentlich besser, als eine nicht ausgewogene. was nützt mir die theoretische rechenleistung, wenn ich sie nicht nützen kann? die shadereinheiten bei ati kann ich quasi nur in techdemos auslasten und ansonsten?! kein physx und auch durch die shaderlast werden diese karte nicht ausgelastet. es gibt kein wirkliches GPGPU und sonst schafft es der sheduler auch nicht alle einheiten auszulasten. tja wofür dann das ganze?
was nützen mir 500ps, wenn ich nur ein dreigang-getriebe habe?
über die shaderleistung des RV670 spricht quasi keiner mehr... :rolleyes:
Wo war die Shaderleistung des rv670 dem g80 weit überlegen?
Die Auslastung der Einheiten ist doch nicht schlecht.
Lieber viele Einheiten , die nicht so gut ausgelastet sind, als wenige die zwar gut ausgelastet, aber trotzdem mehr Diespace und Energie verbrauchen.
Gipsel
2010-04-05, 22:42:55
ist das denn wirklich gut? ich finde eine ausgewogene und brauchbare architektur wesentlich besser, als eine nicht ausgewogene. was nützt mir die theoretische rechenleistung, wenn ich sie nicht nutzen kann? die shadereinheiten bei ati kann ich quasi nur in techdemos auslasten und ansonsten?! kein physx und auch durch die shaderlast werden diese karte nicht ausgelastet. es gibt kein wirkliches GPGPU und sonst schafft es der sheduler auch nicht alle einheiten auszulasten. tja wofür dann das ganze?
was nützen mir 500ps, wenn ich nur ein dreigang-getriebe habe?Und was nützt mir ein 7-Gang sequentielles Getriebe, wenn unter der Haube nur ein 50PS Motörchen werkelt? Dann lieber nur 3 Gänge und dafür 500PS, da kommst Du selbst im zweiten Gang noch schneller von der Ampel weg ;)
Das Problem ist, daß man immer einen Kompromiß machen muß. ATIs Kompromiß sieht so aus, daß man viele Shader auf den Chip packt und an den Steuerung etwas spart. Dadurch verschenkt man Auslastung, ganz klar. Nvidia versucht, die Einheiten gut auszulasten und investiert dafür in eine sehr aufwendige Steuerung der Einheiten. Deswegen können sie auch gar nicht so viele Einheiten wie ATI auf der gleichen Fläche integrieren. Was kommt jetzt raus?
ATI hat im Prinzip jetzt auf zwei Dritteln der Fläche die doppelte Rohleistung. Deswegen kann man es sich leisten, 50% dieser Leistung durch schlechtere Auslastung direkt wieder zu verschenken und kommt immer noch günstiger weg, da man erheblich weniger Transistoren und Die-Fläche dafür investieren mußte. Was ist jetzt der ausgewogenere Chip?
Wenn nvidia durch Verzicht auf etwas Kontrollogik und Auslastung 50% mehr Einheiten hätte unterbringen können und dies zu einer durchschnittlich höheren Performance führen würde, wäre das für mich ausgewogener. Wenn man durch 20% mehr Transistoren die Auslastung von 90% auf 95% hochtreibt, ist dies ineffizient, 20% mehr Einheiten bringen üblicherweise eine höhere Performance. Insofern kann man sagen, daß nvidia eher zuviel Kontrollogik verbaut, ATI vielleicht etwas zu wenig. Am Ende zählt, was hinten an Performance/mm², Performance/W oder Performance/Euro herauskommt. Wer da vorne liegt, hat den ausgewogeneren Chip gebaut. Ganz einfach.
Da fällt mir noch ein, hast Du Dir mal den ISA-Code für irgendwas mit Branches angesehen? Der Kontrollfluß für die SIMD-Lanes (üblicherweise das Aus- und Wiederanknipsen der betreffenden Lane) wird doch auch explizit gemacht.
Ich verstehe nicht genau was du damit meinst, aber statisch kann da gar nichts entschieden werden und alles andere ist ein Implementierungsdetail.
Daß das der Compiler für einen macht, heißt doch nicht, daß die traditionellen Einschränkungen deswegen aufgehoben wären. Das Programmiermodell mag oberflächlich anders aussehen, die Grundlage, auf der der Code ausgeführt wird, ist es aber nicht.
Ein traditioneller Vektorrechner hat Instructions um eine Operation auf ein Array parallel anzuwenden. Dabei läuft nur ein Thread. Das ist schon ein gewaltiger Unterschied zu dem was wir in GPUs haben.
LovesuckZ
2010-04-05, 23:55:24
Doch, weil der Abstand zwischen dem GF100 und dem Cypress mit zunehmender Auflösung schrumpft. ATI hat SGSSAA und Eyefinity zum richtigen Zeitpunkt in die Featureliste reingepackt. Bei niedrigen Auflösungen verpufft die hohe Rechenleistung und Texelfüllrate.
Der Abstand wird geringer, weil der Berechnungsanteil mehr in Richtung Pixel wandert und mehr Bandbreite benötigt wird.
Dagegen gewinnt GF100 bei Veringerung der Auflösung deutlich mehr an Leistung, da der Anteil an Geometrie zu Pixelberechnungen sich in Richtung Geometrie ändert. Da Cypress in hohen Auflösungen immer noch langsamer als GF100 ist und in vielen Fällen beide unspielbar sind, wird der Abstand zwischen GF100 und Cypress größer. Man hat also mehr Reserven für zukünftige Spiele - siehe auch Metro.
Gipsel
2010-04-06, 11:15:28
Ich verstehe nicht genau was du damit meinst, aber statisch kann da gar nichts entschieden werden und alles andere ist ein Implementierungsdetail.Wieso statisch? Das Maskieren der Lanes in Abhängigkeit der dort vorliegenen Daten erfolgt nicht statisch.
Ein traditioneller Vektorrechner hat Instructions um eine Operation auf ein Array parallel anzuwenden. Dabei läuft nur ein Thread. Das ist schon ein gewaltiger Unterschied zu dem was wir in GPUs haben.Ähm, das ist genau das, was GPUs auch machen. Ein Befehl wird auf alle "work items" oder "Threads" im GPU-Sprech in einem Warp/einer Wavefront parallel angewendet. Die übergreifenden Einheiten, sozusagen die "Kerne" bei den ATIs, heißen nicht umsonst auch offiziell "SIMD Engine". Die echten Hardware-Threads sind die Wavefronts oder bei nvidia eben die Warps. Logisch gesehen ist eine Workgroup bzw. ein Threadblock die Vektorlänge, bei (normalen) Pixelshadern gar alle vom Kernel prozessierten Pixel.
Wieso? Eine HD5870 ist doch schlank gegenüber einer GTX480 ;)
Das war aber nicht mein Punkt. Peak-Performance wäre ja zwei mal so viel wie die Konkurrenz. 50% davon reichen doch ;)
Schlank und elegant war die 9600 XT. Die HD 5870 ist aus Spielersicht schlank, aus der GPU-Computing-Perspektive doch eher ein 100m-Hallensprinter als ein Mittel- oder Langstrecken Crossläufer.
-Carsten
Ailuros
2010-04-08, 14:27:52
http://www.pcgameshardware.de/aid,744470/Geforce-GTX-470/480-Fuellraten-Raetsel-geloest/Grafikkarte/Test/
Wird immer seltsamer, warum man unbedingt 48ROPs verbaut hat, mit nur 32 ROPs und dafür 128 TMUs wäre die Leistung wohl deutlich höher.
8x-AA-Leistung, Bandbreite allgemein, L2-Cache-Größe.
-Carsten
Ailuros
2010-04-09, 12:36:24
8x-AA-Leistung, Bandbreite allgemein, L2-Cache-Größe.
-Carsten
Nur ist es eine ziemlich verkorkste Methode 8xMSAA Leistung zu skalieren wenn ich mir ansehe was im Bereich 8xMSAA ein Cypress mit 32 ROPs anstellen kann.
Sag' das Nvidia. :)
Mir ist 8x MSAA sowieso egaler als egal, solange ich irgendeine Form von Supersampling bekommen kann.
-Carsten
Wird immer seltsamer, warum man unbedingt 48ROPs verbaut hat, mit nur 32 ROPs und dafür 128 TMUs wäre die Leistung wohl deutlich höher.
Ich würde mal stark vermuten, dass 64 TMUs weitaus mehr Platz brauchen als 16 ROPs.
Ich würde mal stark vermuten, dass 64 TMUs weitaus mehr Platz brauchen als 16 ROPs.
Mit den ROPs fallen ja auch die Speichercontroller und entsprechenden L2-Cacheanteile weg.
Ob das für 64 weitere TMUs gereicht hätte kann man von Außen natürlich nicht sagen, aber selbst wenn es dann statt 3 3,2Mrd. Transistoren geworden wären, macht das auch nicht mehr viel aus.
Man hätte es ja auch noch alá G80 machen können um ein paar Transistoren zu sparen.
Man hätte es ja auch noch alá G80 machen können um ein paar Transistoren zu sparen.Man könnte sich immer mehr wünschen. Platz für Performance-Steigerungen ist aber erst in einem Refresh-Chip.
mapel110
2010-04-20, 23:30:34
http://www.pcgameshardware.de/aid,701966/Nackte-Platinen-Ueber-40-Grafikkarten-unter-den-Kuehler-geschaut-Update-Geforce-GTX-4x0/Grafikkarte/Test/
529mm² die size für GF100, aber ob die Angabe stimmt?! GT200 wird dort mit 607mm² angegeben, obwohl er doch afaik 576mm² hat?!
http://hardforum.com/showthread.php?t=1325165
Wo soll da ein GF100 ohne HS sein?
Bei den Messungen auf der Karte muss man etwa 0,5mm pro Seite abziehen, die der Schutzschicht entsprechen.
Sollte GF100 529mm² auf dem Package groß sein, so könnten es auf dem Wafer nur knapp über 500mm² sein.
Ailuros
2010-04-23, 10:26:36
Uebrigens TeslaC20 auf NV's Seite jetzt:
http://www.nvidia.com/object/product_tesla_C2050_C2070_us.html
Delivers up to 515 Gigaflops of double-precision peak performance in each GPU, enabling a single workstation to deliver a Teraflop or more of performance. Single precision peak performance is over a Teraflop per GPU.
448*1.15GHz = 515 GFLOPs DP, 247W TDP
Bei TeslaS20 (1-U rack mounts) skaliert die Frequenz von 1.2 bis 1.4GHz mit 900W TDP (typical), ergo handausgesuchte chips nur fuer die clusters (S20).
Wo soll da ein GF100 ohne HS sein?
Bei den Messungen auf der Karte muss man etwa 0,5mm pro Seite abziehen, die der Schutzschicht entsprechen.
Sollte GF100 529mm² auf dem Package groß sein, so könnten es auf dem Wafer nur knapp über 500mm² sein.
Der die ist so oder so nicht quadratisch, ergo stimmt auch 529mm2 so oder so nicht.
AnarchX
2010-04-23, 10:29:15
Das "Preview-Dokument" mit den 1.25-1.4GHz für Tesla ist nun auch vom Server verschwunden: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7020417#post7020417 (unten)
Was da wohl die Kunden denken, nachdem man erst nicht die angekündigten 512SPs liefern konnte und nun den Takt um einiges gesenkt und gleichzeitig die TDP erhöht hat? X-(
Bei TeslaS20 (1-U rack mounts) skaliert die Frequenz von 1.2 bis 1.4GHz mit 900W TDP (typical), ergo handausgesuchte chips nur fuer die clusters (S20).
Oder hier fehlt noch die Anpassung auf den aktuellen Stand.
Ailuros
2010-04-23, 10:42:18
Das "Preview-Dokument" mit den 1.25-1.4GHz für Tesla ist nun auch vom Server verschwunden: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7020417#post7020417 (unten)
Was da wohl die Kunden denken, nachdem man erst nicht die angekündigten 512SPs liefern konnte und nun den Takt um einiges gesenkt und gleichzeitig die TDP erhöht hat? X-(
Ich kann mich nicht daran erinnern irgendwelche 512SP Angaben fuer Tesla's gelesen zu haben. Alle Dokumente die ich gesehen habe sprachen von 448SPs. Ja der TDP ist tatsaechlich um einiges hoeher. Max TDP fuer 2050/2070 wurde bei <225W angegeben, wobei die noch nicht erhaeltliche 6GB/2070 damit gemeint wurde. Mit nur 3GB Speicher und 257W von den originalen >200W ist es ein Mordssprung.
Oder hier fehlt noch die Anpassung auf den aktuellen Stand.
Du hast wohl recht, da sich die Daten mit dem Zeug hier: http://www.nvidia.com/docs/IO/43395/NV_DS_Tesla_S2050_S2070_final_lowres.pdf vom November 09' decken. Prost....
Nighthawk13
2010-04-24, 10:53:35
Interessantes Paper zum GT200:
"Demystifying GPU Microarchitecture through Microbenchmarking"
http://www.eecg.toronto.edu/~myrto/gpuarch-ispass2010.pdf
Laut den Messungen hatte GT200 bereits einen L2-Texturcache, davon hat Nvidia bisher nichts erwähnt.
Die gleiche Analyse für Fermi wäre natürlich interessant.
Bei den Teslas gibt man wenigstens eine ehrliche TDP an. Also 247W bei 448SP und 1,15Ghz. Bei den Desktopkarten ist das nur noch Marketing. Die GTX480 hätte locker 300W verdient, eher 320W TDP.
Gipsel
2010-04-25, 00:58:00
Interessantes Paper zum GT200:
"Demystifying GPU Microarchitecture through Microbenchmarking"
http://www.eecg.toronto.edu/~myrto/gpuarch-ispass2010.pdf
Laut den Messungen hatte GT200 bereits einen L2-Texturcache, davon hat Nvidia bisher nichts erwähnt.
Ich dachte die 8*32kB L2 Cache des GT200 wären genauso bekannt wie die 4*64kB L2 des RV770, die 8*64kB des Cypress oder die 6*128kB L2 des GF100. Das Statement dort, daß ihre Messungen anzeigen, daß der L2 nicht in den TPCs sitzt, ist auch irgendwie lustig. Daß der den ROP-Partitionen bzw. den Speichercontrollern zugeordnet ist, sollten die eigentlich auch schon mal gehört haben.
Aber das kann man sich trotzdem mal merken, da die auch alle Latenzen durchgemessen haben. Wenn also mal wieder der Mythos der kurzen Pipelines bei GPUs auftaucht, hat man dort eine Referenz. Damit nicht jeder sucht, ein GT200 hat 24 Takte Latenz für einfache ALU-Instruktionen (wie aber auch schon vorher bekannt), die DP-Einheit sogar 48 Takte (wobei dort wohl viel für den Transfer der Daten zur einzigen Einheit im SM draufgeht).
Da sieht man auch schön, dass das zusätzliche MUL selbst im besten Fall (nur MULs) nur zu <50% ausgenutzt werden kann.
Auch ein Brüller: DP-Div-Latency: 1366 Cycles X-D
Gipsel
2010-04-25, 12:53:18
Da sieht man auch schön, dass das zusätzliche MUL selbst im besten Fall (nur MULs) nur zu <50% ausgenutzt werden kann.
Auch ein Brüller: DP-Div-Latency: 1366 Cycles X-D
Nun, das wird ja durch Instruktionssequenzen gemacht, weswegen da so hohe Zahlen rauskommen. Eine ATI hat auch immerhin 104 Takte Latenz für das DP-DIV (sind 13 VLIW-Clauses * 8 Takte pro Clause).
Ein großer Vorteil für ATI in dieser Metrik kommt dadurch zustande, daß die "Basis-Latenz" für Instruktionen in SP und DP jeweils nur 8 Takte beträgt, während sich nvidia immer gleich mit 24 bzw. 48 Takten rumschlagen muß. Da werden dann solche Instruktionssequenzen ziemlich schnell sehr teuer. Außerdem führt das dazu, daß nvidia generell mehr Threads in flight halten muß, um auch nur die ALU-Latenzen zu verstecken und die Einheiten ordentlich auszulasten.
Ein Beispiel:
GT200: 240 Einheiten, 24 Takte Latenz => 5760 Threads nötig
Cypress: 320 Einheiten, 8 Takte Latenz => 2560 Threads nötig
Da sieht man auch schön, dass das zusätzliche MUL selbst im besten Fall (nur MULs) nur zu <50% ausgenutzt werden kann.Das ist komisch da das Mul beim GT200 lt. Nvidia sofort "usable" sein soll.
Orbmu2k
2010-05-04, 22:56:22
Da der GF100 ja unzählige Clock domains zuhaben scheint. Wollte ich der Sache mal etwas mehr auf den Grund gehen.
http://www4.pic-upload.de/thumb/04.05.10/v8bd4flru3c6.jpg (http://www.pic-upload.de/view-5523931/fbel.jpg.html)
Die Clock[4] & Clock[11] skalieren automatisch mit dem Shadertakt, daher hab ich die zuerst mal angeschaut.
Das ganze auch richtig zu bewerten vermag ich jedoch nicht, da ich von Grafikchiparchitektur eigentlich keine grosse Ahnung hab.
http://www4.pic-upload.de/thumb/04.05.10/f335k4dsptx.jpg (http://www.pic-upload.de/view-5523941/full_a.jpg.html)
Es scheint aber dass Clock[4] Vertexshading lastig ist und Clock[11] Pixelshading lastig.
Nun, das wird ja durch Instruktionssequenzen gemacht, weswegen da so hohe Zahlen rauskommen.
Schon klar. Aber es wirkt trotzdem unfreiwillig komisch auf mich ;)
Das ist komisch da das Mul beim GT200 lt. Nvidia sofort "usable" sein soll.
Ist es nicht. Allein schon vom Scheduling gibt es da Einschränkungen. Vermutlich aber auch was die Ports angeht zum Register-File.
Ist es nicht. Allein schon vom Scheduling gibt es da Einschränkungen. Vermutlich aber auch was die Ports angeht zum Register-File.GT200 kann entweder mit 16-er Batches arbeiten (optimiert für Branches) und nur das MAD auslasten, oder mit 32-er Batches (optimiert für Rechenleistung) welches dann auch das MUL nutzen kann. Da sehe ich vom Scheduling her keine Probleme. Der Registerzugriff müsste auch entsprechend gegeben sein, sonst ergibt das keinen Sinn, 8 MULs zu haben wenn der Durchsatz nur bei 4 MULs liegt.
Was für Batches? Ein WARP enthält immer 32 Threads.
Es gibt jetzt eine Präsentation (http://www.highperformancegraphics.org/media/Hot3D/HPG2010_Hot3D_NVIDIA.pdf) von NVIDIA über die Fermi-Tesselations-Architektur. Könnte evtl. jemanden interessieren.
Interessant ist auch das zitierte Paper von Stanford (http://graphics.stanford.edu/papers/pomegranate/)
Das ganze könnte langfristig sich langfristig auch als nützlich für Multi-GPU ohne AFR erweisen.
Nighthawk13
2010-10-08, 11:35:27
Interessante Erkenntnis zum L1 Cache auf Fermi:
http://forums.nvidia.com/index.php?showtopic=181432&st=0&p=1123304&#entry1123304
- Scheint wohl linear langsamer zu werden, wenn auf verschiedene Cachelines(128Byte-Abschnitte) innerhalb eines Warps zugegriffen wird
- Beim Shared memory hingegen wird es nur langsamer, wenn die Threads im Warp auf die gleiche Bank zugreifen.
=> Ein Zugriff auf eine Cacheline scheint alle Banks des Shared-Memory-Controllers zu blockieren, auch wenn nur eine Bank davon tatsächlich verwendet wird
=> D.h. einen "Software-Cache" mit shared Memory zu implementieren, kann sich durchaus lohnen(statt nur auf den L1-Cache zu Vertrauen).
Erklärt vielleicht auch, warum der Chip im Grafikmodus auf "viel Shared Memory/wenig L1-Cache" konfiguriert ist.
mapel110
2010-10-24, 01:16:23
http://www.beyond3d.com/content/reviews/55
NVIDIA Fermi GPU and Architecture Analysis
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.