PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : GPU-Entwicklung-Zukunft


VinD
2010-02-28, 19:22:23
GPU-Entwicklung
Bei jedem Grafik-Chip-Entwickler gibt es mehrere Teams die paralel zueinander neue Chips entwickeln.
Z.B. fängt jedes Jahr ein neues Team mit einem neuen Chip an, der erst in XY Jahren rauskommen soll. Entsprechend müssen die Spezifizierer (So nenn ich die Leute jetzt, die dem zukünftigen Chip Features in einem Ranking verpassen) weit vorausplanen und/oder Annahmen machen wie die Konkurenz in der Zeit sich aufstellen könnte.
Ich denke das ist auch der Grund wieso Features oder architektonische Maßnahmen zur verbesserung ewigkeiten brauchen bis sie umgesetzt wurden (war früher wegen der kleineren Transistoranzahl sicher kürzer). Es wird nichtmehr soviel gewagt und Inovationen werden viell sogar fallengelassen um sich nicht zu verspekulieren.

Sinn des Themas hier:
Wenn ihr einem neuem Team eine Feature-Liste geben würdet, wie sähe sie aus und wie würdet ihr sie umsetzten?

viel freude am Fantasieren wünscht euch:
VinD alias White

Coda
2010-02-28, 20:00:20
Mit 15nm Litho würde man bei 500mm² rund 20 Mrd. Transistoren unterbringen.

Der_Korken
2010-02-28, 20:05:29
Ich glaube so einfach, wie du es dir vorstellst, läuft es nicht ab. Es gibt zweifellos mehrere Entwicklerteams, aber die arbeiten in irgendeiner Weise auch zusammen, damit das ganze überhaupt effizient werden kann. Wenn jedes Team nur alle 3 oder 4 Jahre einen Chip rausbringt, dann können die eigentlich jedes Mal wieder bei Null anfangen und ne eigene Architektur aus dem Boden stampfen. Nicht umsonst hält sich eine Grundarchitektur relativ lange, auch bei den GPUs (R600 bis RV870 würde ich zB als Grundarchitektur zusammenfassen).

Die Rahmenbedingungen sind auch eine Sache für sich, ich glaube kaum, dass ein 600mm²-Brummer ein begehrenswertes Ziel ist. Man muss sich vorher überlegen, wie der Chip aussehen muss, dass man ihn noch verkaufen kann. Was nützt einem eine Karte, die man nicht unter 500€ verkaufen kann, wenn sich außer ein paar Freaks keiner so Teil zulegen würde? Hinter dem Transistoren-Budget bzw. der Die-Size steckt schon immer eine bestimmte Intention. Du könntest natürlich sagen, du willst einen Chip haben, der zu seiner Zeit das Maximum an Leistung aus dem technisch machbarem rausholt. Aber dann formulier das so, denn es macht zB wieder einen Unterschied, ob man den Chip in einem ausgereiften Prozess oder einem riskanten neuen Prozess herstellt. Denk ich jedenfalls ;D

15nm sind übrigens viel zu optimistisch. Wenn dann gibt es wohl eher 16nm, aber das wird vor 2015 wohl nichts, da es jetzt (2010) kaum 32nm gibt. 16nm wären 2 Fullnodes weiter. Dementsprechend sind natürlich auch 11-13Mrd Transistoren Humbug

Speicher 2-4GB wär für 2013 OK, 800GByte/s dagegen nicht. Bei einem 512bit-SI bräuchte man dafür Speicher mit einem effektiven Takt von 12,5Ghz !! Ich weiß nicht, wann GDDR6 kommt, aber ich glaube nicht, dass wir in 3 Jahren schon im 2-stelligen Ghz-Bereich sind.

Die restlichen theoretischen Zahlen sind ziemlich wertlos, wenn man nicht weiß, wie sie in die Architektur eingebunden sind. Die können alles oder nichts heißen, wenn dein Chip eine neue unbekannte Architektur besitzt.

So, jetzt hab ich aber genug gemeckert :freak:

VinD
2010-02-28, 20:07:45
@Coda: Wie hastu das ausgerechnet?
Ich hab über Verhälnisse gerechnet und bei auf knapp über 500mm gekommen^^

@Der Korken:
- wie geschrieben "bis 600mm²" klar gibts eine Gewisse wirtschaftliche Grenze
- welcher Prozess da verwendet wird ist nicht sicher, da es mittlerweile Mode ist einige sogar zu überspringen (ende 2010 28nm , ende 2011 könnte schon der 22/25nm Prozess draußen sein)
- es ist nur ein Beispiel und ich habs mir in 5mins aus den Fingern gesaugt
- kritik nehm ich gerne an oder verteidige meine "Werte", du darfst auch selbst etwas "entwerfen". Ich bin gespannt :D
es soll nichtnur rumgemeckert werden sondern verbesserungsvorschläge oder ganz neue Vorschläge gemacht werden. Danke

Spasstiger
2010-02-28, 20:35:52
2013 werden wir wahrscheinlich eine 22-nm-Fertigung für GPUs verfügbar haben, 15 nm auf keinen Fall. *)
In 22 nm wird man auf gleicher Diefläche ungefähr die 3,3-fache Transistorzahl gegenüber heutigen 40-nm-GPUs unterbringen können. Ausgehend vom Cypress (RV870, 334 mm², 2,1 Mrd. Transistoren) wären das rund 10 Mrd. Transistoren auf 500 mm².

Deine Leistungsdaten passen übrigens nicht mit der Architekturbeschreibung zusammen. Ich zähle bei dir 8*16*16 ALUs, wobei jede ALU vier fp32-Operationen ausführen kann. Ich gehe davon aus, dass du dabei von FMA- bzw. MADD-Operationen ausgehst. Bei 1000 MHz Chiptakt wären das 8*16*16*4*2*1000 MFlops = 16,384 TFlops Peak-Rechenleistung (fp32).

*)
Q4 2005: 90 nm (R520, R515)
Q1 2006: 80 nm (R580)
Q3 2007: 65 nm (RV610, RV630)
Q4 2007: 55 nm (RV670)
Q2 2009: 40 nm (RV740)
Q1 2011: 28 nm
Q4 2012: 22 nm ?
Q3 2014: 15-16 nm ?

Coda
2010-02-28, 21:24:34
@Coda: Wie hastu das ausgerechnet?
Ich hab über Verhälnisse gerechnet und bei auf knapp über 500mm gekommen^^
Wenn man in x- und y- Richtung verkleinert ist der Zuwachs an Transistoren natürlich quadratisch und nicht linear.

VinD
2010-02-28, 21:47:57
... Bei 1000 MHz Chiptakt wären das 8*16*16*4*2*1000 MFlops = 16,384 TFlops Peak-Rechenleistung (fp32).

auf dem Chip 8ShaderCluster mit je 16 MIMD-Einheiten mit je 16Prozessoren(Alu/ROP/TMU - sie sind 3 in 1) die max. 4 32bit FP's pro Takt berrechnen können (entweder Mul+ADD oder MADD) alles läuft mit 1-1,3GHz.
Also: 8*16*16*4*1000= 8,192TFlops
oder 8*16*16*4*1300= 10,649TFlops
Wieso du da plötzlich ne 2 reinmultiplizierst interessiert mich ;)

Da die Einheiten auch für anderes verwendet werden kann wird diese Leistung nur bei nicht-ROP/TMU-Anwendungen und einfacherer Genauigkeit erreichbar sein.
Es kann vorkommen das 80 ALUs dazu verdonnert werden TMUs und 40 ALUs dazu verdonnert werden ROPs zu sein, damit sollte sich die Architektur besser an die Aktuelle Anwendung anpassen können. Klar geht damit einher das die ALUs größer werden, allerdings vermindert man so evtl. Flaschenhälse.
Durch die MIMD-Ansteuerung ist es möglich leerlauf zu vermeiden, weil dadurch auch nur einzelne ALUs angesteuert werden können.


