Archiv verlassen und diese Seite im Standarddesign anzeigen : nVidia - Kepler - 28nm - 2012
AwesomeSauce
2010-09-21, 19:45:02
NVIDIAs neue GPU-Architekturen bis 2013:
http://livesmooth.istreamplanet.com/nvidia100921/
2011: Kepler, 2013: Maxwell
http://www.abload.de/img/nvidia_smlgqzb.png (http://www.abload.de/image.php?img=nvidia_smlgqzb.png)
GTX680 = GK104
3*32SPs/SM
8 TMUs/SM
4 SMs/GPC
4 GPCs
32 ROPs
256bit bus
2GB 5.0Gbps GDDR5
950MHz core
2*6pin
GK104 PCB und Chip-Shot (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9192342#post9192342)
GK107 als GT 650M: Chip-Shot und Benchmarks (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9192913#post9192913)
Leak hkepc.com (16.03.2012)
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9211670#post9211670
http://www.abload.de/thumb/162145333351768269vpz22.jpg (http://www.abload.de/image.php?img=162145333351768269vpz22.jpg) http://www.abload.de/thumb/16184849291027403399k8lxd.jpg (http://www.abload.de/image.php?img=16184849291027403399k8lxd.jpg) http://www.abload.de/thumb/1621472747822130373xlaxj.jpg (http://www.abload.de/image.php?img=1621472747822130373xlaxj.jpg) http://www.abload.de/thumb/1621472848108003826vgaam.jpg (http://www.abload.de/image.php?img=1621472848108003826vgaam.jpg) http://www.abload.de/thumb/gkcomplubop.png (http://www.abload.de/image.php?img=gkcomplubop.png) http://www.abload.de/thumb/1618485030222408178fdlne.jpg (http://www.abload.de/image.php?img=1618485030222408178fdlne.jpg) http://www.abload.de/thumb/1618485636161069146qwxxj.jpg (http://www.abload.de/image.php?img=1618485636161069146qwxxj.jpg) http://www.abload.de/thumb/1618485737228405334lvy4d.jpg (http://www.abload.de/image.php?img=1618485737228405334lvy4d.jpg) http://www.abload.de/thumb/161849014124885118583z4o.jpg (http://www.abload.de/image.php?img=161849014124885118583z4o.jpg) http://www.abload.de/thumb/16184902421094941267rdyf8.jpg (http://www.abload.de/image.php?img=16184902421094941267rdyf8.jpg) http://www.abload.de/thumb/16184903432594596835zyih.jpg (http://www.abload.de/image.php?img=16184903432594596835zyih.jpg) http://www.abload.de/thumb/1618490747196043769205xf5.jpg (http://www.abload.de/image.php?img=1618490747196043769205xf5.jpg) http://www.abload.de/thumb/16184912522048248859dzyq8.jpg (http://www.abload.de/image.php?img=16184912522048248859dzyq8.jpg)http://www.abload.de/thumb/16184856361633065601fddyo.jpg (http://www.abload.de/image.php?img=16184856361633065601fddyo.jpg)
AnarchX
2010-09-21, 19:53:41
Ob sich bei dem Sprung zu Maxwell wohl eine Wechsel auf VLIW verbirgt? :D
Und was soll der Thread? Es gibt nichts zu spekulieren. Alles was bekannt ist wurde gesagt: Virtual Memory und preemtives Multitasking.
Ob sich bei dem Sprung zu Maxwell wohl eine Wechsel auf VLIW verbirgt? :D
GF104 zeigt eher in die Richtung, dass die GPU automatisch mehr Parallelität im Instruktionsstrom sucht - wobei der Compiler natürlich helfen kann.
AwesomeSauce
2010-09-21, 19:55:36
Und was soll der Thread?
Kann nichts dafür, der Thread wurde kurzerhand nach dem Post im GF104-Fred zum eigenen Topic umfunktioniert... Und nicht jeder hat die Konferenz geschaut, von daher...
Grivel
2010-09-21, 19:55:44
das sieht aber noch ner guten Effizienz auf dem Screenshot aus. Ob das keine Utopie ist?
@ coda man könnte darüber spekulieren ob bis dahin Nvidia in der derzeitigen Form noch exisitier:biggrin:t
@ coda man könnte darüber spekulieren ob bis dahin Nvidia in der derzeitigen Form noch exisitier:biggrin:t
AaaaAaAAAAaalt: Wie lange machts Nvidia noch? (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=5345) :biggrin:
MfG,
Raff
Bemerkenswert finde ich, dass Kepler schon 2011 kommen soll mit weitaus besserer Energieeffizienz.
Das geht nicht auf Fermi-Basis. Bin wirklich mal gespannt drauf.
Grivel
2010-09-21, 20:02:17
AaaaAaAAAAaalt: Wie lange machts Nvidia noch? (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=5345) :biggrin:
MfG,
Raff
Schande über mich- wie konnte ich das nur übersehen :/ es sei mir doch vergeben...
Naja die Effizienz von Maxwell find ich krass.
Radeonfreak
2010-09-21, 20:04:07
Aber Fermi kam doch erst 2010 auf den Markt oder ? Nicht 09 :confused:
AnarchX
2010-09-21, 20:05:26
Bemerkenswert finde ich, dass Kepler schon 2011 kommen soll mit weitaus besserer Energieeffizienz.
Das geht nicht auf Fermi-Basis. Bin wirklich mal gespannt drauf.
Die 2011 für Kepler hat vielleicht die gleiche Bedeutung wie die 2009 für Fermi. ;)
Wenn die Zahlen halbwegs realistisch sind könnte wohl ein 250W Kepler bei 2,5 bis 3,7 TFLOPs SP landen, je nachdem ob man wieder auf halben DP-Durchsatz setzt oder das GF104-Konzept DP-fähig macht.
Hugo78
2010-09-21, 20:05:36
Aber Fermi kam doch erst 2010 auf den Markt oder ? Nicht 09 :confused:
Es geht wohl um den Start des Designs.
dildo4u
2010-09-21, 20:06:54
Die 2011 für Kepler hat vielleicht die gleiche Bedeutung wie die 2009 für Fermi. ;)
Wenn die Zahlen halbwegs realistisch sind könnte wohl ein 250W Kepler bei 2,5 bis 3,7 TFLOPs SP landen, je nachdem ob man wieder auf halben DP-Durchsatz setzt oder das GF104-Konzept DP-fähig macht.
Jup ist das nicht der normale Sprung den man von 40 auf 28nm erwarten kann?
Die 2011 für Kepler hat vielleicht die gleiche Bedeutung wie die 2009 für Fermi. ;)
Ja. Oder auch nicht.
Jup ist das nicht der normale Sprung den man von 40 auf 28nm erwarten kann?
>3x? Nö.
Huang hat auch gemeint, dass sie an der Architektur gedreht haben dafür. Vielleicht ja doch VLIW.
Bemerkenswert finde ich, dass Kepler schon 2011 kommen soll mit weitaus besserer Energieeffizienz.
Das geht nicht auf Fermi-Basis. Bin wirklich mal gespannt drauf.
Warum nicht? 28nm ahoi! Natürlich wird es ein paar Überarbeitungen geben, aber sie brauchen ja schon einen erheblichen Sprung um überhaupt an die Konkurrenz dran zu kommen.
Black-Scorpion
2010-09-21, 20:08:21
Es geht wohl um den Start des Designs.
Sicher nicht. ;)
Einen Chip entwickelt man nicht in Monaten sondern Jahren.
AnarchX
2010-09-21, 20:09:28
Sicher nicht. ;)
Einen Chip entwickelt man nicht in Monaten sondern Jahren.
Er meinte wohl die öffentliche Architektur-Vorstellung auf der GTC, wie es auch Intel mit seinen CPU-Architekturen auf der IDF macht.
Es geht wohl um den Start des Designs.
Dann müßte Fermi bei 2006 oder so stehen ^^
Edit:
Er meinte wohl die öffentliche Architektur-Vorstellung auf der GTC, wie es auch Intel mit seinen CPU-Architekturen auf der IDF macht.
Das als "Start des Designs" zu bezeichnen ... naja ...
dildo4u
2010-09-21, 20:10:10
>3x? Nö.
Man überspringt doch 32nm deshalb imo ohne weiteres Möglich.
Warum nicht? 28nm ahoi!
Das reicht nicht. 28nm erlaubt gerade mal doppelte Integrationsdichte ggü. 40nm.
Man überspringt doch 32nm deshalb imo ohne weiteres Möglich.
Was redest du da? 40nm -> 28nm ist fast exakt ein 2x Shrink.
Nightspider
2010-09-21, 20:11:20
Man wird Kepler schon für Ende 2011 planen...ob sie es schaffen ist eine andere Frage.
Die ersten kleinen Chips in 28nm werden ja sicherlich im 1. Halbjahr 2011 erscheinen.
Hoffe es ist nicht ganz OT aber gibts für DX12 schon einen groben Zeitplan oder sogar schon Details zu Verbesserungen?
Obwohl man ja mit DX11 schon sogut wie alles machen kann, was man will. Viel Spielraum für große Neuerungen gibt es sicherlich wenig.(Im Gegensatz zu früheren DX Versionen)
Black-Scorpion
2010-09-21, 20:12:00
Er meinte wohl die öffentliche Architektur-Vorstellung auf der GTC, wie es auch Intel mit seinen CPU-Architekturen auf der IDF macht.
Dann sollte er aber überlegen was er schreibt und dem was er sagen will.
Das reicht nicht. 28nm erlaubt gerade mal doppelte Integrationsdichte ggü. 40nm.
Vielleicht noch bessere Packdichte wie AMD von 55nm -> 40nm ?
>3x? Nö.
Ich sehe da <3. Fermi kratzt an der 2, Kepler ist ein bisschen weiter von der 6 entfernt. Und zumindest doppelte Perf/Watt sollte durch 28nm schon möglich sein. Braucht man noch 30% durch die Architektur.
30% ist ja auch kein Pappenstil.
Und ich gehe mal stark davon aus, dass die Mitte des Chips als Skala gewertet werden sollte.
Vielleicht noch bessere Packdichte wie AMD von 55nm -> 40nm ?
Vielleicht weniger "unnötiges" Gamer-Zeugs (wie TMUs)? Ich habe Angst ... :D
MfG,
Raff
Hugo78
2010-09-21, 20:14:26
Dann müßte Fermi bei 2006 oder so stehen ^^
Edit:
Das als "Start des Designs" zu bezeichnen ... naja ...
Ist eurem Befinden das Wort "Vorstellung" genehmer, der Herr? :freak:
Fermi wurde 2009 vorgestellt.
Vielleicht weniger "unnötiges" Gamer-Zeugs (wie TMUs)? Ich habe Angst ... :D
Nachdem sie in GF104 wieder acht pro SM eingebaut haben und sogar FP16 single cycle? Err?
Black-Scorpion
2010-09-21, 20:17:01
Vorstellung und Start des Designs ist ein Riesen Unterschied.
30% ist ja auch kein Pappenstil.
Nur ist AMD da heute schon praktisch.
Und ich gehe mal stark davon aus, dass die Mitte des Chips als Skala gewertet werden sollte.
Fermi erreicht je nach Ausführung bis zu 672,48GLOPs DP, ich denke 2 DP GLOPs/Watt kommt gut hin. 1 wäre zu wenig.
Nachdem sie in GF104 wieder acht pro SM eingebaut haben und sogar FP16 single cycle? Err?
Vielleicht wird ja Kepler der erste separate Profi-Chip?
dildo4u
2010-09-21, 20:21:31
Vielleicht weniger "unnötiges" Gamer-Zeugs (wie TMUs)? Ich habe Angst ... :D
MfG,
Raff
NV baut die GPU's so das sie sie für jeden Markt anpassen können,sieht man am GF 104 schätze das wird näste Gen noch deutlicher getrennt.Könnte sein das man nur Teslas bekommt die solche DP Leistungen erbringen und die Cosumer GPU's mehr Richtung Performance per Watt gehen.
NV baut die GPU's so das sie sie für jeden Markt anpassen können,sieht man am GF 104 schätze das wird näste Gen noch deutlicher getrennt.Könnte sein das man nur Teslas bekommt die solche DP Leistungen erbringen und die Cosumer GPU's mehr Richtung Performance per Watt gehen.
DP Leistung und Perf/Watt ist kein Widerspruch, sieht man ja auch bei der Konkurrenz. NV hat einfach nicht die beste Arbeit geleistet mit GF100.
Gestrandet
2010-09-21, 22:34:24
Ja. Oder auch nicht.
>3x? Nö.
Huang hat auch gemeint, dass sie an der Architektur gedreht haben dafür. Vielleicht ja doch VLIW.
Vielleicht wollen sie sich auch auf ihre Kernkompetenzen konzentrieren und verticken ab Maxwell nur noch umgelabelte ATI, pardon, AMD Chips ;)
Haha bist du lustig. Nicht.
Spasstiger
2010-09-21, 22:41:35
Aber Fermi kam doch erst 2010 auf den Markt oder ? Nicht 09 :confused:
2009 hatte man vermutlich die Entwicklungen am Design abgeschlossen. Der Release war ja ursprünglich auch für Ende 2009 vorgesehen.
Gestrandet
2010-09-21, 22:51:16
Haha bist du lustig. Nicht.
Wenn das ein gefühlter Schwerintellektueller mit so einem ausgezeichnetem Charakter wie deinem sagt, berührt mich das zutiefst :smile:
Bucklew
2010-09-21, 23:10:46
DP Leistung und Perf/Watt ist kein Widerspruch, sieht man ja auch bei der Konkurrenz. NV hat einfach nicht die beste Arbeit geleistet mit GF100.
SP-Leistung ist bei Cypress fast 3x so schnell wie Fermi, bei DP herrscht (fast) Gleichstand.
Wenn das ein gefühlter Schwerintellektueller mit so einem ausgezeichnetem Charakter wie deinem sagt, berührt mich das zutiefst :smile:
Gut, das wir uns hier alle ja auch so gut kennen X-D
MadManniMan
2010-09-22, 00:08:45
Vorstellung und Start des Designs ist ein Riesen Unterschied.
Aye, 2011 kann auch heißen, dass uns Fermi und seine Ableger im Consumermarkt noch bis zum Frühling 2012 als einzige Spielerkarten zur Verfügung stehen werden.
Warten wir mal ab, was die Veranstaltung die nächsten Tage noch bringt - ich erwarte ja zumindest die Ankündigung einer neuen Fast-High-End-Karte auf GF104-Basis, um AMD im schon jetzt den Wind aus den Segeln zu nehmen. Die Taktraten der neuen Radeons dürften ja schon durch sein ...
Ailuros
2010-09-22, 08:35:33
Kann mir jemand vielleicht zeigen wo der "nur" ~2x Unterschied ist zwischen Fermi und Tesla fuer DP/W?
http://forum.beyond3d.com/showpost.php?p=1474753&postcount=57
Kepler braucht lediglich doppelt so viel DP Leistung haben als ein heutiger Fermi 20x0 und es waere dann schon locker ueber 13x Mal die DP Leistung per Watt im Vergleich zum originalen Tesla 10x0.
DP Leistung und Perf/Watt ist kein Widerspruch, sieht man ja auch bei der Konkurrenz. NV hat einfach nicht die beste Arbeit geleistet mit GF100.
Entweder bin ich blind oder ich sehe einen sehr klaren Widerspruch in dem oeden slide. Nochmal fuer diejenigen die zu faul sind auf den Link zu klicken Tesla 1060 liegt bei 78GFLOPs bei 187.8W TDP waerend Tesla 2050 heute auf 515GFLOPs DP bei 238W liegt. Obwohl die Normalisierung auf den gleichen TDP nicht korrekt sein wird aendert sich wenig daran dass die heutigen Teslas um die 5x Mal so viel DP Leistung liefern als die 10x0.
Tesla 20x0 hat 480SPs@1.073GHz = 515 GFLOPs/s. Hier kommt noch dazu dass die Boliden mit 3GB Speicher ein Stueck mehr verbrauchen als 1GB desktop GPUs. Im idealsten Fall wenn alles in Ordnung auf GF100 gewesen waere haetten wir 512SPs@1.3GHz = 665 GFLOPs/ gesehen.
Zwar gute 30% mehr DP GFLOPs im Vergleich zum heutigen Resultat aber im Vergleich zu den "albernen" 70-90GFLOPs die die ersten 10x0 Teslas haben ist es nach wie vor ein Riesensprung.
MadManniMan
2010-09-22, 08:43:46
Gibt es denn ganz konkrete Karten, auf die sich diese Bezeichnungen beziehen? Woher wissen wir genau, welche gemeint sind?
Vielleicht hat man bewusst den Fermi "etwas" mäßiger dargestellt, um die Exponentialdarstellung zu ermöglichen?
Mögliche Gründe:
- Fermis DP/W reichen dicke für aktuelle Anwendungen, künftige Apps benötigen hingegen mehr Leistung -> nVidia gibt zu verstehen, dass sie genau wissen, wann es nötig ist, mit welcher Leistung zu kommen
- Tesla verkauft sich immernoch gut und die Margen sind höher -> nVidia hält Fermi schön klein, weil's einfach wirtschaftlicher ist
Kann mir jemand vielleicht zeigen wo der "nur" ~2x Unterschied ist zwischen Fermi und Tesla fuer DP/W?
http://forum.beyond3d.com/showpost.php?p=1474753&postcount=57
Kepler braucht lediglich doppelt so viel DP Leistung haben als ein heutiger Fermi 20x0 und es waere dann schon locker ueber 13x Mal die DP Leistung per Watt im Vergleich zum originalen Tesla 10x0.
Du hast recht. Fermi sollte in dem Diagramm weit höher liegen. Auf jeden Fall >2 DP GLOPs pro Watt. Damit ist das Diagramm nun vollkommen lächerlich und nicht ernst zu nehmen. Es stimmt weder das Datum noch die Daten. Man hat halt vier Chips alle zwei Jahre in einer e-Funktion aufgereiht. X-D
Gibt es denn ganz konkrete Karten, auf die sich diese Bezeichnungen beziehen? Woher wissen wir genau, welche gemeint sind?
Vielleicht hat man bewusst den Fermi "etwas" mäßiger dargestellt, um die Exponentialdarstellung zu ermöglichen?
Mögliche Gründe:
- Fermis DP/W reichen dicke für aktuelle Anwendungen, künftige Apps benötigen hingegen mehr Leistung -> nVidia gibt zu verstehen, dass sie genau wissen, wann es nötig ist, mit welcher Leistung zu kommen
- Tesla verkauft sich immernoch gut und die Margen sind höher -> nVidia hält Fermi schön klein, weil's einfach wirtschaftlicher ist
Hallo, was redest du hier zusammen? Man weiß ja wie Fermi aussieht. Dazu passen die Daten einfach nicht. Und Leistung kann man nie genug haben.
Ailuros
2010-09-22, 08:54:15
Gibt es denn ganz konkrete Karten, auf die sich diese Bezeichnungen beziehen? Woher wissen wir genau, welche gemeint sind?
Vielleicht hat man bewusst den Fermi "etwas" mäßiger dargestellt, um die Exponentialdarstellung zu ermöglichen?
Oder die roadmap ist uralt und Kepler ist einfach das heutige "Fermi". Dass jegliche zukuenftige GPU in 2011 (welches auch nicht den eigentlichen release anzeigt...ahem) bzw. 2012 immer noch "NUR" um die 5x Mal mehr DP/Watt im Vergleich zur originalen Tesla haben wird klingt mir laecherlich.
Mögliche Gründe:
- Fermis DP/W reichen dicke für aktuelle Anwendungen, künftige Apps benötigen hingegen mehr Leistung -> nVidia gibt zu verstehen, dass sie genau wissen, wann es nötig ist, mit welcher Leistung zu kommen
- Tesla verkauft sich immernoch gut und die Margen sind höher -> nVidia hält Fermi schön klein, weil's einfach wirtschaftlicher ist
Irgend etwas stimmt hier nicht. Tesla 20x0 geht nicht mit hoeheren Frequenzen weil sonst die 3GB und bald 6GB fuer 2070 den Stromverbrauch sprengen wuerden.
***edit: nebenbei schmeckt Maxwell Kaffee furchtbar :P
http://www.heise.de/newsticker/meldung/GTC-Nvidia-gibt-Ausblick-auf-kommende-Grafikchips-1083430.html
Die von Nvidia angegebenen Werte lassen aber keinerlei Rückschlüsse auf die eigentliche 3D-Leistung zu. Auf Nachfrage zur Leistung erklärte Huang während der folgenden Pressekonferenz lediglich, dass der 2013 erwartete Maxwell-Chip etwa um den Faktor 10 schneller sein wird als der aktuelle GF100.
Das wäre wohl gar mehr als die gezeigt Pro-Watt-DP-Leistungssteigerung. Oder hofft Nvidia auf PCIe 4.0 mit einer 500W Spezifikation? :D
Und bei der Execution gelobt man wohl auch Besserung:
Außerdem soll es in Zukunft vom Marktstart einer neuen Grafikgeneration durch einen High-End-Chip maximal 3 Monate dauern, bis man alle Marktsegmente bis zum Low End mit Grafikkarten besetzt hat. Fermi-ähnliche Zustände will Nvidia also zukünftig offenbar nicht wieder erfahren.
http://www.heise.de/newsticker/meldung/GTC-Nvidia-gibt-Ausblick-auf-kommende-Grafikchips-1083430.html
Das wäre wohl gar mehr als die gezeigt Pro-Watt-DP-Leistungssteigerung. Oder hofft Nvidia auf PCIe 4.0 mit einer 500W Spezifikation? :D
Und bei der Execution gelobt man wohl auch Besserung:
Ja, alte Weisheit. Wenn man keine bessere Strategie hat muss man sich diese eben von der Konkurrenz abschauen. Schnell kleinere Chips plus alle zwei Jahre neue Gen, vermutlich dazwischen noch jeweils ein Refresh und man hat exakt ATi kopiert. ;)
Ailuros
2010-09-22, 09:40:35
10x Mal in 3 Jahren will ich erstmal sehen bevor ich es glaube. Unter 28nm wird sich erstmal unter normalen Umstaenden die Leistung um bis zu 2x Mal gegenueber Fermi steigern (wenn mehr desto besser nur ist es nicht so leicht erreichbar) und vor Mitte 2011 (und selbst das ist optimistisch) sehe ich davon nichts.
Außerdem soll es in Zukunft vom Marktstart einer neuen Grafikgeneration durch einen High-End-Chip maximal 3 Monate dauern, bis man alle Marktsegmente bis zum Low End mit Grafikkarten besetzt hat. Fermi-ähnliche Zustände will Nvidia also zukünftig offenbar nicht wieder erfahren.
Das ist natuerlich machbar wenn man mehr als einen chip parallel entwickelt. Hat AMD auch schon gezeigt seit Evergreen. Das einzige Fragezeichen ist wie es aussehen wird wenn man wieder auf single chip high end legt ergo sehr hohe Chip-komplexitaet und der benutzte Herstellungsprozess Probleme macht und die foundry u.a. nicht ueber genug Kapazitaeten verfuegt.
Zwar gab es nichts oeffentliches darueber aber genau den gleichen Brei hoerte ich auch vor ca. 2 Jahren fuer die Fermi Generation off the record pfff...
***edit:
guter Punkt aus dem B3D Forum:
http://forum.beyond3d.com/showpost.php?p=1474766&postcount=60
Where does your 190W for GT200b come? TDP?
If you are running only DP FPU code on GT200, most of the execution units(8/9) are idling, and you are not consuming that much power with just the DP FPU's.
On Fermi, where there are more DP FPU's, there are less idling SP FPU's idling, and you will be running "closer to the TDP" when running DP FPU code.
So you have invalid comparison.
GT200b Teslas hatten tatsaechlich getrennte DP Einheiten, was natuerlich bedeutet dass wenn so ein Ding DP einlegt eine grosse Anzahl an Einheiten einfach idle sind. Im schlimmsten Fall vielleicht 2D idle Watt Verbrauch + der Verbrauch der DP Einheiten. Ich kann mir das Zeug zwar nicht selber ausrechnen, aber so unwahrscheinlich klingt es dann auch nicht dass der Abstand zwischen Fermi und Tesla in der Tabelle stimmt.
***edit Nr.2:
According to Nvidia, Fermi architecture is capable of achieving typical double precision (DP) performance of 1.5GFLOPS per watt.
http://www.xbitlabs.com/news/video/display/20100921165317_Nvidia_Unveils_Three_Years_Roadmap_Kepler_and_Maxwell_Architectur es_Incoming.html
Wie soll ich das jetzt verstehen?
Dural
2010-09-22, 10:13:09
Die grafik stimmt ja so wie so nicht exakt, ist wohl einfach nur show
Tesla / G80 hat null DP und ist auch auf der null linie
Fermi / GF100 soll wohl 2 GFLOPS pro Watt DP haben, was nicht genau stimmt, dürfte etwas mehr sein. abgerundet sind 2 GFLOPS aber OK...
Maxwell dürfte wohl nur noch aus Einheiten bestehe die alle ((in full speed)) DP beherschen und das in 22nm?!
aber ja, wenn NV ca. 4Tera DP für 2013 einhält wäre das schon der hammer...
deekey777
2010-09-22, 10:18:01
Woher soll ein Software-Unternehmen wissen, was die Hardware zu leisten vermag?
Dural
2010-09-22, 10:24:54
1024SP @ 2000MHz @ 22nm @ 4Tera DP @ 250Watt = 16 GFLOP/Watt DP ;D
Edit:
so weit weg scheint das für 2013 gar nicht zu sein... die vergangenheit hatte immer solche steigerungen 128SP/90nm > 240SP/65nm > 512SP/40nm > ?1024SP/28nm? > ?2048SP/22nm?
http://www.xbitlabs.com/news/video/display/20100921165317_Nvidia_Unveils_Three_Years_Roadmap_Kepler_and_Maxwell_Architectur es_Incoming.html
Wie soll ich das jetzt verstehen?
Das nicht das Top des Die als Anhaltspunkt zu nehmen ist, sondern der kleine rote Balken (=L2 Cache Area). Dann passt die Grafik IMHO.
Spasstiger
2010-09-22, 10:37:41
aber ja, wenn NV ca. 4Tera DP für 2013 einhält wäre das schon der hammer...
Wenn Fermi bei 1,5 GFlops/Watt liegen soll nach NV-Aussage und man Maxwell bei 15 GFlops/Watt sieht, dann hätte ein 300-Watt-Maxwell 4500 GFlops. 8 TFlops DP wird man 2013 vielleicht schon sehen (bzw. am Markt dann eher 2014), aber nicht mit Single-GPU.
/EDIT: Bevor ich dich zitiert habe, standen in deinem Posting noch 8 TFlops.
Ailuros
2010-09-22, 10:39:12
Die grafik stimmt ja so wie so nicht exakt, ist wohl einfach nur show
Tesla / G80 hat null DP und ist auch auf der null linie
Fermi / GF100 soll wohl 2 GFLOPS pro Watt DP haben, was nicht genau stimmt, dürfte etwas mehr sein. abgerundet sind 2 GFLOPS aber OK...
Nach xbitlabs behauptete NV selber 1.5GFLOPs/W fuer Fermi; ergo bei 515GFLOPs einer 2050 verbraucht das Ding 344W oder? :rolleyes:
Da bei DP nur die ALUs beschaeftigt werden, kann der reale GFLOP/Watt Wert wohl schwer unter 3 GFLOP/W liegen. Ausser sie wollen uns jetzt sagen dass eine 2050 nicht 515GFLOPs schafft sondern nur etwa die Haelfte.
Maxwell dürfte wohl nur noch aus Einheiten bestehe die alle ((in full speed)) DP beherschen und das in 22nm?!
aber ja, wenn NV ca. 4Tera DP für 2013 einhält wäre das schon der hammer...
Irgend einen merkwuerdigen Haken muss die Tabelle schon haben; erstens damit es als Marketing-slide den erwuenschten "wow-Faktor" bringt und zweitens damit es nicht jeder auf Anhieb herauslesen kann.
Uebrigens spricht die Tabelle erstmal vom Ende der Entwicklung jeglicher Architektur und nicht kommerzieller Verfuegbarkeit. Sonst zeig mir eine Tesla in 2007 oder einen Fermi in 2009.
Und wieso muss auf Maxwell mir nichts dir nichts SP=DP sein? Unter 22nm werden wohl um einiges mehr als 2000SPs moeglich sein und hoeheren als heutigen Frequenzen oder zumindest erhofft sich dieses NV, denn wie oben erwaehnt ist Fermi in Echtzeit wohl um die 30% kuerzer geschnitten als fruehere Projektionen. Wie dem auch sei ueber 3.5 TFLOP DP klingen mir stinknormal fuer 2014.
Summa summarum: eine bunte Vorstellung fuer Investoren und die Welt um zu sagen dass sie noch "alive and kicking" sind. Das wissen wir selber auch so; von da ab heisst es put up or shut up.
Spasstiger
2010-09-22, 10:41:23
Nach xbitlabs behauptete NV selber 1.5GFLOPs/W fuer Fermi; ergo bei 515GFLOPs einer 2050 verbraucht das Ding 344W oder? :rolleyes:
Ein Tesla 2050 verbraucht 230-250 Watt, leistet aber praktisch nie 515 GFlops DP.
Dural
2010-09-22, 10:41:27
Fermi ist nach mir auf der 2 GFLOPS linie, das stimmt in etwas schon: 250Watt und 500GFLOP DP das haben die aktuellen Fermi karten auch!
Maxwell müsste bei 15Giga/Watt bei 250Watt 3750GigaFlops DP haben und ich halte das für 2013 durch aus für möglich!
Edit:
http://www.nvidia.com/object/product_tesla_C2050_C2070_us.html
Double Precision floating point performance (peak) 515 Gflops
Leider gibt NV keine TDP für die 2070 an...
LovesuckZ
2010-09-22, 10:47:45
Fermi ist nach mir auf der 2 GFLOPS linie, das stimmt in etwas schon: 250Watt und 500GFLOP DP das haben die aktuellen Fermi karten auch!
Maxwell müsste bei 15Giga/Watt bei 250Watt 3750GigaFlops DP haben und ich halte das für 2013 durch aus für möglich!
Edit:
http://www.nvidia.com/object/product_tesla_C2050_C2070_us.html
Double Precision floating point performance (peak) 515 Gflops
Leider gibt NV keine TDP für die 2070 an...
Guck unter "Specification": Sind 238 Watt bei 515 GFLOPs.
Ailuros
2010-09-22, 10:56:10
Ein Tesla 2050 verbraucht 230-250 Watt, leistet aber praktisch nie 515 GFlops DP.
Wo steht dass eine 2050 praktisch "nie" 515 GFLOPs erreicht?
Wie schon oben oefters erwaehnt ist der TDP fuer die 2050 bei 238W und damit ist wohl der insgesamte TDP der GPU gemeint. Wenn ich jetzt theoretisch nur in etwa 1/3 des cores einlege wird es wohl nicht die gesamten 238W verdonnern, weil sonst erstmal auch die Relation zwischen Tesla und Fermi in dem bloeden Diagramm ausfaellt.
Aber wenn's schon sein muss koennen wir ja auf die originalen Tesla/Fermi whitepapers zurueckgreifen und es wird leicht zu sehen sein welchen Stromverbrauch bei welchen Frequenzen und mit wie viel DP FLOPs sie in November 2009 noch projezierten.
Und ja ich bezweifle ernsthaft dass eine 2050 die 515GFLOPs in einem synthetischen Test nicht erreichen kann, da das Ding auf nur miserabler 1+GHz Frequenz laeuft.
***edit: uebrigens sind die genauen Frequenzen einer 2050:
575MHz (TMUs)/1150MHz (ALUs)/750MHz Speicher
deekey777
2010-09-22, 11:03:27
Bezieht sich die Präsentation wirklich auf die C2050 oder auf die angepeilte DP-Leistung eines vollwertigen GF100 aus dem Jahr 2009?
Spasstiger
2010-09-22, 11:05:14
Man sollte der Grafik vielleicht auch nicht zu viel Bedeutung beimessen. Die grobe Marschrichtung heißt wohl Faktor 10 bei der Performance pro Watt in 4 Jahren. Das bedeutet ungefähr ein Faktor 1,8 innerhalb eines Jahres.
Bezieht sich die Präsentation wirklich auf die C2050 oder auf die angepeilte DP-Leistung eines vollwertigen GF100 aus dem Jahr 2009?
Der hätte doch fast 4 DP-FLOPs* pro Watt gehabt? :D
* 512SPs @ 1,5GHz ~200W
Wie Spasstiger schon sagt, sollte man das wohl nicht zu ernst nehmen.
Was aber denkbar wäre, dass Nvidia hier eher nicht die optimistischsten Werte anlegt.
deekey777
2010-09-22, 11:13:35
Der hätte doch fast 4 DP-FLOPs* pro Watt gehabt? :D
* 512SPs @ 1,5GHz ~200W
Wie Spasstiger schon sagt, sollte man das wohl nicht zu ernst nehmen.
Was aber denkbar wäre, dass Nvidia hier eher nicht die optimistischsten Werte anlegt.
Es sind angepeilte Ziele von Nvidia: Beim GF100 war das Ziel 2 DP-FLOPs/(TDP-)Watt, was zumindest mit C2030/50 erreicht wurde. Beim Kepler dann 4-6 DP-FLOPs/(TDP-)Watt, usw. Mehr ist da nicht.
LovesuckZ
2010-09-22, 11:15:31
Der hätte doch fast 4 DP-FLOPs* pro Watt gehabt? :D
* 512SPs @ 1,5GHz ~200W
Schöne Lüge von dir.
Es sind angepeilte Ziele von Nvidia: Beim GF100 war das Ziel 2 DP-FLOPs/(TDP-)Watt, was zumindest mit C2030/50 erreicht wurde.
Niemals war das Ziel nur 2 DP-FLOPs pro Watt für Fermi.
Ein Beweis dafür ist das Telsa PDF, was auf Nvidias Server lag, wo man noch C2030/50 mit <=225W bei bis zu 1,4GHz angab.
Schöne Lüge.
Keine Lüge, selbst Ailuros wurden ähnliche Zahlen zugetragen im Bezug auf die Pro-Watt-Leistung der GeForce Versionen.
Hier hat man leider das Ziel deutlich verfehlt, was wohl auch an 40nm lag.
http://i47.tinypic.com/hry4ae.jpg
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=7020417&postcount=1 (ganz unten)
LovesuckZ
2010-09-22, 11:35:43
Keine Lüge, selbst Ailuros wurden ähnliche Zahlen zugetragen im Bezug auf die Pro-Watt-Leistung der GeForce Versionen.
Hier hat man leider das Ziel deutlich verfehlt, was wohl auch an 40nm lag.
Schön für ihn. nVidia selbst hat nur 8x DP auf der GTC2009 angekündigt. Wer irgendwelche Zahlen aus dem Internet nimmt, der wurde enttäuscht, aber nicht angelogen.
Schön für ihn. nVidia selbst hat nur 8x DP auf der GTC2009 angekündigt. Wer irgendwelche Zahlen aus dem Internet nimmt, der wurde enttäuscht, aber nicht angelogen.
Und du glaubst vor der GTC 2009 gab es für bestimmte Kunden noch kein Material, in welchem Nvidia seine Next-Gen-Tesla-Lösungen beworben hat? ;)
>3 DP-FLOPs pro Watt waren Anfang 2009 definitiv ein Ziel von Nvidia. Dass dies im Laufe des Jahres deutlich nach unten korrigiert werden musste, ist natürlich eine andere Sache.
Zumal dass gar nicht die Frage hier ist, sondern ob Nvidia in der Roadmap eben eine eher optimistische oder eher pessimistische Projektion vorgibt, wo man letztere dann zum konkreten Launch noch prestigeträchtig überbieten könnte.
tombman
2010-09-22, 11:46:21
Hab mir jetzt die ganze Präsentation angesehen und ... :eek:
Die war ja supermegageil :massa:
Nvidia will also so gut wie alle Bereiche "acceleraten" :ulol:
Die gezeigten Beispiele waren echt der Hammer, nur eines läßt Böses ahnen: "Geforce" wird nur einmal ganz kurz erwähnt und dann nimmer wieder. Ok, am Anfang wurde fett Wind für Tesselation gemacht, aber das wars dann auch schon. (Jensen hat HAWKS 2 als SIM bezeichnet :facepalm:)
Der Rest war eigentlich nur mehr Fermi-Tesla und wo man die fette number-crunsher power überall einsetzen kann.
Das hatte 100% was von BORG ;D;D
Nvidia, die freundlichen BORGS, die alles assimilieren, nicht zwangsweise, sondern weil sie darum GEBETEN werden. :ulol:
Jensen, komme über uns und BESCHLEUNIGE UNS ...AMEN :ugly:
Jedenfalls muß man sich um Nvidia keine Sorgen machen, so sehr wie die ihren Penis schon in den wichtigen Firmenärschen drinnen haben :D
Leider wird Geforce offenbar nur mehr ein Nebenprodukt in Zukunft sein :(
Um GeForce würde ich mir keine Sorge machen, mit der nun skalierbaren Raster und Geometrie-Architektur hat man ein brauchbares Grundgerüst für viele Jahre.
Und von der steigenden Pro-Watt-Leistung der ALUs profitiert man auch bei den Gamerkarten.
LovesuckZ
2010-09-22, 11:53:57
Und du glaubst vor der GTC 2009 gab es für bestimmte Kunden noch kein Material, in welchem Nvidia seine Next-Gen-Tesla-Lösungen beworben hat? ;)
>3 DP-FLOPs pro Watt waren Anfang 2009 definitiv ein Ziel von Nvidia. Dass dies im Laufe des Jahres deutlich nach unten korrigiert werden musste, ist natürlich eine andere Sache.
Ja. Ich habe längst aufgehört auf jedem zu hören, der meint etwas zu wissen.
Fakt ist, nVidia hat auf der GTC2009 eine bestimmte Leistungsangabe getätigt. Und die haben sie nicht eingehalten. Der Rest ist nonsens aus dem Internet.
Na wenn von NV bis zum 28nm Chip nichts mehr kommt dann Mahlzeit. Wird dann wohl ein hartes Jahr 2011.
Wer sagt das?
Auf 40nm existieren doch durchaus noch Optionen für eine neue Revision/optimierte Version von GF100 und im Gamer-Markt könnte man einen breiteren GF104 einführen.
Spasstiger
2010-09-22, 12:55:37
Fermi-Refresh kommt wohl im High-End.
G80/GT200 war ja im Prinzip auch eine Generation.
Ailuros
2010-09-22, 13:13:27
Schön für ihn. nVidia selbst hat nur 8x DP auf der GTC2009 angekündigt. Wer irgendwelche Zahlen aus dem Internet nimmt, der wurde enttäuscht, aber nicht angelogen.
Momentan ist aus der ersten Generation nur noch die 1060 erhaeltlich welche ueber 78 GFLOPs DP faehig ist, waehrend die nicht mehr erhaeltliche 1070 einen Schnitt ueber 90 GFLOPs lag.
78 * 8 = 624
90 * 8 = 720
Ich bin grosszuegig und nehme nur den ersten Fall. Haette Fermi/Tesla tatsaechlich auf 1.4GHz takten koennen mit tolerablem Stromverbrauch dann waeren es auch genau 624 GFLOPs DP gewesen und daher auch eine Steigerung um einen Faktor 8x.
Das obrige Bildchen dass der Gast geliefert hat war ein oeffentliches NV whitepaper vom November 2009, ergo sind die 1.2-1.4GHz bei bis zu <225W keinermans freie Erfindung und dabei war sogar 6GB Speicher mitprojeziert.
Echtzeit zeigt 1.15GHz bei 3GB/2050 (und ja die Spezifikationen auf der 2050/70 Seite sind hier sehr deutlich dass es NUR fuer die 2050 gilt) und 238W TDP. Bei 6GB/2070 waeren es dann wie viel?
Wie dem auch sei 515 / 78 = 6.6x und eben nicht 8x.
Das mit den random Zahlen aus dem Internet ist wohl der Witz des Tages.
Fakt ist, nVidia hat auf der GTC2009 eine bestimmte Leistungsangabe getätigt. Und die haben sie nicht eingehalten. Der Rest ist nonsens aus dem Internet.
Um zurueck aufs Thema zu kommen: wie Spasstiger schon getroffen notiert hat sollte man Praesentationen wie die momentan im Gespraech nicht allzu wortwoertlich nehmen weil sie am Ende aus diversen Gruenden eben fast immer zu optimistisch sein werden.
Wenn sich aber Anton Shilov nicht verhoert hat und NV gibt heute an dass Fermi lediglich ueber 1.5GFLOP/Watt faehig ist und es auch noch stimmt sieht es ziemlich miserabel fuer Fermi aus. Oder man verdreht mit Absicht die Realitaet so um zukuenftige Designs in ein besseres Licht zu stellen. Man nennt es u.a. marketing und ich selber bin oefters als ich es selber vertragen kann ein Opfer dieses in sehr vielen Bereichen vor allem mit NVIDIA da sie unter den miesesten PR/marketing Abteilungen ueberhaupt haben.
Fermi-Refresh kommt wohl im High-End.
G80/GT200 war ja im Prinzip auch eine Generation.
Stimmt. Und es bestaetigt auch die Angabe dass sie alle zwei Jahre mit einer neuen "Generation" ankommen werden (oder zumindest so ist es momentan geplant) mit einer "refresh-GPU-Familie" ca. pro Jahr. Wenn's jetzt ein paar Monate jeweils mehr sind geht die Welt auch nicht unter.
jetzt geht das hier schon wieder los. ich kann mich noch an den gf100-thread erinnern als LovesuckZ vorhersagt, dass wir vor fermi alle zu kreuze kriechen werden.
Ailuros
2010-09-22, 13:39:20
jetzt geht das hier schon wieder los. ich kann mich noch an den gf100-thread erinnern als LovesuckZ vorhersagt, dass wir vor fermi alle zu kreuze kriechen werden.
Da man normalweise mit dem Kreuz auf den Berg kriecht, schlage ich fuer Kepler einen Ausflug ans Meer vor :biggrin:
Spass beiseite ich moechte denjenigen sehen der zugesteht dass er nie ein Opfer von jeglichem marketing war; also bitte keine Steine im Glashaus ;)
Dural
2010-09-22, 13:41:02
naja Fermi / GF100 rockt zum teil schon ganz gut...
das einzige wirklich entäuschente am GF100 ist der verbrauch und die ausbeute, der den GF100 bis jetzt noch etwas einbremmst.
Ailuros
2010-09-22, 13:49:16
http://www.anandtech.com/show/3939/gtc-2010-reporters-notebook-day-1-nvidia-announces-future-gpu-families-for-2011-and-2013
Ziemlich gut geschrieben IMO.
naja Fermi / GF100 rockt zum teil schon ganz gut...
das einzige wirklich entäuschente am GF100 ist der verbrauch und die ausbeute, der den GF100 bis jetzt noch etwas einbremmst.
Aus dem obrigen Link:
For now they’re merely talking about performance in an abstract manner, in this case Kepler should offer 3-4 times the amount of double precision floating point performance per watt of Fermi. With GF100 NVIDIA basically hit the wall for power consumption (and this is part of the reason current Tesla parts are running 448 out of 512 CUDA cores), so we’re basically looking at NVIDIA having to earn their performance improvements without increasing power consumption. They’re also going to have to earn their keep in sales, as NVIDIA is already talking about Kepler taking 2 billion dollars to develop and it’s not out for another year.
Stromverbrauch und Umsatz sind hier die zwei Stichworte.
NVIDIA still has to release the finer details of the GPUs, but we do know that Kepler and Maxwell are tied to the 28nm and 22nm processes respectively. So if nothing else, this gives us strong guidance on when they would be coming out, as production-quality 28nm fabrication suitable for GPUs is still a year out and 22nm is probably a late 2013 release at this rate. What’s clear is that NVIDIA is not going to take a tick-tock approach as stringently as Intel did – Kepler and Maxwell are going to launch against new processes – but this is only about GPUs for NVIDIA’s compute efforts. It’s likely the company will still emulate tick-tock to some degree, producing old architectures on new processes first; similar to how NVIDIA’s first 40nm products were the GT21x GPUs. In this scenario we’re talking about low-end GPUs destined for life in consumer video cards, so the desktop/graphics side of NVIDIA isn’t bound to this schedule like the Fermi/compute side is.
Wrapping things up, don’t be surprised if Kepler details continue to trickle out over the next year. NVIDIA took some criticism for introducing Fermi months before it shipped, but it seems to have worked out well for the company anyhow. So a repeat performance wouldn’t be all that uncharacteristic for them.
Nein bitte nicht zum fettgedruckten.
LovesuckZ
2010-09-22, 13:50:23
Ich bin grosszuegig und nehme nur den ersten Fall. Haette Fermi/Tesla tatsaechlich auf 1.4GHz takten koennen mit tolerablem Stromverbrauch dann waeren es auch genau 624 GFLOPs DP gewesen und daher auch eine Steigerung um einen Faktor 8x.
Das obrige Bildchen dass der Gast geliefert hat war ein oeffentliches NV whitepaper vom November 2009, ergo sind die 1.2-1.4GHz bei bis zu <225W keinermans freie Erfindung und dabei war sogar 6GB Speicher mitprojeziert.
Kleiner Matheunterricht:
512*1218Mhz = 448*1400Mhz.
Nirgends hat nVidia 1500Mhz mit 512SP kommuniziert. Was sich Leute ausdenken, ist wohl keine Trollgrundlage.
Ailuros
2010-09-22, 14:06:51
Kleiner Matheunterricht:
512*1218Mhz = 448*1400Mhz.
Es wurden NIE seitens NVIDIA mehr als 448SPs fuer Tesla erwaehnt, angedeutet oder angekuendigt.
Das Bild hier:
http://i47.tinypic.com/hry4ae.jpg
stammt von einem NV whitepaper dass im November 2009 auf deren Hauptseite veroeffentlicht wurde. Es steht zwar von 1.25GHz bis zu 1.4GHz drauf aber wenn man das ganze Ding durchgelesen hat, sah man auch dass die 2050/3GB mit einem 190+W TDP angegeben wurde und das was hier sichtbar ist war die maximale Schaetzung fuer die 2070/6GB.
Heute geben sie einen 238W TDP aber nur fuer die 3GB/2050 an und das bei lediglich 1.15GHz.
Ausser Du glaubst dass die zusaetzlichen 3GB Speicher einer 2070 den Stromverbrauch nicht beinflussen werden.
Im Gegensatz geben sie fuer die Quadro 6000 leider keine Frequenzen an: http://www.nvidia.com/object/product-quadro-6000-us.html
Bei 448SPs hier, 384bit bus/750MHz Speicher wird hier ein TDP von 225W und noch der Happen hier:
Featuring new Scalable Geometry Engine™ technology, Quadro can deliver an unheard of 1.3 billion triangles per second, shattering previous 3D graphics limitations².
² Raw throughput number calculated by graphics processing clusters, GPU clock rate, and triangle throughput.
Wobei hoffentlich die 6000 auch eine 1.15GHz Frequenz hat, welches dann auch bedeuten koennte dass sich der TDP mit neueren chips etwas zum besseren geregelt hat. Oder die Frequenz ist doch niedriger als diese. Triolet hat fuer die GTX470 mit 100% culling 1959M Tris messen koennen.
Nirgends hat nVidia 1500Mhz mit 512SP kommuniziert. Was sich Leute ausdenken, ist wohl keine Trollgrundlage.
Hat wer behauptet? Bleiben wir dabei dass NV ihre eigene Projektionen fuer Tesla nicht einhalten konnten. Mehr brauchen wir ueber das Thema gar nicht weitergeigen und unnoetig Bandbreite verschwenden.
LovesuckZ
2010-09-22, 14:13:36
Es wurden NIE seitens NVIDIA mehr als 448SPs fuer Tesla erwaehnt, angedeutet oder angekuendigt.
Sie haben Fermi auf GTC2009 - im September - mit 512 SP angekündigt und 8x als Ziel herausgegeben. Das ergibt eine Taktfrequenz von 1218Mhz.
Erst zwei Monate später kam das Papier an die Öffentlichkeit. Hätten sie die 1400MHz erreicht, wäre die Leitungssteigerung immer noch eingetroffen.
Das ist das Problem mit dem selektiven Lesen. Statt das Gastposting zu löschen, das eine klare Lüge ist, wird hier probiert irgendwas zu zeigen, dass jeder schon weiß, wenn er die Wahrheit kennt.
Ailuros
2010-09-22, 14:35:08
Sie haben Fermi auf GTC2009 - im September - mit 512 SP angekündigt und 8x als Ziel herausgegeben. Das ergibt eine Taktfrequenz von 1218Mhz.
Fermi = Tesla ***edit: anders Fermi bezieht sich als Bezeichnung offensichtlich auf ganze Produkt-familien verschiedener Maerkte.
Erst zwei Monate später kam das Papier an die Öffentlichkeit. Hätten sie die 1400MHz erreicht, wäre die Leitungssteigerung immer noch eingetroffen.
Und alles kommt auf den Punkt zurueck dass sie einiges falsch eingeschaetzt haben was den Stromverbrauch betrifft. Die heutige 2050/3GB TDP liegt >40W (von den originalen 190+W TDP) ueber der Einschaetzung des obrigen whitepapers und dabei ist es mir sogar wurscht ob es nun 1.25 oder 1.4GHz gewesen waeren. Wenn ich die Frequenz von 1.15GHz noch mitberechne wird es noch laecherlicher.
Die 1.4GHz haben sie auf der 480 erreicht, aber mit nur 1GB Speicher und das Ding gehoert auch zur Fermi Familie.
Das ist das Problem mit dem selektiven Lesen. Statt das Gastposting zu löschen, das eine klare Lüge ist, wird hier probiert irgendwas zu zeigen, dass jeder schon weiß, wenn er die Wahrheit kennt.
Ich koennte auch jeglichen Ansatz mit Deinen und meinen Posts inklusive loeschen. Ich probiere hier gar nichts zu zeigen und debattiere wie jeglicher anderer User hier auch. Tud mir leid dass meine Meinung nicht auf Deinem Richtlinien liegt. Mit dem wirst Du wohl leben muessen.
So und koennen wir endlich zum eigentlichem Thema zurueckkommen oder ist der Quark immer noch nicht ausgekaut?
=Floi=
2010-09-22, 15:58:23
aber man wird wohl kaum das top produkt langsamer machen. LZ hat schon recht mit den 512SP und dann gehe ich bei allen produkten davon aus.
@dural
ferma hat schon mehr nachteile und die taktbarkeit ist auch nicht so toll. (wegen niedriger spannung und dem hohen verbrauch)
Gasti
2010-09-22, 16:10:30
Fermi hat ein ausgezeichnetes Taktpotential solange man die Abwärme abführen kann.
Dass ist eben eine limitierung durch den Fertigungsprozess, was bei 3.2 Mrd Trans. nicht verwunderlich ist.
Schlechtes Taktpotential hatte die Shaderdomain des GT200, da ging kaum was egal wie viel Spannung.
dildo4u
2010-09-22, 16:27:02
Hab mir jetzt die ganze Präsentation angesehen und ... :eek:
Die war ja supermegageil :massa:
Nvidia will also so gut wie alle Bereiche "acceleraten" :ulol:
Die gezeigten Beispiele waren echt der Hammer, nur eines läßt Böses ahnen: "Geforce" wird nur einmal ganz kurz erwähnt und dann nimmer wieder. Ok, am Anfang wurde fett Wind für Tesselation gemacht, aber das wars dann auch schon. (Jensen hat HAWKS 2 als SIM bezeichnet :facepalm:)
Leider wird Geforce offenbar nur mehr ein Nebenprodukt in Zukunft sein :(
Gab noch mehr Demos die sich auf Games beziehen.
http://www.hardwareclips.com/video/796/GTC-2010-DX11-Techdemos-von-Nvidia
Gasti
2010-09-22, 16:35:21
Gab noch mehr Demos die sich auf Games beziehen.
http://www.hardwareclips.com/video/796/GTC-2010-DX11-Techdemos-von-Nvidia
Naja der Voxelrenderer mit den Crashtestdummys ist wohl sehr weit von der Praxis entfernt.
Die Leuchturmdemo war allerdings sehr nett.
deekey777
2010-09-22, 16:45:39
Gab noch mehr Demos die sich auf Games beziehen.
http://www.hardwareclips.com/video/796/GTC-2010-DX11-Techdemos-von-Nvidia
Da bezieht sich keine einzige Demo auf irgendein Spiel.
Bucklew
2010-09-22, 16:49:36
Da bezieht sich keine einzige Demo auf irgendein Spiel.
Die grundlegende Technologie kann aber durchaus in Spielen genutzt werden.
deekey777
2010-09-22, 16:51:29
Die grundlegende Technologie kann aber durchaus in Spielen genutzt werden.
Grundlegend, aber klar doch.
Bucklew
2010-09-22, 16:55:06
Grundlegend, aber klar doch.
Nichts anderes meinte Dildo.
Hugo78
2010-09-22, 17:10:51
Leider wird Geforce offenbar nur mehr ein Nebenprodukt in Zukunft sein :(
Ist doch kein Wunder, wenn man sieht, dass in den USA und anderswo zu ~90% nur mit der PS3, Wii, XBox ect. vorm TV gezockt wird.
Und hier in D geht das Verhältnis PC/Konsole ja auch immer weiter vom PC weg.
Auch wenn es sich hier eventuell noch grad so 50/50 hält.
Dural
2010-09-22, 17:16:54
@dural
ferma hat schon mehr nachteile und die taktbarkeit ist auch nicht so toll. (wegen niedriger spannung und dem hohen verbrauch)
fermi ist in sachen Takt eigentlich der hammer, es limitiert nur der verbrauch/temperatur
selbst für ein GF100 sind 800MHz+ kein Problem und in der Regel immer zu erreichen, GF104 und kleiner legen da noch mal etwas zu.
So ein OC potential hab ich bis jetzt noch bei keiner GPU Generation gesehen! zb. läuft meine GTX470 mit stock Kühler bei 90°C GPU temp @ 810MHz @ 1,087Volt furmark stabil!
Bei GF104 und kleiner ist man noch mal ein gutes stück auf diesen werten, da man die hohen temperaturen und verbrauch des GF100 nicht hat zb. eine von mir getestete GTS450 @ 1,000Volt @ 900MHz 30Min. furmark stabil!
Die Einheiten an sich sind beim Fermi auch Super Effizient, zb. die 60TMUs kommen da an fast 100TMUs von RV870 ran, da gab es doch mal einen vergleich???
Fermi hat ein ausgezeichnetes Taktpotential solange man die Abwärme abführen kann.
Dass ist eben eine limitierung durch den Fertigungsprozess, was bei 3.2 Mrd Trans. nicht verwunderlich ist.
Schlechtes Taktpotential hatte die Shaderdomain des GT200, da ging kaum was egal wie viel Spannung.
jep, ist exakt so!
Nakai
2010-09-22, 17:20:58
Ob sich bei dem Sprung zu Maxwell wohl eine Wechsel auf VLIW verbirgt?
Bitter böser Sarkasmus oder Ernst?
IMO sind die Demos sehr eindrucksvoll.
Ist doch kein Wunder, wenn man sieht, dass in den USA und anderswo zu ~90% nur mit der PS3, Wii, XBox ect. vorm TV gezockt wird.
Und hier in D geht das Verhältnis PC/Konsole ja auch immer weiter vom PC weg.
Auch wenn es sich hier eventuell noch grad so 50/50 hält.
NV darf sich blos nicht auf den Profimarkt fixieren. Vor allem wenn der Konsolenmarkt immer größer wird. Derzeit ist die Lage ziemlich schlecht für NV nochmal in den Konsolenmarkt reinzukommen. Perf/mm² sind bei NV nicht so toll, BQ interessiert auch keinen auf den Konsolenmarkt und DP sowieso nicht.
GF104 zeigt aber auch, was möglich wäre. Ich sehe in Zukunft eher eine ähnliche Taktik wie ATI. Eine Performancegpu für den Spielermarkt.
mfg
Dural
2010-09-22, 17:30:31
Denk ich auch beziehungsweisse wird es mit der zeit gar nicht mehr anders gehen!
Man stelle sich nur mal ein 5Miliarden+ Chip vor der voll DP Einheiten usw. ist, da könnte man eine menge Transitoren einsparen wenn es zur um den GeForce/Gaming bereich geht!
Betreffent Konsolen, ein etwas überarbeiteter "GF104" @ 28nm dürfte mit um die 200mm2 nicht mal so schlecht da stehen für diesen Markt.
Hugo78
2010-09-22, 20:54:40
Für Konsolen kann man sich immernoch einen extra Chip bauen.
Da seh ich bei Nvidia kein Problem, eher noch wenn zb. Sony mal wieder auf den letzen Drücker kommt, weil ihr toller "über" Cell nicht die Grafik liefert, die er sollte.
Oder die Proger zu blöd wären damit um zugehen und etwas konservativere HW brauchten .. *g*
Wenn da Nvidia da etwas Zeit gegeben wird, und der Kunde auch weiß was er will, dann bauen die da nach wie vor passende Konsolen Chips.
Aber wirklich was dran verdienen kann man an den Dingern doch eh kaum (mehr).
Und die Frage ist, selbst wenn sie was passendes liefern, könnten sie die Preise mitgehen, wie andere Anbieter mit einem passenden SoC?!
Ich denk nicht (mehr) ... denn zb. in der neusten Box steckt ein SoC.
http://www.computerbase.de/news/hardware/prozessoren/2010/august/xbox-soc-von-ibm-duepiert-intel-und-amd/
Nintendo dürfte sich auch eher an einen "All in One" Anbieter halten und Sony auch, oder die haben immernoch Großmachtspläne vom "100 Core" Cell.
Dann ist Grand Tourismo 6 halt 20 Jahre in der Entwicklung, damit die PS4 auch mal ausgelastet wird. :D
Dural
2010-09-22, 21:10:42
mit dem verdienen geb ich dir recht, glaube auch nicht das man da gross geld macht...
viel interessanter dürfte aber für die firmen was anderes sein: die möglichkeit für Cuda und GPU-PhysX im konsolen bereich!!!
und ich denke genau deswegen dürfte das interesse seitens NV doch recht gross sein in einer der nächsten konsolen generation einen chip von ihnen zu haben! es wäre sehr dumm seitens NV nicht alles dran zusetzten das entweder PS4 oder XBOX3 einen NV chip bekommt...
Ailuros
2010-09-23, 09:41:37
fermi ist in sachen Takt eigentlich der hammer, es limitiert nur der verbrauch/temperatur
Netter Widerspruch. Was nuetzt jegliche Taktbarkeit wenn der Verbrauch bzw. Temperatur limitiert?
Die Einheiten an sich sind beim Fermi auch Super Effizient, zb. die 60TMUs kommen da an fast 100TMUs von RV870 ran, da gab es doch mal einen vergleich???
Den Vergleich hab ich wohl verpasst. Wenn sie wirklich so super-effizient sind wie Du sagst wundere ich mich ernsthaft wieso ploetzlich GF104 8TMUs/SM.
-----------------------------------------------------------------
Zum VLiW Quark den ich wohl uebersehen habe: jegliche Indizie seitens CUDA und deren zukuenftige road-map deuten eher in Richtung dass skalare ALUs erhalten werden.
Netter Widerspruch. Was nuetzt jegliche Taktbarkeit wenn der Verbrauch bzw. Temperatur limitiert?
Ein GF100 aus Willy Wonka's Fab wäre mit dem dort angeboten Prozess auf ~900MHz gelaufen? ;D
Den Vergleich hab ich wohl verpasst. Wenn sie wirklich so super-effizient sind wie Du sagst wundere ich mich ernsthaft wieso ploetzlich GF104 8TMUs/SM.
http://techreport.com/articles.x/19242/6 (Rightmark mit aniso 16x)
Und warum GF10x 8 TMUs hat ist doch ganz einfach, 4 wären einfach zu wenig pro SM gewesen. Zumal durch zwei Quad-TMUs an einem Texture-Cache die effektive Füllrate gegenüber GF100 bei GF10x wieder etwas gesunken ist.
Zum VLiW Quark den ich wohl uebersehen habe: jegliche Indizie seitens CUDA und deren zukuenftige road-map deuten eher in Richtung dass skalare ALUs erhalten werden.
Interessant wäre wie sich eine Entfernung der Shaderdomain auf den Platzbedarf und Stromverbrauch der SPs auswirken würde.
Dural
2010-09-23, 10:26:39
Netter Widerspruch. Was nuetzt jegliche Taktbarkeit wenn der Verbrauch bzw. Temperatur limitiert?
widerspruch? nein keiner den auch GF100 ist trotz diesem probleme sehr gut taktbar!
und umso kühler die GPU ist umso besser lässt sie sich takten, in der Fermi Architektur steckt also sehr sehr viel potential was das betrifft, siehe auch GF104 / GF106 / GF108
Den Vergleich hab ich wohl verpasst. Wenn sie wirklich so super-effizient sind wie Du sagst wundere ich mich ernsthaft wieso ploetzlich GF104 8TMUs/SM.
die aber ineffizienter als im GF100 sind, und einen leistungssprung kam GF104 deswegen auch nicht! siehe GTX460 vs GTX465
Ailuros
2010-09-23, 11:40:07
widerspruch? nein keiner den auch GF100 ist trotz diesem probleme sehr gut taktbar!
Wie soll ich das jetzt verstehen? Dass NV die GTX480 locker auf sagen wir mal 800MHz haette takten koennen? Nichts ist umsonst in 3D (Kristof Beets) und IHVs treffen solche Entscheidungen nicht weil es gerade zu einem Lotterie-Resultat passen koennte.
und umso kühler die GPU ist umso besser lässt sie sich takten, in der Fermi Architektur steckt also sehr sehr viel potential was das betrifft, siehe auch GF104 / GF106 / GF108
Siehe oben.
die aber ineffizienter als im GF100 sind, und einen leistungssprung kam GF104 deswegen auch nicht! siehe GTX460 vs GTX465
Hier spinnte NV eben genauso wie oben; jemand ist eines schoenen Tages aus dem Bett gestiegen und dachte sich dass es schick waere 8TMUs/SM auf GF104 einzubauen oder?
Wenn die zusaetzlichen TMUs gar nichts bringen wuerden, haetten sie sich die area und eine Menge Transistoren sparen koennen und noch besser ein gutes Prozentual an Strom.
Nochmal NV brauchte ein paar Zusaetze um so viel Leistung wie moeglich aus einem GF104 zu quetschen und u.a. legten sie auf zusaetzliche TMUs und 3*16 ALUs.
Interessant wäre wie sich eine Entfernung der Shaderdomain auf den Platzbedarf und Stromverbrauch der SPs auswirken würde.
Nach NV engineering analysieren sie bei jeder Generation ob und bei welchen Einheiten der GPUs es sich lohnt auf hot-clocking zu greifen. Bis jetzt zeigte jegliche Analyse dass es lediglich bei den ALUs lohnt und man sagte mir sogar dass die Analyse fuer GF100 zeigte dass wenn sie die TMUs auf 1.4GHz gejagt haetten die Transistoren sich mehr als verdoppelt haetten.
Ich kann schwer glauben dass NV nicht durch das hot-clocking dazugewinnt. Wenn es sich nicht lohnen wuerde, wuerden sie spinnen die Masche seit G80 beizubehalten.
Ich lass mich gerne eines besseren belehren, aber so weit ich es verstehe sind ALUs als quasi general purpose Einheiten voll geignet fuer solche Turnereien, wobei man es eventuell auch mit CPUs parallelisieren koennte vereinfacht.
Falls Du ein moegliches Opfer fuer den extravaganten Stromverbrauch von GF100 suchst, bezweifle ich dass es an den ALUs liegt oder dass ein universales Frequenz-domain mit anstatt mehr ALUs den Stromverbrauch unbedingt zum besseren wenden wuerde. Charlie trompetiert auf der oeden Speichercontroller-These die mir aber keinen Sinn macht persoenlich und ich glaube eher gerne an irgend ein merkwuerdiges Problem mit der Anzahl der SMs selber.
Was immer das Problem auch sein mag, bezweifle ich dass zukuenftige Varianten von der Fermi Familie mit sich tragen werden. Das einzig schwierige fuer NV ist lediglich den verlorenen Boden seit Herbst 2009 wieder gut zu machen.
Ailuros
2010-09-23, 14:30:04
Ich mach fuer das Ding nicht einen getrennten Thread auf:
http://www.xbitlabs.com/news/other/display/20100921215150_Nvidia_and_Portland_Group_Announce_CUDA_C_x86_Compiler.html
Klingt auesserst interessant.
Charlies Kommentar: http://www.semiaccurate.com/2010/09/23/nvidias-kepler-and-maxwell-barely-beat-moores-law/
Es waren sogar 768 DP-FLOPs bei 150W für den ursprünglichen GF100. ;D
Ailuros
2010-09-23, 15:05:37
Charlies Kommentar: http://www.semiaccurate.com/2010/09/23/nvidias-kepler-and-maxwell-barely-beat-moores-law/
Es waren sogar 768 DP-FLOPs bei 150W für den ursprünglichen GF100. ;D
1.5GHz wurde seitens NV nie oeffiziell erwaehnt. Wenn Charlie nicht mit Absicht uebertreiben wuerde, waere es auch nicht Charlie.
Wer glauben will dass NV je so bloed war und fuer einen >3Mrd. schweren chip mit 1.5GHz hotclocks nur 150W Stromverbrauch vorgesehen hat, sollte gefaelligst mal den Kopf schuetteln.
Das was off the record lange vor dem launch NV vermittelte ist dass sie von Fermi einen aehnlichen Stromverbrauch wie GT200 erwarteten. Waere alles nach Plan gelaufen - hier kann jeder die Luecke ausfuellen was genau das Problem war - dann haette ein voller GF100 bei knapp ueber den heutigen Frequenzen um die +/- 230W TDP (uhhhm echter TDP *hust*) verbraten.
Unter diesen Vorraussetzungen war NV's November 2009 Projektion fuer Tesla 2050/3GHz bei knapp ueber 190W fuer 448SPs bei bis zu 1.4GHz durchaus normal.
Wir werden sehen wie die zukuenftige GF10x Varianten aussehen werden aber wenn sie eine "GTX485" nachladen werden erwarte ich nicht mehr als 725-750MHz. Die maximale theoretische Toleranz der ALUs mit over-volting duerfte bei knapp ueber 1.8GHz liegen was aber Material fuer die Zukunft ist.
AnarchX
2010-10-28, 11:02:05
Ich mach jetzt fuer die Einzelheit nicht einen gentrennten thread auf aber Kepler soll ein ziemliche Ueberraschung werden was Transistoren-Dichte betrifft ;)
Schon VLIW oder noch mehr super-skalare Ausführung (z.B. 5 Vec16-ALUs an 3 Dual-Shedulern)?
Die Landing-Zone für Keplers DP-Leistung sollte auf jeden Fall bei deutlich über 1 TFLOPs liegen, AMDs "RV1090/R1000" und Intels 50-Core LRB werden hier wohl auch landen können.
Ailuros
2010-10-28, 11:36:25
Schon VLIW oder noch mehr super-skalare Ausführung (z.B. 5 Vec16-ALUs an 3 Dual-Shedulern)?
Die Landing-Zone für Keplers DP-Leistung sollte auf jeden Fall bei deutlich über 1 TFLOPs liegen, AMDs "RV1090/R1000" und Intels 50-Core LRB werden hier wohl auch landen können.
Keine Ahnung, deshalb nannte ich es auch eine relative bedeutungslose Kleinigkeit. Die Beschreibung aber der Aenderung der Dichte war in etwa analog zu RV670<->RV770.
Ich weiss zwar noch nicht was sie genau mit Kepler vorhaben (ausser den paar wagen hints seitens Jensen), aber waere es nicht ziemlich umstaendlich fuer CUDA wenn man sich von 1D ALUs entfernen wuerde?
Gipsel
2010-10-28, 18:12:43
Keine Ahnung, deshalb nannte ich es auch eine relative bedeutungslose Kleinigkeit. Die Beschreibung aber der Aenderung der Dichte war in etwa analog zu RV670<->RV770.Da ist die Transistoren-Dichte gar nicht so stark angestiegen (um ~7,5%), was man schon fast dadurch begründen könnte, daß die Fläche für den Speichercontroller relativ gesehen kleiner wurde und bei RV770 auch etwas mehr SRAM (hat sehr hohe Dichte) verbaut wurde. An den ALUs selber (die trotz erweiterter Fähigkeiten kleiner wurden), hat man aber auch ein wenig Feintuning gemacht, so daß man nicht nur minimal dichter packen konnte, sondern wohl auch ein paar Transistoren für einige Aufgaben sparen konnte.
Aber über die Gründe für die angeblich höhere Packdichte von Kepler kann natürlich spekuliert werden:
Keine hot clock mehr? Durchgehend 2fach "superskalar"? Deutlich größere Caches?
Ich weiss zwar noch nicht was sie genau mit Kepler vorhaben (ausser den paar wagen hints seitens Jensen), aber waere es nicht ziemlich umstaendlich fuer CUDA wenn man sich von 1D ALUs entfernen wuerde?
Nicht wirklich. Das erledigt alles der Compiler, so wie bei den Radeons im Moment auch. Der Programmierer muß nicht wissen, ob da 1D, 2D oder sonstwas für Einheiten verbaut sind. Das ist vollkommen transparent für die Programmierschnittstelle. Man kann es schlußendlich höchstens an den Performanceauswirkungen erkennen.
Ein "2D"-Ansatz wäre wahrscheinlich aus nvidias Sicht gar nicht so verkehrt. Man könnte unter Beibehaltung der 1:2-Rate für DP das Scheduling und auch die Registerfiles deutlich vereinfachen (insbesondere, wenn man 2er-Instruktionsgruppen statisch scheduled), momentan kann man das ja nicht wirklich optimal und streamlined nennen.
Zusätzlich läßt sich in typischen GPU-Code eigentlich fast immer genügend ILP finden, so daß man 2er-Gruppen eigentlich fast immer irgendwie füllen kann. AMD schafft es ja sogar bei 5er Gruppen auf 70% im Schnitt zu kommen (und Real-World-Code unter 40%, also 2 von 5 belegt, ist extrem selten). Damit kann man die ALU-Leistung im Vergleich zur jetzigen Architektur schon ganz ordentlich pushen (ich würde jetzt mal glatt bis zu +40% sagen), das würde schon ordentlich was bringen und man würde AMD auch bei der reinen ALU-Leistung ein wenig auf die Pelle rücken (die bisher damit alles totschlagen und darüber die anderen Aspekte ein wenig vernachlässigt haben).
Ailuros
2010-10-28, 18:48:34
Aber über die Gründe für die angeblich höhere Packdichte von Kepler kann natürlich spekuliert werden:
Keine hot clock mehr? Durchgehend 2fach "superskalar"? Deutlich größere Caches?
Dass die "superskalare" Idee auf GF104 kein Zufall oder Eintagsfliege war sollte klar sein. Ich hab zwar keinen Schimmer wie das Ding aussehen koennte aber wenn dann wuerde ich eher an eine gerade Anzahl von SIMDs tippen.
Nicht wirklich. Das erledigt alles der Compiler, so wie bei den Radeons im Moment auch. Der Programmierer muß nicht wissen, ob da 1D, 2D oder sonstwas für Einheiten verbaut sind. Das ist vollkommen transparent für die Programmierschnittstelle. Man kann es schlußendlich höchstens an den Performanceauswirkungen erkennen.
Ein "2D"-Ansatz wäre wahrscheinlich aus nvidias Sicht gar nicht so verkehrt. Man könnte unter Beibehaltung der 1:2-Rate für DP das Scheduling und auch die Registerfiles deutlich vereinfachen (insbesondere, wenn man 2er-Instruktionsgruppen statisch scheduled), momentan kann man das ja nicht wirklich optimal und streamlined nennen.
Zusätzlich läßt sich in typischen GPU-Code eigentlich fast immer genügend ILP finden, so daß man 2er-Gruppen eigentlich fast immer irgendwie füllen kann. AMD schafft es ja sogar bei 5er Gruppen auf 70% im Schnitt zu kommen (und Real-World-Code unter 40%, also 2 von 5 belegt, ist extrem selten). Damit kann man die ALU-Leistung im Vergleich zur jetzigen Architektur schon ganz ordentlich pushen (ich würde jetzt mal glatt bis zu +40% sagen), das würde schon ordentlich was bringen und man würde AMD auch bei der reinen ALU-Leistung ein wenig auf die Pelle rücken (die bisher damit alles totschlagen und darüber die anderen Aspekte ein wenig vernachlässigt haben).
Zwar hat es mit dem Ganzen nichts zu tun aber die Tegra GPU (und obwohl sie feature-maessig ein quasi GF6 Ableger ist) hat Vec4 +1 ALUs (4 MADD + 1 ADD) was auch andeutet dass NV wohl nicht vor VLiW eigentlich abscheut. Der einzige Haken hier eben ist dass das Ding momentan noch auf 240MHz laeuft und weder hoehere Frequenzen noch Gott Hilf hotclocks ein Gedanke waeren.
Das was Du als "2D" beschreibst ist ja eigentlich eine Erweiterung von der GF104 Idee wenn ich Dich jetzt nicht falsch verstanden habe. Wohl dann eher "superskalar" als eigentlich "VLiW".
Und nochmal die superdumme Frage: warum wagt sich keiner der IHVs auf eine pipeline die sowohl VLiW als auch skalare Befehle genauso leicht bearbeiten kann? Zu umstaendlich oder einfach ueberfluessig?
Gipsel
2010-10-28, 20:36:32
Das was Du als "2D" beschreibst ist ja eigentlich eine Erweiterung von der GF104 Idee wenn ich Dich jetzt nicht falsch verstanden habe. Wohl dann eher "superskalar" als eigentlich "VLiW".Kommt drauf an, wenn es statisches Scheduling von 2er Gruppen von Befehlen werden sollte, wäre es sozusagen VLIW, wobei man dann das "V" wohl lieber weglassen und vielleicht von 2er Bundles sprechen sollte.
Und nochmal die superdumme Frage: warum wagt sich keiner der IHVs auf eine pipeline die sowohl VLiW als auch skalare Befehle genauso leicht bearbeiten kann? Zu umstaendlich oder einfach ueberfluessig?Wenn Du mehrere "skalare" Befehle zur Laufzeit von der Hardware gruppieren und parallel ausführen lassen willst, dann bist Du praktisch schon bei GTX460 (könnte man aber noch breiter machen). Wenn Du dann noch richtige out-of-order Exekution dazupacken willst, sprengt der Aufwand dafür wohl das Transistorbudget und ist auch bei den typischen GPU Workloads vollkommen überflüssig und bringt für den Aufwand keine wesentliche Mehrperformance.
Das Problem ist, daß das auch auf das Finden von Parallelität im Instruktionsstrom angewiesen ist (nur muß das eben eben dynamisch zur Laufzeit des Programmes auf der GPU geschehen). Dabei gewinnt man da meiner Meinung nach (momentan) nicht wesentlich mehr, als wenn man das schon zur Kompilierzeit macht (Algorithmen und Datenzugriffe sind recht statisch, Registerspace ist verhältnismäßig groß), wodurch man dann bei VLIW (mehrere unabhängige skalare Instruktionen werden vom Compiler gebündelt) landen würde und sich zudem einen Haufen Verwaltungskram für jede einzelne Instruktion sparen kann.
Was Du vorschlägst, läuft doch praktisch darauf hinaus, daß man ausgehend von einem VLIW-Design mit x Slots die Möglichkeit einbauen sollte, die VLIW-Slots auch als x unabhängige Einheiten (arbeiten alle an einem anderen Workitem aka "Thread") anzusprechen. Dies entspricht dann aber doch einem Design mit x mal mehr 1D-Einheiten mit einem x-fach erhöhten Verwaltungsaufwand.
Was möglich ist (und seit Cypress auch von der Hardware unterstützt wird), ist daß man ausnutzt, daß viele Instruktionen mit einer geringeren Latenz abgearbeitet werden können als die etwas komplexeren Operationen. Damit kann man die Möglichkeit eröffnen, daß man in ein einziges Instruktionsbundle auch abhängige Instruktionen packt.
Auf Cypress z.B. sind die einfachen Fließkommaoperationen (add, mul, mad, sad) schon nach 4 Takten fertig (eigentlich sogar nach nur 3, aber das führt zu weit). Trotzdem kann man erst nach 8 Takten mit dem Ergebnis weiterrechnen (damit die Synchronisation mit anderen Instruktionen nicht verloren geht, außerdem ist das Registerfile nicht so schnell). Hat man jetzt eine Menge abhängiger Befehle, so könnte man doch (statt Slots in den VLIW-Bundles freizulassen) einen Slot die ersten 4 Takte warten lassen und dann in den zweiten vier Takten mit dem Ergebnis eines anderen Slots weiterrechnen lassen.
Ergebnis: Es werden mehr Slots benutzt, die Auslastung steigt und für diese einfachen Instruktionen sieht die VLIW-Einheit nicht mehr wie 4 Slots (+t) aus, sondern effektiv wie nur noch 2 Slots mit doppeltem Takt/halber Latenz.
Ailuros
2010-10-28, 22:32:50
Was Du vorschlägst, läuft doch praktisch darauf hinaus, daß man ausgehend von einem VLIW-Design mit x Slots die Möglichkeit einbauen sollte, die VLIW-Slots auch als x unabhängige Einheiten (arbeiten alle an einem anderen Workitem aka "Thread") anzusprechen. Dies entspricht dann aber doch einem Design mit x mal mehr 1D-Einheiten mit einem x-fach erhöhten Verwaltungsaufwand.
Ich hatte was anderes im Hinterkopf um hab mir Gedanken gemacht ob die SGX ALU Philosophie auch vielleicht im GPU high end Bereich unter Bedingungen Sinn machen wuerde.
Ein einfacher SGX fuer eingebettetes Zeug kann entweder:
1* FP32 (scalar)
2* FP16 (vec2)
4* INT8 (vec3 or vec4)
Bei neueren multi-core Varianten sind es sogar doppelt so viele Instruktionen. Hier frag ich mich ob man das Ganze in der weniger absehbaren Zukunft nicht irgendwie nach der Logik gestalten koennte und sogar von DP ausgehend.
Womoeglich aber wohl doch eine Schnappsidee oder?
AnarchX
2010-10-28, 22:47:09
Es gibt ja auch noch diese Projektion von Nvidia mit Cores mit je 3 FPUs: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7623791#post7623791
Fragt sich ob das eventuell schon die Entwicklungslinie nach Maxwell darstellt, wobei wohl selbst für High-End-GPUs ein Vorlauf von 7 Jahren etwas zu viel wäre.
Gipsel
2010-10-28, 23:45:18
Ein einfacher SGX fuer eingebettetes Zeug kann entweder:
1* FP32 (scalar)
2* FP16 (vec2)
4* INT8 (vec3 or vec4)
Ich weiß zwar nicht, wie das bei SGX genau läuft (ich weiß, Du bist ein fan davon), aber für mich sieht das jetzt auch nicht soo viel anders als die VLIWs des Cypress aus.
Eine VLIW-Einheit eines Cypress kann:
4* FP32 (skalar) bzw. 1* FP32 (vec4 oder gar vec5, falls es das geben würde)
4* Int32 (skalar) bzw. 1* Int32 (vec4), zumindest für die meisten Sachen,
für Multiplikation ist es 1* Int32 (MUL, skalar)
4* Int24 (MUL, skalar) bzw. 1* Int24 (MUL, vec4)
2* FP64 (ADD, Konversionen, skalar) bzw. 1* FP64 (ADD, Konversionen, vec2)
1* FP64 (skalar, alles mit Multiplikationenr)
Ein paar wenige Instruktionen gibt es dann noch, die gleich auf bis zu 16 Int8-Werten rumhantieren.
Als zusätzliches Schmankerl darf man die verschiedenen Möglichkeiten noch beliebig mixen, solange das nicht mehr als 4 oder 5 werden und die Abhängigkeiten das erlauben. Es geht also auch z.B:
FP32 vec3 + Int32 vec2, oder
FP64 vec2 ADD + Int32 skalar MUL
Ailuros
2010-10-29, 11:44:37
Ergo sind ALUs ohnehin schon beim Stadium dass ich im Hinterkopf habe.
AnarchX
2010-10-29, 16:27:01
Könnte man den GF104 Ansatz mit GF100 kombinieren?
Ein SM bzw. Cluster, der so aussieht:
- 3x 16 SPs
- Dual-Sheduler
- 48 SP-FMAs, 16 DP-FMAs
Landingzone für eine 225W Tesla sollte wohl etwa 1,3-1,4 TFLOPs DP sein, braucht man bei konservativeren 1,7GHz etwa 384 DP-FMAs.
Macht für den Gesamt-Chip 1120SPs und 3,8 TFLOPs SP-Leistung.
Also insgesamt 24 Cluster.
Ein GF104-Cluster sollte etwa ~20mm² @ 40nm groß sein, wieder hinzugefügte DP-Fähigkeit vielleicht 30%, ~26mm².
Auf 28nm 13mm², wobei Ailuros noch von vebesserter Packdichte sprach.
Bei 13mm² etwa ~310mm² Gesamtfläche für die Cluster, mit verbesserte Packdichte vielleicht unter 300mm².
Damit läge man über den ~260mm² der Cluster bei GF100, jedoch kann man wohl für Kepler annehmen, dass die reinen 3D-Grafik-Bestandteile nicht so stark gesteigert werden. Wahrscheinlich nur 6 GPCs und 64 ROPs, sodass man wieder bei den üblichen ~550mm2 landen könnte.
Ailuros
2010-10-29, 16:44:59
Ich hab zwar nicht mal einen anstaendigen hint aber was genau spricht gegen 4*16 theoretisch? Ich lass mich ja gerne eines besseren belehren aber waere es fuer eine Architektur mit hoher HPC Konzentration nicht logischer einen um einiges fetteren DP Wert erreichen zu koennen?
Die ExaScale Projektion ist erstens fuer 2017 und nicht fuer 2011/2 und zweitens bin ich mir immer noch nicht sicher ob die angegebenen FLOP Werte nur fuer die GPU Einheiten sind oder ob die 16 CPU cores noch mitgerechnet wurden.
=Floi=
2010-11-28, 07:43:29
wird es hier auch wieder nur eine 1:2 taktdomain geben und warum rückte man vom ungeraden verhältnis ab?
Nightspider
2010-12-09, 22:02:01
wird es hier auch wieder nur eine 1:2 taktdomain geben und warum rückte man vom ungeraden verhältnis ab?
Ich glaub das wird dir hier keiner beantworten können.
Wahrscheinlich schon, weil es einfach bei den letzten Generationen der Fall war. Nvidia könnte aber auch an ein paar Schrauben drehen und das Verhältnis vergrößern.
Interessanter ist die Frage, ob der Next-Gen-Chip erst in 28nm erscheint, denn dann könnte es 2011 knapp werden, wenn etwas schief geht.
Bisher ließt man ja auch nur von Verschiebungen beim Fertigungsprozess.
Ich hoffe das bis Mitte 2011 noch was kommt, da die GTX580 ja nur aufgewärmtes Essen ist, welches schon Ende 2009 auf dem Tisch stehen sollte. Allerdings glaube ich selbst nicht dran das so schnell was Neues kommt.
mapel110
2010-12-09, 22:18:24
Vor 2012 kommt doch nun höchstwahrscheinlich kein 28nm-Chip. Also wird das ganze Jahr 2011 ziemlich langweilig. Ich glaube kaum, dass nvidia unter 40nm noch was neues bringen wird. Bissl Rebranding und das wars.
Hugo78
2011-01-20, 16:04:01
Doch noch 28nm Geforces in Q4/ 2011?
http://ht4u.net/news/23257_nvidias_28-nm-gpus_kommen_im_viertem_quartal/
Dural
2011-01-20, 16:24:44
Kepler steht ja auch auf der roadmap für Q4 2011 :wink: also wäre es nur der reguläre zeit plan.
Ailuros
2011-01-21, 08:05:23
Doch noch 28nm Geforces in Q4/ 2011?
http://ht4u.net/news/23257_nvidias_28-nm-gpus_kommen_im_viertem_quartal/
Low end oder high end GPU?
MadManniMan
2011-01-21, 08:08:42
Wie üblich mit Vorreitern höchstens im Mainstream, nehme ich an?
Ailuros
2011-01-21, 08:15:10
Wie üblich mit Vorreitern höchstens im Mainstream, nehme ich an?
http://ht4u.net/news/22929_verfuegt_nvidia_bereits_ueber_28-nm-chips/
http://fudzilla.com/graphics/item/20742-nvidia-has-28nm-sample-chips
Ich erinnere daran dass GT21x die ersten 40nm@TSMC GPUs waren.
MadManniMan
2011-01-21, 09:06:13
Das Übliche also - dann muss die 460 GTX wohl bis Anfang/Mitte 2012 halten ;)
AnarchX
2011-05-04, 10:55:08
NVs GTC vom Herbst 2011 auf Frühjahr 2012 verschoben: http://ht4u.net/news/23795_nvidia_gtc_verschoben_auf_fruehjahr_2012/
Ob das etwas mit aktuellen Stand von 28nm und entsprechend Kepler zu tun haben könnte?
N0Thing
2011-05-04, 13:23:14
In der Pressemitteilung von Nvidia (http://pressroom.nvidia.com/easyir/customrel.do?easyirid=A0D622CE9F579F09&version=live&prid=749979&releasejsp=release_157&xhtml=true) liest sich das ganze eher so, daß man Aufgrund von inhaltlichen Überschneidungen die GTC in den USA verschiebt, um den anderen Veranstaltungen in diesem Jahr mehr Aufmerksamkeit zu geben.
Entwicklungs- oder Produktionsprobleme würde ich da nicht heraus lesen.
Nightspider
2011-05-06, 22:36:11
TSMCs 28nm Gigafab wird eher fertig, beginnt mit Testproduktionen im 3.Q und Serienfertigung ab 4Q.:
http://www.computerbase.de/news/wirtschaft/unternehmen/2011/mai/tsmcs-neue-gigafab-liegt-vor-dem-zeitplan/
Könnte dadurch Nvidias Kepler alias GTX 680 schon im ~Dezember/ Januar aufschlagen?
AffenJack
2011-05-06, 23:03:50
Das hat doch gar nix mit Kepler zutun, der Prozess muss gut genug sein und der Chip auch fertig sein. Sowieso ist das nur die 2te 28nm Fabrik. Der Vorteil der früheren Fertigstellung ist eher, dass man schon früh ne 2te Fab hat und dadurch die 28nm Kapazitäten deutlich höher sein sollten als bei 40nm am Anfang.
Nightspider
2011-05-06, 23:38:15
Jetzt ist aber auch die Frage wann die erste 28nm Fab ihre Serienproduktion aufnimmt?
Nvidia dürfte längst fertig sein, mit Kepler imo. Die warten doch bestimmt auf den nächsten Fertigungsprozess.
Auf jeden Fall ist es positiv das die Verfügarkeit bei 28nm von Anfang an besser wird.
M4xw0lf
2011-05-07, 08:56:04
Ich erinnere daran dass GT21x die ersten 40nm@TSMC GPUs waren.
Von Nvidia zumindest - ansonsten war die HD 4770 die erste 40nm GPU.
Ailuros
2011-05-07, 10:46:48
Von Nvidia zumindest - ansonsten war die HD 4770 die erste 40nm GPU.
Offensichtlich da es ein NV relativer thread ist; es ging lediglich darum dass IHVs wohl zuerst mit kleineren chips auf Prozess X experimentieren bevor sie groessere zur Produktion schicken. NV hat mit GT21x genauso ueble Erfahrungen gemacht wie auch mit jedem Fermi-testrun in 2009. Erst mit GF11x schnallte NV wie man einen "leak-freundlichen" Prozess wie 40G@TSMC "behandeln" muss.
@ail
da kommen NV (und AMD wahrscheinlich auch) erst mit kleineren Chips unter 28nm und nicht mir ihren HighEnd Chips oder?
@all
gibts denn schon Infos zu Kepler? mal abgesehen davon dass er im 28nm Prozess gefertigt werden soll?
Dalai-lamer
2011-05-07, 15:14:52
Hm,
diese Energieeffizienz wäre ideal für die neue Next gen
Nightspider
2011-05-07, 15:30:27
Hm,
diese Energieeffizienz wäre ideal für die neue Next gen
Wovon redest du?
boxleitnerb
2011-05-07, 16:45:50
Er meint wohl die Folie, die die DP-GFLOPS/W zeigte bis Maxwell. Aber das hat mit der Effizienz in Spielen ja nun überhaupt nichts zu tun.
Nightspider
2011-05-07, 16:56:42
Eben...Marketingfolien, die bis zu 2 Jahre vor dem Release gezeigt wurden haben wenig Aussagekraft.
mapel110
2011-05-16, 00:22:01
http://www.xbitlabs.com/news/other/display/20110515145941_TSMC_Sees_Design_Explosion_with_28nm_Chips.html
http://www.eetimes.com/electronics-news/4215986/Design-starts-triple-for-TSMC-at-28-nm
28nm scheint ganz gut zu laufen. Jedenfalls vertrauen viele Kunden offenbar darauf.
"The smartphone and tablet is the new killer application," said Maria Marced, president of TSMC Europe. "We are seeing a design explosion at 28-nm. We have 89 tape-outs in the pipeline," Marced added. She said that by TSMC's estimate the company currently holds 90 percent of the world's pending tape-outs at 28-nm.
=Floi=
2011-05-16, 02:02:56
nur sind solche kleinen chips eben nicht am maximum des prozesses designt.
Nightspider
2011-05-16, 02:22:50
Damit dürften die Tablets und Smartphones nächstes Jahr erneut mind. eine Geschwindigkeitsverdopplung erfahren.
Hoffentlich sehen wir bei NV mal wieder einen Grafikchip, der vor allem bei Games richtig gut abgeht, wie der G80 damals... die letzten Sprünge waren ja höchstens doppelt so schnell bei extremen Settings und der G100 hat viel anderen Schnickschnack für Rechencluster usw, die man als Gamer nicht braucht. AMDs Chips sind ja fast ausschließlich auf Games getrimmt, weshalb ja viele den HD5000er Karten eine bessere Effizienz bescheinigt haben.
Wäre toll wenn NV mal wieder einen richtig hohen Leistungssprung hinlegt. (>2x Performance)
boxleitnerb
2011-05-16, 07:38:36
Damit dürften die Tablets und Smartphones nächstes Jahr erneut mind. eine Geschwindigkeitsverdopplung erfahren.
Hoffentlich sehen wir bei NV mal wieder einen Grafikchip, der vor allem bei Games richtig gut abgeht, wie der G80 damals... die letzten Sprünge waren ja höchstens doppelt so schnell bei extremen Settings und der G100 hat viel anderen Schnickschnack für Rechencluster usw, die man als Gamer nicht braucht. AMDs Chips sind ja fast ausschließlich auf Games getrimmt, weshalb ja viele den HD5000er Karten eine bessere Effizienz bescheinigt haben.
Wäre toll wenn NV mal wieder einen richtig hohen Leistungssprung hinlegt. (>2x Performance)
Ack!
Und ich wünsche mir auch neue Features. Abgesehen von DX10/11 ist da jetzt nichts Weltbewegendes passiert (jedenfalls in den Bereichen, die mich interessieren).
aylano
2011-05-16, 09:12:44
nur sind solche kleinen chips eben nicht am maximum des prozesses designt.
Und das meiste der Tape-Outs wird hier eh 28nm-LP sein und nur ein wenige 28nm-HP. (Mindestens zwei könnten laut AMD von AMD sein, da sie beim 1Q Geschäftsbericht-Call von mehrere 28nm-Tape-Outs für das 2Q berichteten.)
Gipsel
2011-05-16, 11:17:17
"We have 89 tape-outs in the pipeline," Marced added. She said that by TSMC's estimate the company currently holds 90 percent of the world's pending tape-outs at 28-nm.
Interessanter wäre es fast gewesen, wenn man den Anteil an bereits erfolgten Tapeouts erfahren hätte und nicht, wieviele man für die Zukunft plant. :rolleyes:
Und wie hier schon angesprochen, der erste 28nm Prozeß von TSMC soll ja der LP ohne HKMG sein, der HP und die zweite Version des LP ("HPL", mit HKMG) sollen ja erst etwas später folgen.
Knuddelbearli
2011-05-19, 01:54:00
Damit dürften die Tablets und Smartphones nächstes Jahr erneut mind. eine Geschwindigkeitsverdopplung erfahren.
Hoffentlich sehen wir bei NV mal wieder einen Grafikchip, der vor allem bei Games richtig gut abgeht, wie der G80 damals... die letzten Sprünge waren ja höchstens doppelt so schnell bei extremen Settings und der G100 hat viel anderen Schnickschnack für Rechencluster usw, die man als Gamer nicht braucht. AMDs Chips sind ja fast ausschließlich auf Games getrimmt, weshalb ja viele den HD5000er Karten eine bessere Effizienz bescheinigt haben.
Wäre toll wenn NV mal wieder einen richtig hohen Leistungssprung hinlegt. (>2x Performance)
will hier jetzt keine Diskussion entfachen aber so stimmt das nicht! Auch bei den kleineren Modellen, wo auch NV diesen Schnickschnack gestrichen hat, hat AMD die bessere Effizienz
Nightspider
2011-05-19, 01:58:28
Ja GF104 gehört für mich mit zum GF100 dazu. Unterscheiden sich ja nicht so stark.
SamLombardo
2011-05-19, 08:58:06
Die Effizienz ist für mich zweitrangig. Ich erwarte von Keppler hauptsächlich brachiale Spieleleistung. Wenn ich eine doppelte GF100 Leistung bei ähnlichem Verbrauch bekomme bin ich zufrieden;)
M.(to_the)K.
2011-05-23, 15:44:49
Die Effizienz ist für mich zweitrangig. Ich erwarte von Keppler hauptsächlich brachiale Spieleleistung. Wenn ich eine doppelte GF100 Leistung bei ähnlichem Verbrauch bekomme bin ich zufrieden;)
Doppelte Lesitujng wird es nicht geben. Nicht mal ansatzweise. warum werden hier immer diese wunschträume geäußert? mit 40 auf 28 nm ist wohl ersmal nur eine steigerung der transsitoren um faktor 1,6 umsetzbar. plus vllt. ein paar optimierungen bei der packdichte, aber das ist ja eher atis fachgebiet.
Also bleiben defakto vllt. 40% Mehr leistung bei gleichem Verbruach hängen. Und das wäre auch schon beachtlich.
LovesuckZ
2011-05-23, 15:46:45
Stimmt. Wir sollten von mindesten 4x ausgehen, sowie es GF100 zu GT200b geschafft hat.
boxleitnerb
2011-05-23, 15:56:16
Stimmt. Wir sollten von mindesten 4x ausgehen, sowie es GF100 zu GT200b geschafft hat.
Rosinenpickerei zählt nicht ;)
Kaum eine neue Generation hat wirklich die 200% geschafft im Schnitt in den letzten Jahren.
http://www.computerbase.de/artikel/grafikkarten/2010/test-nvidia-geforce-gtx-480/21/#abschnitt_performancerating_qualitaet
LovesuckZ
2011-05-23, 16:01:06
Rosinenpickerei zählt nicht ;)
Kaum eine neue Generation hat wirklich die 200% geschafft im Schnitt in den letzten Jahren.
http://www.computerbase.de/artikel/grafikkarten/2010/test-nvidia-geforce-gtx-480/21/#abschnitt_performancerating_qualitaet
Geometrie und vorallem Tessellation sind keine Rosinenpickerei. Der Sprung von GT200b auf GF100 war riesig und dieser Begriff ist nichtmal annährend passend dafür.
Ich erwarte mir von Kepler eine vollkommen andere Rechenarchitektur. Und dann könnte dies die selben Auswirkungen haben wie das neue Front-End von Fermi.
fondness
2011-05-23, 16:06:28
mit 40 auf 28 nm ist wohl ersmal nur eine steigerung der transsitoren um faktor 1,6 umsetzbar.
Wie kommst du auf die 1,6 jetzt genau?
boxleitnerb
2011-05-23, 16:21:50
Geometrie und vorallem Tessellation sind keine Rosinenpickerei. Der Sprung von GT200b auf GF100 war riesig und dieser Begriff ist nichtmal annährend passend dafür.
Ich erwarte mir von Kepler eine vollkommen andere Rechenarchitektur. Und dann könnte dies die selben Auswirkungen haben wie das neue Front-End von Fermi.
Natürlich ist das Rosinenpickerei - siehst du deine +300% in den verlinkten Ratings irgendwo? Wir reden von einem Pool von Spielen, nicht von einzelnen Benchmarks. Ich spiele keine Benchmarks :P
Außerdem kannst du DX11 mit GT200b gar nicht vergleichen, weil der das nicht kann. Klar hat man in manchen Bereichen massive Möglichkeiten geschaffen, aber ein Spiel besteht nunmal auch aus Pixeln und Texturen, und die wollen ebenso berechnet werden, nicht nur Dreiecke. Siehe Pixel- und Texelfüllrate. Ich erwarte von Kepler vor allem Stärke in hohen Auflösungen (Downsampling) und SGSSAA. Das ist mir persönlich viel wichtiger als Tessellation und Co.
LovesuckZ
2011-05-23, 16:30:36
Natürlich ist das Rosinenpickerei - siehst du deine +300% in den verlinkten Ratings irgendwo? Wir reden von einem Pool von Spielen, nicht von einzelnen Benchmarks. Ich spiele keine Benchmarks :P
DAS ist Rosinenpickerei. Das Front-End benötigt Transistoren, die eben nicht in TMUs und Recheneinheiten gesteckt werden konnten. Klar, wenn man keinen Bock auf Fortschritt hat und liebers Fake-Aliasing-Methoden statt reale Geometrie will, dann wird man nie mehr als 200% erreichen und enttäuscht sein.
Außerdem kannst du DX11 mit GT200b gar nicht vergleichen, weil der das nicht kann. Klar hat man in manchen Bereichen massive Möglichkeiten geschaffen, aber ein Spiel besteht nunmal auch aus Pixeln und Texturen, und die wollen ebenso berechnet werden, nicht nur Dreiecke. Siehe Pixel- und Texelfüllrate. Ich erwarte von Kepler vor allem Stärke in hohen Auflösungen (Downsampling) und SGSSAA. Das ist mir persönlich viel wichtiger als Tessellation und Co.
Ja - kein Fortschritt. Was du willst, ist Stillstand. Dann wird man vielleicht enttäuscht sein. Ich will endlich mehr als dem selben Crap immer und immer wieder. Und wer dann Downsampling und SGSSAA will, kann ja immer noch auf SLI gehen.
boxleitnerb
2011-05-23, 16:42:58
DAS ist Rosinenpickerei. Das Front-End benötigt Transistoren, die eben nicht in TMUs und Recheneinheiten gesteckt werden konnten. Klar, wenn man keinen Bock auf Fortschritt hat und liebers Fake-Aliasing-Methoden statt reale Geometrie will, dann wird man nie mehr als 200% erreichen und enttäuscht sein.
Rosinenpickerei ist es, einzelne Anwendungsfälle zu betrachten, wo die neue Architektur sich besonders gut schlägt. Das Gegenteil davon ist, eine breites Feld von Anwendungen zu betrachten - eben das, was die Grafikkarte in der Realität auch berechnen muss.
Du selbst setzt doch Downsampling ein - jetzt soll das stinkig sein??? Flimmerfreie Grafik ist für mich auch eine Form von Fortschritt. Es gibt nicht nur den Fortschritt, den du propagierst, sondern er kommt in vielerlei Form.
Es ist aber auch müßig, darüber zu diskutieren - solange die Konsolen nicht massig Geometrie verarbeiten können, wird ein Großteil der Spiele die Möglichkeiten nicht ausnutzen können. Ich will eher das, was jetzt schon massiv zu einem besseren Bild (bei ausreichenden fps) beitragen kann.
Ich sag ja nicht, dass die massive Geometrieleistung schlecht ist - nur zu früh dank der Konsolen. Momentan hab ich davon ziemlich wenig bis nichts - von AA-Spielereien hingegen sehr viel, weil ich damit Dutzende Spiele optisch aufwerten kann wo ich sonst mit einem Grieselbrei auf dem Bildschirm leben müsste.
Und wer dann Downsampling und SGSSAA will, kann ja immer noch auf SLI gehen.
Hab ich ja schon. Schau dir mal die Samaritan Demo der neuen Unrealengine an. 3x GTX580 nötig für ein flüssiges Spielerlebnis. An welcher Stelle es da genau hakt, weiß ich nicht, aber ziemlich sicher nicht nur an der Geometrieleistung...
Alles in allem stimmen deine 400% eben nur in absoluten Einzelfällen und das weißt du auch.
LovesuckZ
2011-05-23, 16:55:23
Rosinenpickerei ist es, einzelne Anwendungsfälle zu betrachten, wo die neue Architektur sich besonders gut schlägt. Das Gegenteil davon ist, eine breites Feld von Anwendungen zu betrachten - eben das, was die Grafikkarte in der Realität auch berechnen muss.
Du selbst setzt doch Downsampling ein - jetzt soll das stinkig sein??? Flimmerfreie Grafik ist für mich auch eine Form von Fortschritt. Es gibt nicht nur den Fortschritt, den du propagierst, sondern er kommt in vielerlei Form.
Die Abwärtskompartibilität auf dem PC ist in diesem Fall eben ein Fluch. Es ist wohl logisch, dass GF100 nicht 400% schneller kann, wenn dies nur eintrifft, wenn man Tessellation verwendet. Ältere Spiele zeigen es eben nicht. Deswegen ist es auch Rosinenspickerei auf ältere Spiele oder Spiele ohne Tessellation zu zeigen. Man kann eigenlich froh sein, dass GF100 noch so schnell in diesen Spielen geworden, wenn man vergleicht, dass AMD trotz erbärmlicher Tessellationimplementierung auch nicht mehr erreicht hat.
Achja, Downsampling ist toll, aber kein Ersatz für richtige Geometrie oder auch Effektphysik. Und nicht vergessen: Echte Geometrie lässt sich per MSAA glätten, was wiederum dazuführt, dass SSAA an Bedeutung verliert und man mehr Leistung für andere Effekte hat.
Hab ich ja schon. Schau dir mal die Samaritan Demo der neuen Unrealengine an. 3x GTX580 nötig für ein flüssiges Spielerlebnis. An welcher Stelle es da genau hakt, weiß ich nicht, aber ziemlich sicher nicht nur an der Geometrieleistung...
2xGTX für's Rendering und 1x für GPU-PhysX. Und das soll in Echtzeit laufen. Der 3DMark2011 läuft selbst mit 3xGTX570 in Extreme beschissenen...
Alles in allem stimmen deine 400% eben nur in absoluten Einzelfällen und das weißt du auch.
Nein, die trifft immer dann zu, wenn man eben auf die Verbesserungen setzt. Das ist auch logisch.
Spasstiger
2011-05-23, 17:06:30
Ich fordere reine Wireframe-Spiele ohne Texturen für LovesuckZ.
Eine Erhöhung der Rechenleistung um 300% gegenüber Fermi halte ich für die nächste Generation (28 nm) für nicht möglich.
Gipsel
2011-05-23, 17:07:18
Es ist wohl logisch, dass GF100 nicht 400% schneller kann, wenn dies nur eintrifft, wenn man Tessellation verwendet. Ältere Spiele zeigen es eben nicht.
Auch neuere nicht. Die müssen nämlich auch noch was anderes machen als nur zu tessellieren. Auch neue Spiele bestehen eben nicht nur aus Tessellation.
Deswegen ist es auch Rosinenspickerei auf ältere Spiele oder Spiele ohne Tessellation zu zeigen.Es ist mindestens genausogut Rosinenpickerei, einen nicht unter gleichen Voraussetzungen möglichen Vergleich durchzuführen, GT200 kann keine Tess, GF100 kann es. Wie kommst Du da auf 400% Leistungssteigerung?!?
Und nicht vergessen: Echte Geometrie lässt sich per MSAA glätten, was wiederum dazuführt, dass SSAA an Bedeutung verliert und man mehr Leistung für andere Effekte hat.
Und nicht vergessen: Eine exorbitante Steigerung der Geometrie hat eine steigende Ineffizienz der heutigen quadbasierten Renderer zur Folge, die die effektiv verfügbare Shaderleistung drastisch mindert, ohne die Grafikqualität noch merklich (bei einem Echtzeitrenderer) anzuheben.
boxleitnerb
2011-05-23, 17:11:35
Die Abwärtskompartibilität auf dem PC ist in diesem Fall eben ein Fluch. Es ist wohl logisch, dass GF100 nicht 400% schneller kann, wenn dies nur eintrifft, wenn man Tessellation verwendet. Ältere Spiele zeigen es eben nicht. Deswegen ist es auch Rosinenspickerei auf ältere Spiele oder Spiele ohne Tessellation zu zeigen. Man kann eigenlich froh sein, dass GF100 noch so schnell in diesen Spielen geworden, wenn man vergleicht, dass AMD trotz erbärmlicher Tessellationimplementierung auch nicht mehr erreicht hat.
Zum Fett gedruckten: Lol! Also wir sind zwar oft einer Meinung, aber das ist doch völliger Unsinn. Die Mehrheit der bisher erschienenen und aktuellen Spiele nutzt diese Möglichkeiten nicht. Damit ist es keine Rosinenpickerei. Sag mal, das Wort muss man dir doch nicht erklären?
Achja, Downsampling ist toll, aber kein Ersatz für richtige Geometrie oder auch Effektphysik. Und nicht vergessen: Echte Geometrie lässt sich per MSAA glätten, was wiederum dazuführt, dass SSAA an Bedeutung verliert und man mehr Leistung für andere Effekte hat.
Du wirfst hier wahllos Sachen durcheinander. Geometrie ist nicht das einzige, was Flimmern kann. Du glaubst doch nicht im Ernst, dass die Entwickler auf Oberflächenshader verzichten werden sobald die Oberflächen schön ausmodelliert sind! Antialiasing - in welcher Form auch immer - wird IMMER wichtig sein. Unabhängig von Physik, Geometrie oder dem Weihnachtsmann. Vegetation gibts auch noch. Bis jedes Blatt in 3D dargestellt wird und entsprechend geglättet werden kann, vergehen sicher noch ein paar Jährchen.
2xGTX für's Rendering und 1x für GPU-PhysX. Und das soll in Echtzeit laufen. Der 3DMark2011 läuft selbst mit 3xGTX570 in Extreme beschissenen...
K. Und das dann bitte auf anderthalb GTX680 :tongue:
Nein, die trifft immer dann zu, wenn man eben auf die Verbesserungen setzt. Das ist auch logisch.
Tut nur kaum jemand - ist auch logisch, denn es kostet Geld und die Konsolen könnens nicht, also macht man es nicht in 98% aller Titel. Und jetzt? Du darfst die Realität im Markt nicht ausklammern, die ist wichtig :freak:
Gipsel
2011-05-23, 17:13:22
Ich fordere reine Wireframe-Spiele ohne Texturen für LovesuckZ.;D
Eine Erhöhung der Rechenleistung um mehr 300% gegenüber Fermi halte ich für die nächste Generation (28 nm) für nicht möglich.Auf 250-300% halte ich das bei der 28nm Generation für möglich. Die eigentlichen Shadereinheiten sind nicht so übermäßig groß (auch wenn sie bei nvidia aus bekannten Gründen deutlich mehr Platz pro ALU einnehmen als bei Radeons). Das Problem ist eher, wie man die Fragen der Datenversorgung, des Schedulings usw. effizient löst.
Spasstiger
2011-05-23, 17:20:56
Auf 250-300% halte ich das bei der 28nm Generation für möglich.
Um 300% wären allerdings schon auf 400%. Und LovesuckZ spinnt sich zusammen, dass NV das, was bei der Geometrieleistung erreicht wurde, nun für die Rechenleistung umgesetzt wird.
Eine Erhöhung auf 250% bzw. um 150% erscheint mir noch im Rahmen des Möglichen. Aber da glaube ich eher daran, dass NV einfach Fermi skaliert auf z.B. 32 SMs.
boxleitnerb
2011-05-23, 17:24:27
Ich finde es sowieso erstaunlich, dass Nvidia mit deutlich weniger Pixel- und Texturfüllrate und weniger Shaderpower den HD6000 trotzdem voran ist. Selbst bei SGSSAA ist man (fast) gleichauf, ebenso bei hohen Auflösungen. Wieso?
LovesuckZ
2011-05-23, 17:25:51
Auch neuere nicht. Die müssen nämlich auch noch was anderes machen als nur zu tessellieren. Auch neue Spiele bestehen eben nicht nur aus Tessellation.
Ja - z.B. meine Sicht mit POM vollkleistern, dass Rechenleistung benötigt, die ich eigentlich brauche, um das Flimmern mit dem rechenintensiven SSAA zu beseitigen. :freak:
Es ist mindestens genausogut Rosinenpickerei, einen nicht unter gleichen Voraussetzungen möglichen Vergleich durchzuführen, GT200 kann keine Tess, GF100 kann es. Wie kommst Du da auf 400% Leistungssteigerung?!?
Der normale Geometrieoutput ist 8x höher. Ist die Zahl besser für dich?
Wobei: Laut dir ist Tessellation auf der GPU ja langsamer als über die CPU. Hm, dann lag ich ja doch sehr daneben. :(
Und nicht vergessen: Eine exorbitante Steigerung der Geometrie hat eine steigende Ineffizienz der heutigen quadbasierten Renderer zur Folge, die die effektiv verfügbare Shaderleistung drastisch mindert, ohne die Grafikqualität noch merklich (bei einem Echtzeitrenderer) anzuheben.
Bitte Gipsel, kannst du es unterlassen in diesen Threads deine falsche Meinung immer und immer wieder zu vertreten? Ich fühle mich wirklich gelangweilt. Entweder beweist du es, oder du behälst sie für dich. nVidia sieht es nämlich ziemlich anders und die haben sogar Zahlen aus HAWX 2 und ihrer Techdemo, die dies beweisen. Bring it or shut up.
Zum Fett gedruckten: Lol! Also wir sind zwar oft einer Meinung, aber das ist doch völliger Unsinn. Die Mehrheit der bisher erschienenen und aktuellen Spiele nutzt diese Möglichkeiten nicht. Damit ist es keine Rosinenpickerei. Sag mal, das Wort muss man dir doch nicht erklären?
Ähm - wenn kein Spiel die neuen Fähigkeiten nutzt, dann wird es auch keine Verbesserung geben. Darüber brauchen wir nicht reden. Und ich weiß, was Rosinenspickerei ist. Nur sollte man sehen, dass das "Spicken" von Spielen, die eben nicht die neuen Fähigkeiten verwenden, ebenfalls genau das ist.
Das diese den Großteil des Marktes ausmachen, ist historisch begründet. Aber man sollte auch im Laufe der letzten Jahre begriffen haben, dass es ohne Hardware hier keinen Fortschritt geben wird.
Du wirfst hier wahllos Sachen durcheinander. Geometrie ist nicht das einzige, was Flimmern kann. Du glaubst doch nicht im Ernst, dass die Entwickler auf Oberflächenshader verzichten werden sobald die Oberflächen schön ausmodelliert sind! Antialiasing - in welcher Form auch immer - wird IMMER wichtig sein. Unabhängig von Physik, Geometrie oder dem Weihnachtsmann. Vegetation gibts auch noch. Bis jedes Blatt in 3D dargestellt wird und entsprechend geglättet werden kann, vergehen sicher noch ein paar Jährchen.
Echte Geometrie dort, wo man zur Zeit mit Fake-Methoden arbeiten, würde schonmal deutlich das Shader-Aliasing minimieren (siehe auch Dragon Age 2). Alpha-Test lässt sich mit AAA bekämpfen. Fermi ist z.B. bei Fluid-Berechnungen mehr als doppelt so schnell als GT200b (siehe Dark Void). Aber es bringt nichts, wenn niemand solche Berechnungen in Spielen einsetzt. Du kannst solche Effekte nicht mit Downsampling und SSAA aufwiegen. Ich liebe Flimmerfreiheit, aber ich liebe Fortschritt umso mehr.
Um 300% wären allerdings schon auf 400%. Und LovesuckZ spinnt sich zusammen, dass NV das, was bei der Geometrieleistung erreicht wurde, nun für die Rechenleistung umgesetzt wird.
Ja - weil ja jeder vor der CES2010 wusste, dass nVidia solch ein Geometrie-Monster bauen werde. Man sollte seine Spekulationen einstellen, wenn es um nVidia geht.
AnarchX
2011-05-23, 17:27:23
Ich finde es sowieso erstaunlich, dass Nvidia mit deutlich weniger Pixel- und Texturfüllrate und weniger Shaderpower den HD6000 trotzdem voran ist. Selbst bei SGSSAA ist man (fast) gleichauf, ebenso bei hohen Auflösungen. Wieso?
Weil SGSSAA eben auch abhängig von der Raster- und Geometrie-Leistung ist.
Für GK100 wären imo 20 Cluster zu je 8 TMUs + 80 CUDA-Cores (superskalare Ausführung) und ein 512-Bit SI eine nette Basis.
Gipsel
2011-05-23, 17:31:08
Ich finde es sowieso erstaunlich, dass Nvidia mit deutlich weniger Pixel- und Texturfüllrate und weniger Shaderpower den HD6000 trotzdem voran ist. Selbst bei SGSSAA ist man (fast) gleichauf, ebenso bei hohen Auflösungen. Wieso?
Das Problem ist eher, wie man die Fragen der Datenversorgung, des Schedulings usw. effizient löst.
;)
Tesseract
2011-05-23, 17:37:32
Ich finde es sowieso erstaunlich, dass Nvidia mit deutlich weniger Pixel- und Texturfüllrate und weniger Shaderpower den HD6000 trotzdem voran ist. Selbst bei SGSSAA ist man (fast) gleichauf, ebenso bei hohen Auflösungen. Wieso?
voran sind sie, weil sie schlicht den größeren chip haben. ein auf 3M transistoren aufgeblasener cayman wär auch nicht langsamer.
warum sie diese leistung mit deutlich weniger rohpower erreichen liegt daran, dass die architektur darauf ausgelegt ist die units möglichst gut auszulasten wärend AMD eher die brute-force-schiene fährt was die cores angeht.
Gipsel
2011-05-23, 17:51:49
Der normale Geometrieoutput ist 8x höher. Ist die Zahl besser für dich?
Wenn Du mir dann noch mal erklärst, was Du mit ~3,1 Milliarden Dreiecken die Sekunde (die Du auf keiner aktuellen Geforce-Karte auch nur annähernd messen wirst, warum wohl?) verteilt auf vielleicht 5 Millionen Pixel pro Frame sinnvoll anfängst, ohne daß die Performance bei Einsatz von ein paar Shadern, die da noch berechnet werden wollen, vollkommen einbricht ...
Wobei: Laut dir ist Tessellation auf der GPU ja langsamer als über die CPU. Hm, dann lag ich ja doch sehr daneben. :(;D
Meine Aussagen unzutreffend wiederzugeben, scheint ja eines Deiner Hobbies zu sein. Oder verstehst Du sie einfach nicht? :rolleyes:
Du kannst mich gerne per PM noch mal nach einer ausführlichen Erklärung fragen.
Bitte Gipsel, kannst du es unterlassen in diesen Threads deine falsche Meinung immer und immer wieder zu vertreten?:lol: Das müßte ich mir fast wieder in die Signatur packen! :lol:
nVidia sieht es nämlich ziemlich anders und die haben sogar Zahlen aus HAWX 2 und ihrer Techdemo, die dies beweisen. Bring it or shut up.Nein. Ich habe hier sogar schon mal eine gemeinsame Präsentation von AMD und nvidia verlinkt, in der beide genau das von mir erwähnte Problem der sinkenden Rastereffizienz bei kleinen Dreiecken ansprechen (AMD hat das später nur mehr betont, weil die Grenze bei doppelt so großen Dreiecken liegt, was aber nicht heißt, daß nv dagegen gefeit ist). Das muß bei den heutigen GPUs von AMD und nvidia auftreten. Falls Du also der Meinung bist, daß nvidia gesagt hat, daß das auf sie nicht zutrifft, bitte ich um entsprechende Belege Deinerseits.
LovesuckZ
2011-05-23, 18:07:56
Wenn Du mir dann noch mal erklärst, was Du mit ~3,1 Milliarden Dreiecken die Sekunde (die Du auf keiner aktuellen Geforce-Karte auch nur annähernd messen wirst, warum wohl?) verteilt auf vielleicht 5 Millionen Pixel pro Frame sinnvoll anfängst, ohne daß die Performance bei Einsatz von ein paar Shadern, die da noch berechnet werden wollen, vollkommen einbricht ...
;D
Hm, wieso bleiben wir nicht einfach mal bei 2,5 Millionen Dreiecke pro Sekunde. Wie z.B. in HAWX2. Und die Dreiecke sind dort auch nur 3x6 Pixel groß. Ironischerweise war das schon zuviel für eine gewisse Grafikkartefirma. :freak:
Achja, nVidia wie auch Sweeney widersprechen dir. Die wollen noch mehr Dreiecke pro Frame. Man kann von Sweeney und Epic halten, was man will. Aber die Wahl zwischen dir und ihnen fällt eigentlich leicht:
"I believe the industry has correctly converged on shaded triangles as a low-level surface representation," says Sweeney, the industry’s leading graphics engineer. "Triangles are the most efficient general primitive for representing most scenes and most objects, which are largely opaque and contain well-defined boundaries. With that in mind, though, I think we're well on our way down the REYES path, decomposing higher-order objects via tessellation."
...
Having established that Sweeney wants Pixar-level graphics, he outlines the technology he’d require to achieve such a feat in real-time.
"Give us a sufficiently higher triangle rate to render multiple triangles per pixel, say 10 billion triangles per second, and we'd use tessellation and displacement to dice every object in the scene into sub-pixel triangles -- treating it as a "free" effect, just as texture-mapping became a free effect 14 years ago." NVIDIA’s most powerful graphics card, the GeForce GTX 590, is only capable of 3.2 billion triangles per second, so while Sweeney waits for technology to catch up with his ambition, he’s content to "layer increasingly advanced effects on top of triangle-based scenes, such as volumetric effects, particle systems, post-processing, and so on."
http://www.geforce.com/#/News/articles/epic-tim-sweeney-and-nvidia-talk-samaritan-and-the-future-of-graphics-page2
Nein. Ich habe hier sogar schon mal eine gemeinsame Präsentation von AMD und nvidia verlinkt, in der beide genau das von mir erwähnte Problem der sinkenden Rastereffizienz bei kleinen Dreiecken ansprechen (AMD hat das später nur mehr betont, weil die Grenze bei doppelt so großen Dreiecken liegt, was aber nicht heißt, daß nv dagegen gefeit ist). Das muß bei den heutigen GPUs von AMD und nvidia auftreten. Falls Du also der Meinung bist, daß nvidia gesagt hat, daß das auf sie nicht zutrifft, bitte ich um entsprechende Belege Deinerseits.
Das habe ich leider nie geschrieben oder behauptet. Ich will von dir beweisen haben, dass dieses Problem ein "Gamebreaker" ist. nVidia sagt es selbst, dass es ineffizient werde. Deswegen auch ein dynamisches LoD, um dort viele, kleine Dreiecke zu erzeugen, wo es notwendig ist. Du bist komplett gegen kleine Dreiecke.
Und wo wir bei AMD sind: HAWX2 verwendet 18 Pixel große Dreiecke. Und HAWX2 war ja böse. Wieviel Wert die Aussagen von AMD und somit auch von dir haben, muss jeder selbst einschätzen. Aber ich gebe keinen Wert auf deine Meinung, wenn diese so offensichtlich falsch ist.
fondness
2011-05-23, 18:37:28
Ich finde es sowieso erstaunlich, dass Nvidia mit deutlich weniger Pixel- und Texturfüllrate und weniger Shaderpower den HD6000 trotzdem voran ist. Selbst bei SGSSAA ist man (fast) gleichauf, ebenso bei hohen Auflösungen. Wieso?
Weil theoretische Zahlen eben nur theoretische Zahlen sind. Defacto benötigt NV eben auch deutlich mehr Transistoren für ihre Einheiten.
Gipsel
2011-05-23, 19:22:15
Schonmal ein sorry für die Quotes, aber ich wollte das nochmal im Ablauf und im Kontext darstellen.
Der normale Geometrieoutput ist 8x höher.
Wenn Du mir dann noch mal erklärst, was Du mit ~3,1 Milliarden Dreiecken die Sekunde (die Du auf keiner aktuellen Geforce-Karte auch nur annähernd messen wirst, warum wohl?) [..]
Hm, wieso bleiben wir nicht einfach mal bei 2,5 Millionen Dreiecke pro Sekunde. Wie z.B. in HAWX2.
Und wo bleibt dann der Dreiecksdurchsatz als Flaschenhals? Meinst Du nicht, die Performance wird erheblich wesentlicher durch etwas anderes als die Geometrierate bestimmt, wenn man wie in Deinem Beispiel bei weniger als einem Tausendstel des theoretischen Maximaldurchsatzes herumkrebst? Nur mal so als Gedanke ... :rolleyes:
Achja, nVidia wie auch Sweeney widersprechen dir. Die wollen noch mehr Dreiecke pro Frame. Man kann von Sweeney und Epic halten, was man will. Aber die Wahl zwischen dir und ihnen fällt eigentlich leicht:
Nur dummerweise kann auch eine GTX580 REYES nicht effektiv rendern. Und das liegt nicht am von Sweeney festgestellten fehlenden Faktor 3 der Dreiecksrate (Edit: Der Vergleich mit den 3,2 Mrd. Dreiecken kommt ja gar nicht von Sweeney selber, das ist vom Schreiberling des Artikels). Sondern genau am Problem der für jedes durch Tessellation erzeugte Mikropolygon auszuführenden Shader, der dann letztendlich die Farbe festlegt, die dann natürlich mit den restlichen Mikropolygonen im Pixel verrechnet werden muß, damit man kein Aliasing bekommt. Und das geht bei heutigen GPUs nur höchst ineffizient, insbesondere wenn man Mikropolygone (also mehrere pro Pixel) hat. Nvidia empfiehlt ja nicht umsonst z.B. eine Mindestgröße von 8 Pixeln pro sichtbarem Polygon, damit die Effizienz nicht in den Keller geht. Das ist nämlich mit momentanen GPUs letztendlich das viel größere Problem.
Eine exorbitante Steigerung der Geometrie hat eine steigende Ineffizienz der heutigen quadbasierten Renderer zur Folge, die die effektiv verfügbare Shaderleistung drastisch mindert,[..]
nVidia sieht es nämlich ziemlich anders und die haben sogar Zahlen aus HAWX 2 und ihrer Techdemo, die dies beweisen.Nein. Ich habe hier sogar schon mal eine gemeinsame Präsentation von AMD und nvidia verlinkt, in der beide genau das von mir erwähnte Problem der sinkenden Rastereffizienz bei kleinen Dreiecken ansprechen [..]. Das muß bei den heutigen GPUs von AMD und nvidia auftreten. Falls Du also der Meinung bist, daß nvidia gesagt hat, daß das auf sie nicht zutrifft, bitte ich um entsprechende Belege Deinerseits.
Das habe ich leider nie geschrieben oder behauptet. Ich will von dir beweisen haben, dass dieses Problem ein "Gamebreaker" ist. nVidia sagt es selbst, dass es ineffizient werde.q.e.d.
Habe das auch gleich mal farblich markiert, damit das besser kenntlich wird.
Im Übrigen wäre es schon interessant zu diskutieren, was in zukünftigen GPUs vielleicht geändert werden könnte, damit sowas wie REYES dann effizient hardwarebeschleunigt werden kann.
Edit:
Übrigens, hast Du mal die Einleitung zu den Sweeney-Zitaten in dem von Dir verlinkten Artikel gelesen?
This is the standard Tim Sweeney, Epic’s CEO and Technical Director, sees the industry moving towards over the next however many years. ;)
LovesuckZ
2011-05-23, 19:51:43
Und wo bleibt dann der Dreiecksdurchsatz als Flaschenhals? Meinst Du nicht, die Performance wird erheblich wesentlicher durch etwas anderes als die Geometrierate bestimmt, wenn man wie in Deinem Beispiel bei weniger als einem Tausendstel des theoretischen Maximaldurchsatzes herumkrebst? Nur mal so als Gedanke ... :rolleyes:
Dein Zital, dass du komischerweise abgeschnitten hast(?!), lautet nämlich so:
Wenn Du mir dann noch mal erklärst, was Du mit ~3,1 Milliarden Dreiecken die Sekunde (die Du auf keiner aktuellen Geforce-Karte auch nur annähernd messen wirst, warum wohl?) verteilt auf vielleicht 5 Millionen Pixel pro Frame sinnvoll anfängst, ohne daß die Performance bei Einsatz von ein paar Shadern, die da noch berechnet werden wollen, vollkommen einbricht ...
Ich will nirgendwo 3,1 Milliarden Dreiecke pro Sekunde. Ich möchte mehr Dreiecke. Du bist aber klar gegen mehr Dreiecke. Ich warte also immernoch auf ein Beleg, dass mehr Dreiecke als die Pixel-Anzahl falsch wären und das Dreiecke kleiner als 16 Pixel die Architektur in die Knie zwingen würden.
Nur dummerweise kann auch eine GTX580 REYES nicht effektiv rendern. Und das liegt nicht am von Sweeney festgestellten fehlenden Faktor 3 der Dreiecksrate. Sondern genau am Problem der für jedes durch Tessellation erzeugte Mikropolygon auszuführenden Shader, der dann letztendlich die Farbe festlegt, die dann natürlich mit den restlichen Mikropolygonen im Pixel verrechnet werden muß, damit man kein Aliasing bekommt. Und das geht bei heutigen GPUs nur höchst ineffizient, insbesondere wenn man Mikropolygone (also mehrere pro Pixel) hat.
Deswegen will Sweeney auch, dass die Hardware es in Zukunft schafft. Aber hey, laut Gipsel wird das nie, ich betone es nochmal, NIE möglich sein, soetwas in Echtzeit umzusetzen. ;D
Nvidia empfiehlt ja nicht umsonst z.B. eine Mindestgröße von 8 Pixeln pro sichtbarem Polygon, damit die Effizienz nicht in den Keller geht. Das ist nämlich momentan letztendlich das viel größere Problem.
Das empfiehlt und sagt nVidia so nirgendwo. Das "viel größere Problem" sind Leute wie du, die irgendwas behaupten, das falsch ist.
In HAWX2 war das Ziel 18 Pixel große Dreiecke. Das ist aber mit einem dynamischen LoD nicht 100% regelbar. Es gibt keine jedoch keine "krassen" Leistungsbrüche. Im HAWX2 Beispiel erreicht eine GTX460 im Szenarium, wo die Dreieckesgröße irgendwo zwischen 1 - 20 Pixel liegt immernoch 127 FPS.
q.e.d.
Habe das auch gleich mal farblich markiert, damit das besser kenntlich wird.
Richtig. nVidia sieht es nämlich anders. Das Fermi natürlich nicht in der Lage ist 3,1 Milliarden Dreiecke pro Sekunde bzw. Frame in Echtzeit zu rendern, ändert nichts an der Tatsache, dass nVidia deutlich mehr Dreiecke pro Frame haben will. Und das ist es, dass nVidia sagt.
Nur mal für dich: Laut der Techdemo von nVidia bricht die FPS Zahl einer GTX460 von 175 FPS (mit 400k tris/s) über 94 FPS (2,4M tris/s) auf 35 FPS (14M tris/s) ein. Wir reden von Faktor 6x bzw. 35x zusätzlicher Dreiecke. Es limitiert also bei nVidia sowieso erst die Rechen-, Pixel- und/oder Texturleistung. Aber hey, it's Gipsel. :freak:
Gipsel
2011-05-23, 20:02:23
Mensch LS, überliest Du das absichtlich, wenn ich explizit immer wieder von momentan verfügbaren GPUs rede? :confused: Ich habe das Thema der in Zukunft möglichen Änderungen, um das zu verbessern, doch sogar explizit erwähnt!
Und die Logik Deines restlichen Konvoluts verstehst wohl auch nur Du. Wo habe ich geschrieben, das mehr Geometrie schlecht ist? Ich sage nur, ab einer gewissen Grenze wird es bei heutigen GPUs eben ineffizient. Eine Tatsache, die Du ja in einem einzigen Posts sowohl selber zugibst als auch anzweifelst. Das verstehe wer will. Genauso wie Deine Argumentation(?) mit den Zahlen von der Tech-Demo. Was soll das denn überhaupt sagen? Daß der Geometrie-Durchsatz an sich höchst selten der limitierende Faktor ist, sage ich doch schon eine ganze Weile!?! Du erinnerst Dich vielleicht, das war mein ursprünglicher Punkt. :wink:
M.(to_the)K.
2011-05-23, 20:18:50
Wie kommst du auf die 1,6 jetzt genau?
Die zahl hab ich von einen Freund. der kennt einiege leute die sich ziemlich gut mit chipfertigung auskennen. die sagen das man in fachkreisen momentan von einer steigerung der transsistordichte um den faktor 1,6 ausgeht. beim sprung von 40 auf 28 nm. zumindest am anfang.
mathematisch möglich und technisch umsetzbar sind halt 2 verschiedene paar schuhe. zumal die fertigung brand neu ist und gpus nunmal so ziemlich das komplizierteste indurstieprodukt überhaupt sind.
M.(to_the)K.
2011-05-23, 20:27:31
voran sind sie, weil sie schlicht den größeren chip haben. ein auf 3M transistoren aufgeblasener cayman wär auch nicht langsamer.
warum sie diese leistung mit deutlich weniger rohpower erreichen liegt daran, dass die architektur darauf ausgelegt ist die units möglichst gut auszulasten wärend AMD eher die brute-force-schiene fährt was die cores angeht.
Außßerdem hat nvidida die bessere softwwareabteilung. Dadurch kann nvidida mehr leistung aus den karten kitzeln als amd. obwohl gerade amd-karten von bessere software, aufgrund der vliw 5/ vliw4 shader, welche extrem schwierig auszulasten sind, profitieren.
Hätte AMD also mehr leute für die softwareentwcklung angestellt würde nvidida vermutlich ganz schön in die röhre gucken. zum glück für nvidia is dafür kein geld da. :freak:
Gipsel
2011-05-23, 20:42:26
Die zahl hab ich von einen Freund. der kennt einiege leute die sich ziemlich gut mit chipfertigung auskennen. die sagen das man in fachkreisen momentan von einer steigerung der transsistordichte um den faktor 1,6 ausgeht. beim sprung von 40 auf 28 nm. zumindest am anfang.
mathematisch möglich und technisch umsetzbar sind halt 2 verschiedene paar schuhe. zumal die fertigung brand neu ist und gpus nunmal so ziemlich das komplizierteste indurstieprodukt überhaupt sind.
Hängt auch ein wenig von Gate First vs. Last ab. Von TSMC gibt es tatsächlich in einer Beschreibung ihrer Prozesse (http://www.tsmc.com/download/brochures/2011_28%20Nanometer%20Process%20Technology.pdf) die Angabe von 1,6 mit "traditional layout rules". Mit entsprechend angepaßten Restricted Design Rules sollen maximal 1,95 drin sein. Von GlobalFoundries gibt es die Ansage eines glatten Faktor 2 gegenüber 40nm (die sie ja eigentlich gar nicht haben, also wahrscheinlich gegen TSMCs 40nm verglichen). Deswegen haben die ja auch schon ewig mit dem besseren Scaling geworben (edit: GF schafft den Faktor 2 ohne spezielle Anpassungen des Layouts, weswegen 40nm Designs auch noch einfacher portiert werden können).
M.(to_the)K.
2011-05-23, 21:03:37
Ist denn bekannt welchen prozess nvidia nimmt? 1,6 und 1,95. das sind ja schon 2 himmelweite unterscheide.
Tesseract
2011-05-23, 22:15:45
Ich warte also immernoch auf ein Beleg, dass mehr Dreiecke als die Pixel-Anzahl falsch wären
nicht falsch aber extrem ineffizient, das ergibt sich aus der funktionsweise der rastersierung. wenn ein polygon aus vielen fragments besteht kann man sich einen ganzen haufen arbeitsschritte sparen.
z.B. verliert multisampling seinen performance-vorteil gegenüber supersampling neben einem ganzen haufen anderer nachteile.
statt so kleinen polygonen sollte man dann besser freiformflächen oder ähnliches verwenden.
Ich warte also immernoch auf ein Beleg, dass mehr Dreiecke als die Pixel-Anzahl falsch wären und das Dreiecke kleiner als 16 Pixel die Architektur in die Knie zwingen würden.
Für momentane Architekturen gibts *hier* (http://bps10.idav.ucdavis.edu/talks/10-fatahalian_MicropolygonsRealTime_BPS_SIGGRAPH2010.pdf) eine schöne Zusammenfassung der Probleme.
mapel110
2011-05-23, 23:49:32
Für momentane Architekturen gibts *hier* (http://bps10.idav.ucdavis.edu/talks/10-fatahalian_MicropolygonsRealTime_BPS_SIGGRAPH2010.pdf) eine schöne Zusammenfassung der Probleme.
Interessante PDF. Auch wenn man als Laie davon nur wenig versteht.
Nur dummerweise kann auch eine GTX580 REYES nicht effektiv rendern.
Dazu kann ich vielleicht bisschen was sagen, weil ich das letztens tatsächlich mal zum Spaß versucht habe.
Kurzfassung: Der DX11-Tesselator lässt sich dafür nicht gescheit einsetzen, weil man die Dreieckssoße die dabei rauskommt nicht in einen Buffer geschrieben bekommt. Zumindest nicht mit der DX11-API. Vielleicht gibt's da ne OpenGL-Extension.
Den normalen Rasterizer kann man nicht verwenden, weil der ja gar nicht die Eigenschaften für Reyes hat - Obwohl er ziemlich schnell ist.
Ach so, und der DirectX-Tesselator ist auch gar nicht so gut für "dice" geeignet, weil das erzeugte Muster ungünstig ist.
LovesuckZ
2011-05-24, 00:37:50
Mensch LS, überliest Du das absichtlich, wenn ich explizit immer wieder von momentan verfügbaren GPUs rede? :confused: Ich habe das Thema der in Zukunft möglichen Änderungen, um das zu verbessern, doch sogar explizit erwähnt!
Wenn ich heute keine 3 Mrd Dreiecke benötige, dann auch nicht morgen, nächstes Jahr oder sonst wann.
Achja dein Quote nochmal:
Wenn Du mir dann noch mal erklärst, was Du mit ~3,1 Milliarden Dreiecken die Sekunde (die Du auf keiner aktuellen Geforce-Karte auch nur annähernd messen wirst, warum wohl?) verteilt auf vielleicht 5 Millionen Pixel pro Frame sinnvoll anfängst, ohne daß die Performance bei Einsatz von ein paar Shadern, die da noch berechnet werden wollen, vollkommen einbricht ...
Würde das heute ohne Probleme gehen, wäre doch alles toll. Aber anscheinend bist du so ein Typ, der irgendein Quatsch schreibt, nur um später sagen zu können: Ja, also, ich habe nie ausgeschlossen, dass es sinnvoll sein könnte. Aber nur am Tag X, mit Hardware Y von Hersteller Z war es klar, dass es unsinnig wäre. Wow.
Ich sage nur, ab einer gewissen Grenze wird es bei heutigen GPUs eben ineffizient. Eine Tatsache, die Du ja in einem einzigen Posts sowohl selber zugibst als auch anzweifelst. Das verstehe wer will. Genauso wie Deine Argumentation(?) mit den Zahlen von der Tech-Demo. Was soll das denn überhaupt sagen? Daß der Geometrie-Durchsatz an sich höchst selten der limitierende Faktor ist, sage ich doch schon eine ganze Weile!?! Du erinnerst Dich vielleicht, das war mein ursprünglicher Punkt. :wink:
Das ist schön. Heutige Hardware wird in vielen Bereichen ineffizient. Aber was hat das damit zu tun, dass man das Geometrie-Level dank GF100 um z.B. Faktor 5x-10x erhöhen kann, ohne dass Fermi ineffizient wird?
Du verbreitest hier genau eine Ansicht, dass der Einsatz von Tessellation zur reinen Ineffizient-Schlacht verkommt. Ohne Beweise, ohne Belege, ohne Zahlen. Das nennt man leider Propaganda (http://de.wikipedia.org/wiki/Propaganda). Du magst kein Tessellation. Du findest es doof, dass AMD es einfach verkackt hat. Das ist in Ordnung. Aber lasse es dauernd uns mitzuteilen, dass der Einsatz von Tessellation nur ineffizient wäre. Damit stehst du nämlich vollkommen alleine da.
Achja, deine Aussage war diese:
Und nicht vergessen: Eine exorbitante Steigerung der Geometrie hat eine steigende Ineffizienz der heutigen quadbasierten Renderer zur Folge, die die effektiv verfügbare Shaderleistung drastisch mindert, ohne die Grafikqualität noch merklich (bei einem Echtzeitrenderer) anzuheben.
Doof nur, dass du nichtmal selbst weiß, was "exorbitante Steigerung" in Zahlen bedeutet. Demnach kann ich wohl lange auf Beweise warten, die zeigen, dass GF100 zwar viel Geometrie erzeugen kann, aber eigentlich viel zu ineffizient wäre, um dies einzusetzen.
Nightspider
2011-05-24, 02:07:46
Kein Schwein braucht im Moment die Tessallation Leistung. Die Verwendung in den bisherigen 3 Games ist ein Witz.
Wer die paar Performance-Ausreißer im positiven Sinne bei den wenigen Tessellation Games als Leistungsindex der GF100 Chips ranholt spinnt.
Nur weil mit extremer Tessellation der GF100 Chip bis zu 3-4 mal so schnell ist wie der GT200 ist er real in aktuellen Games NICHT MAL ANNÄHREND so viel schneller.
Das ist FAKT.
Was anderes zählt aktuell für Gamer nicht, die DS oder viel AA verwenden wollen.
Ob der Chip paar Jahre nach Release deutlich mehr Leistung durch die gute DX11 Performance bringt ist für kaum einen von Relevanz, außer für Zweit- oder Drittbesitzer.
Vor allem sind die Radeons bei anderen D3D11-Workloads sogar schneller. Vor allem bei Compute-Shadern. Einfach durch die sehr hohe rohe Rechenleistung.
Gipsel
2011-05-24, 03:16:22
Wenn ich heute keine 3 Mrd Dreiecke benötige, dann auch nicht morgen, nächstes Jahr oder sonst wann.Hmm. Ich sehe das anders. :)
Achja dein Quote nochmal:
Wenn Du mir dann noch mal erklärst, was Du mit ~3,1 Milliarden Dreiecken die Sekunde (die Du auf keiner aktuellen Geforce-Karte auch nur annähernd messen wirst, warum wohl?) verteilt auf vielleicht 5 Millionen Pixel pro Frame sinnvoll anfängst, ohne daß die Performance bei Einsatz von ein paar Shadern, die da noch berechnet werden wollen, vollkommen einbricht ...
Würde das heute ohne Probleme gehen, wäre doch alles toll.Natürlich. Aber man muß ja auch mal die Realität im Auge behalten. Und in der geht es eben einfach noch nicht. :rolleyes:
Aber anscheinend bist du so ein Typ, der irgendein Quatsch schreibt, nur um später sagen zu können: Ja, also, ich habe nie ausgeschlossen, dass es sinnvoll sein könnte. Aber nur am Tag X, mit Hardware Y von Hersteller Z war es klar, dass es unsinnig wäre. Wow.Wow! Wirklich! Du hättest wohl auch schon bei der Erfindung des Transistors oder bei der ersten Veröffentlichung über das Phänomen der Halbleiter jeden, der nicht von heutigen CPUs und GPUs fantasiert hätte sondern zuerst etwas naheliegendere Probleme lösen wollte als fortschrittsfeindlich verurteilt. :freak:
Achja, deine Aussage war diese:
Und nicht vergessen: Eine exorbitante Steigerung der Geometrie hat eine steigende Ineffizienz der heutigen quadbasierten Renderer zur Folge, die die effektiv verfügbare Shaderleistung drastisch mindert, ohne die Grafikqualität noch merklich (bei einem Echtzeitrenderer) anzuheben.
Doof nur, dass du nichtmal selbst weiß, was "exorbitante Steigerung" in Zahlen bedeutet. Demnach kann ich wohl lange auf Beweise warten, die zeigen, dass GF100 zwar viel Geometrie erzeugen kann, aber eigentlich viel zu ineffizient wäre, um dies einzusetzen.
Nun erstmal muß ich Dir wohl erklären, daß "exorbitant" sinngemäß in etwa "übertrieben" oder "über alle Maße" bedeutet. :wink:
Den Begriff "knee of the curve" hast Du schonmal gehört? Da man eben keine unlimitierten Resourcen hat, muß man eben Performance gegen gewünschte Qualität abwägen und einen möglichst optimalen Kompromiß finden. Daß sich in Zukunft bei mehr verfügbarer Performance (oder eben angepaßten GPU-Designs) der Kompromiß verschieben wird, ist ja wohl selbstverständlich, oder?
Überdies habe ich schon mehrfach quantifiziert, wann diese Ineffizienz in etwa losgeht. Wie gesagt spricht sogar nvidia selber von ~8 Pixeln/Dreieck als Faustregel, was aufgrund der Funktionsweise der verbauten Rasterizer auch vollkommen nachzuvollziehen ist. Je nach Anwendungsfall kann man mit ein paar Ineffizienzen natürlich schon leben, aber man muß sich eben darauf einstellen, daß alle pixelbasierten Operationen (alles ab Raster) ineffizient werden: obwohl die nominelle Pixelanzahl im Frame konstant bleibt, muß mehr und mehr Arbeit für deren Berechnung aufgewendet werden. Nicht nur weil jede Rasterengine nur ein Dreieck pro Takt schafft, das ist ja wie erwähnt meist gar nicht so das Problem, sondern weil die Quads nicht mehr gefüllt werden können und jedes Mikropolygon mindestens ein ganzes Quad belegt, so daß etliche Quads für die Berechnung eines einzelnen Pixels draufgehen können. Bei großen Deiecken ist der "Pixel-Aufwand" dagegen praktisch konstant.
Oder anders gesagt:
Mit relativ großen Dreiecken kann ich fast die volle Rechenleistung der GPU in aufwendige Pixelshader/Postprocessing (SSAA verursacht genau diese Art von Pixel-Last ;)) oder sonstwas stecken. Verkleinere ich die Dreiecke (zu) stark, muß ich irgendwann anfangen, am Pixel-Processing zu sparen, um meine gewünschten 50fps oder was auch immer zu halten. Die Frage ist eben nur, wie lange überwiegt die durch die höhere Dreieckszahl gesteigerte Bildqualität den resultierenden Performancenachteil. Spätestens, wenn man am AA zu sparen anfangen müßte, würdest Du sicher auch zustimmen, daß der Punkt des optimalen Kompromisses erreicht, wenn nicht überschritten wurde, oder?
Und apropos Propaganda. Hast Du vielleicht mal in die von RLZ verlinkte Präsentation reingeschaut? Schon komisch, daß dort ein alternatives (zu REYES) Mikropolygon-Renderingverfahren vorgeschlagen wird, was ein paar Erweiterungen in der Pipeline (allerdings weniger als REYES) und insbesondere bei den Rastereinheiten benötigt. Da wird dann auch ziemlich ausführlich das "Quad-fragment merging" erklärt, welches eben genau die von mir in obigen Zitat angesprochene Ineffizienz heutiger quadbasierter GPUs stark minimieren würde. Aber ich erzähle ja nur Märchen :rolleyes:
Also LS, laß es gut sein!
edit:
Also nur um mal zu zeigen, wieviel Shaderleistung momentan bei kleinen Dreiecken unnötig verschwendet wird, hier eine Abbildung aus der von RLC verlinkten Präsentation der Jungs aus Stanford:
http://gipsel.dyndns.org:8000/dsl_usb1/fragment_merging.png
Also bei einem halben Pixel Dreiecksgröße bringt das doch glatt einen Faktor 8 Vorteil. Heutige GPUs müssen bei der Dreiecksgröße jede Pixeloperation im Schnitt 14mal für einen einzigen sichtbaren Pixel ausführen, bei großen Dreiecken liegt man logischerweise sehr nah bei einem einzigen Durchlauf. Die Pixellast (ist heutzutage immer noch der dominierende Faktor mit typischerweise deutlich mehr als 50% Anteil an der Renderzeit pro Frame) erhöht sich also trotz konstanter Auflösung in dem Beispiel auf grob das 14fache des Limits großer Dreiecke. Das ist ein wesentlich härterer Limiter für Mikropolygonrendering, nicht die Dreiecksrate.
5 MPixel * 2 Dreiecke/Pixel * 60 fps sind ja "nur" 600 MPolys/s.
Allerdings werden daraus im Schnitt eine gute Milliarde Quads, also über 4 Milliarden zu shadende Fragments. Und das wird dann langsam schon etwas enger mit aufwendigen Shadern, selbst mit einem oder auch zwei TeraFlop, die man da vielleicht drauf loslassen kann (Bandbreite noch gar nicht mal betrachtet), die Shader vor dem Rasterizer (Laufzeit der Domainshader z.B. skaliert linear mit der Anzahl der Dreiecke) müssen ja auch noch irgendwo ausgeführt werden. Wenn man das auf ~500 Millionen Fragments, also 125 Millionen Quads eindampfen kann, sieht das mit der Effizienzfrage doch schon mal gleich viel besser aus, vor allem auch die Skalierung. Die Dreiecksgröße kann stark vermindert werden, ohne die Pixellast so explodieren zu lassen, wie mit herkömmlichen GPUs.
Gipsel, warum verschwendest du eigentlich nochmal deine Zeit?
Gipsel
2011-05-24, 04:30:35
Gipsel, warum verschwendest du eigentlich nochmal deine Zeit?
Kann gerade nicht schlafen :freak: :lol:
LovesuckZ
2011-05-24, 12:38:58
Ach Gipsel,
du betreibst immer noch Propaganda und bemerkst es nicht mal. Was du schreibst, ist doch jedem bekannt. Was du anscheinend ignorierst, ist die Tatsache, dass unser heutiges Niveau einfach lächerlich gering ist. Du propagierst, dass der Einsatz von Tessellation grundsätzlich zur Ineffizient durch die heutige Architektur führen würde und man es nicht vernünftig einsetzen dürfte. Was soll das? Was hat ein Mensch davon, sich so gegen eine Technik zu stellen?
Durch dynamisches LoD und einem geringen Grundniveau sind wir ewig davon entfernt, dass eine Steigerung zur Verschwendung von Pixelleistung führt.
Laut deinem Bild können Dreiecke bis zu 1,5 Pixel groß bzw. klein werden, ohne das Oversampling in die Höhe schnallen zu lassen. HAWX2 hat ein Sweet Spot von 18 Pixel große Dreiecke, wobei dank dynamischen LoD ein Großteil zwischen 10-20 Pixel sich befindet. Und der dynamische LoD hilft auch, dass Rechenleistung eingespart wird und somit die Ineffizient zu senken. Laut nVidia erreicht eine GTX460 in einer Szene, in der ein Großteil der Dreiecke <15 Pixel ist immer noch mehr als 100 FPS. Wo ist die Ineffizient, die du hier propagierst? Eine GTX580 läuft mit 80 FPS* durch Stone Giant in 1080p. Wo ist die Ineffizient, die du hier propagierst? In der Water Demo kann ich die Dreiecksanzahl um das 800 fache erhöhen und meine Frames brechen um Faktor 5 oder so ein. Wo ist die Ineffizient, die du hier propagierst?
Ich frage mich am Ende einfach: Wenn ich als Laie schon begreife, dass Tessellation auf Basis des heutigen Grundniveaus und durch Fermi im großen Maße einsatzbereit ist, wieso führt jemand wie du dann solch einem Krieg dagegen.
Schön ist, dass du wenigsten eine Zahl bzw. einen Bereich nennst. Das zeigt dann, dass deine Meinung im Grunde nicht viel Wert hat, da du grundsätzlich den Worst-Case als Beispiel nimmst, um Tessellation generell als sinnlos zu bezeichnen.
*um mal zu zeigen, was 80 FPS in Stone Giant bedeuten. Eine GTX285 erreicht irgendwas um 6x FPS im DX10 Modus, der sogar noch ein Stückchen schneller ist als DX11. Wenn also eine Karte mit der höhsten Tessellationstufe noch schneller ist als das beste aus der alten Generation, wie kann dann jemand sich in diesem Forum hinstellen und DX11-Tessellation als vollkommen ineffiziente Methode zur Erzeugung von realer Geometrie bezeichnen?
/edit: Im 3DMark2011 kosten Effekte, die Rechenleistung benötigen, deutlich mehr als die Erzeugung der Geometrie in der höhsten Stufe. Im Stone Giant verliert eine GTX480 beim Einsatz vom erweitertem DoF nur 15% an Leistung, wenn Tessellation von off -> high erhöht wird. Ohne sind es 26%. Fermi hat überhaupt keine Probleme ein für heutige Verhältnisse hohes Niveau an Geometrie zu erzeugen, weil die zu Grunde liegende Rechenleistung viel zu gering ist.
Gipsel
2011-05-24, 14:12:29
LS, bei Dir ist anscheinend nichts zu machen. Du sperrst Dich einfach jeglicher vernünftigen Argumentation. Coda fragt mich wirklich zu Recht, warum ich mit Dir meine Zeit verschwende. Offensichtlich willst Du Gedankengänge nicht verstehen, die von Deiner Überzeugung auch nur minimal abweichen. Tja, da kann man wohl nix machen.
Aber eine Bitte habe ich noch: Höre mit Deinen ewigen Unterstellungen auf, ich wäre gegen Tessellation oder würde sagen, es wäre prinzipiell ineffizient! Das ist einfach schwachsinnig. So blöd kannst Du gar nicht sein, um mich in diesem Punkt mißzuverstehen. Das muß schon Absicht sein.
Durch dynamisches LoD und einem geringen Grundniveau sind wir ewig davon entfernt, dass eine Steigerung zur Verschwendung von Pixelleistung führt.
Laut deinem Bild können Dreiecke bis zu 1,5 Pixel groß bzw. klein werden, ohne das Oversampling in die Höhe schnallen zu lassen.Ein Faktor ~7 "Oversampling" (sic!) ist also "weit davon entfernt"? Das dort vorgeschlagene Quad-Fragment merging würde das doch mal glatt auf ein Viertel Verringern, also die für pixelbasierte Operationen verfügbare Leistung glatt Vervierfachen! Und das ganz ohne Erhöhung der Shader oder ROP-Kapazitäten. Also meine nüchterne Feststellung wäre da schon, daß unsere GPUs bei solchen Workloads auf den ersten Blick schon nicht mehr übermäßig effizient aussehen. Aber nunja, Du hast ja offensichtlich eine etwas andere Definition von Effizienz als der Rest der Welt. :rolleyes:
HAWX2 hat ein Sweet Spot von 18 Pixel große Dreiecke, wobei dank dynamischen LoD ein Großteil zwischen 10-20 Pixel sich befindet.Womit sich der Rest erübrigt, da man erstens oberhalb der 8Pixel/Dreieck Faustregel für nvidia-Karten ist und zweitens damit bei Full-HD-Auflösung, 10 Pixel/Dreieck und 60fps auf nur 12 MTris/s kommt (was heißt, daß das Dreieckssetup an sich ziemlich sicher nicht der entscheidende Flaschenhals ist).
Irgendwie hast Du immer noch nicht verstanden, daß der "Sweetspot" heutiger Karten wahrscheinlich so ganz grob bei eben ~8 Pixel/Dreieck (oder meinetwegen auch 4 oder 12 Pixel je nach genauem Anwendungsfall, aber eben so die Größenordnung, verdopple das grob für Radeons) liegt. Aber mehr - also kleinere - Dreiecke können im Endeffekt eher kontraproduktiv sein, da eben definitiv überproportional Pixelleistung flöten geht, man aber eben nur noch mittelprächtig an Grafikqualität gewinnt. Ausnahmen gibt es immer, aber ein paar Details mit 1 Pixel kleinen Dreiecken zu machen, bringt jetzt auch keine GPU sofort um. Aber natürlich kann man mit Mikropolygonen (also <1 Pixel/Dreieck) auch tolle Sachen machen, nur eben nicht wirklich gut mit heutigen GPUs. Es ist nicht so, daß man nicht irgendein Demo mit 100fps und 4 MTris/frame zum laufen bekommt. Aber um das wirklich praxistauglich einzusetzen, dafür zerbrechen sich etliche Leute gehörig den Kopf, um das ganze eben effizienter zu bekommen und nicht nur ein rudimentärer Pixelshader drübergejagt werden kann, weil das Ding sonst einfach nur noch Standbilder liefert.
wie kann dann jemand sich in diesem Forum hinstellen und DX11-Tessellation als vollkommen ineffiziente Methode zur Erzeugung von realer Geometrie bezeichnen?
Zum allerletzten Mal: Das habe ich nie getan. Du lügst, verstehst es einfach nicht oder trollst. Such es Dir aus! Das Problem mit den Quads hat mit Tessellation erstmal überhaupt nichts zu tun. Das tritt bei "normaler" Geometrie genau so auf. Das ist einfach ein fundamentales Problem momentaner GPUs.
Edit:
Achja, da kann mir wahrscheinlich Coda aushelfen, aber bei einem deferred Renderer wird das DOF doch beim finalen Compositing berechnet, oder? Der Schritt ist übrigens gerade nicht von dieser Quad-Ineffizienz betroffen (ist eher vergleichbar mit einem ScreenSpace Post-Processing), genau wie MLAA-Algorithmen. Es betrifft wie gesagt alles, was durch die Rasterstufe muß (irgendwie müssen die Buffer ja erstmal sinnvoll gefüllt werden, die dann beim Compositing verrechnet werden). Insofern sollte es für deferred renderer für einige Sachen etwas günstiger aussehen als für die klassischen forward renderer.
LovesuckZ
2011-05-24, 14:55:19
Offensichtlich willst Du Gedankengänge nicht verstehen, die von Deiner Überzeugung auch nur minimal abweichen. Tja, da kann man wohl nix machen.
Ich verstehe dich doch sehr gut. ich sehe, dass du den Worst-Case nimmst, um Tessellation madig zu machen.
Das wäre so als wenn ich behaupte: Da man beim Autofahren sterben kann, sollten alle nur noch zu Fuß gehen.
Aber eine Bitte habe ich noch: Höre mit Deinen ewigen Unterstellungen auf, ich wäre gegen Tessellation oder würde sagen, es wäre prinzipiell ineffizient! Das ist einfach schwachsinnig. So blöd kannst Du gar nicht sein, um mich in diesem Punkt mißzuverstehen. Das muß schon Absicht sein.
Das war dein Einstieg in die Diskussion:
Und nicht vergessen: Eine exorbitante Steigerung der Geometrie hat eine steigende Ineffizienz der heutigen quadbasierten Renderer zur Folge, die die effektiv verfügbare Shaderleistung drastisch mindert, ohne die Grafikqualität noch merklich (bei einem Echtzeitrenderer) anzuheben.
Es ist ersichtlich, dass du alles unternimmst, dass Tessellation schlecht dasteht. Selbst, wenn niemand gesagt hat, dass man Milliarden an Dreiecke benötigt. Ich bin nicht blöd, ich kann leider nur lesen. Achja, meine Aussage war nur, dass echte Geometrie besser ist als Fake-Methoden.
Ein Faktor ~7 "Oversampling" (sic!) ist also "weit davon entfernt"? Das dort vorgeschlagene Quad-Fragment merging würde das doch mal glatt auf ein Viertel Verringern, also die für pixelbasierte Operationen verfügbare Leistung glatt Vervierfachen! Und das ganz ohne Erhöhung der Shader oder ROP-Kapazitäten. Also meine nüchterne Feststellung wäre da schon, daß unsere GPUs bei solchen Workloads auf den ersten Blick schon nicht mehr übermäßig effizient aussehen. Aber nunja, Du hast ja offensichtlich eine etwas andere Definition von Effizienz als der Rest der Welt. :rolleyes:
Laut der Folie erhöht sich das Oversampling um 75% gegen über 11 pixelgroßen Dreiecke. Der Anzahl der Dreiecke wird dagegen massiv steigern. Und das nur bei statischer Realisierung. Sieht ziemlich effizient aus.
Die Folie geht leider nicht weiter zurück, da aber der Verlauf ziemlich gradlinie nach hinten wird, kann man vielleicht von einem Faktor 2 bei 18 -> 1,5 ausgehen.
Womit sich der Rest erübrigt, da man erstens oberhalb der 8Pixel/Dreieck Faustregel für nvidia-Karten ist und zweitens damit bei Full-HD-Auflösung, 10 Pixel/Dreieck und 60fps auf nur 12 MTris/s kommt (was heißt, daß das Dreieckssetup an sich ziemlich sicher nicht der entscheidende Flaschenhals ist).
Der Dreiecksdurchsatz ist auch nie der limitierende Faktor gewesen. Aber das hast du bis jetzt immer durchgehend ignoriert. Das Fermi selbst bei nichtmal 1 Mrd. Dreiecke pro Sekunde Frame 8x schneller ist als Cayman, war für dich und deinem Feldzug nie von Belang. Du kommst immer mit den selben Aussagen, selbst wenn zwischen den Konkurrent solch ein Abstand herrscht. Wenn Fermi also soviel schneller ist, kann nicht Tessellation auf heutigen Architekturen ineffizient sein, sondern die Architektur von AMD ist für Tessellation einfach unbrauchbar. Du vermischt also wesentlich Punkte, um am Ende Tessellation madig zu machen.
Zum allerletzten Mal: Das habe ich nie getan. Du lügst, verstehst es einfach nicht oder trollst.
Man sollte nicht denjenigen des Trollen bezichtigen, der dich einfach 1:1 wiedergibt. Du bist derjenige, der Tessellation in der jetzigen Form als vollkommen nutzlos hinstellt, der es als ineffizient bezeichnet und der es absurd findet, dass DX11 bis zu 64 Stufen unterstützt, wo doch 8 vollkommen ausreichend wären.
Und das du auf die Beispiele aus heutigen Anwendungen nicht eingehst, ist dann nicht mehr mal bezeichnend. Welche Erklärungen hast du denn, dass der Einbruch in Stone Giant mit erweitertem DoF geringer ist als ohne, wenn Tessellation doch die Effizienz in Bezug auf Rechenleistung deutlich verringert? Warum verliert man im 3DMark11 gerademal 10% an Leistung, wenn man mit allen Effekte Tessellation dazuschaltet? Die Wirklichkeit widespricht dir zZ leider noch. Das heißt wiederrum, wie können heutzutage den Geometriegrad deutlich erhöhen ohne Effizienzprobleme zu erhalten.
Gipsel
2011-05-24, 16:12:28
Ich verstehe dich doch sehr gut. ich sehe, dass du den Worst-Case nimmst, um Tessellation madig zu machen.Habe ich nicht gerade nochmal geschrieben, daß das mit Tessellation gar nichts zu tun hat?!?
Das war dein Einstieg in die Diskussion:
Dann zitiere Dich selber auch gleich mal mit:
Und nicht vergessen: Echte Geometrie lässt sich per MSAA glätten, was wiederum dazuführt, dass SSAA an Bedeutung verliert und man mehr Leistung für andere Effekte hat.
Und nicht vergessen: Eine exorbitante Steigerung der Geometrie hat eine steigende Ineffizienz der heutigen quadbasierten Renderer zur Folge, die die effektiv verfügbare Shaderleistung drastisch mindert, ohne die Grafikqualität noch merklich (bei einem Echtzeitrenderer) anzuheben.
Wenn Du SSAA halbwegs gleichwertig durch MSAA ersetzen willst, benötigst Du im Prinzip Mikropolygone (bei denen MSAA auch keinen Performancevorteil mehr aufweist, wie Tesseract schon ganz richtig angemerkt hat (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8746952#post8746952)). Wenn Dir das nicht klar ist, kann ich da auch nichts machen. Oder anders: Deine Aussage war schlicht unzutreffend, worauf ich Dich mit einem grundlegenden Fakt (btw., liest Du da irgendwas von Tessellation? :rolleyes:), der einen Effekt in die gegenteilige der von Dir behaupteten Richtung zur Folge hat, aufmerksam machen wollte.
Laut der Folie erhöht sich das Oversampling um 75% gegen über 11 pixelgroßen Dreiecke. Der Anzahl der Dreiecke wird dagegen massiv steigern. Und das nur bei statischer Realisierung. Sieht ziemlich effizient aus.Mal abgesehen, daß ich da eher einen Faktor 2 erkenne, kommt mir das ein wenig so vor wie in den Anfangszeiten der LED, in der gerne so eine Art differentieller Wirkungsgrad definiert wurde. Also nicht rauskommende Leistung durch reingehende Leistung geteilt wurde, sondern die Ableitungen davon genommen wurde :freak:.
Ineffizient bleibt ineffizient. Und das es "nur" nochmal doppelt so ineffizient wird, als es ohnehin schon ist, als Erfolg zu verkaufen, ist vielleicht nicht ganz so erfolgversprechend, wie in Zukunft diese Ineffizienz vielleicht mal zu beheben ;).
Der Dreiecksdurchsatz ist auch nie der limitierende Faktor gewesen. Aber das hast du bis jetzt immer durchgehend ignoriert.Komisch. Und ich dachte schon, ich hätte das ständig gesagt. ;D
Du kommst immer mit den selben Aussagen ...:freak:
Da sag ich jetzt mal nix zu. Okay, ein Stichwort liefere ich Dir: Selbstreflexion.
Ansonsten wird mir das hier echt zu blöd. Also mach's noch gut!
LovesuckZ
2011-05-24, 17:10:48
Habe ich nicht gerade nochmal geschrieben, daß das mit Tessellation gar nichts zu tun hat?!?
Es geht hier alleinig um Tessellation. Tessellation - also Geometrieerzeugung auf der GPU - ist der Grund, warum Fermi so aussieht. Aber dies hast du auch schon im anderen Thread dauernd runtergespielt. Der normale Geometrieoutput ist doch nur ein Nebeneffekt aus der Parallerität und der Zielsetzung für die Größe der Dreiecke.
Wenn Du SSAA halbwegs gleichwertig durch MSAA ersetzen willst, benötigst Du im Prinzip Mikropolygone (bei denen MSAA auch keinen Performancevorteil mehr aufweist, wie Tesseract schon ganz richtig angemerkt hat (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8746952#post8746952)). Wenn Dir das nicht klar ist, kann ich da auch nichts machen. Oder anders: Deine Aussage war schlicht unzutreffend, worauf ich Dich mit einem grundlegenden Fakt (btw., liest Du da irgendwas von Tessellation? :rolleyes:), der einen Effekt in die gegenteilige der von Dir behaupteten Richtung zur Folge hat, aufmerksam machen wollte.
Ich sehe in meinem Zitat nunmal nichts in diese Richtung. Jeder kann mit dem D3D SDK diesen Fall selbst austesten: Parallel Mapping und Hardware Tessellation. Und ironischerweise ist HTW mit MSAA deutlich schneller als PM mit SSAA. Dragon Age 2 führt Aliasing durch PM ein, dass nur durch SSAA entfernt werden kann. Hätte man in diesem Fall echte Geometrie verwendet, müsste man nicht zwischen 50-66% an Leistung opfern, um solchen Quatsch wegzubekommen.
Ineffizient bleibt ineffizient. Und das es "nur" nochmal doppelt so ineffizient wird, als es ohnehin schon ist, als Erfolg zu verkaufen, ist vielleicht nicht ganz so erfolgversprechend, wie in Zukunft diese Ineffizienz vielleicht mal zu beheben ;).
Die Aussage ist eine einzige Plattitüde. Wenn ich z.B. 10x soviele Dreiecke erhalte, dabei aber nur 2x soviel Rechenleistung investieren muss, dann ist dies nicht ineffizient. Denn ineffizient bedeutet, dass das selbe Ergebnis auf einem anderen Weg besser zu lösen sei. Der einzige Bezug auf BQ ist dabei genauso falsch, da es genug Effekte gibt, die ineffizient per Recheneinheiten umgesetzt werden.
Da sag ich jetzt mal nix zu. Okay, ein Stichwort liefere ich Dir: Selbstreflexion.
Das ist ein Punkt, den du wirklich machen solltest. Dein einziger Punkt, warum Tessellation angeblich unnütz wäre, ist die Ineffizientät durch Oversampling. Aber das ist ja im Grunde nur vorgeschoben. Nach Occam's razor gibt es nur eine Möglichkeit: AMD hat es verkackt. Mir ist kein aktueller Fall bekannt, indem Tessellation auf der GPU zu so starkem Oversampling führte, dass der Leistungseinbruch dermaßen höher liegt als er sollte. Weder in Stone Giant noch im 3DMark2011 macht sich Oversampling bemerkbar. Man verliert in Stone Giant relativ weniger Leistung, wenn DoF eingeschaltet wird. Das bedeutet, trotz einem Vorsprung von 2x in Stone Giant vor der Konkurrenz ist die Erzeugung der Dreiecke auf Fermi immer noch über dem Punkt, wo es ineffizient wäre. Dein einziges Argument spielt für die heutige und morgige Generation überhaupt keine Rolle, da das Front-End nicht schnell genug die Dreiecke berechnen, erzeugen und rastern kann, sowie jedenfalls bei nVidia auch nicht genug Rechenleistung zur Verfügung steht.
Gipsel
2011-05-24, 22:55:20
Dein einziges Argument spielt für die heutige und morgige Generation überhaupt keine Rolle, da das Front-End nicht schnell genug die Dreiecke berechnen, erzeugen und rastern kann, sowie jedenfalls bei nVidia auch nicht genug Rechenleistung zur Verfügung steht.
Verstehst Du Dich eigentlich selber? :confused:
Was nun, Frontend nicht schnell genug (mööp, das ist doch GEOD, um mal B3D zu zitieren) oder nicht genügend Rechenleistung?
GEOD = geometry engine of doom
LovesuckZ
2011-05-25, 00:52:31
Verstehst Du Dich eigentlich selber? :confused:
Was nun, Frontend nicht schnell genug (mööp, das ist doch GEOD, um mal B3D zu zitieren) oder nicht genügend Rechenleistung?
Och, scheint echt schwer zu sein die Architektur verstehen zu können. Aber ich kann das verstehen, wenn man schon eine Seite zitieren muss, die falsche Behauptungen aufstellt. :rolleyes:
Das Front-End limitiert - später als bei AMD, aber es limitiert. Die Rechenleistung limitiert bzgl. der ganzen Effekte. Oversampling ist ein Geist, der theoretisch für die Zukunft Probleme bereiten kann, wenn Front-End und Rechenarchitektur soweit entwickelt sind, dass sie die Last auch in Echzeit stemmen können. Weder 3DMark11 noch Stone Giant zeigen eine Limitierung durch das Front-End bei Fermi. Und diese haben "eine exorbitante Steigerung der Geometrie" gegenüber heutigen Verhältnissen.
AMD wird nie Probleme durch Oversampling haben, da deren Front-End schon bei geringsten Einsatz zur Limitierung neigt. Aber das passiert wohl, wenn man den Tessellation-Teil nicht über die Shader durchführen lässt. :freak:
Gipsel
2011-05-25, 09:03:52
:facepalm:
Den habe ich noch nie benutzt, aber hier ist er mal angebracht. Also bei dem Mangel an Wille, grundsätzliche logische Zusammenhänge zu erfassen, verschwende ich meine Zeit nicht mehr.
Vielleicht kann man sich jetzt wieder dem Thema widmen, was Kepler und Maxwell für Änderungen bringen. Eventuell können wir ja später in der Nachschau noch mal auf diesen Punkt zurückkommen. :rolleyes:
LovesuckZ
2011-05-25, 12:01:35
:facepalm:
Den habe ich noch nie benutzt, aber hier ist er mal angebracht. Also bei dem Mangel an Wille, grundsätzliche logische Zusammenhänge zu erfassen, verschwende ich meine Zeit nicht mehr.
Eigentlich - erfasse ich die Zusammenhänge sehr gut. Ich belege meine Aussagen mit Beispielen aus Anwendungen und versuche meinem Standpunkt ausführlich zu erklären.
Du bringst Worthülsen, Plattiduden und "Oversampling". Bist nicht in der Lage deine Aussagen auf die heutigen Verhältnisse zu übertragen und schaffst es nichtmal einzelne Punkte überhaupt zu belegen. Das du die Beispiele Stone Giant und 3DMark11 ignorierst, zeigt förmlich, dass es dir nicht um die Wirklichkeit geht. Wie soll man also mit dir über nVidia und gewisse Features diskutieren, wenn du hier rein zum Zwecke von Propaganda (http://de.wikipedia.org/wiki/Propaganda) teilnimmst um AMD zu verteidigen bzw. nVidia schlecht zu machen?
Am Ende bist du es, der ein "Mangel an Wille, grundsätzliche logische Zusammenhänge zu erfassen," aufweist. Nicht weil du dumm bist, sondern weil du aufgrund einer Agenda keine anderen Aussagen tätigen kannst oder willst. Wenn du also bereit bist, mit freiem Geist über nVidia und Technologien zu reden, die nVidia favorisieren, dann gerne. Aber du langweilst mit deiner Propaganda (http://de.wikipedia.org/wiki/Propaganda), dass alles doof, schlecht und ineffizient wäre.
Screemer
2011-05-25, 12:28:17
Nicht weil du dumm bist, sondern weil du aufgrund einer Agenda keine anderen Aussagen tätigen kannst oder willst. Wenn du also bereit bist, mit freiem Geist über nVidia und Technologien zu reden, die nVidia favorisieren, dann gerne. Aber du langweilst mit deiner Propaganda, dass alles doof, schlecht und ineffizient wäre. das wäre ein schönes zitat für die signatur. ich habe eure diskussion nur oberflächlich verfolgt, da ich nicht das know-how habe um bei den technischen details mitreden zu können, aber soviel ich sehe bist es eher du der sich sperrt zukünftige entwicklungen mit in seine überlegungen einzubeziehen. ich frage mich manchmal wirklich von wem dir deine agenda diktiert wird. gipsel sollte es einfach gut sein lassen. mit dir zu diskutieren führt zu gar nichts, denn du rückst keinen milimeter von deinem standpunkt ab oder nimmst argumente von anderen in deine überlegungen auf. das ist nicht der erste thread der seitenweise deine agenda zeigt.
ich habe eure diskussion nur oberflächlich verfolgt, da ich nicht das know-how habe um bei den technischen details mitreden zu können, aber soviel ich sehe bist es eher du der sich sperrt zukünftige entwicklungen mit in seine überlegungen einzubeziehen.
Immerhin schön, dass jemand der Diskussion noch folgen kann. Ich kann die Kerndiskussionspunkte da schon lange nicht mehr rauslesen. Zu oft wird das Thema gewechselt und wieder zurückgesprungen. Imo vertreten Gipsel und Lovesuckz unterschiedliche Betrachtungsweisen und schaffen es nicht mehr Argumente für den anderen verständlich und überzeugend zu erklären. :freak:
Seit ich mich erinnern kann, enden solche Forumdiskussionen eh in keinem anderen Ergebnis, als dass sich jeder in seinem Standpunkt bestätigt fühlt. :D
LovesuckZ
2011-05-25, 13:45:48
das wäre ein schönes zitat für die signatur. ich habe eure diskussion nur oberflächlich verfolgt, da ich nicht das know-how habe um bei den technischen details mitreden zu können, aber soviel ich sehe bist es eher du der sich sperrt zukünftige entwicklungen mit in seine überlegungen einzubeziehen.
Welchen Bezug haben zukünftige Architekturen, wenn jemand heute mit "Oversampling" als Gegenbehauptung argumentiert, wenn vorallem heutige und, aus meiner Sicht, morgige Architekturen nicht in dieses Problem laufen werden? Niemand weiß, wie zukünftige Architekturen aussehen, aber man kann gewisse Punkte abschätzen.
ich frage mich manchmal wirklich von wem dir deine agenda diktiert wird. gipsel sollte es einfach gut sein lassen. mit dir zu diskutieren führt zu gar nichts, denn du rückst keinen milimeter von deinem standpunkt ab oder nimmst argumente von anderen in deine überlegungen auf. das ist nicht der erste thread der seitenweise deine agenda zeigt.
Das Problem ist, dass ich nur von meinem Standpunkt abrücken kann, wenn mir jemand auch vernünftige Thesen mit Beweisen gegenüberstellt. Wie soll ich denn meine Meinung ändern, wenn ich Belege für meinen Standpunkt habe, der Diskussiongegner aber nur Thesen? Gipsel's Standpunkt beruht darauf, dass heutige Architekturen generell < 1 pixelgroße Dreiecke durch's Front-End ohne Limitierung erzeugen können. Da diese Annahme jedoch falsch ist, ist seine einzige Diskussionsgrundlage vollkommen belanglos.
Das Problem am Internet wird immer mehr, dass Leute nicht mehr nach Informationen gieren, sondern nur das Weiterverbreiten, was sie als "richtig" ansehen. Und somit gehen sie auch mit den Thesen mit, die ihren Standpunkt entsprechend. Falsch bleibt falsch. Es ist irgendwie ironisch, dachte ich immer, dass der Mensch nach der Wahrheit strebt.
LovesuckZ, du bist nicht in einer Position solche Unterstellungen zu verbreiten. Gipsel mag auch nicht 100% richtig liegen, aber er versteht mit Sicherheit weit mehr von der Technik als du.
Gipsel
2011-05-25, 14:22:44
Ich kann die Kerndiskussionspunkte da schon lange nicht mehr rauslesen.Stell' Dein Licht mal nicht unter den Scheffel! Immerhin hast Du doch ganz richtig erkannt, worum es ging, und eine exakt zum Thema passende Präsentation verlinkt (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8747068#post8747068) ;)
Imo vertreten Gipsel und Lovesuckz unterschiedliche Betrachtungsweisen und schaffen es nicht mehr Argumente für den anderen verständlich und überzeugend zu erklären. :freak:Ja welche Betrachtungsweise vertritt LS denn? Frontend limitiert oder limitiert nicht? Rechenleistung limitiert. Kannst Du das hier rauslesen?
Das Front-End limitiert - später als bei AMD, aber es limitiert. Die Rechenleistung limitiert bzgl. der ganzen Effekte. Oversampling [sic!] ist ein Geist, der theoretisch für die Zukunft Probleme bereiten kann, wenn Front-End und Rechenarchitektur soweit entwickelt sind, dass sie die Last auch in Echzeit stemmen können. Weder 3DMark11 noch Stone Giant zeigen eine Limitierung durch das Front-End bei Fermi. Und diese haben "eine exorbitante Steigerung der Geometrie" gegenüber heutigen Verhältnissen.Das zeigt mir doch höchstens, daß er das Problem der ineffizienten Nutzung der GPU-Hardware in Fragment/Pixelshadern, die sich bei fein aufgelöster Geometrie noch verstärkt und auch bereits in heutigen Szenarien akut sein kann, vollkommen verkennt. Zum einen sagt er richtigerweise, daß die Shaderleistung der heutigen GPUs in vielen Szenarien limitierend wirkt, sperrt sich aber gegen die Erkenntnis, daß für jeden ausgegebenen Pixel in einer Szene mit im Schnitt immerhin noch 6 Pixel großen Dreiecken (was keineswegs unrealistisch ist), noch nicht einmal die Hälfte(*) der Shadereinheiten bei einem Pixelshader sinnvolle Arbeit verrichtet. Der Rest wird im Prinzip schlicht verworfen! Wenn man das abstellt (bei in Zukunft verstärkt auftretenden Szenarien mit sehr kleinen Dreiecken wird das Problem noch eklatanter und in die Zukunft wollen wir ja wohl alle hin ;)), dann behebt man vielleicht nicht den Bedarf an zusätzlicher Rechenleistung, kann ihn aber sehr effektiv vermindern.
Für den breiten Einsatz von Mikropolygonrendering ist eine Lösung für das Problem einfach erforderlich, will man das nicht mit ansonsten unnötig viel erforderlicher Rechenleistung totschlagen. Dazu bedarf es Änderungen an der Grafikpipeline. Über diese kann hier spekuliert werden.
(*):
In der Grafik werden für die Dreiecksgröße zwar ~4 Shaderdurchläufe pro Pixel angegeben, aber ein paar davon sind für's AA (Multisampling) verwendbar, also nicht umsonst (zumindest wenn AA aktiviert, aber davon sollte man wohl ausgehen). Das dort vorgeschlagene Quad-Fragment Merging hat ja das 4xAA praktisch schon integriert (zwischen benachbarten Dreiecken eines Meshes, wenn auch in etwas reduzierter Qualität, die aber innerhalb benachbarter Dreiecke eines Modells insbesondere, wenn sie durch Tessellation erzeugt werden, kaum auffallen dürfte, die Silhouetten müssen noch auf dem normalen Weg gemacht werden).
LovesuckZ
2011-05-25, 14:30:23
LovesuckZ, du bist nicht in einer Position solche Unterstellungen zu verbreiten. Gipsel mag auch nicht 100% richtig liegen, aber er versteht mit Sicherheit weit mehr von der Technik als du.
Habe ich nie in Frage gestellt. Nur sollte er dementsprechend auf Basis seines Wissens die richtigen Schlüsse ziehen.
Gipsel
2011-05-25, 14:37:05
So, das nimmt jetzt mit dem OT wirklich überhand.
BTT please!
LovesuckZ
2011-05-25, 14:59:06
Ja welche Betrachtungsweise vertritt LS denn? Frontend limitiert oder limitiert nicht? Rechenleistung limitiert. Kannst Du das hier rauslesen?
Es steht eindeutig im Posting. Lerne bitte lesen.
Dein einziges Argument spielt für die heutige und morgige Generation überhaupt keine Rolle, da das Front-End nicht schnell genug die Dreiecke berechnen, erzeugen und rastern kann, sowie jedenfalls bei nVidia auch nicht genug Rechenleistung zur Verfügung steht.
Das zeigt mir doch höchstens, daß er das Problem der ineffizienten Nutzung der GPU-Hardware in Fragment/Pixelshadern, die sich bei fein aufgelöster Geometrie noch verstärkt und auch bereits in heutigen Szenarien akut sein kann, vollkommen verkennt.
Ich bitte um Belege aus "heutigen Szenarien". Weniger Platitüden und mehr Inhalt.
Zum einen sagt er richtigerweise, daß die Shaderleistung der heutigen GPUs in vielen Szenarien limitierend wirkt, sperrt sich aber gegen die Erkenntnis, daß für jeden ausgegebenen Pixel in einer Szene mit im Schnitt immerhin noch 6 Pixel großen Dreiecken (was keineswegs unrealistisch ist), noch nicht einmal die Hälfte(*) der Shadereinheiten bei einem Pixelshader sinnvolle Arbeit verrichtet. Der Rest wird im Prinzip schlicht verworfen! Wenn man das abstellt (bei in Zukunft verstärkt auftretenden Szenarien mit sehr kleinen Dreiecken wird das Problem noch eklatanter und in die Zukunft wollen wir ja wohl alle hin ;)), dann behebt man vielleicht nicht den Bedarf an zusätzlicher Rechenleistung, kann ihn aber sehr effektiv vermindern.
Oversampling wird laut der Folie erst bei sehr kleinen Dreiecken zum Problem. Du führst hier plötzlich 6 pixelgroße Dreiecke an, bei dem der Overhead gegenüber z.B. 11 pixelgroße nur minimal ansteigt. Die Probleme sind also - jedenfalls nach der Folie - nicht relevant. Geht man davon aus, dass das Oversampling kaum geringer wird bei Zunahme der Größe der Dreiecke, sind 6 Pixelgroße Dreiecke vielleicht unschön, aber kein "GameBreaker". Natürlich annehmend, dass das Front-End überhaupt in der Lage ist ohne Limitierung 6 pixelgroße Dreiecke ohne Zeitverlust erzeugen zu können, was jedenfalls bei AMD und nVidia nicht der Fall ist.
Hugo78
2011-05-25, 15:06:16
Ich kapier grad nicht, warum ihr euch wegen Tess so heiß macht?!
Das wäre doch ein Thema für AMDs 28nm Chips.
Bei Kepler und Maxwell könnte Nvidia auf dem Leistungsstand von Fermi paar Jahre verharen und wäre dann immernoch 10mal schneller als jeder Konsolenport, es je anbieten wird.
Ausser Sony und MS legen sich mal entsprechende HW zu, für ihre nächsten Brotkisten.
Und das weiß Nvidia auch, die werden sich um andere Dinge mit Kepler kümmern, als Tess.
NVIDIA ist mit dem Thema eh praktisch durch. Das Verfahren was sie mit Fermi implementiert haben ist erstmal beliebig skalierbar.
LovesuckZ
2011-05-25, 15:17:41
Ich kapier nicht grad warum ihr euch wegen Tess so heiß macht?!
Es ging um die Aufwendung von Transistoren bei Fermi bzgl. Tessellation. Und das Fermi trotzdem deutlich schneller ist als GT200b. Man kann es nicht in einem Head-to-Head messen, aber da eine GTX580 ca. 80-90% schneller als eine GTX285 in "heutigen Spielen" ist, kann man in Spielen das Geometrielevel dermaßen erhöhen, ohne langsamer als eine GTX285 zu werden. Siehe dazu auch Stone Giant, wo die GTX580 mit Tessellation@high immer noch knapp 50% schneller ist als eine GTX285 mit DX10.
Ailuros
2011-05-25, 15:29:21
NVIDIA ist mit dem Thema eh praktisch durch. Das Verfahren was sie mit Fermi implementiert haben ist erstmal beliebig skalierbar.
Eben. Ich versuch gerade vergebens erstmal zu verstehen wo die eigentliche Relevanz zu Tessellation liegt in der Debatte und dann noch zusaetzlich was es genau mit zukuenftigen Generationen zu tuhen haben koennte, ueberhaupt da der Pegel fuer Tessellation ab GF100 ziemlich hoch angelegt ist. Von da ab kann sich das Ganze nur steigern. Das es spaeter (vielleicht schon bei Maxwell) zu moeglichen tieferen Aenderungen der pipeline fuer Unmengen an micro-Polygonen kommen koennte ist dann natuerlich ein anderes Kapitel.
Kurz: was verpass ich gerade :confused:
Gipsel
2011-05-25, 15:36:08
Es steht eindeutig im Posting.Nein.
Oversampling wird laut der Folie erst bei sehr kleinen Dreiecken zum Problem.Nein. Bzw. je nach dem, was Du als "sehr klein" bezeichnest. 4 Fragmentshader-Durchläufe pro Pixel sehe ich als Effizienzproblem und 6 Pixel pro Dreieck sind nicht gerade utopisch. Die bekommmst Du auch schon heute hin.
Btw., der von Dir gewählte Begriff "Oversampling" trifft es nicht wirklich ;)
Du führst hier plötzlich 6 pixelgroße Dreiecke an, bei dem der Overhead gegenüber z.B. 11 pixelgroße nur minimal ansteigt. Die Probleme sind also - jedenfalls nach der Folie - nicht relevant.Nun, auch bei 11 Pixeln ist es eben schon nicht mehr der Ausbund an Effizienz. Die Verschwendung steigt von Faktor 3 auf Faktor 4. Ist ja super toll!
Die Abarbeitung in Quads ist eben ein Kompromiß um an Scheduling-Hardware der GPUs zu sparen, genau wie insgesamt die Organisation der GPUs als SIMD-Arrays mit ihren recht großen Warp-/Wavefrontgrößen (32 bzw. 64 Fragments) ein Kompromiß ist, der in Zeiten recht großer Dreiecke und recht wenig Dynamik im Renderablauf sehr gut war. Die Effizienz fängt aber bereits heute an (deutlich) zu leiden und wird bei den für die Zukunft absehbaren Anforderungen ganz klar suboptimal sein. Deswegen wird das Problem ziemlich sicher früher oder später angegangen werden.
Natürlich annehmend, dass das Front-End überhaupt in der Lage ist ohne Limitierung 6 pixelgroße Dreiecke ohne Zeitverlust erzeugen zu können, was jedenfalls bei AMD und nVidia nicht der Fall ist.Nein?
Bei Full-HD sind das gerade mal 346k Tris pro Frame und bei 60fps 20 Millionen Dreiecke pro Sekunde. Da gab es schon vor etlichen Jahren Demos mit mehr. Wieviele Dreiecke sieht man denn z.B. bei Crysis mit sehr hohen Details so?
Edit:
Gerade mal gegoogelt. Das letzte Ruby-Demo für R600 (!) hatte grob 2 Millionen Dreiecke pro Frame. Das Ruby-Modell alleine bestand aus etwa 200k Polygonen. Nur mal so nebenbei. Selbst wenn davon jeweils ein ansehnlicher Teil verdeckt war, kommt mein Argument wohl schon noch rüber. Und Fermi hat auf das Potential ja noch eine ganz ordentliche Schippe draufgelegt (bei AMD wurde es seitdem nur grob auf Faktor 2,4 erhöht).
Ich kapier grad nicht, warum ihr euch wegen Tess so heiß macht?!Wie schon mal gesagt, hat das mit Tess nur mittelbar zu tun. Es geht um eine prinzipielle Ineffizienz heutiger quadbasierter Renderer mit viel Geometrie.
Ich wäre schon arg enttäuscht, wenn nvidia uns in Zukunft z.B. mit Maxwell keinen Lösungsansatz bietet. Ich hatte das schon ein paar mal angedeutet, aber ich denke bereits Fermi ging einen ersten Schritt, um das GPU-Design auch genau dafür vorzubereiten (vielleicht erstmal Duads statt Quads zur Linderung, das halbiert sozusagen das Problem).
Ailuros
2011-05-25, 15:43:36
Fuer Forschungen fuer zukuenftige Architekturen mit tonnenweise Micropolygonen gibt es auch den alten Thread hier im Technologie-Forum:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=496241
Wobei man in beiden whitepapers deutlich sehen kann dass es in Zukunft aus mehreren Gruenden eben nicht so weitergehen kann wie heute.
LovesuckZ
2011-05-25, 16:09:49
Nein. Bzw. je nach dem, was Du als "sehr klein" bezeichnest. 4 Fragmentshader-Durchläufe pro Pixel sehe ich als Effizienzproblem und 6 Pixel pro Dreieck sind nicht gerade utopisch. Die bekommmst Du auch schon heute hin.
Btw., der von Dir gewählte Begriff "Oversampling" trifft es nicht wirklich ;)
Nun, auch bei 11 Pixeln ist es eben schon nicht mehr der Ausbund an Effizienz. Die Verschwendung steigt von Faktor 3 auf Faktor 4. Ist ja super toll!
Mehr Inhalt weniger Platitüde. Von welchen "heutigen Szenarien" wird gesprochen? Stone Giant - ein Niveau, dass erreichbar sein sollte - zeigt kein Effizienzproblem. Das bedeutet, die Dreiecke in Stone Giant sind größer als angenommen oder die Limitierung bzgl. der Leistung wird nicht durch eine schlechtere Effizienz aufgrund von zu kleinen Dreiecken hervorgerufen.
Die Effizienz fängt aber bereits heute an (deutlich) zu leiden und wird bei den für die Zukunft absehbaren Anforderungen ganz klar suboptimal sein. Deswegen wird das Problem ziemlich sicher früher oder später angegangen werden.
Mehr Inhalt und weniger Platitüde. Natürlich wird sich dem Problem in Zukunft angenommen. Nur ist nVidia heute weiter als AMD. Wir reden also über ein Problem, dass AMD eigentlich überhaupt nicht betrifft, da deren Front-End eher aufgrund der Last implodiert als das die Erzeugung von Dreiecken die Recheneinheiten ausbremsen wird. Wir sollten also nicht über Dinge reden, die noch weit in der Zukunft liegen und sie auf heutige Verhältnisse anwenden, um eine Technik als schlecht zu deklarieren, die einem nicht gefällt.
Nein?
Bei Full-HD sind das gerade mal 346k Tris pro Frame und bei 60fps 20 Millionen Dreiecke pro Sekunde. Da gab es schon vor etlichen Jahren Demos mit mehr. Wieviele Dreiecke sieht man denn z.B. bei Crysis mit sehr hohen Details so?
Ich dachte, wir hätten geklärt, dass der reine Dreiecksdurchsatz nicht das Problem darstellt, sondern die Erzeugung der Dreiecke auf der GPU? Hast du nicht tolle Smileys genau deswegen abgesetzt?!
Du argumentierst immer an diesem Punkt vorbei. Und genau das ist das Problem: Die Erzeugung führt zur Limitierung, da das Front-End bei großer Anzahl nicht schnell genug ist - bei nVidia wie bei AMD. Bevor dieser Punkt nicht eliminiert wurde, brauchen wir uns nicht über nicht ausgelastene Recheneinheiten unterhalten.
Gipsel
2011-05-25, 16:24:48
:freak:
Und genau das ist das Problem: Die Erzeugung führt zur Limitierung, da das Front-End bei großer Anzahl nicht schnell genug ist - bei nVidia wie bei AMD. Bevor dieser Punkt nicht eliminiert wurde, brauchen wir uns nicht über nicht ausgelastene Recheneinheiten unterhalten.
NVIDIA ist mit dem Thema eh praktisch durch. Das Verfahren was sie mit Fermi implementiert haben ist erstmal beliebig skalierbar.
:rolleyes:
AMD trifft es nur bei heutigen GPUs später, weil das Frontend bei Tessellation (sonst hat nv das bei Geforces ja künstlich unter Cayman-Niveau beschnitten, was in der realen Welt aber kaum Auswirkungen haben dürfte) schwächlicher ist und relativ gesehen damit deutlich mehr Shaderleistung zur Verfügung steht (die aber ohne bzw. nur moderater Tess aus den gleichen Gründen auch nicht ausreicht). Es aber als nichtexistent zu deklarieren, geht ziemlich an der Sache vorbei. Bei nv ist das sogar ziemlich akut. Die müssen was tun. Also das Problem für die Zukunft ist definitiv nicht die Erzeugung der Geometrie. Du kannst mit Tess auf einer GTX580 Milliarden an Dreiecken pro Sekunde rausblasen (ohne Tess "nur" ~ eine Milliarde), aber da kannst Du keine ordentlichen Shader für die heute bzw. in Zukunft wünschenswerten Effekte mehr drüberlaufen lassen. Ein sehr gewichtiger Grund dafür ist, daß der ganze Fragment-Teil der Pipeline (ab Rasterizer) bei so kleinen Dreiecken fast nur noch umsonst rechnet.
LovesuckZ
2011-05-25, 16:49:27
:freak:
:rolleyes:
Ich weiß nicht, wieso du Coda zitierst. Aber sein Punkt hat nichts damit zu tun. Nur weil die Erzeugung bei nVidia hoch parallisiert und skalierbar ist, heißt das noch lange nicht, dass es das Ende der Fahnenstange bedeutet.
AMD trifft es nur bei heutigen GPUs später, weil das Frontend bei Tessellation (sonst hat nv das bei Geforces ja künstlich unter Cayman-Niveau beschnitten, was in der realen Welt aber kaum Auswirkungen haben dürfte) schwächlicher ist und relativ gesehen damit deutlich mehr Shaderleistung zur Verfügung steht (die aber ohne bzw. nur moderater Tess aus den gleichen Gründen auch nicht ausreicht). Es aber als nichtexistent zu deklarieren, geht ziemlich an der Sache vorbei.
Es hat keine Auswirkungen für AMD, weil sie überhaupt nicht in der Lage sind in dieses Limit zulaufen. Je mehr Dreiecke durch hohe Faktoren erzeugt werden müssen, umso größer wird der Abstand zwischen Fermi und Cayman. Es gibt keine abnormale Absenkung der Abstandskurve, die auf eine Limitierung bei Fermi abseits der Geometriepipeline hindeuten.
Bei nv ist das sogar ziemlich akut. Die müssen was tun. Also das Problem für die Zukunft ist definitiv nicht die Erzeugung der Geometrie. Du kannst mit Tess auf einer GTX580 Milliarden an Dreiecken pro Sekunde rausblasen (ohne Tess "nur" ~ eine Milliarde), aber da kannst Du keine ordentlichen Shader für die heute bzw. in Zukunft wünschenswerten Effekte mehr drüberlaufen lassen. Ein sehr gewichtiger Grund dafür ist, daß der ganze Fragment-Teil der Pipeline (ab Rasterizer) bei so kleinen Dreiecken fast nur noch umsonst rechnet.
Fermi ist in der Lage bei gleicher FPS Anzahl wie Cayman deutlich mehr Dreiecke zu erzeugen. Bis heute ist mir kein Fall bekannt, beidem Fermi plötzlich auf das Niveau von Cayman einbricht, weil durch zuviele Dreiecke eine Ineffizienz eintritt, die zur starken Limitierung führt.
Das nVidia ihre Rechenarchitektur deutlich überarbeiten muss, ist nichts neues. Wurde von mir hier auch angesprochen und von dir als "lächerlich" betitelt. Schön zu sehen, dass wir eigentlich der selben Meinung sind.
Gipsel
2011-05-25, 18:02:49
Ich weiß nicht, wieso du Cuda zitierst. Aber sein Punkt hat nichts damit zu tun. Nur weil die Erzeugung bei nVidia hoch parallisiert und skalierbar ist, heißt das noch lange nicht, dass es das Ende der Fahnenstange bedeutet.Es heißt, daß es erstmal kein Problem darstellt. Deswegen ist das genau der Punkt in dieser Frage.
Es hat keine Auswirkungen für AMD, weil sie überhaupt nicht in der Lage sind in dieses Limit zulaufen.Natürlich können auch Radeons in ineffiziente Bereiche kommen. Mensch, die sind da zum Teil schon mitten drin! Dazu benötigt es keine GEOD des Fermi und Tessellation bis zum Abwinken, etliche Millionen Dreiecke die Sekunde bekommt auch eine Radeon spielend hin. Ich habe ja nicht umsonst auf das Ruby-Demo für den R600 verwiesen. ;)
Je mehr Dreiecke durch hohe Faktoren erzeugt werden müssenMüssen sie ja nicht unbedingt. Ich habe doch bestimmt schon dreimal gesagt, daß das mit Tessellation erstmal nichts zu tun hat. Es ist vollkommen Banane, woher die kleinen Dreiecke kommen.
Nochmal ein Zitat von oben:
Dein einziges Argument spielt für die heutige und morgige Generation überhaupt keine Rolle, da das Front-End nicht schnell genug die Dreiecke berechnen, erzeugen und rastern kannNein. Auch die heutige Generation kann bereits schnell genug die Dreiecke berechnen, erzeugen und rastern. Zumindest in dem Sinne, daß man da keine enormen Flaschenhälse oder sowas hat. Geometrie ist bei Fermi schnell genug und läßt sich gut skalieren (der Begriff "geometry engine of doom" bei B3D ist ja achtungsvoll gemeint, falls Dir das entgangen sein sollte). Kleine Dreiecke sind dort kein Problem. Aber wenn es dann daran geht, die aus den gerasterten Dreiecken entstandenen Quads zu shaden, da verschwendet man sehr viel Leistung, ergo ein Problem. Da muß dringend dran gearbeitet werden, wenn man auf das Ziel des durchgehenden Einsatzes sehr kleiner Dreiecke zugehen will und man keine völlig ineffizient arbeitenden GPUs haben will. Performance/W limitiert heute ja sehr dominant, Verschwendung von Rechenleistung ist also schlecht und führt direkt zu einer niedrigeren Gesamtperformance.
Das nVidia ihre Rechenarchitektur deutlich überarbeiten muss, ist nichts neues. Wurde von mir hier auch angesprochen und von dir als "lächerlich" betitelt.Da kann ich mich ehrlich gesagt nicht dran erinnern. Kannst Du mir da auf die Sprünge helfen?
Was hat das mit Keppler zu tun?
LovesuckZ
2011-05-25, 21:31:14
Es heißt, daß es erstmal kein Problem darstellt. Deswegen ist das genau der Punkt in dieser Frage.
Leider hast du den Begriff "skalierbar" nicht verstanden. Er bedeutet weder "kein Problem" noch "schnell genug".
Natürlich können auch Radeons in ineffiziente Bereiche kommen. Mensch, die sind da zum Teil schon mitten drin! Dazu benötigt es keine GEOD des Fermi und Tessellation bis zum Abwinken, etliche Millionen Dreiecke die Sekunde bekommt auch eine Radeon spielend hin. Ich habe ja nicht umsonst auf das Ruby-Demo für den R600 verwiesen. ;)
Müssen sie ja nicht unbedingt. Ich habe doch bestimmt schon dreimal gesagt, daß das mit Tessellation erstmal nichts zu tun hat. Es ist vollkommen Banane, woher die kleinen Dreiecke kommen.
Du hast anscheinend die Problematik einfach nicht verstanden. Du kannst aber gerne erklären, wieso eine GTS450 in diesem Test mit dem SDK (http://www.pcgameshardware.de/aid,803440/Radeon-HD-6970-und-HD-6950-im-Test-AMDs-neue-Oberklasse-Grafikkarten/Grafikkarte/Test/?page=12) schneller wird als die 6970, wenn Tessellation nicht dafür verantwörtlich wäre.
Nein. Auch die heutige Generation kann bereits schnell genug die Dreiecke berechnen, erzeugen und rastern. Zumindest in dem Sinne, daß man da keine enormen Flaschenhälse oder sowas hat.
Das sehe ich leider nicht. Ich bitte um Beispiele, dass "keine enormen Flaschenhälse" bei AMD und nVidia existieren.
Geometrie ist bei Fermi schnell genug und läßt sich gut skalieren (der Begriff "geometry engine of doom" bei B3D ist ja achtungsvoll gemeint, falls Dir das entgangen sein sollte). Kleine Dreiecke sind dort kein Problem. Aber wenn es dann daran geht, die aus den gerasterten Dreiecken entstandenen Quads zu shaden, da verschwendet man sehr viel Leistung, ergo ein Problem. Da muß dringend dran gearbeitet werden, wenn man auf das Ziel des durchgehenden Einsatzes sehr kleiner Dreiecke zugehen will und man keine völlig ineffizient arbeitenden GPUs haben will. Performance/W limitiert heute ja sehr dominant, Verschwendung von Rechenleistung ist also schlecht und führt direkt zu einer niedrigeren Gesamtperformance.
Entweder hat B3D die Architektur von Fermi nicht verstanden oder du hast schwerwiegende Probleme beim Verständnis. Fermi hat 16 unabhängige Geometriepipelines. Die entstehende Last kann durch auf die einzelnen Pipelines bzw. Einheiten verteilt werden. Das ist vorallem für die Erzeugung von vielen Dreiecken aus einem geringen Basemash notwendig. Trotzdem reichen 16 Einheiten noch lange nicht aus, um den vollen spezifizierten Faktorumfang ausreizen zu können oder auch um später höhrere Faktoren zu zulassen. Das Problem ist, und anscheinend hast du mir nur zugestimmt um den schwarzen Peter los zuwerden, nicht der Dreiecksdurchsatz. Die Erzeugung durch Tessellation ist das Problem. Deswegen hat nVidia auch zwei Limitierungen: Das Front-End und der Rest (aus meiner Sicht die Rechenarchitektur). Bei geringer Anzahl an erzeugten Dreiecken wird nie das Front-End limitieren. Erst ab einem gewissen Punkt verlagert sich der Limitierungsbereich weg vom Rest auf das Front-End. Deswegen wird der Abstand zwischen nVidia und AMD bei zunehmenden Tessellation auch größer und nie mehr kleiner. Was du hier als Illusion eines Problems darstellst, wird für die heutige Architektur nie eintreffen.
Und ich bitte, dass Platitüden unterlassen werden. Was ist bitte "schnell genug"?
mapel110
2011-05-26, 02:13:14
http://www.xbitlabs.com/news/other/display/20110525165906_Nvidia_to_Collaborate_with_Imec_on_Scaling_of_Process_Technologie s.html
Nvidia Joins Imec's Research of Sub-20nm/Triple-Gate Process Technologies
Gipsel
2011-05-26, 02:54:06
Leider hast du den Begriff "skalierbar" nicht verstanden.:freak:
Am besten fragst Du mal bei Coda nach, wie er das mit dem "beliebig skalierbar" im Zusammenhang mit "NVIDIA ist mit dem Thema eh praktisch durch" wohl gemeint hat. ;)
Entweder hat B3D die Architektur von Fermi nicht verstanden oder du hast schwerwiegende Probleme beim Verständnis. Fermi hat 16 unabhängige Geometriepipelines. Die entstehende Last kann durch auf die einzelnen Pipelines bzw. Einheiten verteilt werden. Das ist vorallem für die Erzeugung von vielen Dreiecken aus einem geringen Basemash notwendig. Trotzdem reichen 16 Einheiten noch lange nicht aus, um den vollen spezifizierten Faktorumfang ausreizen zu können oder auch um später höhrere Faktoren zu zulassen.:freak:
Für die verfügbare Shaderleistung ist das beinahe Overkill (deswegen GEOD ;)). Wenn da eine nur halbwegs der Shaderleistung entsprechende Steigerung in Zukunft erfolgt (was durch die skalierbare Architektur fast notgedrungen erfolgen wird, da das ja praktisch automatisch mit der Anzahl der SMs bzw. GPCs skaliert), dann wird das kein wesentliches Problem werden. Nvidia ist mit dem Thema erstmal durch, wie Coda das ausdrückte.
Die Erzeugung durch Tessellation ist das Problem.Nein. Eine Geforce benötigt sogar Tessellation, um überhaupt auf seine maximale Dreiecksrate zu kommen. Wie soll das ein Problem sein? Und hast Du mal ganz grob abgeschätzt, wieviel Rechenleistung und Bandbreite man in etwa benötigt, um bei FullHD-Auflösung und 60fps irgendwas auf 2 Dreiecke/Pixel runterzutessellieren (entspricht einem Vertex pro Pixel, also der maximal möglichen sichtbaren Geometrieabtastung) und mit Domainshader entsprechend zu transformieren?
Deswegen hat nVidia auch zwei Limitierungen: Das Front-End und der Rest (aus meiner Sicht die Rechenarchitektur). Bei geringer Anzahl an erzeugten Dreiecken wird nie das Front-End limitieren. Erst ab einem gewissen Punkt verlagert sich der Limitierungsbereich weg vom Rest auf das Front-End. Deswegen wird der Abstand zwischen nVidia und AMD bei zunehmenden Tessellation auch größer
Nvidia hat zwei Limits: Speicherzugriffe und Rechenoperationen. SCNR.
Aber mal im Ernst, was gehört bei Dir zum Frontend? Und wie limitiert das bei Tessellation?
Meiner Meinung nach limitiert bei nv recht selten das Frontend, sondern meist der Shadercore/Backend (wenn man jetzt mal die Zeiten unberücksichtigt läßt, die vertrödelt werden, wenn ein neuer Drawcall kommt). Ja, auch bei Tessellation. Mit steigender Anzahl der Deiecke steigt der Aufwand für die Domain- und Geometry-Shader (grob linear zur Anzahl der erzeugten Dreiecke) und kann schlußendlich eine erkleckliche Rechenlast darstellen. Die Rasterizer können bis zu 4 Dreiecke pro Takt verarbeiten und bei kleinen Dreiecken also 16 Fragments pro Takt an den Shadercore zurückreichen (und bei kleinen tun sie das auch fast, und 12 Milliarden Fragments pro Sekunde sind eine ganze Menge; daß nicht genau vier Tris/Takt geschafft werden, liegt übrigens auch daran, daß Dreiecke, die Quads in mehreren Rastertiles berühren, durch alle beteiligten Rastereinheiten laufen müssen). Und natürlich muß nach dem Rasterizer alles noch durch die Pixelshader, die ROPs sowie eventuell das Postprocessing, alles nix Frontend. An dessen Limit kommst Du bei GF100 kaum hart ran, wenn Du irgendwas halbwegs Forderndes in den ganzen Shadern machen willst.
Das ist schon ein wenig anders als bei den Radeons, wo es anscheinend momentan zwar mit der Ausführung der Hull-/Domainshader hakt, allerdings weil das Frontend das nicht so gut managen kann. Das Zusammenspiel Commandprocessor/Scheduler scheint aus dem Tritt zu kommen weil das Verteilen des von einem Vertex-/Hullshader verarbeiteten und dann tessellierten Patches oder besser der so neu erzeugten Dreiecke auf die SIMDs nicht klappt. Die müssen auch auf dem gleichen SIMD durch den Domainshader laufen, ergo ein mangelndes Load-Balancing der Shaderlast. Zudem bricht es stärker ein, wenn viele Daten übergeben werden müssen => offenbar kleine Puffer/niedrige Bandbreite), weswegen das dann im Vergleich relativ mies läuft. Aber hier soll es ja um zukünftige nVidia-GPUs gehen.
Dieses Problem hat nv aber wie schon gesagt bereits erschlagen, so daß es dort eben nicht mehr hängt. Genau deswegen ziehen die GF100 bei steigenden Tessfaktoren den Radeons weg. Eben weil bei ihnen meist kein FrontEnd-Limit vorliegt. Du kannst mit gewissem Recht auch sagen, daß bei Fermi Teile des traditionellen Frontends in den Shadercore gewandert sind und auch mit diesem skalieren. Das ist genau das, was Du mit Deinen "16 unabhängigen Geometriepipelines" meinst, genau jeder SM hat eine und kann parallel zu den anderen arbeiten. Und nvidia hat auch gleich für eine angemessene Dimensionierung gesorgt. Dieses prinzipielle Problem ist also bereits recht nachhaltig gelöst worden. Im Prinzip muß nvidia nur die Anzahl der SMs/GPCs vergrößern und das Netzwerk dazwischen (zum Verteilen der Daten) entsprechen mitwachsen lassen, wenn sie mehr Geometrie verarbeiten wollen. Und mehr Shadereinheiten wird man ja wohl sowieso bekommen.
Eine Entlastung von der bei kleinen Dreiecken zu einem beträchtlichen Teil unnützen Pixelshaderlast (dieses Quad-Merging z.B. würde auch die ROPs entlasten) wäre demzufolge bei nvidia bei ansonsten ungeänderter Architektur sogar ein deutlicherer Vorteil als für die Radeons (die relativ gesehen ein paar mehr Quads unnütz verballern könnten, ohne das es viel kostet). Deswegen erwarte ich auch von nvidia, daß sie dieses Problem spätestens mit Maxwell angehen.
Was ist bitte "schnell genug"?Ich hatte wirklich überlegt, noch ein "gemessen an der Shaderleistung" dazuzusetzen. Dachte dann aber wohl fälschlicherweise, daß sich das von selbst versteht. :redface:
@mapel110:
Sub-20nm (28 => 20 => 14nm), wird das nicht der Prozeß des Nachfolgers von Maxwell? Gibt's da schon einen Codenamen? Planck? :wink:
Eine Entlastung von der bei kleinen Dreiecken zu einem beträchtlichen Teil unnützen Pixelshaderlast (dieses Quad-Merging z.B. würde auch die ROPs entlasten) wäre demzufolge bei nvidia bei ansonsten ungeänderter Architektur sogar ein deutlicherer Vorteil als für die Radeons (die relativ gesehen ein paar mehr Quads unnütz verballern könnten, ohne das es viel kostet). Deswegen erwarte ich auch von nvidia, daß sie dieses Problem spätestens mit Maxwell angehen.
Das Problem daran ist, das Quad-Merging eigentlich gegen die Render-Regeln verstößt. Evtl. geht das nur mit einer neuen API, die sowas zulässt.
Gipsel
2011-05-26, 03:48:43
Das Problem daran ist, das Quad-Merging eigentlich gegen die Render-Regeln verstößt. Evtl. geht das nur mit einer neuen API, die sowas zulässt.
Ich weiß (die gehen ja auf die möglichen Abweichungen auch ein). Die Präsentation damit war nur ein Vorschlag zur Erweiterung der DX11-Pipeline um zwei weitere Stufen, also sowas wie ein hypothetisches DX11.5 meinetwegen. Das geht natürlich auch anders.
Eine Prämisse dort war ja, daß man mit möglichst geringen Änderungen an der Pipeline auskommen will, nur eben die bisher bestehenden Nachteile für kleine Dreiecke möglichst einfach zu mindern. Im Einzelnen wollte man die bisher bestehende Quadstruktur beibehalten.
Ehrlich gesagt glaube ich nicht daran, daß das so kommt (deswegen habe ich das Wort "Vorschlag" öfter mal betont). Ich denke momentan, daß man eher die Quads an sich auflockert. Ich habe das vorhin schon mal (und auch schon vor einiger Zeit im GF100-Thread) angesprochen, daß man im Prinzip mit ein wenig gutem Willen schon bei GF100 erste Schritte in die Richtung erkennen kann. Am auffälligsten ist vielleicht, daß die logische Breite der SIMDs nicht mehr 4x die physische Breite wie bei allen vorher existierenden GPUs ist (ein Quad wird von einer Einheit in vier aufeinanderfolgenden Takten abgearbeitet), sondern nur noch 2x (ein Quad in nur 2 Takten in zwei nebeneinander liegenden Einheiten, daher können die die entsprechende Logik immer noch teilen). Die TMUs können nicht nur ein Textur(quad, was eventuell noch for free bilinear interpoliert wird) um eine Adresse lesen sondern alternativ auch (allerdings ohne Interpolation) von zwei unterschiedlichen Adressen (ist die Grundlage für die verdoppelte Performance des Fermi bei 4offset_gather4). Diese Adressen sind zwar (noch?) nicht völlig unabhängig, der maximale Offset von (momentan?) +-64 Texel dürfte aber bei benachbarten Dreiecken meist reichen (ja ich weiß, ist so noch nicht universell einsetzbar). Und fordert DX11 nicht sogar schon die Möglichkeit zur Berechnung von Gradienten (die klassischerweise mit Quadgranularität erfolgt) mit Pixelgranularität? Ich dachte, ich hätte das mal irgendwo gesehen (HD5k aufwärts kann das).
Will sagen, warum sollte Maxwell nicht z.B. die Abarbeitung in "Duads" beherrschen? Sprich, die Rasterizer spucken keine Fragment-Quads mehr aus, sondern nur noch Pärchen. Halbiert die Verschwendung, allerdings auch die Größe der garantiert sequentiellen Speicherzugriffe, was mehr Last auf die Caches legt. Aber da hat nvidia ja auch angefangen, andere Wege zu beschreiten.
LovesuckZ
2011-05-26, 11:48:39
:freak:
Am besten fragst Du mal bei Coda nach, wie er das mit dem "beliebig skalierbar" im Zusammenhang mit "NVIDIA ist mit dem Thema eh praktisch durch" wohl gemeint hat. ;)
Wieso sollte ich bei Coda nachfragen, weil du fremde Werke für deine Agenda missbrauchst? Wie pervers ist das denn?
Coda spricht von was vollkommen anderes als wir beide. Ich habe sein Posting in Bezug auf das von Hugo verstanden. Du anscheinend nicht...
:freak:
Für die verfügbare Shaderleistung ist das beinahe Overkill (deswegen GEOD ;)). Wenn da eine nur halbwegs der Shaderleistung entsprechende Steigerung in Zukunft erfolgt (was durch die skalierbare Architektur fast notgedrungen erfolgen wird, da das ja praktisch automatisch mit der Anzahl der SMs bzw. GPCs skaliert), dann wird das kein wesentliches Problem werden. Nvidia ist mit dem Thema erstmal durch, wie Coda das ausdrückte.
Hier kommt das Problem zum Tragen, dass du den Begriff "skalierbar" nicht verstanden hast. Wird die selbe Architektur nach oben skaliert, ändert sich nichts am Bild und am Problem an sich. Es wird nur schneller, wodurch die Problematik abgemindert wird. Siehe dazu auch GTS450 -> GTX580.
Nein. Eine Geforce benötigt sogar Tessellation, um überhaupt auf seine maximale Dreiecksrate zu kommen. Wie soll das ein Problem sein?
Ich habe das Problem hier bereits dargelegt.
Aber mal im Ernst, was gehört bei Dir zum Frontend? Und wie limitiert das bei Tessellation?
OnChip-Memory, Geometrieeinheiten, Rasterizer. Es limitiert im übertragenden Sinn der selbe Bereich wie bei AMD.
Meiner Meinung nach limitiert bei nv recht selten das Frontend, sondern meist der Shadercore/Backend (wenn man jetzt mal die Zeiten unberücksichtigt läßt, die vertrödelt werden, wenn ein neuer Drawcall kommt).
Ja, auch bei Tessellation. Mit steigender Anzahl der Deiecke steigt der Aufwand für die Domain- und Geometry-Shader (grob linear zur Anzahl der erzeugten Dreiecke) und kann schlußendlich eine erkleckliche Rechenlast darstellen
Ich bitte um Beweise, dass das Front-End die Dreiecke so schnell erzeugen kann, dass die Recheneinheiten zur Limitierung werden. Ich siehe dies leider in keiner Anwendung, die mir zur Verfügung steht.
Das ist schon ein wenig anders als bei den Radeons, wo es anscheinend momentan zwar mit der Ausführung der Hull-/Domainshader hakt, allerdings weil das Frontend das nicht so gut managen kann. Das Zusammenspiel Commandprocessor/Scheduler scheint aus dem Tritt zu kommen weil das Verteilen des von einem Vertex-/Hullshader verarbeiteten und dann tessellierten Patches oder besser der so neu erzeugten Dreiecke auf die SIMDs nicht klappt. Die müssen auch auf dem gleichen SIMD durch den Domainshader laufen, ergo ein mangelndes Load-Balancing der Shaderlast. Zudem bricht es stärker ein, wenn viele Daten übergeben werden müssen => offenbar kleine Puffer/niedrige Bandbreite), weswegen das dann im Vergleich relativ mies läuft. Aber hier soll es ja um zukünftige nVidia-GPUs gehen.
Ergo: Es limitiert das Front-End, was dazu führt, dass AMD nie in dein angebliches schwerwiegendes Problem laufen wird. Haben wir das also auch geklärt.
Dieses Problem hat nv aber wie schon gesagt bereits erschlagen, so daß es dort eben nicht mehr hängt. Genau deswegen ziehen die GF100 bei steigenden Tessfaktoren den Radeons weg. Eben weil bei ihnen meist kein FrontEnd-Limit vorliegt.
Diese Schlussfolgerung ist falsch. Das Beispiel aus dem SDK zeigt, dass Fermi mit steigender Last ebenfalls einbricht. Das weist klar auf eine Limitierung im Front-End hin und nicht auf eine entstehende Ineffizienz im Back-End Bereich. Die abfallende Kurve nimmt nirgendwo ein Knicks, der eine Limitierungsänderung kennzeichnet - siehe z.B. AMD mit fehlendem OffChip Buffering.
Ich hatte wirklich überlegt, noch ein "gemessen an der Shaderleistung" dazuzusetzen. Dachte dann aber wohl fälschlicherweise, daß sich das von selbst versteht. :redface:
Auch das wäre eine Platitüde gewesen. Was soll "schnell genug gemessen an der Shaderleistung" bedeuten? Das Fermi zu wenig Rechenleistung für "moderates" Tessellation hat, ist bekannt. Wir reden jedoch über den limitierenden Faktor, wenn Tessellation mit hohen Faktoren eingesetzt wird. Und hier zeigen Zahlen aus realen Anwendungen, dass mehr Geometrieeinheiten und wohl auch mehr onChip Speicher benötigt wird. Du ignorierst zwar meine Beispiele, aber es ist wichtig anhand dieser zu zeigen, was Sache ist: In Stone Giant verliert Fermi von off -> high knapp 25% an Leistung, wenn kein erweitertes DoF aktiviert wird. Es limitiert also klar die Geometrieerzeugung (Tessellation, Berechnung von Hull/Domain-Shader). Wird die Last für das Back-End erhöht (aus meiner Sicht den Recheneinheiten), dann ist der Einbruch deutlich geringer. Erweitertes DoF kostet auf einer GTX580 knapp 50% an Leistung. Aktiviert man nun Tessellation von off -> high brechen die Frames im Durchschnitt um maximal 10%. Das ist wohl der Anteil, den die Hull/Domain-Berechnungen benötigen. Die reine Erzeugung und das Umherschicken ist kein limitierender Faktor. Gleichzeitig stellt sich auch keine Ineffizienz aufgrund zu kleiner Dreiecke ein, da der Einbruch ansonsten höher sein müsste. Wir kommen also zu dem Punkt, dass das Front-End nur dann limitiert, wenn wir viele Dreiecke aus einem geringen Basemash mit hohen Faktoren erzeugen ohne eine hohe Last auf den Recheneinheiten anliegen zu haben. Da dies vorallem in Spielen so nicht eintreten wird, ist es vorallem die Rechenleistung, die limitiert. Nicht, weil es zukleine Dreiecke werden, sondern weil die ganzen anderen heutigen Effekte noch berechnet werden.
Du redest hier ein Problem daher, dass niemanden tangiert. AMD-Karten sind generell zu langsam, um überhaupt in vernünftigen Maße diese Dreiecke erzeugen zu können und den nVidia-Karten fehlt einfach die Rechenleistung, um in spielbare Bereiche mit allen Effekten zu kommen.
Ich weiß (die gehen ja auf die möglichen Abweichungen auch ein). Die Präsentation damit war nur ein Vorschlag zur Erweiterung der DX11-Pipeline um zwei weitere Stufen, also sowas wie ein hypothetisches DX11.5 meinetwegen. Das geht natürlich auch anders.
Eine Prämisse dort war ja, daß man mit möglichst geringen Änderungen an der Pipeline auskommen will, nur eben die bisher bestehenden Nachteile für kleine Dreiecke möglichst einfach zu mindern. Im Einzelnen wollte man die bisher bestehende Quadstruktur beibehalten.
Ehrlich gesagt glaube ich nicht daran, daß das so kommt (deswegen habe ich das Wort "Vorschlag" öfter mal betont). Ich denke momentan, daß man eher die Quads an sich auflockert. Ich habe das vorhin schon mal (und auch schon vor einiger Zeit im GF100-Thread) angesprochen, daß man im Prinzip mit ein wenig gutem Willen schon bei GF100 erste Schritte in die Richtung erkennen kann. Am auffälligsten ist vielleicht, daß die logische Breite der SIMDs nicht mehr 4x die physische Breite wie bei allen vorher existierenden GPUs ist (ein Quad wird von einer Einheit in vier aufeinanderfolgenden Takten abgearbeitet), sondern nur noch 2x (ein Quad in nur 2 Takten in zwei nebeneinander liegenden Einheiten, daher können die die entsprechende Logik immer noch teilen). Die TMUs können nicht nur ein Textur(quad, was eventuell noch for free bilinear interpoliert wird) um eine Adresse lesen sondern alternativ auch (allerdings ohne Interpolation) von zwei unterschiedlichen Adressen (ist die Grundlage für die verdoppelte Performance des Fermi bei 4offset_gather4). Diese Adressen sind zwar (noch?) nicht völlig unabhängig, der maximale Offset von (momentan?) +-64 Texel dürfte aber bei benachbarten Dreiecken meist reichen (ja ich weiß, ist so noch nicht universell einsetzbar). Und fordert DX11 nicht sogar schon die Möglichkeit zur Berechnung von Gradienten (die klassischerweise mit Quadgranularität erfolgt) mit Pixelgranularität? Ich dachte, ich hätte das mal irgendwo gesehen (HD5k aufwärts kann das).
Will sagen, warum sollte Maxwell nicht z.B. die Abarbeitung in "Duads" beherrschen? Sprich, die Rasterizer spucken keine Fragment-Quads mehr aus, sondern nur noch Pärchen. Halbiert die Verschwendung, allerdings auch die Größe der garantiert sequentiellen Speicherzugriffe, was mehr Last auf die Caches legt. Aber da hat nvidia ja auch angefangen, andere Wege zu beschreiten.
Das wird nicht passieren.
Du kannst die Gradienten nur mit Quads berechnen. Es gibt mit abhängigen Texture-Fetches keine andere Alternative, außer du zwingst die Entwickler dazu, diese explizit zu berechnen und anzugeben.
Gipsel
2011-05-26, 15:55:26
Och LS! Natürlich hat Hugo78 von Tess geredet, sogar sehr explizit (letzter Satz):
die werden sich um andere Dinge mit Kepler kümmern, als Tess.Was Coda dann noch bekräftigt hat, daß nv "mit dem Thema eh praktisch durch" ist. Wenn Du nicht verstehst, was die Leute hier schreiben, frage sie am besten per PM, aber deute nicht einfach deren Aussagen in was Entgegengesetztes um (wie Du das auch bei meinen Aussagen immer wieder tust).
Und daß eher die Shaderlast/Füllrate limitieren (was wie gesagt durch die Quadstrukturen verschärft wird), siehst Du in praktisch jeder Anwendung mit entsprechend aufwendigen Shadern, nur in einfachen Dreiecksdurchsatztests nicht (die kaum mehr machen, als alle Daten einfach durchzuschleifen) kommst Du ans Frontend-Limit. Und selbst da hängst Du im Prinzip auch oft schon verdammt dicht an der Füllrate (man muß ja bedenken, daß ein durchschnittliches 2 Pixel-Dreieck, im Mittel schon beinahe 2 Quads belegt, also vielleicht 6 bis 7 Fragments erzeugt, die geshadet und durch die ROPs wollen). Du siehst ja bei fast leeren Shadern sogar schon einen Einfluß der Attributinterpolation (von den Shadereinheiten gemacht), mit mehr Attributen wird es etwas langsamer als mit wenigen/einfachen. Das spielt sich aber in einem Bereich ab (>1 Millarde Tris/s), den man sowieso nicht mehr im Guten mit realistischer Shaderlast durchgeschleust bekommen würde (bzw. wenn der Early-Z-Test das Ganze verwirft, liegt die Grenze noch höher, aber dann kommt das ja auch nicht mehr in die Shaderpipes zurück).
Im Prinzip zeigen doch sogar Deine Zahlen von dieser einen nv-Techdemo das Gleiche aus (kann man bestimmt mal einfach modellieren), wie Du ja sogar zwischendurch selbst gesagt hast:
Laut der Techdemo von nVidia bricht die FPS Zahl einer GTX460 von 175 FPS (mit 400k tris/s) über 94 FPS (2,4M tris/s) auf 35 FPS (14M tris/s) ein. Wir reden von Faktor 6x bzw. 35x zusätzlicher Dreiecke. Es limitiert also bei nVidia sowieso erst die Rechen-, Pixel- und/oder Texturleistung.Ganz genau. Kommt es nur mir so vor, daß Du irgendwie inkohärent kreuz und quer argumentierst? Z.B. jetzt wieder:
Ich bitte um Beweise, dass das Front-End die Dreiecke so schnell erzeugen kann, dass die Recheneinheiten zur Limitierung werden. Ich siehe dies leider in keiner Anwendung, die mir zur Verfügung steht.
Insgesamt scheinst Du Dir immer wieder selbst zu widersprechen, z.B. beim Vergleich:
Diese Schlussfolgerung [kein wesentliches Frontend-Limit] ist falsch. Das Beispiel aus dem SDK zeigt, dass Fermi mit steigender Last ebenfalls einbricht. Das weist klar auf eine Limitierung im Front-End hin und nicht auf eine entstehende Ineffizienz im Back-End Bereich. Die abfallende Kurve nimmt nirgendwo ein Knicks, der eine Limitierungsänderung kennzeichnet
Deswegen hat nVidia auch zwei Limitierungen: Das Front-End und der Rest (aus meiner Sicht die Rechenarchitektur). Bei geringer Anzahl an erzeugten Dreiecken wird nie das Front-End limitieren. Erst ab einem gewissen Punkt verlagert sich der Limitierungsbereich weg vom Rest auf das Front-End.
Schlußfolgerung aus Deinen Ausführungen wäre eigentlich: kein Frontend-Limit. Wobei das prinzipielle Verhalten recht ähnlich ist, nur mit unterschiedlichen Vorfaktoren für die einzelnen Einflüsse (Du vergißt wahrscheinlich, daß die Domain- und Geometry-Shaderlast linear mit der Anzahl der Dreiecke steigt!). Bei einem Frontend-Limit läuft man normalerweise also früher und demzufolge auch steiler rein. Also z.B wie man das hier an den Zahlen für dein erwähntes SDK-Sample erkennen kann (Dreieckszahl skaliert quadratisch mit der "subdivision"):
http://www.abload.de/img/dx-sdk-subd11-samplegs94.png
Es limitiert also klar die Geometrieerzeugung (Tessellation, Berechnung von Hull/Domain-Shader). Wird die Last für das Back-End erhöht (aus meiner Sicht den Recheneinheiten), dann ist der Einbruch deutlich geringer.Absolut gesehen (frame rendering time) dürfte er aber vermutlich grob genau so groß sein. Relative Leistungseinbrüche zu vergleichen, bringt bei so was nicht viel. Das hatte ich Dir in einem anderen Thread auch schon mal gesagt.
Außerdem schwant mir gerade was. Ich hatte nicht umsonst gefragt, was Du unter dem Frontend verstehst. Der Shadercore ist es nämlich schon mal nicht. Auf dem werden ja auch die Vertex-/Hull-/Domain-/Geometryshader ausgeführt. Wenn also irgendwann die Rechenleistung für einen aufwendigen Domain- oder Geometryshader ausgeht, würde das wohl kaum einer als Frontend-Limit bezeichnen. Die werden aus dem gleichen Rechenleistungsbudget wie auch die Pixelshader bedient. Wahrscheinlich geht deswegen Deine Argumentation irgendwie in die Richtung 'Recheneinheiten limitieren, das ist ein Frontend-Problem'.
War eine schwere Geburt, aber gut, daß wir das jetzt geklärt haben. :)
Aktiviert man nun Tessellation von off -> high brechen die Frames im Durchschnitt um maximal 10%. Das ist wohl der Anteil, den die Hull/Domain-Berechnungen benötigen. Die reine Erzeugung und das Umherschicken ist kein limitierender Faktor. Gleichzeitig stellt sich auch keine Ineffizienz aufgrund zu kleiner Dreiecke ein, da der Einbruch ansonsten höher sein müsste.Und wie hältst Du die mit der Anzahl der Dreiecke steigende Shaderlast in DS und GS von der ebenfalls mit der Dreieckszahl steigenden Shaderlast in den Pixelshadern auseinander? Das ändert sich doch bei DOF an oder aus nicht. Außerdem hatte ich auch schon mal erwähnt, daß DOF bei einem deferred shader afaik beim final compositing berechnet wird, welches dadurch nicht beeinflußt wird.
So, dann jetzt mal wieder zu den drängenderen Problemen von Kepler/Maxwell.
Gipsel
2011-05-26, 16:04:14
Das wird nicht passieren.
Du kannst die Gradienten nur mit Quads berechnen. Es gibt mit abhängigen Texture-Fetches keine andere Alternative, außer du zwingst die Entwickler dazu, diese explizit zu berechnen und anzugeben.
Oder die GPUs duplizieren die Berechnungen bei Bedarf intern (also bei kleinen Dreiecken, ansonsten kann man sich die Daten teilen, k.A. ob es günstiger ist, das zweimal zu berechnen oder über eine Datenleitung das Ergebnis zu schicken). Daß das nicht umsonst geht, ist schon klar. Die Frage ist, wie schätzt nvidia die Anforderungen an eine GPU mit einem Transistorbudget von vielleicht grob 12 Milliarden Transistoren in 20nm im Jahre 2014 ein. Mit so einem Teil sollten die meisten low-Poly-Anwendungen schon totzuschlagen sein ;). Aber ich dachte, das Ziel am Horizont seien z.B. 1-2 Dreiecke pro Pixel.
Oder die GPUs duplizieren die Berechnungen bei Bedarf intern (also bei kleinen Dreiecken, ansonsten kann man sich die Daten teilen, k.A. ob es günstiger ist, das zweimal zu berechnen oder über eine Datenleitung das Ergebnis zu schicken).
Führ bitte mal genauer aus was du meinst. Was duplizieren? Welche Daten teilen?
LovesuckZ
2011-05-26, 17:54:48
Och LS! Natürlich hat Hugo78 von Tess geredet, sogar sehr explizit (letzter Satz):
Was Coda dann noch bekräftigt hat, daß nv "mit dem Thema eh praktisch durch" ist. Wenn Du nicht verstehst, was die Leute hier schreiben, frage sie am besten per PM, aber deute nicht einfach deren Aussagen in was Entgegengesetztes um (wie Du das auch bei meinen Aussagen immer wieder tust).
Nochmal: Du verstehst das Problem nicht. Du zitierst Leute, die mit unserer Diskussion nichts zu tun, haben, da wir über ein komplett anderes Thema sprechen. Wieso sollte ich Coda und Hugo um eine Erklärung bitten, wenn du derjenige bist, der weder unsere Diskussion noch deren Postingzusammenhang verstanden hat?
Weder Hugo noch Coda haben dich in deiner Aussage, dass nVidia schnell genug sehr viele und voralle kleine Dreiecke mit hohem Faktor und der jetzigen GF110 Architekturausprägung ohne Zeitverlust erzeugen könnte, bestätigt. Dein fehlendes Leseverständnis und vorhandener Fanatismus (http://de.wikipedia.org/wiki/Fanatismus) führt dazu, dass du Inhalte erkennen willst, die nicht vorhanden sind.
Im Prinzip zeigen doch sogar Deine Zahlen von dieser einen nv-Techdemo das Gleiche aus (kann man bestimmt mal einfach modellieren), wie Du ja sogar zwischendurch selbst gesagt hast:
Die Zahlen zeigen, dass man das Geometrieniveau "exorbitant steigern" kann ohne dass es eine "steigende Ineffizienz der heutigen quadbasierten Renderer zur Folge [hätte], die die effektiv verfügbare Shaderleistung drastisch mindert, ohne die Grafikqualität noch merklich (bei einem Echtzeitrenderer) anzuheben." Deine Erklärungen ignorieren den Fakt, das keine heutige Architektur für die Erzeugung von vielen Dreiecken mit hohen Faktor gebaut wurde.
Ganz genau. Kommt es nur mir so vor, daß Du irgendwie inkohärent kreuz und quer argumentierst? Z.B. jetzt wieder:
Insgesamt scheinst Du Dir immer wieder selbst zu widersprechen, z.B. beim Vergleich:
Ich habe es schonmal gesagt: Nur im Kontext zitieren. Ich weiß, dass die Moderation dir einen Freischein für solch ein Verhalten gegeben hat, aber unterlasse es doch einfach. Wenn du Zusammenhänge in Texten nicht verstehst, solltest du vielleicht mal überlegen, ob ein Internetforum nicht der falsche Ort für Diskussion für dich ist. Ich wiederum habe keine Lust, mein geschriebenes zu wiederholen, weil dein Fanatismus (http://de.wikipedia.org/wiki/Fanatismus) dazu führt, dass nur Teilsätze und einzelne Wörter von Bedeutung sind. Kontext ist das Schlagwort.
Schlußfolgerung aus Deinen Ausführungen wäre eigentlich: kein Frontend-Limit. Wobei das prinzipielle Verhalten recht ähnlich ist, nur mit unterschiedlichen Vorfaktoren für die einzelnen Einflüsse (Du vergißt wahrscheinlich, daß die Domain- und Geometry-Shaderlast linear mit der Anzahl der Dreiecke steigt!). Bei einem Frontend-Limit läuft man normalerweise also früher und demzufolge auch steiler rein. Also z.B wie man das hier an den Zahlen für dein erwähntes SDK-Sample erkennen kann (Dreieckszahl skaliert quadratisch mit der "subdivision"):
Diese "steilen Punkte" gibt es ebenfalls bei nVidia. Zum Ende der Skala ist das Linienverhalten annährend gleich. Nimmt man dazu die Werte der GTS450, liegt bei nVidia hier ebenfalls eine Limitierung des Frontends vor. Die Karte kann maximal 520 Million Dreiecke/s erzeugen und hat 610 GFLOPs. Vorallem bei der Rechenleistung erreicht man nur 1/4 von einer 6970. Deiner Argumentation folgend würde bei Fermi die Rechenleistung limitieren. Wenn dies stimmen würde, müsste die GTS450 langsamer als die AMD Karten werden. Das geschieht nicht. Der Vergleich mit der GTX580 offenbart dabei sogar, dass der Abstand größer statt kleiner wird. Von 3,3x zu ca. 4,2x - was dem Unterschied in der Geometrie statt der Rechenleistung zeigt.
Absolut gesehen (frame rendering time) dürfte er aber vermutlich grob genau so groß sein. Relative Leistungseinbrüche zu vergleichen, bringt bei so was nicht viel. Das hatte ich Dir in einem anderen Thread auch schon mal gesagt.
Absolut gesehen stimmt das genauso wenig. 10% von ca. 50 FPS sind absolut ebenfalls weniger wie 25% von 100 FPS.
Außerdem schwant mir gerade was. Ich hatte nicht umsonst gefragt, was Du unter dem Frontend verstehst. Der Shadercore ist es nämlich schon mal nicht. Auf dem werden ja auch die Vertex-/Hull-/Domain-/Geometryshader ausgeführt. Wenn also irgendwann die Rechenleistung für einen aufwendigen Domain- oder Geometryshader ausgeht, würde das wohl kaum einer als Frontend-Limit bezeichnen. Die werden aus dem gleichen Rechenleistungsbudget wie auch die Pixelshader bedient. Wahrscheinlich geht deswegen Deine Argumentation irgendwie in die Richtung 'Recheneinheiten limitieren, das ist ein Frontend-Problem'.
Ich habe hier doch Werte aus Stone Giant und 3DMark2011 angebracht, die zeigen, dass mit erhöhter Last auf den Recheneinheiten durch zusätzliche Effekte die Latenz für die Erzeugung und Versendung der Dreiecke nicht mehr ins Gewicht fällt und einzig und allein noch die benötigte Kapazität für Hull-,Domain- und von mir aus Geometrie-Shader sich auswirken.
Und wie hältst Du die mit der Anzahl der Dreiecke steigende Shaderlast in DS und GS von der ebenfalls mit der Dreieckszahl steigenden Shaderlast in den Pixelshadern auseinander? Das ändert sich doch bei DOF an oder aus nicht. Außerdem hatte ich auch schon mal erwähnt, daß DOF bei einem deferred shader afaik beim final compositing berechnet wird, welches dadurch nicht beeinflußt wird.
Die Ausgabezeit eines Frames mit DoF in Stone Giant verdoppelt sich. Es spielt bei der Betrachtung keine Rolle, welcher Teil der Architektur für die Verdopplung der Zeit verantwortlich ist. Fakt ist, dass das Aktivieren von Tessellation darüber hinaus nur noch für eine ca. 10% längere Bearbeitungsdauer verantwortlich ist. Diese ist deutlich geringer, als wenn kein DoF aktiviert wurde.
Dieses Verhalten lässt sich im 3DMark2011 und der Endless City Demo von nVidia nachstellen.
LS kannst du bitte mal aufhören mich "Cuda" zu nennen :ugly:
N0Thing
2011-05-26, 18:09:16
So kann man nebenbei noch product placement betreiben. :D
LovesuckZ
2011-05-26, 18:10:15
LS kannst du bitte mal aufhören mich "Cuda" zu nennen :ugly:
Arg, sry. Ich werde es rauseditieren.
Gipsel
2011-05-27, 15:47:45
Führ bitte mal genauer aus was du meinst. Was duplizieren? Welche Daten teilen?
Nun, es ging doch um die Gradienten, oder? Nehmen wir die Texturkoordinaten als Beispiel, da liefert die Interpolation für jeden Pixel die Koordinaten, die Gradienten (die MipMap-Level und AF-Grad bestimmen) ergeben sich dann aus den Differenzen im Quad. Die werden also nur mit Quadgranularität berechnet, was Aufwand spart. Wenn man keine Quads mehr hat, geht das so natürlich nicht. Da hast Du vollkommen Recht.
Es gibt jetzt mehr oder weniger zwei Fälle. Man hat etwas größere Deiecke, so daß sowieso 2x2 Pixel wieder zu einem Dreieck gehören. Dann können zwei benachbarte "Duads" (oder auch 4 einzelne Fragmente) ihre Texturkoordinaten austauschen und die Gradienten wieder ganz genau so bestimmt werden wie jetzt auch schon, die Quads werden praktisch "dynamisch" gebildet (man könnte das vielleicht auch als virtuelle Quads bezeichnen), am Renderoutput ändert sich rein gar nichts zu heute. Der einzige Unterschied wäre, daß man ein Befehl für ein Quad nicht mehr auf 4 Takte verteilt in einer Einheit laufen läßt, sondern eben auf 2 oder 4 Einheiten (physisch nebeneinander liegende) verteilt. Diese Einheiten können auf die Texturkoordinaten der benachbarten Einheiten zugreifen, so daß sich die Gradienten ohne Mehraufwand (außer Datenaustausch) ermitteln lassen.
An Dreieckskanten (oder allgemein bei kleinen Dreiecken) wird es aber passieren, daß die benachbarten Fragments nicht mehr zum gleichen Dreieck gehören, also nicht so einfach mitbenutzt werden können. Hier bräuchte man einen Hint vom Rasterizer, ob das der Fall ist oder nicht. Heutzutage setzt der Rasterizer auch für jedes Fragment eines Quads ein Bit, ob es noch im Dreieck liegt oder am Ende sowieso verworfen wird. Jetzt benötigt man halt ein einziges Bit, was einem Fragment sagt, ob das darüber oder darunter zum gleichen Dreieck gehört oder nicht. Wenn dies der Fall ist, siehe oben. Wenn nicht, muß die Interpolation eben ein wenig ausführlicher ausfallen (wird doch heute sowieso von den Shadern gemacht, sollte also kein problem sein, abhängig von einem gesetzten Bit zwei verschiedene Versionen laufen zu lassen) und zusätzlich die Texturkoordinaten für die benachbarten, aber eben nicht mehr dazu gehörenden Fragments ausspucken, damit das ganz genauso wie heute weiter gehen kann. Ein zusätzlicher Aufwand ist das dabei nicht. Die Berechnung muß bei Vorhandensein echter Quads ja genau so gemacht werden, allerdings belegt man eben dann unnütz Platz im weiteren Verlauf der Pixelshader. Diesen kann man jetzt sparen.
Perspektivisch kann man darüber nachdenken, ob man nicht die Interpolation/Gradienten-Berechnung sparsamer nutzen will. Bei kleinen Dreiecken (also diese 1 Vertex pro Pixel bzw. 0,5 Pixel pro Dreieck) wäre doch gewissermaßen flat shading (also keine Interpolation übers Dreieck, was ja irgendwie sinnlos wird, wenn es kleiner als ein Pixel ist) besser. Für die Texturierung (und Filterung), kann man im Prinzip die Gradienten jedes Fragments auch aus der Oberflächennormale bestimmen (sogar ziemlich einfach), ganz ohne Datenaustausch/-sharing mit benachbarten Fragments.
Wenn nicht, muß die Interpolation eben ein wenig ausführlicher ausfallen (wird doch heute sowieso von den Shadern gemacht)
Und genau da ist dein Denkfehler. Die Interpolation ist nur ein Shader-Input. Ich kann für jedes Fragment in einem Quad eine beliebige Berechnung machen um Texturkoordinaten zu erzeugen und die an einen Texture-Fetch übergeben. Die muss nichtmal von der Interpolation abhängig sein.
Die einzige Möglichkeit die bleibt um allgemein einen halbwegs passablen Gradienten zu finden ist deshalb mit Quads zu arbeiten.
Für die Texturierung (und Filterung), kann man im Prinzip die Gradienten jedes Fragments auch aus der Oberflächennormale bestimmen (sogar ziemlich einfach), ganz ohne Datenaustausch/-sharing mit benachbarten Fragments.
Kann man nicht. Der Gradient ist Abhängig von der Rotation, Skalierung und damit der Verzerrung der Textur und sonst von nichts. (Insbesondere ist deshalb auch AF nicht von einem "Winkel" abhängig, "winkelunabhängiges AF" müsste eigentlich "verzerrungsunabhängiges AF" o.ä. heißen).
Und wieder hast du immer noch die Denkweise drin als wäre Texturierung irgend ein Spezialfall, der direkt mit der Interpolation in Verbindung steht. Ist es nicht. Interpolation kann man dafür benutzen, wenn einem beliebt, muss man aber nicht.
Gipsel
2011-05-27, 18:44:06
Und genau da ist dein Denkfehler. Die Interpolation ist nur ein Shader-Input. Ich kann für jedes Fragment in einem Quad eine beliebige Berechnung machen um Texturkoordinaten zu erzeugen und die an einen Texture-Fetch übergeben. Die muss nichtmal von der Interpolation abhängig sein.Stimmt, das klappt nur, wenn man mit den vom Vertexshader (oder wo auch immer vor dem Rasterizer) zugewiesenen Texturkoordinaten arbeitet.
Kann man nicht. Der Gradient ist Abhängig von der Rotation, Skalierung und damit der Verzerrung der Textur und sonst von nichts. (Insbesondere ist deshalb auch AF nicht von einem "Winkel" abhängig, "winkelunabhängiges AF" müsste eigentlich "verzerrungsunabhängiges AF" o.ä. heißen).
Ja, allerdings ergibt sich die Verzerrung eben aus Rotation und Skalierung der Textur sowie der Orientierung der Oberfläche zur Kamera. Zumindest wenn man nicht die Texturkoordinaten im Pixelshader verbiegt (wofür der Grund häufig ist, eine andere Geometrie vorzutäuschen, was bei 1 Vertex/Pixel entfallen würde), sondern einfach nur möglichst korrekt eine Textur draufkleben will.
Allgemein muß man ja schon feststellen, daß die Berechnung im Quad wenig Sinn macht, wenn die dort herangezogenen Werte potentiell von ein oder zwei Dreiecksgrößen entfernten Orten stammen. Deswegen glaube ich schon, daß die Benutzung entweder der Oberflächennormalen (kann der Nutzer ja dann beliebig gestalten) oder vielleicht sogar die benachbarter Pixel, selbst wenn die zu einem anderen Dreieck gehören (bei tessellierten Patches mit halbwegs glatten Übergängen sollte das kein unlösbares Problem sein, Pixel verschiedener Dreiecke in ein Quad zu packen wie bei dem Quad-Merging, vielleicht kommt das ja doch ;)) eine Option werden kann. Aber das ist dann natürlich nicht mehr 100% kompatibel, benötigt also eine angepaßte Spezifikation.
Und wieder hast du immer noch die Denkweise drin als wäre Texturierung irgend ein Spezialfall, der direkt mit der Interpolation in Verbindung steht. Ist es nicht. Interpolation kann man dafür benutzen, wenn einem beliebt, muss man aber nicht.Ich wollte es eigentlich oben nur als Beispiel anführen. Ich habe "nur" nicht beachtet, daß es eben kein allgemeines Beispiel für die Gradientenberechnung ist (egal ob bei Texturierung oder was anderem).
Also Schlußfolgerung: Die Quads loszuwerden wird wohl nicht so einfach, wenn man den bisherigen Ablauf möglichst wenig ändern will. ;)
Ich bin da anderer Meinung. Die Quads funktionieren in sogut wie allen Fällen, bei denen man eine (annähernd) kontinuierliche Funktion für die Texturkoordinaten benutzt sehr gut.
Wenn die Werte weit auseinanderliegen, dann wird halt eine sehr kleine Mip verwendet. Wenigstens flimmert's nicht.
Gipsel
2011-05-28, 01:19:36
Ich bin da anderer Meinung. Die Quads funktionieren in sogut wie allen Fällen, bei denen man eine (annähernd) kontinuierliche Funktion für die Texturkoordinaten benutzt sehr gut.Daß es funktioniert, steht außer Frage. Die Sache ist eher, daß es ein wenig komisch aussieht, wenn man als Gradienten die Differenzen zwischen Punkten nimmt, die weiter auseinander liegen, als die Dreiecke in Zukunft wohl groß sein werden. Und die Interpolation über das Dreieck verliert irgendwie ihren Sinn (sie mutiert zur Extrapolation), wenn das Dreieck kleiner als ein Pixel wird (dann ist keine Interpolation - also flat shading - genau so gut).
Edit: Oder anders gesagt sollte man vielleicht die Interpolation in den Domainshader verlegen ;)
Diese ganze Quad-Geschichte stammt ja aus einer Zeit, als man damit Aufwand sparen konnte, weil eben 2x2 Pixel ziemlich sicher in einem Dreieck lagen. Diese Rechnung wird in Zukunft wohl anders ausfallen, da man sich dann zwar offensichtlich was Neues für die Gradienten überlegen muß (und Veränderungen sind oft schwer), aber nur wegen der Gradienten immer drei Fragments eines Quads am Ende zu verwerfen, kann auf Dauer irgendwie auch nicht die Lösung sein.
Im Prinzip könnte man das wohl auch so implementieren, daß die Quads nur erhalten bleiben, wenn man sie benötigt (also Shader nur mit Quads gemäß Spezifikation ausgeführt werden können). Wenn der JIT-Shader-Compiler feststellt, daß es auch ohne geht (z.B. weil im Pixelshader Gradienten explizit pro Pixel ausgerechnet werden), dann kann man die Quads kicken, also verschiedene Dreiecke in ein Quad packen. Schon heutige GPUs (von Radeons weiß ich es) führen in Fragments außerhalb eines Dreiecks nur die Instruktionen aus, die für die Gradientenberechnung notwendig sind, alle anderen werden über entsprechend gesetzte Kontrollbits maskiert (das macht der Shader-Compiler). Das führt dann zwar nicht zu einer Performancesteigerung (diese Fragments nehmen immer noch unnötig Platz ein), aber immerhin zu einem etwas verminderten Stromverbrauch. Falls also der JIT-Compiler festetellt, daß nie Fragments außerhalb des Dreiecks benötigt werden, könnte der Rasterizer dann in den "Single-Fragment-Mode" gehen.
Gipsel
2011-05-28, 02:40:03
In Stone Giant verliert Fermi von off -> high knapp 25% an Leistung, wenn kein erweitertes DoF aktiviert wird. [..] Erweitertes DoF kostet auf einer GTX580 knapp 50% an Leistung. Aktiviert man nun Tessellation von off -> high brechen die Frames im Durchschnitt um maximal 10%.
Absolut gesehen stimmt das genauso wenig. 10% von ca. 50 FPS sind absolut ebenfalls weniger wie 25% von 100 FPS.
DOF ist praktisch ein Postprocessing Effekt (wie schon mehrfach für deferred Shading erwähnt, allerdings ist es fast egal wie man's macht, wenn ich so darüber nachdenke, es stimmt eigentlich immer, bei StoneGiant wird es afaik mit einem Computeshader gemacht). Es gibt einen Serialisierungspunkt nach dem Shaden des letzten Dreiecks, vorher kann die GPU damit nicht anfangen. Das DOF streitet also nicht mit den Domainshadern um Rechenleistung, es packt einfach eine zusätzliche Anforderung hinten drauf ;).
Okay, also rechnen wir mal mit Deinen Zahlen für eine GTX480, die Du hier gepostet hast (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7985270#post7985270):
Tess aus, DOF aus: 87,35 fps, 11,45 ms Frametime
Tess aus, DOF an: 45,44fps, 22,01 ms Frametime
=> DOF kostet 10,56 ms
Tess medium, DOF aus: 77,68 fps, Frametime 12,87 ms
Tess medium, DOF an: 42,40 fps, Frametime 23,58 ms
=> DOF kostet 10,71 ms
Tess high, DOF aus: 68,85 fps, Frametime 14,52 ms
Tess high, DOF an: 39,43 fps, Frametime 25,36 ms
=> DOF kostet 10,84 ms
Hmm, Das sieht für mich irgendwie ziemlich konstant aus! Daß die Aktivierung von DOF bei kleinen Dreiecken tendenziell (hängt auch ein wenig von der jeweiligen Implementation ab) etwas teurer werden kann, liegt z.B. daran, daß z.T. in den Pixelshadern die Tiefeninformation nochmal zusätzlich anders codiert in einen Puffer (oder einen Kanal des Framebuffers) geschrieben wird (und man somit einen kleinen Anteil der sinkenden Quadauslastung auch in der oben dem DOF zugeschriebenen Zeit sieht) bzw. z.B. die Framebufferkompression für kleine Dreiecke an Effizienz verlieren kann (insbesondere bei AA, wenn der DOF-Algorithmus die einzelnen Samples berücksichtigt).
Diese Deine Zahlen stützen Deine These nicht. Können wir das jetzt also mal abschließen?
LovesuckZ
2011-05-28, 04:34:02
DOF ist praktisch ein Postprocessing Effekt (wie schon mehrfach für deferred Shading erwähnt, allerdings ist es fast egal wie man's macht, wenn ich so darüber nachdenke, es stimmt eigentlich immer, bei StoneGiant wird es afaik mit einem Computeshader gemacht). Es gibt einen Serialisierungspunkt nach dem Shaden des letzten Dreiecks, vorher kann die GPU damit nicht anfangen. Das DOF streitet also nicht mit den Domainshadern um Rechenleistung, es packt einfach eine zusätzliche Anforderung hinten drauf ;).
Die Erklärung macht null Sinn. Ein serieller Bottleneck kann nicht dadurch gelöst werden, indem am Ende mehr Last angelegt wird. DoF ist der entscheidene limitierende Faktor. Der Einbruch durch Tessellation entsteht durch das Sharing der Ressourcen.
Okay, also rechnen wir mal mit Deinen Zahlen für eine GTX480, die Du hier gepostet hast (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7985270#post7985270):
Tess aus, DOF aus: 87,35 fps, 11,45 ms Frametime
Tess aus, DOF an: 45,44fps, 22,01 ms Frametime
=> DOF kostet 10,56 ms
Tess medium, DOF aus: 77,68 fps, Frametime 12,87 ms
Tess medium, DOF an: 42,40 fps, Frametime 23,58 ms
=> DOF kostet 10,71 ms
Tess high, DOF aus: 68,85 fps, Frametime 14,52 ms
Tess high, DOF an: 39,43 fps, Frametime 25,36 ms
=> DOF kostet 10,84 ms
Hmm, Das sieht für mich irgendwie ziemlich konstant aus! Daß die Aktivierung von DOF bei kleinen Dreiecken tendenziell (hängt auch ein wenig von der jeweiligen Implementation ab) etwas teurer werden kann, liegt z.B. daran, daß z.T. in den Pixelshadern die Tiefeninformation nochmal zusätzlich anders codiert in einen Puffer (oder einen Kanal des Framebuffers) geschrieben wird (und man somit einen kleinen Anteil der sinkenden Quadauslastung auch in der oben dem DOF zugeschriebenen Zeit sieht) bzw. z.B. die Framebufferkompression für kleine Dreiecke an Effizienz verlieren kann (insbesondere bei AA, wenn der DOF-Algorithmus die einzelnen Samples berücksichtigt).
Die Werte sind alt. Mal neuere Zahlen mit meinem TRI-SLI System:
Tess aus, DOF aus: 234 fps, 4,27 ms Frametime
Tess aus, DOF an: 126 fps, 7,94ms Frametime
=> DOF erhöht die Dauer um 86% (3,67 ms)
Jetzt kommt das typische gipsel'sche Problem, dass Texte nicht verstanden werden. Ich rede davon, dass der Leistungseinbruch beim Aktivieren von Tessellation geringer wird, je mehr Last anliegt. Schauen wir uns also die Zahlen dazu an:
Tess aus, DOF aus: 234 fps, 4,27 ms Frametime
Tess high, DOF aus: 188 fps, 5,32 ms Frametime
=> Tess high erhöht die Dauer um 25% (1,05 ms)
Tess aus, DOF an: 126 fps, 7,94ms Frametime
Tess high, DOF an: 112 fps, 8,93 ms Frametime
=> Tess high erhöht die Dauer um 12% (0,99 ms)
Das Verwenden von absoluten Abstandswerten, die von unterschiedlichen Basen mit unterschiedlicher Relation ermitteln werden, ist für sich schon absurd. Aber bleiben wir dabei: Da selbst die absolute Frametimezunahme beim Aktivieren von Tessellation unter DoF geringer ist als im Fall ohne DoF, zeigt, dass DoF den limitierende Faktor darstellt. Wie man dies nicht sehen kann, ist mir ein Rätsel.
Diese Deine Zahlen stützen Deine These nicht. Können wir das jetzt also mal abschließen?
Ironischerweise hast du mit deinen Werten eigentlich nichts anderes gezeigt: DoF wird zum limitierenden Faktor.
Trotzdem ist dies eine bezeichnende Aussage. Ich habe nämlich das hier am Anfang über Stone Giant geschrieben:
Im Stone Giant verliert eine GTX480 beim Einsatz vom erweitertem DoF nur 15% an Leistung, wenn Tessellation von off -> high erhöht wird. Ohne [DoF] sind es 26%. Fermi hat überhaupt keine Probleme ein für heutige Verhältnisse hohes Niveau an Geometrie zu erzeugen, weil die zu Grunde liegende Rechenleistung viel zu gering ist.
Ich habe also nicht die Kosten von DoF gemeint, sondern die Kosten von Tessellation bei unterschiedlicher Last auf dem Back-End. Wir sind also an einem Punkt angekommen, der mit absoluter Sicherheit jedenfalls eins zeigt: Du bist in einem textbasierten Diskussionsforum ein Paradoxon (http://de.wikipedia.org/wiki/Paradoxon). Du kannst Texte nicht verstehen, was dazu führt, dass Diskussion eher einem Kreis entsprechend, wo man dir dauernd und dauernd und dauernd das geschriebene erklären muss. Du gehst auf Inhalte nicht ein und Aussagen werden vollkommen wirr und aus dem Kontext wiedergegeben.
Lass uns das abschließen. Ich denke, es macht keinen Sinn in Zukunft mit dir über solche Themen zu reden, da man davon ausgehen muss, dass nichts ankommt und Aussagen für den eigenen Fanatismus (http://de.wikipedia.org/wiki/Fanatismus) missbraucht werden.
Gipsel
2011-05-28, 06:43:58
Ich habe schon verstanden, was Du sagen wolltest. Du hast aber nicht verstanden, daß das so nicht funktioniert. DOF (wie auch MLAA und andere Postprocessing-Dinge) wirkt als praktisch konstanter Offset für die Frametimes, weshalb Du aus dem Vergleich Tess on/off mit und ohne DOF nichts lernen kannst. Prinzipiell geht das nicht. Die Tessellation, die Pixelshader, ja der komplette Rendervorgang merken eigentlich gar nichts davon ob DOF an oder aus ist. Erst wenn das komplett fertig ist, wird hinterher das DOF berechnet (deswegen heißt es auch Postprocessing ;)), weswegen sich der Aufwand einfach addiert.
Ich habe Dir vorgerechnet, daß meine Erklärung Deiner Benchmarkwerte sehr gut hinkommt. Das gilt natürlich auch für Deine Daten mit dem Tri-SLI-System (DOF kostet ohne 3,67ms, mit Tess 3,61ms, das dürfte wohl so ziemlich die Meßunsicherheit sein).
Edit:
Und gerade noch gesehen, mit Tri-SLI kostet DOF mit Tess 3,61ms. Mit single GTX480 sind es 10,84ms.
Und wie der Zufall so will sind 10.84ms / 3 = 3,61ms ;D
Ist aber wirklich eher Zufall, auch wenn das DOF-Zeugs eine gute SLI-Skalierung zeigen sollte. Du hast ja bestimmt auch mal zwischendurch den Treiber gewechselt.
Mein simples Performancemodell paßt gut, Du hast gar keins. :wink:
Undertaker
2011-05-28, 11:02:48
Müll entsorgt. Lovesuckz, auch dein letzter Beitrag ist mehr als grenzwertig. Weitere persönliche Angriffe werden geahndet. Andere Diskussionsteilnehmer schaffen es sehr wohl, sachlich zu bleiben.
LovesuckZ
2011-05-28, 13:10:00
[...] weshalb Du aus dem Vergleich Tess on/off mit und ohne DOF nichts lernen kannst.
Nein? :freak:.
Der Offset durch Tessellation ist deutlich geringer als durch DoF. Das impliziert, dass der Frameseinbruch von Tessellation mit mehr Effekten geringer wird und nicht mehr der limitierende Faktor darstellt. Also genau DAS, was ich hier seit anfang gesagt habe. Eine angebliche Ineffizienz der Recheneinheiten durch Tessellation wird jedenfalls nicht in Stone Giant erreicht, wenn der Offset mit 1,05ms noch höher liegt als die 0,99ms in Verbindung mit DoF.
Mein simples Performancemodell paßt gut, Du hast gar keins. :wink:
Du hast garnichts. Du hast weder Werte noch eigene Erfahrungen. Du nimmst meine Werte und willst darauf Aussagen treffen.
Hier mal heutige Werte mit einer GTX570 aus Stone Giant:
Tess aus, DOF aus: 83.817 fps, 11,93 ms Frametime
Tess aus, DOF an: 44.744 fps, 22,34 ms Frametime
=> DOF erhöht die Dauer um 87,26% (10,41 ms)
Tess aus, DOF aus: 83.817 fps, 11,93 ms Frametime
Tess high, DOF aus: 66.537 fps, 15,03 ms Frametime
=> Tess high erhöht die Dauer um 25,98% (3,01 ms)
Tess aus, DOF an: 44.744 fps, 22,34 ms Frametime
Tess high, DOF an: 39.439 fps, 25,36 ms Frametime
=> Tess high erhöht die Dauer um 13,45 % (3,02 ms)
Es spiegelt die SLI-Werte annährend 1:1 wieder. Nachher zeige ich dir noch Werte aus der Endless City Demo.
Durch bist mit einer Platitüde, also eine inhaltsleere Aussage, eingestiegen. Begriffe wie "exorbitante Steigerung der Geometrie", "steigende Ineffizienz der heutigen quadbasierten Renderer", "effektiv verfügbare Shaderleistung drastisch mindert" und "die Grafikqualität noch merklich (bei einem Echtzeitrenderer) anzuheben" sind vollkommen belanglos, wenn man sie nicht in Verhältnis zu etwas setzen kann. Wir haben nun Werte aus Stone Giant. Sind die 3 ms mit Tessellation schon ein Zeichen für "steigende Ineffizienz der heutigen quadbasierten Renderer" auf Basis einer "exorbitante[n] Steigerung der Geometrie"? Wie soll man also deine Behautpung einschätzen?
Du hast keine Gegenwerte, die zeigen, dass das grafische Niveau deutlich schneller erreicht werden kann. Demnach muss man davon ausgehen, dass jedenfalls das geometrische Niveau in Stone Giant nicht unter deine Einstiegsbehauptung fällt.
Hier mal heutige Werte mit einer GTX570 aus Stone Giant:
Tess aus, DOF aus: 83.817 fps, 11,93 ms Frametime
Tess aus, DOF an: 44.744 fps, 22,34 ms Frametime
=> DOF erhöht die Dauer um 87,26% (10,41 ms)
Tess aus, DOF aus: 83.817 fps, 11,93 ms Frametime
Tess high, DOF aus: 66.537 fps, 15,03 ms Frametime
=> Tess high erhöht die Dauer um 25,98% (3,01 ms)
Tess aus, DOF an: 44.744 fps, 22,34 ms Frametime
Tess high, DOF an: 39.439 fps, 25,36 ms Frametime
=> Tess high erhöht die Dauer um 13,45 % (3,02 ms)
Andere Reihenfolge:
Tess aus, DOF aus: 83.817 fps, 11,93 ms Frametime
Tess aus, DOF an: 44.744 fps, 22,34 ms Frametime
=> DOF erhöht die Dauer um 87,26% (10,41 ms)
Tess high, DOF aus: 66.537 fps, 15,03 ms Frametime
Tess high, DOF an: 39.439 fps, 25,36 ms Frametime
=> DOF erhöht die Dauer um 68,73% (10,33 ms)
Man sieht IMO recht deutlich dass DOF als Postprocessing (in StoneGiant) ein fixer overhead in der Frametime ist. (~10 ms bei dieser Karte)
Natürlich wirkt sich das je nach der übrigen Grafiklast absolut prozentuell unterschiedlich aus.
Tess aus, DOF aus: 83.817 fps, 11,93 ms Frametime
Tess high, DOF aus: 66.537 fps, 15,03 ms Frametime
=> Tess high erhöht die Dauer um 25,99 % (3,1 ms)
Tess aus, DOF an: 44.744 fps, 22,34 ms Frametime
Tess high, DOF an: 39.439 fps, 25,36 ms Frametime
=> Tess high erhöht die Dauer um 13,45 % (3,02 ms)
Man sieht IMO recht deutlich dass Tesselation im Frontend (in StoneGiant) ein fixer overhead in der Frametime ist. (~3 ms)
Natürlich wirkt sich das je nach der übrigen Grafiklast absolut prozentuell unterschiedlich aus.
Ich denke Gipsel versucht nur zu sagen dass mit steigender Geometriedichte (auf Subpixel Niveau analog REYES) der aktuelle Quadbasierte Renderansatz ineffizient wird. (Pixar bzw. Renderman gibt ihm Recht)
StoneGiant wäre dafür kein relevantes Beispiel da die durchschnittliche Dreiecksgröße AFAIK noch zu groß ist. (>=1Pixel)
Ich denke Gipsel versucht auch zu sagen dass nvidia mit ihrer aktuellen Fermi Architektur im Geometriedurchsatz "weiter fortgeschritten" ist als im Fragmentdurchsatz. Dies betrifft sowohl die derzeitige maximale Ausbaustufe GF110 als die zukünftige Skalierbarkeit der Einheiten.
StoneGiant wäre dafür ein relevantes Beispiel da die Frametime nur minimal beim Einsatz von Tesselation steigt. (unter Anbetracht eines durchschnittlichen modernen Shaderworkloads sodass noch genügend Kapazität im Shadercore für Hull und Domainshader bleibt)
Daraus würde er schliessen dass die folgenden Generationen bei nvidia wohl eher, aber natürlich nicht aussschliesslich, versuchen die bei Subpixel großen Dreiecken auftretenden Ineffizienzen der heutigen Quadbasierten Rasterizer zu lösen.
Da würde ich ihm Recht geben.
Gipsel
2011-05-28, 14:52:11
Danke für die treffende Zusammenfassung.
LovesuckZ
2011-05-28, 16:08:52
Ich denke Gipsel versucht nur zu sagen dass mit steigender Geometriedichte (auf Subpixel Niveau analog REYES) der aktuelle Quadbasierte Renderansatz ineffizient wird. (Pixar bzw. Renderman gibt ihm Recht)
StoneGiant wäre dafür kein relevantes Beispiel da die durchschnittliche Dreiecksgröße AFAIK noch zu groß ist. (>=1Pixel)
Ich denke Gipsel versucht auch zu sagen dass nvidia mit ihrer aktuellen Fermi Architektur im Geometriedurchsatz "weiter fortgeschritten" ist als im Fragmentdurchsatz. Dies betrifft sowohl die derzeitige maximale Ausbaustufe GF110 als die zukünftige Skalierbarkeit der Einheiten.
StoneGiant wäre dafür ein relevantes Beispiel da die Frametime nur minimal beim Einsatz von Tesselation steigt. (unter Anbetracht eines durchschnittlichen modernen Shaderworkloads sodass noch genügend Kapazität im Shadercore für Hull und Domainshader bleibt)
Daraus würde er schliessen dass die folgenden Generationen bei nvidia wohl eher, aber natürlich nicht aussschliesslich, versuchen die bei Subpixel großen Dreiecken auftretenden Ineffizienzen der heutigen Quadbasierten Rasterizer zu lösen.
Da würde ich ihm Recht geben.
Was Gipsel sagt, ist verstanden wurden. Er argumentiert jedoch auf einer so hohen Abstraktionsebene über das Problem, dass die Wirklichkeit vollkommen ignoriert wird. Das ist so als wenn mir jemand erklärt, dass ein Alien-Angriff 2013 für die Menschheit sehr schlimm wäre, nachdem die Menschheit 2012 zu Grunde gegangen ist. Dieses Problem hat heute keine Relevanz.
Gipsel stieg mit folgendem Zitat in diese Diskussion ein:
Und nicht vergessen: Eine exorbitante Steigerung der Geometrie hat eine steigende Ineffizienz der heutigen quadbasierten Renderer zur Folge, die die effektiv verfügbare Shaderleistung drastisch mindert, ohne die Grafikqualität noch merklich (bei einem Echtzeitrenderer) anzuheben.
Das Problem ist doch, dass dieser Einstieg vollkommen inhaltsleer ist. Jede Steigerung der Last führt zur "Ineffizienz", weil man perse weniger Frames hat. Basierend auf den Werten von Stone Giant, führt die " exorbitante Steigerung der Geometrie" nicht zur "steigende[n] Ineffizienz der heutigen quadbasierten Renderer zur Folge, die die effektiv verfügbare Shaderleistung drastisch mindert". Sein angeblich "simples Performancemodell" widerlegt zu 100% seine getätigte Aussage.
Werte aus der Endless City Demo von nVidia:
Tess aus, Basic Shading aus: 57,1 fps, 17,51 ms Frametime
Tess aus, Basic Shading an: 30,5 fps, 32,79 ms Frametime
=> Basic Shading erhöht die Dauer um 87,26% (15,28 ms)
Tess aus, Basic Shading aus: 57,1 fps, 17,51 ms Frametime
Tess an, Basic Shading aus: 39,4 fps, 25,38 ms Frametime
=> Tess an erhöht die Dauer um 44,95% (7,87 ms)
Tess aus, Basic Shading an: 30,5 fps, 32,79 ms Frametime
Tess an, Basic Shading an: 26,7 fps, 37,45 ms Frametime
=> Tess an erhöht die Dauer um 14,2% (4,66 ms)
Vorallem das letzte Beispiel zeigt, dass überhaupt nicht die Leistung der schnellsten Grafikkarte vorhanden ist, um in dieses angebliche Problem laufen zu können.
Was Gipsel sagt, ist verstanden wurden. Er argumentiert jedoch auf einer so hohen Abstraktionsebene über das Problem, dass die Wirklichkeit vollkommen ignoriert wird. Das ist so als wenn mir jemand erklärt, dass ein Alien-Angriff 2013 für die Menschheit sehr schlimm wäre, nachdem die Menschheit 2012 zu Grunde gegangen ist. Dieses Problem hat heute keine Relevanz.
Hallo LovesuckZ, im Thread über die Next-Gen-Architekturen Kepler und Maxwell über Geometrieraten zu diskutieren die heutige Anwendungen und Techdemos wie Stone-Giant übersteigen und darauf basierend Spekulationen über eventuelle Bottlenecks und deren Lösungsmöglichkeiten und Wahrscheinlichkeiten anzustellen finde ich eigentlich sehr On-Topic und relevant. Heutige Architekturen, Anwendungen und Techdemos sind die Basis für diese Spekulationen um daraus zukünftige Entwicklungen zu abstrahieren.
Wir befinden uns ja nicht umsonst im Spekulationsforum und das Spekulieren soll ja Spaß machen.
Gipsel stieg mit folgendem Zitat in diese Diskussion ein:
Das Problem ist doch, dass dieser Einstieg vollkommen inhaltsleer ist. Jede Steigerung der Last führt zur "Ineffizienz", weil man perse weniger Frames hat. Basierend auf den Werten von Stone Giant, führt die " exorbitante Steigerung der Geometrie" nicht zur "steigende[n] Ineffizienz der heutigen quadbasierten Renderer zur Folge, die die effektiv verfügbare Shaderleistung drastisch mindert". Sein angeblich "simples Performancemodell" widerlegt zu 100% seine getätigte Aussage.
Wie ich Gipsels Zustimmung zu meiner Zusammenfassung, deiner Quote von Gipsel und deinem oben zitierten Absatz entnehmen kann spricht er exakt die Ineffizienz eines Quadbasierten Rasterizers bei Subpixel großen Dreiecken an. Das hat nichts mit einer von dir angenommen allgemeinen Ineffizienz bei steigenden Workloads zu tun. (die sich zumindest für mich nicht aus dem Kontext dieses Threads erschliesst)
Hier geht es speziell darum dass Shaderleistung für Fragments verbraucht wird die sowieso discarded - also verworfen werden. Genau das ist die Ineffizienz um die es in Zukunft mit an Sicherheit grenzender Wahrscheinlichkeit gehen wird.
Werte aus der Endless City Demo von nVidia:
Tess aus, Basic Shading aus: 57,1 fps, 17,51 ms Frametime
Tess aus, Basic Shading an: 30,5 fps, 32,79 ms Frametime
=> Basic Shading erhöht die Dauer um 87,26% (15,28 ms)
Tess aus, Basic Shading aus: 57,1 fps, 17,51 ms Frametime
Tess an, Basic Shading aus: 39,4 fps, 25,38 ms Frametime
=> Tess an erhöht die Dauer um 44,95% (7,87 ms)
Tess aus, Basic Shading an: 30,5 fps, 32,79 ms Frametime
Tess an, Basic Shading an: 26,7 fps, 37,45 ms Frametime
=> Tess an erhöht die Dauer um 14,2% (4,66 ms)
Vorallem das letzte Beispiel zeigt, dass überhaupt nicht die Leistung der schnellsten Grafikkarte vorhanden ist, um in dieses angebliche Problem laufen zu können.
Tut mir leid ich verstehe deinen letzten Satz vermutlich nicht.
Kannst du deine Interpretation der Endless City Resultate bitte genauer darlegen?
Danke für die treffende Zusammenfassung.
Bitte gerne.
Interessante Diskussion wenn auch zum Teil etwas mühsam zu verfolgen.
Danke an die Moderation für die Bereinigung!
Schaffe89
2011-05-28, 17:01:08
Das Problem ist doch, dass dieser Einstieg vollkommen inhaltsleer ist. Jede Steigerung der Last führt zur "Ineffizienz", weil man perse weniger Frames hat. Basierend auf den Werten von Stone Giant, führt die " exorbitante Steigerung der Geometrie" nicht zur "steigende[n] Ineffizienz der heutigen quadbasierten Renderer zur Folge, die die effektiv verfügbare Shaderleistung drastisch mindert". Sein angeblich "simples Performancemodell" widerlegt zu 100% seine getätigte Aussage.
Ich kapiere nicht, was dein Stone Gigant Beispiel beweisen soll.
Gipsel hat dir Folien präsentiert, welche zeigen, dass mit steigender Geometriedichte auf subpixel niveau der aktuelle Renderansatz ineffizient wird.
Dein Beispiel liefert keine relevanz, da die Dreicksgröße zu groß ist, um jenes zu zeigen.
Kannst du deine Interpretation der Endless City Resultate bitte genauer darlegen?
Das wäre auch mein Anliegen.
Er argumentiert jedoch auf einer so hohen Abstraktionsebene über das Problem, dass die Wirklichkeit vollkommen ignoriert wird.
Inwiefern wird die Wirklichkeit ignoriert?
LovesuckZ
2011-05-28, 17:26:15
Hallo LovesuckZ, im Thread über die Next-Gen-Architekturen Kepler und Maxwell über Geometrieraten zu diskutieren die heutige Anwendungen und Techdemos wie Stone-Giant übersteigen und darauf basierend Spekulationen über eventuelle Bottlenecks und deren Lösungsmöglichkeiten und Wahrscheinlichkeiten anzustellen finde ich eigentlich sehr On-Topic und relevant. Heutige Architekturen, Anwendungen und Techdemos sind die Basis für diese Spekulationen um daraus zukünftige Entwicklungen zu abstrahieren.
Wir befinden uns ja nicht umsonst im Spekulationsforum und das Spekulieren soll ja Spaß machen.
Wir diskutieren aber anhand heutiger Hardware über die Anwendbarkeit von Tessellation. Sein Einstieg basierte auf dieser Aussage:
Und nicht vergessen: Echte Geometrie lässt sich per MSAA glätten, was wiederum dazuführt, dass SSAA an Bedeutung verliert und man mehr Leistung für andere Effekte hat.
Es nimmt von vornerein an, dass Tessellation nur dazu angewendet wird, um den kompletten Bildschirm mit subpixelgroße Dreiecken vollzupappen. Was natürlich schon zeigt, dass er das Thema in eine Richtung lenken will, in die Tessellation als negatives Werkzeug für mehr Geometrie darsteht.
Hier geht es speziell darum dass Shaderleistung für Fragments verbraucht wird die sowieso discarded - also verworfen werden. Genau das ist die Ineffizienz um die es in Zukunft mit an Sicherheit grenzender Wahrscheinlichkeit gehen wird.
Darum geht es. Um in dieses Problem laufen zu können, muss die Erzeugung schnell genug erfolgen. Das ist bei AMD nicht der Fall und bei nVidia nur in bestimmten Situationen. Gleichzeitig wird vergessen, dass Spiele die Recheneinheiten für andere Effekte benötigen. Es ist bezeichnend, dass Gipsel auf einem sarkastischen Kommentar (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8746377&postcount=156) von Spasstiger geantwortet hat, der an mich gerichtet war, aber er es ist, der Spiele fordert, die "vollgepapp sind" mit subpixelgroßen Dreiecken, weil er dann recht hätte. Sowas ist dann doch sehr lustig.
Niemand weiß von uns, wie zukünftige Hardware aussehen wird. Es ist mühsam darüber zu spekulieren, ob und welche Veränderungen vorgenommen werden, um dieses Problem zu mindern. Aber es auf heutige Hardware zu übernehmen, um Tessellation ins Miskredit zu bringen, ist einfach falsch.
Der Begriff Effzienz existiert nur in Zusammen mit einem Verhältnisvergleich. Solange wie Gipsel nicht darlegt, welche Zahlen er als Grundlage heranzieht, ist es eine Worthülse. Gleichbedeutend mit "zu schnell fahren" ohne auch nur eine Definition, wann "zu schnell fahren" überhaupt möglich wäre.
Tut mir leid ich verstehe deinen letzten Satz vermutlich nicht.
Kannst du deine Interpretation der Endless City Resultate bitte genauer darlegen?
Es zeigt, dass Fermi nicht die Leistungsfähigkeit besitzt subpixelgroße Dreiecke noch und nöcher erzeugen und gleichzeitig viele andere Effekte in Echzeit berechnen zu können. Gleichzeitig ist Fermi aber in der Lage, mit weniger Leistungsverlust sehr viele Dreiecke auf der GPU zu produzieren, ohne dass man hier von einer "Ineffizienz" reden kann.
Gipsel
2011-05-28, 19:15:26
Es nimmt von vornerein an, dass Tessellation nur dazu angewendet wird, um den kompletten Bildschirm mit subpixelgroße Dreiecken vollzupappen. Was natürlich schon zeigt, dass er das Thema in eine Richtung lenken will, in die Tessellation als negatives Werkzeug für mehr Geometrie darsteht.Und ich dachte immer, Dir kann es schon heute nicht genug Geometrie geben, so daß Du das sogar als praktisch einziges Performancemerkmal zur Berücksichtigung der Leistungssteigerung zulassen wolltest.
Wenn Du das also willst (Maximum an Geometrie, sieher Deiner Aussage in Sig von Schaffe89), dann definierst Du als Ziel etwas in die Richtung von 1 Vertex pro Pixel (=2 Dreiecke pro Pixel, optimale Abtastung der Geometrie). Und wie ich schon mal erwähnte, geht es ja immerhin um die Zielstellung für einen Chip, der mit ~12 Milliarden Transistoren im Jahre 2014 das Highend darstellen soll. Das ist also in Reichweite wenn man da hinwill, oder meinst Du nicht?
Kann natürlich auch sein, daß man sagt: Nun, 8 Pixel pro Dreieck sind doch auch schon ganz nett anzusehen, wir arbeiten lieber auf andere Ziele hin (welche?). Man beläßt es also beim "Status Quo" bei GPUs (zu dessen Änderung man, wie der Diskussion zu entnehmen wohl am besten die DirectX Specs anpassen würde) und muß dann Anwendungen, in denen doch sehr kleine Dreiecke vorherrschen, deutlich ineffizienter mit einem Mehr an brutaler Shaderpower totschlagen. Oder die Leute fangen an, Engines an der DX11-Pipeline vorbei zu schreiben, mitsamt Software-Rasterizer und so (Larrabee reloaded, die haben sich da ja schon was bei gedacht gehabt). Das ist aber auch ineffizient, da fixed function Einheiten aus Performance/Watt-Gründen schon noch ihren Sinn haben.
Es ist bezeichnend, dass Gipsel [..] Spiele fordert, die "vollgepapp sind" mit subpixelgroßen Dreiecken, weil er dann recht hätte. Sowas ist dann doch sehr lustig.Nein das ist nicht lustig (höchstens, daß Du so dagegen argumentierst). Das ist auch keine Forderung. Das ist einfach nur eine Überlegung, in welche Richtung sich zukünftige Anforderungen wohl entwickeln werden, mit denen dann Maxwell konfrontiert wird. Und Du selbst bestehst doch heute ständig auf Tess und mehr Geometrie! Sind wir schon bei der Perfektion angekommen? Willst Du etwa Stillstand? :D
Es zeigt, dass Fermi nicht die Leistungsfähigkeit besitzt subpixelgroße Dreiecke noch und nöcher erzeugen und gleichzeitig viele andere Effekte in Echzeit berechnen zu können. Gleichzeitig ist Fermi aber in der Lage, mit weniger Leistungsverlust sehr viele Dreiecke auf der GPU zu produzieren,So, und was spricht dann für die Zukunft dagegen, daß man versucht, die effektiv in den Pixelshadern verfügbare Leistung zu erhöhen, indem man die Anzahl der in den Quads verschwendeten Fragments zu minimieren versucht? Dann könnte man selbst ohne Anhebung der nominellen Rechenleistung (die aber selbstverständlich auch steigen wird) schon mehr kleine Dreiecke auch noch mit anspruchsvolle Effekten versehen. Was ist daran so schwer zu verstehen? Wenn Du für's Pixelshaden von 4mal so vielen (kleinen) Dreiecken dann z.B. nur 2mal so viel Rechenleistung benötigst statt fast 4 Mal so viel mit einem heutigen Design, wäre das doch super!
LovesuckZ
2011-05-28, 21:10:57
Und ich dachte immer, Dir kann es schon heute nicht genug Geometrie geben, so daß Du das sogar als praktisch einziges Performancemerkmal zur Berücksichtigung der Leistungssteigerung zulassen wolltest.
Auch das ist wieder eine wirre Wiedergabe meiner Postings. :rolleyes:
DAS ist Rosinenpickerei. Das Front-End benötigt Transistoren, die eben nicht in TMUs und Recheneinheiten gesteckt werden konnten. Klar, wenn man keinen Bock auf Fortschritt hat und liebers Fake-Aliasing-Methoden statt reale Geometrie will, dann wird man nie mehr als 200% [sic! 100%] erreichen und enttäuscht sein.
Es ist ersichtlich, was gemeint war
Wenn Du das also willst (Maximum an Geometrie, sieher Deiner Aussage in Sig von Schaffe89), dann definierst Du als Ziel etwas in die Richtung von 1 Vertex pro Pixel (=2 Dreiecke pro Pixel, optimale Abtastung der Geometrie). Und wie ich schon mal erwähnte, geht es ja immerhin um die Zielstellung für einen Chip, der mit ~12 Milliarden Transistoren im Jahre 2014 das Highend darstellen soll. Das ist also in Reichweite wenn man da hinwill, oder meinst Du nicht?
Nein. Denn AMD zeigt, dass der Dreiecksdurchsatz überhaupt nichts aussagt. "Maximum" wäre 2 Mrd Dreiecke/s bei 60 FPS. Da brauchen wir bestimmt nicht darüber reden, ob das 2014 möglich wäre. Wir haben ja geklärt, dass Stone Giant ein Niveau hat, dass Hocheffizient ist und somit erstrebenswert. Das reicht erstmal vollkommen.
Nein das ist nicht lustig (höchstens, daß Du so dagegen argumentierst). Das ist auch keine Forderung. Das ist einfach nur eine Überlegung, in welche Richtung sich zukünftige Anforderungen wohl entwickeln werden, mit denen dann Maxwell konfrontiert wird. Und Du selbst bestehst doch heute ständig auf Tess und mehr Geometrie! Sind wir schon bei der Perfektion angekommen? Willst Du etwa Stillstand? :D
Leider habe ich solche Aussagen nicht getätigt. Also unterlasse es, mir etwas zu unterstellen.
So, und was spricht dann für die Zukunft dagegen, daß man versucht, die effektiv in den Pixelshadern verfügbare Leistung zu erhöhen, indem man die Anzahl der in den Quads verschwendeten Fragments zu minimieren versucht? Dann könnte man selbst ohne Anhebung der nominellen Rechenleistung (die aber selbstverständlich auch steigen wird) schon mehr kleine Dreiecke auch noch mit anspruchsvolle Effekten versehen. Was ist daran so schwer zu verstehen? Wenn Du für's Pixelshaden von 4mal so vielen (kleinen) Dreiecken dann z.B. nur 2mal so viel Rechenleistung benötigst statt fast 4 Mal so viel mit einem heutigen Design, wäre das doch super!
Jede zukünftige Architektur wird auch Effizienzverbesserungen bringen. Was das aber mit den heutigen Architekturen und deinem angeblichen Effizienzproblem bei hohem Geometrieniveau zu tun hat, verstehe ich nicht.
Screemer
2011-05-28, 22:29:13
Du kannst scheinbar nicht unterscheiden ob gipsel von zukuebftigen grafikszenarios auf aktueller Hardware spricht (subpixel polies) und deren ineffiziens bei solchen Szenarios oder davon wie man diese Probleme in zukünftiger Hardware vermeiden könnte. Thread "zukünftige Architekturen " im Spekulationen Forum. Leiter da was?
Sorry kommt vom Handy.
Hugo78
2011-05-28, 22:50:59
Ich für meinen Teil würde hier gerne wieder was lesen, was ausschließlich mit Kelper und Maxwell zutun hat.
Für alles andere, dass sicherlich auch Kepler und Maxwell berührt oder berühren könnte,
aber ebend letztlich eher allgemeine Fragen der zukünftigen Chipentwicklung sind, sollte man doch ein neues Thema eröffnen.
Ailuros
2011-05-28, 22:52:07
Seit Ihr Herren endlich fertig mit dem Tessellations-/Geometrie-Seitensprung? Maxwell ist mir zu weit in der Zukunft, aber zumindest fuer Kepler waere es angenehm ein paar logische Spekulationen ueber NV's Moeglichkeiten fuer Keppler zu lesen.
Duplex
2011-05-28, 22:53:35
Setzt Nvidia bei Kepler weiterhin auf 1D-Shader wie bei Fermi?
Dei aktuellen Nvidia Karten sind ja schon Top Karten, würde doch reichen wenn man die Shader in 28nm erweitert damit die Leistung ca. 50% erhöht wird?
mapel110
2011-05-28, 23:00:07
Dafür, dass Kepler schon Ende des Jahres auf der Matte stehen könnte, haben wir aber sehr wenig Infos.
boxleitnerb
2011-05-28, 23:05:25
Nach dem Fermi-Desaster glaube ich nicht an 2011. Paperlaunch 2012 April oder so, kaufbar im Juni. Meine Prognose...
Hugo78
2011-05-28, 23:57:02
Von Kepler erwarte ich eigentlich, dass man die einzelnen SPs noch besser ausreizt ohne das dabei der Aufwand in der Treiberentwicklung wieder die Ausmaße der GF5/6/7 Zeiten annimmt.
Also ich glaube nicht dass NV wieder auf Vectoren (ein Vec 2 oder Vec 3 oder so), geht sondern eher einen Weg findet ihre aktuellen SPs noch kleiner zumachen und die wenn erforderlich, dynamisch als Cluster zusammen arbeiten lässt.
Und wenn nicht, ebend abschaltet um Energie zusparen.
(mal grob als Laie gesprochen)
@boxleitnerb
Es ist zu oberflächlich hier von Fermi auf Kepler zuschließen.
Das Problem bei Fermi war ja grundsätzlich nicht, dass das Design nicht fertig* war,
sondern das Nvidia bei der Entwicklung an einer Stelle nicht sorgfältig gearbeitet hatte und sie nacharbeiten mussten (Stichwort: Fabric).
- http://www.youtube.com/watch?v=9NjEviEPtZc&hd=1
Wenn sich so ein Fehler bei Kepler nicht wieder einschleicht und der 28nm von TSMC passt, wird/sollte sich die Verschiebung a la Fermi nicht wiederholen.
* Bugfix und Optimierungen wird es immer geben.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.