*)
Q4 2005: 90 nm (R520, R515)
Q1 2006: 80 nm (R580)
Q3 2007: 65 nm (RV610, RV630)
Q4 2007: 55 nm (RV670)
Q2 2009: 40 nm (RV740)
Q1 2011: 28 nm
Q4 2012: 22 nm ?
Q3 2014: 15-16 nm ?

Wieso der große Sprung zwischen 22nm und 15-16nm???
Es sind nur Annahmen und es ist nur ein Beispiel ;)

Spasstiger
2010-02-28, 22:24:47
Wieso du da plötzlich ne 2 reinmultiplizierst interessiert mich ;)
Weil ein MADD/FMA eben als zwei Floating-Point-Operationen gerechnet wird. Es ist gleichzeitig eine Addition und eine Multiplikation.

Wieso der große Sprung zwischen 22nm und 15-16nm???
Es sind nur Annahmen und es ist nur ein Beispiel ;)
Schau halt mal die Schritte an, die ich fett markiert habe und die Abstände dazu. Der Sprung von 22 nm (ein Prozess, an dem konkret gearbeitet wird) auf 15-16 nm ist kleiner als von 65 nm auf 40 nm. Mag sein, dass es noch einen Zwischenschritt geben wird, z.B. 19 nm, aber afaik ist in dieser Richtung nur was für Flashspeicher geplant. Ich bleibe jedenfalls dabei, dass wir 2013 noch nichts in Richtung 15 nm oder 16 nm sehen werden. 10 Mrd. Transistoren halte ich dagegen für denkbar.

Btw.: nVidia GPUs in >2013 - Projektion (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=429619)

VinD
2010-02-28, 22:57:49
Weil ein MADD/FMA eben als zwei Floating-Point-Operationen gerechnet wird. Es ist gleichzeitig eine Addition und eine Multiplikation.


Schau halt mal die Schritte an, die ich fett markiert habe und die Abstände dazu. Der Sprung von 22 nm (ein Prozess, an dem konkret gearbeitet wird) auf 15-16 nm ist kleiner als von 65 nm auf 40 nm. Mag sein, dass es noch einen Zwischenschritt geben wird, z.B. 19 nm, aber afaik ist in dieser Richtung nur was für Flashspeicher geplant. Ich bleibe jedenfalls dabei, dass wir 2013 noch nichts in Richtung 15 nm oder 16 nm sehen werden. 10 Mrd. Transistoren halte ich dagegen für denkbar.

Btw.: nVidia GPUs in >2013 - Projektion (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=429619)

oh okay, dann hab ich mich doch verrechnet Ö.ö ups... :biggrin:
Dann wäre das dann in etwa das was NV in ihrer Prognose berechnet hat... auch nicht schlecht...
Was da genau für ein Prozess an der Reihe ist, kann nun echt niemand sagen da immernoch geforscht wird. Daher hab ich mich auch für 15nm entschieden weil der in etwa 2013-2014 rauskommen könnte, vorher hatte ich den 22nm im Blick, aber da ich bei der Die-Fläche irgendeinen Müll zusammengerechnet habe und bei 900mm² rauskam hab ich kurzerhand geguckt was in der Zeit am höhsten möglich wäre ;)

@ dein BTW: wenn man sich die beiden Bilder so ansieht, wird man bemerken das das Neuste nach oben korigiert wurde. Daran sieht man das man nix anderes kann als in den Nebel zu entwickeln...

Ansicht: Ich sehe zurzeit wie AMD und NV immer mehr Einheiten einbauen und sich immermehr eine gewisse ineffizienz zeigt (NV schneller als ATI obwohl ATI die besseren Daten zeigt). Dem wollte ich mit der MIMD-Überlegung von Voll-Flexiblen Einheiten entgegenwirken und frage mich seit langem wie man das in Zukunft lösen wird. Daher auch mal die frage hier ins Forum ;)

Coda
2010-03-01, 00:20:32
MIMD dürfte für Grafikaufgaben viel ineffizienter sein als SIMD. Es gibt für reines Streamprocessing eigentlich keine Effizienzprobleme. Die kommen eher von den Einheiten die das Bild zeichnen und die Jobs verwalten.

VinD
2010-03-01, 16:17:02
MIMD dürfte für Grafikaufgaben viel ineffizienter sein als SIMD. Es gibt für reines Streamprocessing eigentlich keine Effizienzprobleme. Die kommen eher von den Einheiten die das Bild zeichnen und die Jobs verwalten.
Sind die zu verrechneten und/oder zu erzeugenden Daten allerdings kleiner als die Breite der SIMD, entstehen Leerläufe.
Sind alle Daten schnell genug da und muss nurnoch durch TMU/ROPs, die in einer zu kleinen Menge vorhanden sind, nennt man das Flaschen-Hals.
Sind da kleinere (4x4) MIMD-Einheiten nicht flexibler und anpassungsfähiger wenn sie die Aufgaben von TMU/ALU/ROP übernehmen können?
Durch die MIMDs ist es auch möglich einige zu einem Cluster zu vereinigen (Bildlich gesehen) indem man ihnen die selben Inst. schickt?(SIMD)
Es ist ein größerer Verwaltungsaufwand, aber es lohnt sich denk ich mal mehr als wenn dauernt irgendein Faktor bremst...

Pinoccio
2010-03-01, 16:48:41
AnandTech (http://www.anandtech.com/video/showdoc.aspx?i=3469&p=1) hat bezogen auf den RV770 eine sehr ausführliche Geschichte, wie ein Chip entsteht.

mfg

Der_Korken
2010-03-01, 17:55:02
Sind die zu verrechneten und/oder zu erzeugenden Daten allerdings kleiner als die Breite der SIMD, entstehen Leerläufe.
Sind alle Daten schnell genug da und muss nurnoch durch TMU/ROPs, die in einer zu kleinen Menge vorhanden sind, nennt man das Flaschen-Hals.
Sind da kleinere (4x4) MIMD-Einheiten nicht flexibler und anpassungsfähiger wenn sie die Aufgaben von TMU/ALU/ROP übernehmen können?
Durch die MIMDs ist es auch möglich einige zu einem Cluster zu vereinigen (Bildlich gesehen) indem man ihnen die selben Inst. schickt?(SIMD)
Es ist ein größerer Verwaltungsaufwand, aber es lohnt sich denk ich mal mehr als wenn dauernt irgendein Faktor bremst...

Wenn du universelle Einheiten baust, dann kosten die sehr viel Platz. Wenn dann sowieso nur (ich sag jetzt einfach mal) 20% der Rechenleistung für TMU/ROP-Arbeit draufgeht, warum müssen die restlichen 80% der Einheiten das dann auch beherrschen? Das könnte man dann auch wieder als eine gewisse Ineffizienz auslegen.

Gast
2010-03-01, 18:04:29
Wenn du universelle Einheiten baust, dann kosten die sehr viel Platz. Wenn dann sowieso nur (ich sag jetzt einfach mal) 20% der Rechenleistung für TMU/ROP-Arbeit draufgeht, warum müssen die restlichen 80% der Einheiten das dann auch beherrschen? Das könnte man dann auch wieder als eine gewisse Ineffizienz auslegen.

Das verstehe ich nicht ganz.
Eine universelle Recheneinheit kann alles Rechnen und wird nicht dadurch langsamer das Sie z.B ROP-funktionen beherrscht (sie kann eh alles rechnen, da frei Programmierbar).
Der Grund warum das nicht gemacht wird ist, dass die entsprechenden Funktionen sehr unperformant in Software nachgebildet werden können.
Ineffizient sind eher die FF-Einheiten, da Sie wenn nicht genug geeignete Aufgaben vorliegen wenig leisten und im Extremfall lange Zeit überhaupt nichts tun.

VinD
2010-03-01, 20:34:17
@Pinoccio: kenn ich und ist mir bekannt... aber ist stellte eine andere Frage ;)

@Der_Korken: In einigen Anwendungsfällen wird halt viel TMU/ROP-Leistung und in anderen garkeine oder nur wenig.
Der Unterschied in den Einheiten besteht darin das bestimmte Rechenoperationen nicht vorhanden sind und andere in einem Rutsch erledigt werden...
Erweitert man also einfach gesagt die ALU-Fähigkeiten um ROP- und TMU-Fähigkeiten, erreicht man eine höhere Flexibilität! Klar werden die Einheiten größer, dafür drehen 30% nicht mehr sinnlos Däumchen...

Coda
2010-03-02, 04:03:15
Sind die zu verrechneten und/oder zu erzeugenden Daten allerdings kleiner als die Breite der SIMD, entstehen Leerläufe.
Sind alle Daten schnell genug da und muss nurnoch durch TMU/ROPs, die in einer zu kleinen Menge vorhanden sind, nennt man das Flaschen-Hals.
Sind da kleinere (4x4) MIMD-Einheiten nicht flexibler und anpassungsfähiger wenn sie die Aufgaben von TMU/ALU/ROP übernehmen können?
Durch die MIMDs ist es auch möglich einige zu einem Cluster zu vereinigen (Bildlich gesehen) indem man ihnen die selben Inst. schickt?(SIMD)
Es ist ein größerer Verwaltungsaufwand, aber es lohnt sich denk ich mal mehr als wenn dauernt irgendein Faktor bremst...
Ich verstehe ehrlich gesagt nicht was du schreibst, aber MIMD würde in GPUs genau das gleiche sein wie heutige SIMDs mit einer Wavefront/WARP-Size von 1 statt 64 bzw. 32.

Das heißt man hätte 64x bzw. 32x mal mehr Kontrolllogik. So groß ist der Effizienzverlust von SIMD-GPUs bei branchlastigem Code aber bei weitem nicht, damit sich das rechnet. Für die Transistoren die dafür draufgehen muss man weniger Recheneinheiten verbauen.

NVIDIA und ATI wissen schon genau was sie tun. Es ist ja nicht so als wäre MIMD irgendwie schwer zu implementieren.

VinD
2010-03-02, 09:19:08
Ich verstehe ehrlich gesagt nicht was du schreibst, aber MIMD würde in GPUs genau das gleiche sein wie heutige SIMDs mit einer Wavefront/WARP-Size von 1 statt 64 bzw. 32.

Das heißt man hätte 64x bzw. 32x mal mehr Kontrolllogik. So groß ist der Effizienzverlust von SIMD-GPUs bei branchlastigem Code aber bei weitem nicht, damit sich das rechnet. Für die Transistoren die dafür draufgehen muss man weniger Recheneinheiten verbauen.

NVIDIA und ATI wissen schon genau was sie tun. Es ist ja nicht so als wäre MIMD irgendwie schwer zu implementieren.

Also, du weißt sicher das die WF/Warps immer in einen SIMD-Array belegen.
Bei NV 32 und bei AMD üblicherweiße 64.
4(Quad)*8(ShaderEinheiten) bzw. 4(Quad)*16(ShaderEinheiten).
In meinem Beispiel wären es 4(Quad)*4(Einheiten) sind also kleinere Warps/WFs wie du richtig bemerkt hast. Grund ist der das eine ganze Gruppe nicht immer das ganze SIMD-Array besetzten kann und einige Einheiten einfach mal Däumchendrehen, um dem endgegenzuwirken kann man die Warps/WFs kleiner halten.
Wenn man die Peak-Leistung von NV und AMD anschaut sieht man das in der Praxis die AMDs hinterher liegen. Die Ursache ist in den nicht ganz ausgelasteten SIMD-Arrays zu finden. Durch MultiThreading ist da noch bisschen was zu retten aber auch nicht alles. Deshalb denk ich ist es besser die Warps/WFs zu verkleinern, damit sie oft genug voll genutzt werden können. Problem ist sicher wie du sicher feststellst, wenn sie zu klein sind müssen sie auf mehrere SIMDs gelegt werden oder mehrfach durch einen... Deswegen die MIMD-Überlegung: Man könnte durch simples zusammenlegen kurzzeitig 2MIMD-Arrays wie ein breiteres SIMD-Array behandeln und spart sich verlorene Zeit.
Das ist ein Gedankenspiel und in der Praxis sicher im moment nicht testbar =(

Vorteil: so wie ich das sehe kann man durch das Effizentere Nutzen der Arrays einiges an PEAK-leistung einsparen, so auch EInheiten, dass heißt man hat mehr Platz für größere Einheiten die Multifunktionaler sind ->somit hebt es sich wieder auf
MIMDs ist es möglich mehrere unterschiedliche Daten- und Instruktions-Ströme gleichzeitig ausführen zu können, damit kann man in SIMDs-LeereEinheiten in einer MIMD-Architektur beschäftigen und die Effizens erhöhen

Nachteil: Nicht getestet; neue Treiber-Programmierung => zu hohes Risiko es zu Probieren

Aber ich sehe das sich NV zum Beispiel mit G200 und Fermi dem MIMDs immermehr annähert, zumindest meine beobachtung.

hoffe du verstehst es
LG

Aquaschaf
2010-03-02, 12:32:24
Aber ich sehe das sich NV zum Beispiel mit G200 und Fermi dem MIMDs immermehr annähert, zumindest meine beobachtung.

Nein, das ist genauso SIMD wie G80 bzw. je nachdem wie man es betrachtet sogar eher breiter.

Coda
2010-03-02, 12:57:19
Wenn man die Peak-Leistung von NV und AMD anschaut sieht man das in der Praxis die AMDs hinterher liegen. Die Ursache ist in den nicht ganz ausgelasteten SIMD-Arrays zu finden.
Nein. Das liegt an den Vektorrecheneinheiten von ATI. Das hat überhaupt nichts mit SIMD oder nicht zu tun.

GT200 hat in diesem Punkt auch exakt die gleiche Architektur wie G80.

hoffe du verstehst es
Nicht wirklich. Deine sprachliche Ausdrucksweise ist immer noch sehr gewöhnungsbedürftig. Aus dem Kauderwelsch wird man kaum schlau.

VinD
2010-03-02, 15:19:33
Nein. Das liegt an den Vektorrecheneinheiten von ATI. Das hat überhaupt nichts mit SIMD oder nicht zu tun.

klar die 5te Einheit ist eigendlich zu vernachlässigen... und ich finde die SIMDs von AMD/ATI sind viel zu breit.

GT200 hat in diesem Punkt auch exakt die gleiche Architektur wie G80.

Klar, nur mehr Einheiten die jeweils mehr können. Z.B. ist das MUL des G80 im G200 auch für anderes verwendbar. Zudem wurden große teile der Organisation überarbeitet:

G80:
2x8Alus (2 SIMD)=1Sreaming Multiprocessor
8 SM (8 MiMD) + TMU/ROP = G80 (128)

G200:
2x4Alus (1 SIMD)=1Streaming Multiprocessor
3 SM (3 MIMD)= 1ShaderCluster + TMU/ROP
10 SC (10 MIMD) = G200 (240)


Nicht wirklich. Deine sprachliche Ausdrucksweise ist immer noch sehr gewöhnungsbedürftig. Aus dem Kauderwelsch wird man kaum schlau.

Viell hilft dir das dabei:
http://groups.google.com/group/alt.comp.hardware.amd.x86-64/browse_thread/thread/3c20b91418f571d5

Beispiel: Stell dir vor...
...du willst nur die Eckpunkte eines Dreiecks manipulieren.
Du hast je eckpunkt 3Koordinaten die du in alle drei Raumrichtungen verschiebst.
Sind also 3x3x3=27 Additionen die ein SIMD erledingen muss.
Du hast bei AMD 80(5D) bzw. effektiv 64(4d)Vector-Units zu verfügung. Was machen die anderen 53(5D) bzw. 37(4D) Vector-Units?
Bei NV werden die koordinaten(xyz) nacheinander abgerechnet...
...also brauchst du nur 3 Einheiten von 8 ALUs(G200) oder 16 ALUs(G80) die anderen 5(G200) oder 13(G80) Machen wieder garnix.

Vorschlag:
2x2Alus (1 SIMD)=1 Quad *Jede ALU ist 128Bit breit und Multifunktional sowie Skalar
16 Quad (16 MIMD)= 1 QuadCluster
32 QC (32 MIMD) = Was-Weiß-Ich (4096)

Pinoccio
2010-03-02, 15:38:03
Viell hilft dir das dabei:sOT: ymmd :-)
Beispiel: Stell dir vor...
...du willst nur die Eckpunkte eines Dreiecks manipulieren.
Du hast je eckpunkt 3Koordinaten die du in alle drei Raumrichtungen verschiebst.:confused:

mfg

Der_Korken
2010-03-02, 18:30:17
Das verstehe ich nicht ganz.
Eine universelle Recheneinheit kann alles Rechnen und wird nicht dadurch langsamer das Sie z.B ROP-funktionen beherrscht (sie kann eh alles rechnen, da frei Programmierbar).
Der Grund warum das nicht gemacht wird ist, dass die entsprechenden Funktionen sehr unperformant in Software nachgebildet werden können.
Ineffizient sind eher die FF-Einheiten, da Sie wenn nicht genug geeignete Aufgaben vorliegen wenig leisten und im Extremfall lange Zeit überhaupt nichts tun.

Effizienz kann man auf verschiedene Weisen auslegen. Natürlich erreicht man mit universellen Einheiten immer eine höhere Auslastung, da kein Einzelfaktor limitiert, sondern wenn dann nur die Gesamtzahl an Einheiten. Die Frage ist aber, wie viele ALUs man braucht, um damit die TMUs und ROPs zu ersetzen, um welche Funktionen man sie eventuell erweitern muss und ob sich das in der Transistoren/Energiebilanz rechnet. Bald kommt auch noch Tesselation dazu, was die Sache auch noch komplizierter macht. Wenn du alles in einem haben willst, werden ALUs Unmengen an Transistoren verschlingen im Vergleich zu heutigen ALUs. Möglicherweise ist es dann eben doch klüger, sich FF-Einheiten zu behalten, die zwar nicht immer voll ausgelastet sind aber nur einen Bruchteil der Transistoren (und entsprechend auch Energie) brauchen. Das sehe ich eben auch als eine Form der Effizienz an.

Gast
2010-03-02, 18:43:01
Effizienz kann man auf verschiedene Weisen auslegen. Natürlich erreicht man mit universellen Einheiten immer eine höhere Auslastung, da kein Einzelfaktor limitiert, sondern wenn dann nur die Gesamtzahl an Einheiten. Die Frage ist aber, wie viele ALUs man braucht, um damit die TMUs und ROPs zu ersetzen, um welche Funktionen man sie eventuell erweitern muss und ob sich das in der Transistoren/Energiebilanz rechnet. Bald kommt auch noch Tesselation dazu, was die Sache auch noch komplizierter macht. Wenn du alles in einem haben willst, werden ALUs Unmengen an Transistoren verschlingen im Vergleich zu heutigen ALUs. Möglicherweise ist es dann eben doch klüger, sich FF-Einheiten zu behalten, die zwar nicht immer voll ausgelastet sind aber nur einen Bruchteil der Transistoren (und entsprechend auch Energie) brauchen. Das sehe ich eben auch als eine Form der Effizienz an.

Es kann sein, dass ich das jetzt falsch verstanden habe für den Fall sry.
Die jetzigen ALUs können bereits Alles. Sie müssen nicht größer werden.
Man kann auf dieser Fläche die durch die Entfernung der FF frei wird mehr von Ihnen platzieren. Der Rest hängt eben von der Performanz der Softwareemulation ab. Es gibt Sachen die könnte man durchaus einigermaßen performant nachbilden(ROPs) andere (Filtereinheiten) währen einfach viel zu langsam mit den heute zur Verfügung stehenden Algorhytmen.
Es ist am Ende nur noch eine reine Softwarefrage die ALUs sind grundsätzlich schon heute dazu in der Lage.

VinD
2010-03-02, 18:46:03
Effizienz kann man auf verschiedene Weisen auslegen. Natürlich erreicht man mit universellen Einheiten immer eine höhere Auslastung, da kein Einzelfaktor limitiert, sondern wenn dann nur die Gesamtzahl an Einheiten. Die Frage ist aber, wie viele ALUs man braucht, um damit die TMUs und ROPs zu ersetzen, um welche Funktionen man sie eventuell erweitern muss und ob sich das in der Transistoren/Energiebilanz rechnet. Bald kommt auch noch Tesselation dazu, was die Sache auch noch komplizierter macht. Wenn du alles in einem haben willst, werden ALUs Unmengen an Transistoren verschlingen im Vergleich zu heutigen ALUs. Möglicherweise ist es dann eben doch klüger, sich FF-Einheiten zu behalten, die zwar nicht immer voll ausgelastet sind aber nur einen Bruchteil der Transistoren (und entsprechend auch Energie) brauchen. Das sehe ich eben auch als eine Form der Effizienz an.

Ab einer bestimmten Einheitenanzahl muss man sich allerdings doch überlegen was am besten dafür geeignet ist ALLE Einheiten Ordentlich Auszulasten.

@Gast: am R600-670 sah man das es möglich ist, da da die Textur-Einheiten Defekt waren und die ALUs zu hilfe genommen werden mussten.

Aquaschaf
2010-03-02, 19:36:24
@Gast: am R600-670 sah man das es möglich ist, da da die Textur-Einheiten Defekt waren

Seit wann denn das?

Der_Korken
2010-03-02, 20:10:22
Es kann sein, dass ich das jetzt falsch verstanden habe für den Fall sry.
Die jetzigen ALUs können bereits Alles. Sie müssen nicht größer werden.
Man kann auf dieser Fläche die durch die Entfernung der FF frei wird mehr von Ihnen platzieren. Der Rest hängt eben von der Performanz der Softwareemulation ab. Es gibt Sachen die könnte man durchaus einigermaßen performant nachbilden(ROPs) andere (Filtereinheiten) währen einfach viel zu langsam mit den heute zur Verfügung stehenden Algorhytmen.
Es ist am Ende nur noch eine reine Softwarefrage die ALUs sind grundsätzlich schon heute dazu in der Lage.

OK, wenn die ALUs das heute schon theoretisch in Software ausführen können, wäre es eine Hürde weniger. Aber ich glaube, dass uns zumindest die TMUs noch ne Weile erhalten bleiben, weil die ALU-Ressourcen zu wertvoll ist, als dass man mit denen alles in Software filtert. Es ist ein wenig wie mit CPU und GPU. Eine CPU lastet ihre Einheiten besser aus als jede GPU. Trotzdem ist die CPU kein Ersatz, weil sie viel zu wenig Rohleistung hat.

Gast
2010-03-02, 21:25:31
OK, wenn die ALUs das heute schon theoretisch in Software ausführen können, wäre es eine Hürde weniger. Aber ich glaube, dass uns zumindest die TMUs noch ne Weile erhalten bleiben, weil die ALU-Ressourcen zu wertvoll ist, als dass man mit denen alles in Software filtert. Es ist ein wenig wie mit CPU und GPU. Eine CPU lastet ihre Einheiten besser aus als jede GPU. Trotzdem ist die CPU kein Ersatz, weil sie viel zu wenig Rohleistung hat.

Das kommt darauf an, wie lange es dauert um einen entsprechenden Algorithmus zu finden, der das Filtern in Software deutlich beschleunigt.
Ansonsten wir wohl auch in Zukunft zumindest jede Highendkarte TMUs haben.

Den Vergleich zwischen GPU und CPU Einheiten ist wohl in jeder Hinsicht sinnlos.
Aber dennoch ist die CPU ein besserer GPU-Ersatz als umgekehrt.

VinD
2010-03-07, 22:56:29
Hier ein Diagramm mit evtl bezug auf den Fermi (von 2008).

http://extreme.pcgameshardware.de/attachments/87725d1237893724-geforce-gtx-380-high-end-performance-mit-gt212-oder-erst-mit-gt300-gpu-jon_olick_future_of_rasterization_alluding_to_gt300.png

Wenn man diese Engpässe in die Shader-ALUs verschiebt, ist eine größere Beschleunigung sicherlich möglich.

Die TMU/TAU-Einheiten des Fermi wurden auchschon Load/STore-EInheiten genannt. Es sieht also nach universalisierung der Shader-ALUs aus ;)

Coda
2010-03-07, 23:46:29
@Gast: am R600-670 sah man das es möglich ist, da da die Textur-Einheiten Defekt waren und die ALUs zu hilfe genommen werden mussten.
Blödsinn. Die ROPs waren (vielleicht) teilweise kaputt. Texturierung in den ALUs habe ich zufälligerweise schon ausführlich gemacht (siehe Signatur). Und es ist auch auf heutigen GPUs viel zu langsam.

Die TMU/TAU-Einheiten des Fermi wurden auchschon Load/STore-EInheiten genannt. Es sieht also nach universalisierung der Shader-ALUs aus ;)
Load/Store und TMUs sind doch etwas anderes in Fermi. Das neuste Paper anschauen.

pest
2010-03-08, 01:02:17
Du hast je eckpunkt 3Koordinaten die du in alle drei Raumrichtungen verschiebst.
Sind also 3x3x3=27 Additionen die ein SIMD erledingen muss.


rechtschreibsprechrechenschwäche? :freak:

Coda
2010-03-08, 01:08:35
klar die 5te Einheit ist eigendlich zu vernachlässigen... und ich finde die SIMDs von AMD/ATI sind viel zu breit.
Nein, die ist nicht "zu vernachlässigen", auch nicht "eigentlich". Die Breite ist relativ zu betrachten. Normalerweise liegt die Auslastung zwischen 60 bis 80%. Dafür bekommt AMD aber momentan auch deutlich mehr Rechenleistung pro Chipfläche unter.

Das hat nichts mit SIMD oder MIMD zu tun. Ob man auf einzelner Instruktionseben VLIW oder skalare Ops hat ist bei der Betrachtung völlig irrelevant.


Klar, nur mehr Einheiten die jeweils mehr können. Z.B. ist das MUL des G80 im G200 auch für anderes verwendbar.
Das war es auch bei G80, nur noch eingeschränkter. Allgemein ist dieses MUL aber auch bei G200 ziemlich irrelevant, weil das Scheduling ziemlich komplex ist für den Compiler und zudem die SFUs die es zur Verfügung stellen auch Interpolation und transzendente Funktionen ausführen müssen.

G80:
2x8Alus (2 SIMD)=1Sreaming Multiprocessor
8 SM (8 MiMD) + TMU/ROP = G80 (128)

G200:
2x4Alus (1 SIMD)=1Streaming Multiprocessor
3 SM (3 MIMD)= 1ShaderCluster + TMU/ROP
10 SC (10 MIMD) = G200 (240)
Ein Streaming Multiprocessor hat sowohl bei G80 als auch G200 jeweils 8 ALUs (ein SIMD). Der TPC hat bei G200 drei davon, bei G80 zwei. Das ist alles.

Du wirfst da offensichtlich Sachen durcheinander.

Beispiel: Stell dir vor...
...du willst nur die Eckpunkte eines Dreiecks manipulieren.
Du hast je eckpunkt 3Koordinaten die du in alle drei Raumrichtungen verschiebst.
Sind also 3x3x3=27 Additionen die ein SIMD erledingen muss.
Du hast bei AMD 80(5D) bzw. effektiv 64(4d)Vector-Units zu verfügung. Was machen die anderen 53(5D) bzw. 37(4D) Vector-Units?
Bei NV werden die koordinaten(xyz) nacheinander abgerechnet...
...also brauchst du nur 3 Einheiten von 8 ALUs(G200) oder 16 ALUs(G80) die anderen 5(G200) oder 13(G80) Machen wieder garnix.
Jetzt wird's völlig konfus. Es läuft nicht ein Thread auf einem SIMD, sondern viele. Du verwechselst Thread-Parallelität mit Instruction-Parallelität. Letztere gibt es nur bei ATI.

Ein Wavefront einer 5870 enthält immer 64 Threads die parallel durch einen SIMD-Cluster gehen (z.B. 64 Pixel oder 64 Eckpunkte). Um Latenzen zu vermeiden sind aber über den ganzen Chip gleichzeitig sogar mehrere tausend Threads "in flight". Die 64 Threads ergeben sich dadurch weil 16 ALUs in einem SIMD vorhanden sind und jede Pipeline-Stage 4x loopt.

Nochmal: Die Auslastung der VLIW-ALU-Einheiten bei ATI hat *REIN GARNICHTS* mit der Auslastung eines SIMD zu tun. Letztere kann nur durch Sprungdivergenzen innerhalb einer Wavefront beeinflusst werden. Die Auslastung der einzelnen Recheneinheiten wird auch statisch durch den Compiler vorgenommen, während die Auslastung der SIMDs ein Problem bei der Ausführung ist.

In dem von dir aufgeführten Beispiel hättest du sowohl bei G80 als auch G200 jeweils eine Auslastung von 100%, weil gar keine Sprünge vorkommen. Deine 27 Operationen gelten zwar für einen Thread, aber es wird nicht ein Thread auf einem 8er SIMD ausgeführt (ja, auch G80 hat 8er SIMDs, siehe oben), sondern 32 davon (entspricht einem Warp; wie bei ATI loopt jede Stage 4x). Mit einer effektiven Latenz von 108 Takten werden also 32 Dreiecke gleichzeitig fertig und keine ALU hat auch nur einen Takt nichts zu tun gehabt.

Im Falle einer ATI-Karte müssen die 27 Ops zunächst vom Compiler auf die Vektoreinheiten verteilt werden. Da es keinerlei Abhängigkeiten gibt geht das in diesem Fall mit 6 VLIW-Ops pro Threads. Also 24 Takte für 64 Threads/Dreiecke und eine Auslastung von 90%.

Noch dazu werden die Wavefronts/WARPs in jedem SIMD-Cluster abwechselnd gescheduled um Latenzen bei Speicher- und Texturzugriffen zu verstecken. Alle 4 Takte läuft also normalerweise eine andere Wavefront/WARP in einer Pipeline-Stage. Die Anzahl der Wavefronts/WARPs wird in einem Cluster nur durch die Größe des Registerfiles begrenzt. Das ist auch der Grund warum man große Registerfiles braucht um Blasen in der Pipeline zu vermeiden.

Das Beispiel an sich ist übrigens schon ziemlich obskur, denn um ganze Dreiecke zu bearbeiten muss man Geometry Shader verwenden. Was für so eine Aktion ziemlich komisch wäre. Normalerweise macht man sowas in einem Vertex Shader der nur Eckpunkte "sieht".

Ich weiß, dass das alles schwer zu verstehen ist, aber du hast dir da gefährliches Halbwissen angelesen.

VinD
2010-03-09, 15:04:06
Nein, die ist nicht "zu vernachlässigen", auch nicht "eigentlich". Die Breite ist relativ zu betrachten. Normalerweise liegt die Auslastung zwischen 60 bis 80%. Dafür bekommt AMD aber momentan auch deutlich mehr Rechenleistung pro Chipfläche unter.

Das hat nichts mit SIMD oder MIMD zu tun. Ob man auf einzelner Instruktionseben VLIW oder skalare Ops hat ist bei der Betrachtung völlig irrelevant.



Das war es auch bei G80, nur noch eingeschränkter. Allgemein ist dieses MUL aber auch bei G200 ziemlich irrelevant, weil das Scheduling ziemlich komplex ist für den Compiler und zudem die SFUs die es zur Verfügung stellen auch Interpolation und transzendente Funktionen ausführen müssen.


Ein Streaming Multiprocessor hat sowohl bei G80 als auch G200 jeweils 8 ALUs (ein SIMD). Der TPC hat bei G200 drei davon, bei G80 zwei. Das ist alles.

Du wirfst da offensichtlich Sachen durcheinander.


Jetzt wird's völlig konfus. Es läuft nicht ein Thread auf einem SIMD, sondern viele. Du verwechselst Thread-Parallelität mit Instruction-Parallelität. Letztere gibt es nur bei ATI.

Ein Wavefront einer 5870 enthält immer 64 Threads die parallel durch einen SIMD-Cluster gehen (z.B. 64 Pixel oder 64 Eckpunkte). Um Latenzen zu vermeiden sind aber über den ganzen Chip gleichzeitig sogar mehrere tausend Threads "in flight". Die 64 Threads ergeben sich dadurch weil 16 ALUs in einem SIMD vorhanden sind und jede Pipeline-Stage 4x loopt.

Nochmal: Die Auslastung der VLIW-ALU-Einheiten bei ATI hat *REIN GARNICHTS* mit der Auslastung eines SIMD zu tun. Letztere kann nur durch Sprungdivergenzen innerhalb einer Wavefront beeinflusst werden. Die Auslastung der einzelnen Recheneinheiten wird auch statisch durch den Compiler vorgenommen, während die Auslastung der SIMDs ein Problem bei der Ausführung ist.

In dem von dir aufgeführten Beispiel hättest du sowohl bei G80 als auch G200 jeweils eine Auslastung von 100%, weil gar keine Sprünge vorkommen. Deine 27 Operationen gelten zwar für einen Thread, aber es wird nicht ein Thread auf einem 8er SIMD ausgeführt (ja, auch G80 hat 8er SIMDs, siehe oben), sondern 32 davon (entspricht einem Warp; wie bei ATI loopt jede Stage 4x). Mit einer effektiven Latenz von 108 Takten werden also 32 Dreiecke gleichzeitig fertig und keine ALU hat auch nur einen Takt nichts zu tun gehabt.

Im Falle einer ATI-Karte müssen die 27 Ops zunächst vom Compiler auf die Vektoreinheiten verteilt werden. Da es keinerlei Abhängigkeiten gibt geht das in diesem Fall mit 6 VLIW-Ops pro Threads. Also 24 Takte für 64 Threads/Dreiecke und eine Auslastung von 90%.

Noch dazu werden die Wavefronts/WARPs in jedem SIMD-Cluster abwechselnd gescheduled um Latenzen bei Speicher- und Texturzugriffen zu verstecken. Alle 4 Takte läuft also normalerweise eine andere Wavefront/WARP in einer Pipeline-Stage. Die Anzahl der Wavefronts/WARPs wird in einem Cluster nur durch die Größe des Registerfiles begrenzt. Das ist auch der Grund warum man große Registerfiles braucht um Blasen in der Pipeline zu vermeiden.

Das Beispiel an sich ist übrigens schon ziemlich obskur, denn um ganze Dreiecke zu bearbeiten muss man Geometry Shader verwenden. Was für so eine Aktion ziemlich komisch wäre. Normalerweise macht man sowas in einem Vertex Shader der nur Eckpunkte "sieht".

Ich weiß, dass das alles schwer zu verstehen ist, aber du hast dir da gefährliches Halbwissen angelesen.

Kurz gesagt, jede ALU ist einzeln Ansteuerbar und kann jeweils mit bis zu 64 Threads gefüttert werden, die je 4Takte Zeit haben. Die SIMDs, die die Vielen ALUs enthalten, senden an ihre ALUs ein Signal, das einen Thread-Wechsel hervorruft. Gleichzeitig haben 4ALUs + 1SU-ALU (5D) einen kleinen Gemeinsamen Speicher, um Latenzen bei häufig gebrauchten Vector-Rechnungen(z.B. 2D; 3D; 4D) zu vermeiden.
Diese "5D-ALUs" sind 16 mal in einem Cluster mit zusätzlich 4(?)TMUs und einem kleinen Cache um Latenzen zu verstecken.
Die SIMD-Cluster (20 Stück beim 5870) bekommen nicht zur gleichen Zeit ein Thread-Wechsel-Signal sondern nacheinander um einen Massiven Speicherzugriff zu vermeiden.
Soweit Richtig?

Coda
2010-03-10, 17:15:50
Kurz gesagt, jede ALU ist einzeln Ansteuerbar und kann jeweils mit bis zu 64 Threads gefüttert werden, die je 4Takte Zeit haben.
Nein. Ein SIMD aus 16 ALUs wird mit 64 Threads gefüttert. Und nein sie haben nicht "4 Takte Zeit", sondern brauchen 4 Takte je Pipeline Stage.

Es sind also gleichzeitig mehrere Wavefronts (64 Threads) gleichzeitig in der Pipeline.

Die SIMDs, die die Vielen ALUs enthalten, senden an ihre ALUs ein Signal, das einen Thread-Wechsel hervorruft.
Das ergibt keinen Sinn.

Gleichzeitig haben 4ALUs + 1SU-ALU (5D) einen kleinen Gemeinsamen Speicher, um Latenzen bei häufig gebrauchten Vector-Rechnungen(z.B. 2D; 3D; 4D) zu vermeiden.
Nö. Es gibt ein großes Registerfile in einem SIMD. Und du machst immer noch den Eindruck als würdest du meinen als wären das Vektor-ALUs. Das ist so nicht richtig. Es ist VLIW, das heißt jede der fünf ALUs kann völlig unabhängig angesteuert werden. Die einzigen Einschränkungen sind, dass nur die 5. die Sonderoperationen durchführen kann und natürlich die Berechnungen unabhängig sein müssen.

Diese "5D-ALUs" sind 16 mal in einem Cluster mit zusätzlich 4(?)TMUs und einem kleinen Cache um Latenzen zu verstecken.
Ja. Die 16 5D-ALUs sind ein SIMD, und zusammen mit den 4 TMUs ein Cluster.

Die SIMD-Cluster (20 Stück beim 5870) bekommen nicht zur gleichen Zeit ein Thread-Wechsel-Signal sondern nacheinander um einen Massiven Speicherzugriff zu vermeiden.
Es laufen tausende Wavefronts gleichzeitig und wenn einer warten muss kommt halt der andere dran. Mit einem Signal hat das wenig zu tun.

VinD
2010-03-11, 16:19:58
Nö. Es gibt ein großes Registerfile in einem SIMD. Und du machst immer noch den Eindruck als würdest du meinen als wären das Vektor-ALUs. Das ist so nicht richtig. Es ist VLIW, das heißt jede der fünf ALUs kann völlig unabhängig angesteuert werden. Die einzigen Einschränkungen sind, dass nur die 5. die Sonderoperationen durchführen kann und natürlich die Berechnungen unabhängig sein müssen.


5 ALUs nutzen nicht ein gemeinsames Register, wenn sie dafür ausgelegt sind alleine zu rechnen oder?
Es wird immer von einer 5D-Vectoreinheit gesprochen statt von 5 ALUs die sich ein Register teilen und 5D-Vetoren begünstigen ;)
In vielen Dokumenten wird allerdings davon ausgegangen, dass es schwieriger ist 1D+1D+1D+1D+1D(cosin) zu erzeugen. Somit seien die 5ALUs nie ausgelastet und der Threadwechsel würde auch nicht viel bringen, dann sind nur andere ALUs im Leerlauf.

Dann gehört der 16Kbyte Cache also je einer ganzen SIMD und nicht 5ALUs. Es steht immer sehr schwammig da.
z.B. Nennt man 5ALUs einen Shaderkern und schreibt im nächsten Satz, dass jeder Shaderkern zugriff auf einen 16Kbyte großen Cache hat, kann man leicht auf den Gedanken kommen das eine SIMD-Einheit 16 mal 16Kbyte Cache besitzt.
Ich frage mich grade wo du alles so verausfinden kannst ohne Denkunfälle zu produzieren.

BTT:
@Coda: wie sähe eine GPU aus wenn du es in der Hand hättest sie zu entwickeln?
DIe Frage stell ich auch jedem der hier mal vorbeischaut ; D

Nighthawk13
2010-03-17, 00:13:58
@Vind: Vielleicht klärt das einige Unklarheiten(Seite 11-13):
http://developer.amd.com/gpu_assets/Stream_Computing_Overview.pdf

Ich versuchs auch mal zu erklären.
Architektur:
- Der RV870-Chip(Stream-Prozessor) besteht aus 20 SIMD-Engines, die unabhängig voneinander arbeiten
- Jede SIMD-Engine ist in 16 ThreadProzessoren unterteilt, die stets die gleiche Instruktion ausführen(ein VLIW).
- Jeder Thread-Prozessor hat 5 skalare Alus(Stream-Cores), die von einem VLIW gesteuert werden

Ablauf:
- Alle 4 Takte führt eine SIMD-Engine ein identisches VLIW für eine Wavefront(=Bündel aus 64 Threads) aus
- In Takt0 wird das VLIW für die Threads 0-15 ausgeführt, Takt2: Threads 16-31, Takt3: Threads 32-47, Takt4: Threads 48-63. Jeweils von den 16 Threadprozessoren.
- In jedem VLIW sind 5 skalare Instruktionen kodiert, die keine Abhängigkeit untereinander haben. Eine Instruktion davon kann komplex sein(sin/cos), die anderen 4 MAD.

=> Dieses 5D-VLIW wurde vom Compiler erzeugt und ist danach fix.
Wenn der (Shader-)-Sourcecode nicht genug unabhängige Instruktionen ermöglicht, wird das VLIW mit bis zu 4 NOPs aufgefüllt, und die Effizienz sinkt entsprechend auf bis zu 20%.

Zusammenfassend: Je SIMD-Engine und Taktzyklus werden also bis zu 16x5=80 skalare Instruktionen abgearbeitet. Auf dem gesamten Chip also 20x80=1600.

Gast
2010-03-18, 13:31:20
Nvidia plant zukünftig Rechnerarchitekturen und CPUs per GPU zu emulieren.

Dazu soll eine spezielle an Cuda angepasste Virtual Machine genutzt werden, der Vorteil des Systems ist einfach die riesige Flexibilität. So kann man mit der Virtual Machine jedes Computersystem der letzten 20 Jahre simulieren, der eigentliche Hauptprozesor wird dabei nahezu unnötig.

Doch bevor es soweit ist müssen die Cuda-Cores weiterentwickelt werden um ein effizientes abarbeiten von CPU-Code zu sichern.

VinD
2010-03-20, 10:30:37
@Nighthawk13
danke. Ist wirklich mal so erklärt, dass man es auf Anhieb verstehen kann ;)

BTT: habt ihr ne Idee wie man den Overdraw(:=EDIT danke Neomi^^) beseitigen könnte, der entsteht wenn mehrere Dreiecke übereinander gezeichnet werden?(Verdeckung) Jegliche Art von Vorausberechnung scheint soviel Transistoren zu fressen das sich NV und ATI nicht herantrauen soetwas zu integrieren.

Gast
2010-03-20, 12:04:58
BTT: habt ihr ne Idee wie man den Overhead beseitigen könnte, der entsteht wenn mehrere Dreiecke übereinander gezeichnet werden?(Verdeckung)


Raytracing ;)

VinD
2010-03-20, 13:33:22
Raytracing ;)
ein Teilalgoritmus viell, aber sicher nicht alles, da es noch aufwendiger ist als Rastering. Ich will doch Leistung sparen um schneller zu sein und nicht andersherum.
Obwohl, es gab bisher keine Raytrace-Optimierte Hardware, deshalb könnte man nicht sagen ob es effizenter und schneller arbeitet bei gleichem Transistorbugget... mhmm...

Neomi
2010-03-20, 18:50:29
BTT: habt ihr ne Idee wie man den Overhead beseitigen könnte, der entsteht wenn mehrere Dreiecke übereinander gezeichnet werden?

Overhead ist Zusatzarbeit (bzw. Zusatzdaten) zur Koordination der eigentlichen Arbeit (bzw. Daten). Was du meinst ist Overdraw.

Um Overdraw zu verhindern, können GPUs eigentlich nur zwei Dinge machen:

1. Early-Z Rejection, dabei werden resultierende Pixelblöcke von Dreiecken (Vertextransformation und Triangle Setup bereits geschehen) recht früh in der Pixelpipeline verworfen, wenn ein Z-Fail sicher ist. Dazu müssen die passenden Renderstates gegeben sein (Z-Test an) und der Pixelshader darf den Z-Wert nicht verändern.

2. Deferred Rendering, so wie es der Kyro II z.B. kachelbasiert gemacht hat. Dabei werden Dreiecke nicht direkt gezeichnet, sondern erstmal gesammelt und dann vor dem Zeichnen sortiert.

Die Early-Z Rejection sollte durch die Grafikengine unterstützt werden, so daß eine sehr hohe Effizient entsteht. Solide Geometrie (also Z-Write an und Alphablending aus) sollte von vorne nach hinten gezeichnet werden, transparente Geometrie danach von hinten nach vorne. Einzelne Meshes lassen sich auch noch so optimieren, daß interne Überlappungen aus verschiedenen Betrachtungswinkeln heraus mit hoher Wahrscheinlichkeit diese Anforderungen erfüllen. Auch ein vorgeschalteter Z-Pass kann helfen, wenn die Vertexlast niedrig und die Pixellast hoch ist.

Alle anderen Möglichkeiten funktionieren nicht ohne konkrete Unterstützung durch die Grafikengine (z.B. Predicated Rendering) bzw. müssen durch die Grafikengine alleine abgearbeitet werden (z.B. Frustrum Culling).

VinD
2010-03-21, 10:14:40
@Neomi:
Wenn man das vordere Dreieck vom dahinterliegenden Abschneidet und aus dem "verkrüppelten" Dreieck 2 oder mehr Dreiecke macht, könnte man sich auch den Overdraw sparen. Wäre evtl. beim Tesselator einfügbar. Ich mach mir dann nur sorgen um Schattenberechnungen und Spiegelungen auf grundlage der nun fehlenden Vertex-Punkte.

Neomi
2010-03-21, 16:51:26
Wenn man das vordere Dreieck vom dahinterliegenden Abschneidet und aus dem "verkrüppelten" Dreieck 2 oder mehr Dreiecke macht, könnte man sich auch den Overdraw sparen. Wäre evtl. beim Tesselator einfügbar.

Ein Dreieck kann ein dahinter liegendes Dreieck in bis zu 6 kleinere Dreiecke schneiden. Wenn du das mit vielen Dreiecken machst (jedes resultierende wird durch weitere Dreiecke evtl. weiter geschnitten), hast du für ein Ursprungsdreieck hinterher evtl. hunderte Mikrodreiecke, die nur so kleine Pixelbereiche abdecken, daß alleine das Rendering danach schon furchtbar ineffizient wird. Dazu kommt eben noch die nicht gerade triviale Extralogik zum Schneiden und zusätzliche Buffer für die zusätzlich erzeugte Geometrie.

So eine Herangehensweise würde imho deutlich mehr Schaden verursachen als Nutzen. Wenn ich schätzen sollte, was es gegenüber Early-Z Rejection (bei einfach nur sortierten Dreiecken) "bringt", dann würde ich von 5% Vorsprung im konstruierten Best Case und einen Einbruch auf 10-20% der Ursprungsperformance im Worst Case (gezielt konstruiert wahrscheinlich noch weniger) ausgehen.

Ich mach mir dann nur sorgen um Schattenberechnungen und Spiegelungen auf grundlage der nun fehlenden Vertex-Punkte.

Gerade das nicht. Schatten und Spiegelungen werden in eigenen Durchläufen berechnet, in eigene Rendertargets und mit anderen Kamerapositionen und Blickrichtungen als die, die der Spieler letztendlich sieht. Schatten und Spiegelungen sind keine Fähigkeiten der GPU, sondern nur Nutzungsmöglichkeiten von Rendertarget-Texturen und Dependant Texture Reads.

Coda
2010-03-21, 20:56:35
@Nighthawk13
danke. Ist wirklich mal so erklärt, dass man es auf Anhieb verstehen kann ;)
Ich bezweifel, dass du es verstanden hast.

VinD
2010-03-21, 20:57:01
Ein Dreieck kann ein dahinter liegendes Dreieck in bis zu 6 kleinere Dreiecke schneiden. Wenn du das mit vielen Dreiecken machst (jedes resultierende wird durch weitere Dreiecke evtl. weiter geschnitten), hast du für ein Ursprungsdreieck hinterher evtl. hunderte Mikrodreiecke, die nur so kleine Pixelbereiche abdecken, daß alleine das Rendering danach schon furchtbar ineffizient wird. Dazu kommt eben noch die nicht gerade triviale Extralogik zum Schneiden und zusätzliche Buffer für die zusätzlich erzeugte Geometrie.


Anwendungsbezogen hab ich ehrlichgesagt nie ein einzelnes Dreieck über ein anderes gesehen bzw. innerhalb ;)

Es wurde schon immer viel unsinn vermieden, dementsprechend könnte man es trotzdem erlauben ein Dreieck in einer bestimmten Tolleranz mit einem Anderen schneiden zu lassen.

Die extralogik sollte sich in grenzen halten, da der Tesselator nix anderes macht als Dreiecke zu zerlegen. müsste nur entsprechend modifiziert werden.

Coda
2010-03-21, 21:13:59
Die Extralogik dafür würde sich ganz bestimmt nicht in Grenzen halten. Die IMR-GPUs haben von der Polygonsuppe als Ganzes bisher überhaupt keine Ahnung.

Was du willst hat PowerVR bereits vor Jahren implementiert und zwar auf intelligenterem Wege als irgendwas zu zerschneiden.

VinD
2010-03-21, 23:05:26
Die Extralogik dafür würde sich ganz bestimmt nicht in Grenzen halten. Die IMR-GPUs haben von der Polygonsuppe als Ganzes bisher überhaupt keine Ahnung.

An beiden Enden sparen:= in Treiber den Algorithmus schreiben und in Hardware den Algorithmus BEGÜNSTIGEN


Was du willst hat PowerVR bereits vor Jahren implementiert und zwar auf intelligenterem Wege als irgendwas zu zerschneiden.
PowerVR verwirft komplettverdeckte Dreiecke. Ich will allerdings auch die Teile halbverdeckter Dreiecke rauslassen. Klar, was man in die Geometriezerschneidung und Aussortierung reinsteckt ist viell wahnsinn, könnte aber anderherum zu einem Problem werden(resultiernde Pixelleistung).
Oder gibt der Tesselator nur die Sichtbaren Dreiecke weiter? Wenn nicht, sollte man meiner Meinung nach wirklich nur die sichtbaren Teile weitergeben und den Rest verwerfen.

Und ja, bei ihm habe ich es verstanden, weil er es mit Wörtern erklärt, die auch ein "Halbwissender" kennt.

LG :>

Coda
2010-03-21, 23:56:28
An beiden Enden sparen:= in Treiber den Algorithmus schreiben und in Hardware den Algorithmus BEGÜNSTIGEN
Es gibt solche Algorithmen, aber es wäre wahnsinnig langsam sie zu implementieren. Egal ob in Software oder in Hardware.

PowerVR verwirft komplettverdeckte Dreiecke.
Nein. PowerVR berechnet die Verdeckung pixelgenau. Zero Overdraw. Ja, du hast richtig gelesen.

Es geht nicht besser. Und nein, sie schneiden dafür nicht an Dreiecken rum.

Oder gibt der Tesselator nur die Sichtbaren Dreiecke weiter? Wenn nicht, sollte man meiner Meinung nach wirklich nur die sichtbaren Teile weitergeben und den Rest verwerfen.
Der Tesselator sieht auf einmal genau *ein Dreieck*. Wie soll dieser mit diesen beschränkten Informationen irgendwas "abschneiden"?

VinD
2010-03-23, 15:04:45
Es gibt solche Algorithmen, aber es wäre wahnsinnig langsam sie zu implementieren. Egal ob in Software oder in Hardware.
Deswegen eine Kombination aus beidem: der Alogrithmus gesteuert vom Treiber und die Hardware-Einheiten auf Operationen ausgerichtet, die am häufigsten durchgeführt werden müssen. Es ist nie etwas am besten, sonst bräuchten wir ja auch nicht ständig neue Chipgenerationen.


Nein. PowerVR berechnet die Verdeckung pixelgenau. Zero Overdraw. Ja, du hast richtig gelesen.
Sie zeichnen die Z-Werte eines Dreiecks in einen internen Cache und ein bestimmter Z-Wert überschreibt einen anderen. Erst wenn das durchgeführt wurde, geht das Rendering richtig los. Es ist in meinen Augen allerdings nur eine verschiebung des Problems an eine Stelle wo noch nicht soviel Rechenleistung verpulvert wurde und spart durch den internen Cache noch Latenzen.


Es geht nicht besser. Und nein, sie schneiden dafür nicht an Dreiecken rum.

Wenn man die Projektionskorrektur für jedes Dreieck vorgenommen hat und nicht-sichtbare Dreiecke verworfen hat, muss man noch die halb-verdeckten Dreiecke zerkleinern/zerteilen und mit den resultierenden Daten wirklich nur die Pixel berechnen, die am Ende wirklich noch sichtbar sind. Und selbst allerkleinste Dreiecke sind noch ohne unendliche Verluste möglich, wenn man sich anguckt was der Tesselator anrichtet und die Chips noch an Framerate herauskitzeln können. Zudem fällt ja jetzt auch nötige Rechenleistung weg ( Pixelberechnungen), die man in diesem Schritt wieder nutzen kann(Latenzwahrscheinlichkeit steigt durch kleinere Dreiecke).


Der Tesselator sieht auf einmal genau *ein Dreieck*. Wie soll dieser mit diesen beschränkten Informationen irgendwas "abschneiden"?
Er zerlegt ein Dreieck(Input 1) anhand einer Beschreibung/Map(Input 2) wenn nun ein Teil der Map frei ist (also Rechnungslos). Verschont er den Teil dann mit seiner Rechnung oder lässt er ihn weg? Bei zweiterem wäre sicher ein 'leichtes' ein zerteilen von Dreiecken hervorzurufen, um verschwendete Pixelrechnungen zu sparen.

LG

Coda
2010-03-24, 02:19:32
Sie zeichnen die Z-Werte eines Dreiecks in einen internen Cache und ein bestimmter Z-Wert überschreibt einen anderen. Erst wenn das durchgeführt wurde, geht das Rendering richtig los. Es ist in meinen Augen allerdings nur eine verschiebung des Problems an eine Stelle wo noch nicht soviel Rechenleistung verpulvert wurde und spart durch den internen Cache noch Latenzen.
Ja, und das ist zig mal effizienter als irgendwie was zu zerschneiden.

Wenn man die Projektionskorrektur für jedes Dreieck vorgenommen hat
Was soll bitte eine "Projektionskorrektur" sein?

und nicht-sichtbare Dreiecke verworfen hat, muss man noch die halb-verdeckten Dreiecke zerkleinern/zerteilen und mit den resultierenden Daten wirklich nur die Pixel berechnen, die am Ende wirklich noch sichtbar sind.
Und das ist um Magnituden aufwändiger als einfach das zu tun was PVR macht.

Er zerlegt ein Dreieck(Input 1) anhand einer Beschreibung/Map(Input 2) wenn nun ein Teil der Map frei ist (also Rechnungslos). Verschont er den Teil dann mit seiner Rechnung oder lässt er ihn weg? Bei zweiterem wäre sicher ein 'leichtes' ein zerteilen von Dreiecken hervorzurufen, um verschwendete Pixelrechnungen zu sparen.
Komplett wirres Zeug. Woher soll dein "Input 2" kommen? Willst du jedes Dreiecke mit jedem in der Szene vergleichen ob da was abzuschneiden wäre oder wie? Das allein ist O(n²) Komplexität und würde bei Mio. von Dreiecken in die Minuten Rechenzeit gehen.