Archiv verlassen und diese Seite im Standarddesign anzeigen : Larrabee vs. GT300 vs. RV870
turboschlumpf
2009-01-21, 00:02:14
Ich bitte um Input, sobald sich neue Annahmen zu den Spezifikationen treffen lassen.
Larrabee Fermi Cypress
Verfügbarkeit H1 2010 Q1 2010 Q4 2009
Fertigung 45 nm 40 nm 40 nm
Transistoren 3,1 Mrd. 2,15 Mrd.
Größe < 576 mm² 334 mm²
Chip 1,000 GHz 0,700 GHz 0,850 GHz
Shader 2,000 GHz 1,700 GHz 0,850 GHz
Speicher 1,000 GHz 1,200 GHz 1,200 GHz
"Cores" 32 16 20
VPUs/Core 1 32 16
VPU 16-wide 1-wide 5-wide
SP TFlop/s 2,048 1,740 2,720
512 MADD 512 FMA 1600 FMA
DP TFlop/s 0,512 0,870 0,544
128 MADD 256 FMA 320 FMA
ROPs 48 32
GPixel/s 33,6 27,2
TMUs 8 Quad 32 Quad 20 Quad
GTexel/s 32,0 89,6 68,0
SI 256 Bit 384 Bit 256 Bit
Speicher 1024 MiB 1536 MiB 1024 MiB
GDDR5 GDDR5 GDDR5
Bandbreite 128,0 GB/s 230,4 GB/s 153,6 GB/s
(Teilweise handelt es sich um Spekulationen ohne vorhandene Quellen.)
Larrabee GT300 RV870
Q1 2010 Q4 2009 Q4 2009
45 nm 40 nm 40 nm
TMUs 1,000 GHz 0,700 GHz 0,900 GHz
Shader 2,000 GHz 1,600 GHz 0,900 GHz
Speicher 1,000 GHz 1,100 GHz 1,100 GHz
"Cores" 32 16 12
VPUs/Core 1 4x8 20
VPU 16-wide 1-wide 5-wide
SP TFlop/s 2,048 2,458 2,160
512 MADD 512 MADD+MUL 1200 MADD
DP TFlop/s 0,512 0,410 0,432
128 MADD 128 MADD 240 MADD
TMUs 8 Quad 32 Quad 12 Quad
GTexel/s 32,0 89,6 43,2
256 bit 512 bit 256 bit
1024 MiB 2048 MiB 1024 MiB
GDDR5 GDDR5 GDDR5
128,0 GB/s 281,6 GB/s 140,8 GB/s
deekey777
2009-01-21, 01:04:05
Ich bin mir nicht ganz sicher, dass der LRB mit 48 Kernen kommen wird, eher mit 32. Die Daten des ersten Larrabee* stehen noch unter NDA und niemand will sie herausrücken.
*Auf Lehrgängen soll Intel schon von der zweiten Generation erzählen.
turboschlumpf
2009-01-21, 01:52:28
Es wird ja spekuliert, dass die Workstation-Variante von Larrabee in H2 2009 erscheinen soll und die Desktop-Variante dann H1 2010.
Wenn die Desktop-Variante erst H1 2010 erscheint, dann ist 32 nm zumindest nicht gänzlich unwahrscheinlich. Bei 45 nm hätte Intel trotz des späteren Launches nämlich einen Nachteil bei der Fertigungstechnologie. In 32 nm könnte man dann auch 48 Cores realisieren und zusätzlich eine teildeaktivierte Variante mit 32 Cores anbieten.
32 Cores und 45 nm wäre in H1 2010 etwas enttäuschend.
Vor allem bei Larrabee sind doch jegliche Spec-Vergleiche mit "traditonellen" Architekturen von vornherein total für die Katz.
Was soll das also?
reunion
2009-01-21, 07:35:25
Es wird ja spekuliert, dass die Workstation-Variante von Larrabee in H2 2009 erscheinen soll und die Desktop-Variante dann H1 2010.
Wenn die Desktop-Variante erst H1 2010 erscheint, dann ist 32 nm zumindest nicht gänzlich unwahrscheinlich. Bei 45 nm hätte Intel trotz des späteren Launches nämlich einen Nachteil bei der Fertigungstechnologie. In 32 nm könnte man dann auch 48 Cores realisieren und zusätzlich eine teildeaktivierte Variante mit 32 Cores anbieten.
32 Cores und 45 nm wäre in H1 2010 etwas enttäuschend.
Intel schafft es mit etwas Glück 32nm für CPUs im Q4/2009 vorzustellen. Da Larrabee zumindest in der Workstation-Variante offiziell im H2/2009 kommen soll kannst du das mit 32nm IMHO ganz schnell vergessen.
Ailuros
2009-01-21, 10:39:25
Vor allem bei Larrabee sind doch jegliche Spec-Vergleiche mit "traditonellen" Architekturen von vornherein total für die Katz.
Was soll das also?
Eine bessere Frage waere wie "traditionell" z.B. GT3x0 ueberhaupt sein koennte. Nur aus dem Grund dass NV die Welt so stark ueber USC vor dem G80 verarscht haben, traue ich ihnen so manches zu was D3D11 betrifft.
***edit: ich mach einen besseren spekulativen Vergleich:
LRB1 = insgesamt nichts besonders imposantes wegen beschissener Treiber.
LRB2 = zieht besser ab weil man dem Treiberteam mehr Zeit und Resourcen jeden Fetzen aus der hardware zu jagen LOL :D
Eine bessere Frage waere wie "traditionell" z.B. GT3x0 ueberhaupt sein koennte. Nur aus dem Grund dass NV die Welt so stark ueber USC vor dem G80 verarscht haben, traue ich ihnen so manches zu was D3D11 betrifft.naja, im gewissen sinne ist der G80 schon das selbe. 8core mit SIMD16. NVidia sagt natuerlich 128Cores im cluster von je 16 die einen codepfad abarbeiten koennen... aber genau das ist SIMD.
2010 duerften 1GB Vram im Midrange, eher Low-Highend Bereich eine Rolle spielen.
2009 "muessten" schon die ersten 2Gb[vram] auf dem Markt erscheinen, sollte 256bit Anbindung weiterhin von beiden favorisiert werden.
128bit = R:I:P ¿?
256bit = low, midrange
512bit = high midrange,highend [low,mid]
>512bit[8800GTX alike] highend Bereich
deekey777
2009-01-23, 00:43:30
naja, im gewissen sinne ist der G80 schon das selbe. 8core mit SIMD16. NVidia sagt natuerlich 128Cores im cluster von je 16 die einen codepfad abarbeiten koennen... aber genau das ist SIMD.
16 Cores mit 8-Way-SIMDs (eigentlich 32-Way für vier Takte).:smile:
naja, im gewissen sinne ist der G80 schon das selbe. 8core mit SIMD16.
Das kann man trotzdem nicht vergleichen. Die Shader werden völlig anders auf die ALUs verteilt.
Ailuros
2009-01-23, 07:43:29
naja, im gewissen sinne ist der G80 schon das selbe. 8core mit SIMD16. NVidia sagt natuerlich 128Cores im cluster von je 16 die einen codepfad abarbeiten koennen... aber genau das ist SIMD.
Im Vergleich zu G7x wohl aber nicht. Alle anderen wichtige Aenderungen zur Seite, G80 hat seine cluster sozusagen in einer MIMD Logik miteinander verbunden, welches nur auf Radeons seit 2002 der Fall war.
Nochmal G80 ist keine 8-quad-G70 Variante. Was man heute unter "traditionellen GPUs" verstehen koennte beinhaltet natuerlich Architekturen wie G80/R600 und alle Nachfolger. Larabee in diesem Sinn eher nicht.
Das kann man trotzdem nicht vergleichen. Die Shader werden völlig anders auf die ALUs verteilt.
das ist eine reine software loesung, ist mit cuda nicht anders, du schreibst code der "parallel" laeuft, in wirklichkeit vektorisieren sie den einfach nur (und zwar nicht nur auf 16elemente/1simd, sondern entsprechend viel dass auch die grosse latenz versteckt wird, wofuer intel scheinbar HT ausgegraben hat).
entsprechend bricht die performance extrem ein falls du branching hast oder ein scatter/gather-pattern hast dass nicht von der hardware unterstuetzt wird.
aber die selbe software abstraktion kannst du dir auch sehr einfach mit einer ausreichend breiten vector-klasse erreichen. dann sind dir die folgen auch viel realer vor augen wenn du soeinen if-else fuer z.b. 64element-vectors implementierst.
Ailuros
2009-01-23, 08:21:41
Wenn Du schon alle Differenzen auf der SW-Basis begrenzen willst, erinner ich daran dass LRB im Grund ein "software driven TBDR" ist. So wie Intel die LRB hw ausgelegt hat, sieht es auch nicht danach aus dass es viele andere Moeglichkeiten gab ohne die Notwendigkeit fuer zusaetzliche Logik.
GT3x0 ist weiterhin sowohl auf HW- als auch auf Treiberbasis ein IMR; egal ob das Grundkonzept des Prozessors eigentlich besser aufgehoben waere in einem vollen hw-TBDR.
das ist eine reine software loesung, ist mit cuda nicht anders, du schreibst code der "parallel" laeuft, in wirklichkeit vektorisieren sie den einfach nur (und zwar nicht nur auf 16elemente/1simd, sondern entsprechend viel dass auch die grosse latenz versteckt wird, wofuer intel scheinbar HT ausgegraben hat).
Larrabee rastert Dreiecke in einem Quad-Muster (nach dem Binning) und übergibt dann QQuads, also 16 Pixel an die Pixelshader-Threads, die irgendwie mit speziellem HW-Thread-Scheduling abgearbeitet werden um die Latenzen zu verstecken.
Bei einem G80 ist das so, dass jeweils 32 Pixel einen Warp formen der in mit 4 Takten/Instruction im TPC abgearbeitet wird. Und zwar nicht einer auf einmal, sondern viele Warps abwechselnd, damit man die Latenzen verstecken kann.
Verdammt du hast recht, es ist recht ähnlich :ugly:
Wenn Du schon alle Differenzen auf der SW-Basis begrenzen willst,
nein nein, das will ich auf keinen fall, ich hab lediglich die shadereinheiten verglichen, denn ganz ehrlich, auch wenn es abzusehen war dass sie einen software rasterizer schreiben, ein simpler rasterizer in hardware wie NV den nutzt ist um eonen flexibler und schneller. jedoch kostet natuerlich die hardwired masse auch platz den alu-cores haben koennten. und deren ausnutzung ist bei aller effiziens auch nicht 100%, sie liegen am ende also leider auch oft brach, waehrend ein softwaresystem mehr potential hat, falls man es gut balanzieren kann.
Pinoccio
2009-01-23, 16:33:01
Verdammt du hast recht, es ist recht ähnlich :ugly:Dann schlag doch mal was vor, am besten etwas, was der Endanwender vergleichen kann. :rolleyes:
mfg
Verdammt du hast recht, es ist recht ähnlich :ugly:ja, sowas behaupte ich schon seit jahren, so laeuft das auch schon in der art ab bei NV40 usw.
und weil man immer soviele 'wraps' usw. in den registern halten muss, damit man genug zu tun hat um ram-latenzen zu verstecken (der erste zugriff ist nur teuer, grafikarbeit ist ansonsten sehr koherent und somit danach cahcefreundlich), erklaert das weshalb man frueher unglaublich bei NV leidete, wenn zuviele temps verwendet wurden. -> weniger wraps -> schechtere latenz 'versteckung'
Intel hat das ganze von NV analysiert und kommt mit einem aenlichen ergebniss auf den markt.
das ist nicht verwunderlich, eher deterministisch :)
ja, sowas behaupte ich schon seit jahren, so laeuft das auch schon in der art ab bei NV40 usw.
Also NV40 war noch sehr viel anders, vor allem wurden die ALUs da noch ganz klassisch vertikal und nicht horizontal eingesetzt. Also ein Shader läuft nicht skalar ab, sondern auf Vec4. Außerdem waren die TMUs noch seriell in die ALUs verschalten und es gab auch kein aufwändiges Thread-Scheduling.
Es heißt "Warp" bei G80, nicht "Wrap". Und die gibt's bei NV40 auch noch nicht.
centurio81
2009-01-23, 20:16:27
Meine nächste Karte wird jedenfalls dann der GT300.. Ich will wieder SS..
(und zwar nicht nur auf 16elemente/1simd, sondern entsprechend viel dass auch die grosse latenz versteckt wird, wofuer intel scheinbar HT ausgegraben hat).
es sind 8xSIMDs, mit 16xSIMDs wäre es wohl kaum möglich auf 24 ALUs/cluster zu kommen.
deekey777
2009-01-23, 22:58:22
es sind 8xSIMDs, mit 16xSIMDs wäre es wohl kaum möglich auf 24 ALUs/cluster zu kommen.
Es sind 16 "SIMDs": Jeder einzelne Multiprozessor kann tatsächlich eine eigene Instruction ausführen, sprich innerhalb eines Clusters kann führen die einzelnen Cores unterschiedliche Instructions unabhängig voneinander aus.
Oder bin ich im falschen Kino?
(Ich wurde selbst korrigiert)
Es sind 16 "SIMDs": Jeder einzelne Multiprozessor kann tatsächlich eine eigene Instruction ausführen, sprich innerhalb eines Clusters kann führen die einzelnen Cores unterschiedliche Instructions unabhängig voneinander aus.
nein, es sind 8x SIMDs, diese 8 kanäle führen zu einem zeitpunkt immer die selbe instruktion aus.
diese 8x-SIMDs werden von sogenannten warps gefüttert die aus 32 threads bestehen und welche dann in 4 takten abgearbeitet werden.
in einem cluster sind idealerweise bei G8x/9x 2 und bei GT2xx 3 warps gleichzeitig in bearbeitung.
deekey777
2009-01-23, 23:21:32
nein, es sind 8x SIMDs, diese 8 kanäle führen zu einem zeitpunkt immer die selbe instruktion aus.
diese 8x-SIMDs werden von sogenannten warps gefüttert die aus 32 threads bestehen und welche dann in 4 takten abgearbeitet werden.
in einem cluster sind idealerweise bei G8x/9x 2 und bei GT2xx 3 warps gleichzeitig in bearbeitung.
Du meinst 8-Ways-SIMDs? :)
Du meinst 8-Ways-SIMDs? :)
ja
Ailuros
2009-01-24, 13:58:43
nein nein, das will ich auf keinen fall, ich hab lediglich die shadereinheiten verglichen, denn ganz ehrlich, auch wenn es abzusehen war dass sie einen software rasterizer schreiben, ein simpler rasterizer in hardware wie NV den nutzt ist um eonen flexibler und schneller. jedoch kostet natuerlich die hardwired masse auch platz den alu-cores haben koennten. und deren ausnutzung ist bei aller effiziens auch nicht 100%, sie liegen am ende also leider auch oft brach, waehrend ein softwaresystem mehr potential hat, falls man es gut balanzieren kann.
Um wirklich jeden Fetzen aus LRB durch den Treiber zu jagen, muesste Intel daran denken ein paar Patent-rechte an IMG abzubezahlen.
Da wäre ich mir nicht so sicher. Hardware-Patente gelten nicht unbedingt für Software.
Armaq
2009-01-25, 09:30:07
Nur wenn Hard- und Software zusammen gehören. Es muss eine unbedingte funktionelle Verknüpfung geben. Software läuft ansonsten unter Urheberrecht (Bücher), da man das einheitliche Werk schützen, aber die einzelnen Zeilen nicht patentieren kann.
loewe
2009-01-25, 19:19:50
Ich glaube nicht, dass sie wirklich so dicht an PowerVR dran sind.
AFAIK ist LRB kein TBDR sondern "nur" ein TBR. Mit diesen Teilen hat intel sowieso schon entsprechende Erfahrung. Man sollte sie hier auf keinen Fall unterschätzen, sie haben den Willen, die Leute und das know kow. :)
Theoretisch können sie ihre Bins so erzeugen, dass der Chip keinen Overdraw erzeugt.
Aber laut den Papers machen sie nur Hier-Z, anscheinend auch aus Kompatibilitätsgründen.
loewe
2009-01-26, 00:03:22
Theoretisch können sie ihre Bins so erzeugen, dass der Chip keinen Overdraw erzeugt.
Aber laut den Papers machen sie nur Hier-Z, anscheinend auch aus Kompatibilitätsgründen.
Das sehe ich genauso! Sie arbeiten in Software und verletzen keine Patente. Warum sie dann nicht etwas ähnliches wie PowerVRs TA (Tile Accelerator) und das HSR implementieren, ist mir nicht klar. Sie sagen zwar es bringt nicht genug Gewinn, erreichen aber zu keinem Zeitpunkt die Effizienz von PowerVR.
Was ist PowerVR? Könnte mir das jemand bitte erläutern?:)
Spasstiger
2009-01-26, 00:39:28
Was ist PowerVR?
PowerVR Technologies ist ein Independent Hardware Vendor (IHV) wie AMD, Nvidia, Intel oder S3.
PowerVR entwickelt Grafiklösungen und verkauft dieses geistige Eigentum in Form von Lizenzen. Im Gegensatz zu Nvidia oder AMD verkaufen sie aber keine Hardware.
loewe redet hier von einer Technologie, die PowerVR in ihre Grafikchips integriert hat. Grafikchips von PowerVR findest du momentan vor allem im Handheld- und Mobiltelefon-Bereich (prominentes Beispiel: Apple iPhone).
Der integrierte Grafikchip GMA 500, den Intel im Poulsbo-Chipsatz verwendet, ist auch ein Grafikchip von PowerVR.
Vor ein paar Jahren war PowerVR in der Consumerwelt noch ein wenig bekannter, sie boten sogar mal über den Hersteller Videologic dedizierte 3D-Grafikkarten in Konkurrenz zur Voodoo 1 an. Und etliche Spielhallenautomaten sowie die Spielekonsole Sega Dreamcast wurden von PowerVR-Grafikchips befeuert. Auch die in Konkurrenz zur GeForce 3 stehende Grafikkartenserie "Kyro" von ST basierte auf der Technologie von PowerVR.
erreichen aber zu keinem Zeitpunkt die Effizienz von PowerVR.
Die Sache ist dass man das HSR ja in Software machen würde. Die PowerVR-Chips haben dafür dedizierte Logik.
Rein in Software kann es schon effizienter sein alles zu rendern bevor man anfängt nur sichtbare Geometrie zu rendern.
AFAIK enthalten die PowerVR-Bins auch nicht die zu rendernden Faces, sondern die zu rendernden Pixel.
PowerVR Technologies ist ein Independent Hardware Vendor (IHV) wie AMD, Nvidia, Intel oder S3.
loewe redet hier von einer Technologie, die PowerVR in ihre Grafikchips integriert hat. Grafikchips von PowerVR findest du momentan vor allem im Handheld- und Mobiltelefon-Bereich (prominentes Beispiel: Apple iPhone).
Der integrierte Grafikchip GMA 500, den Intel im Poulsbo-Chipsatz verwendet, ist auch ein Grafikchip von PowerVR.
Vor ein paar Jahren war PowerVR in der Consumerwelt noch ein wenig bekannter, sie boten sogar mal dedizierte 3D-Grafikkarten in Konkurrenz zur Voodoo 1 an. Und etliche Spielhallenautomaten sowie die Spielekonsole Sega Dreamcast wurden von PowerVR-Grafikchips befeuert. Auch die in Konkurrenz zur GeForce 3 stehende Grafikkartenserie "Kyro" von ST basierte auf der Technologie von PowerVR.
Oh, OK. Danke für die ausführliche Antwort, Spasstiger.
Spasstiger
2009-01-26, 01:07:42
Oh, OK. Danke für die ausführliche Antwort, Spasstiger.
Hab oben noch eine kleine Korrektur angebracht. PowerVR lässt keine Grafikchips selbst fertigen, sondern verkauft lediglich Lizensen für ihre Technologie. Somit passt die Bezeichnung Independent Hardware Vendor nicht.
Die Sache ist dass man das HSR ja in Software machen würde. Die PowerVR-Chips haben dafür dedizierte Logik.
Rein in Software kann es schon effizienter sein alles zu rendern bevor man anfängt nur sichtbare Geometrie zu rendern.
AFAIK enthalten die PowerVR-Bins auch nicht die zu rendernden Faces, sondern die zu rendernden Pixel.
Rein von der Logik her erscheint mir das nicht grade effizienter als umgekehrt.
Hab oben noch eine kleine Korrektur angebracht. PowerVR lässt keine Grafikchips selbst fertigen, sondern verkauft lediglich Lizensen für ihre Technologie. Somit passt die Bezeichnung Independent Hardware Vendor nicht.
Ah ok, also leben die mehr oder weniger von ihren Patenten (Technologien)?
Diese ist ja -wie schon oben genannt- dann an der HW verankert, nur erschließt sich mir nicht wieso andere große Unternehmen da nicht selber Ähnliches entwickeln.
Naja, genug OFF-Topic
ignoriert mich einfach:)
Und danke nochmal für die Aufklärung;)
Rein von der Logik her erscheint mir das nicht grade effizienter als umgekehrt.
Das Problem ist, dass man sonst beim HSR sonst auch Dreieck splitten müsste. Das ist numerisch eher instabil.
Ich bitte um Input, sobald sich neue Annahmen zu den Spezifikationen treffen lassen. Aktuell ist ja noch ziemlich wenig bekannt.
Larrabee GT300 RV870
D3D11 D3D11 D3D11
48 Cores
1x Vec16-ALU/Core
32 nm 40 nm 40 nm
≥ 1024 MiB ≥ 1024 MiB ≥ 1024 MiB
GDDR5 GDDR5 GDDR5
≥ 256 bit ≥ 256 bit ≥ 256 bit
H1 2010 Q4 2009 Q4 2009
Du könntest ja mal bestene GPUs mit in den Vergleich aufnehmen.
Also Geforce 8800 & CO.
Vor allem bei Larrabee sind doch jegliche Spec-Vergleiche mit "traditonellen" Architekturen von vornherein total für die Katz.
Was soll das also?
Sehe ich auch so.
Man müßte ja erstmal in einer Tabelle aufzeigen was ein einziger Core berechnen kann.
Beim Larabee ist es klar -> 386
Aber bei NVidia und ATI, wie sieht es da aus?
Multiplikation
Division
Adition
Subtraktion
Verzweigung
Schleifen?
Was können deren Cores?
Beim Larabee ist es klar -> 386
Gar nichts ist klar. Es wurde behauptet es seine Pentium MMX, also P55C-Kerne (wie kommst du auf 386?), aber wenn überhaupt dann in einer starken Evolutionsstufe davon.
Aber bei NVidia und ATI, wie sieht es da aus?
Multiplikation
Division
Adition
Subtraktion
Verzweigung
Schleifen?
Was können deren Cores?
Alles davon. Was Larrabee den derzeitigen GPUs vorraus hat ist Support für Traps (Hardware Exceptions) und MMU-Unterstützung mit Speicherpages.
Es ist aber nicht so unwahrscheinlich, dass das mit den nächsten GPUs der traditonellen Herstellern nicht auch kommt.
Dann schlag doch mal was vor, am besten etwas, was der Endanwender vergleichen kann. :rolleyes:
mfg
Dem Endanwender sollte man vielleicht erstmal in einem ausführlichen 3dCenter Artikel erklären was ein SIMD und ein Core ist.
Und dann das ganze mal vernünftig in einem Diagram für die jeweils unterschiedlichen GPUs aufzeigen.
Ich glaube nicht, dass sie wirklich so dicht an PowerVR dran sind.
AFAIK ist LRB kein TBDR sondern "nur" ein TBR. Mit diesen Teilen hat intel sowieso schon entsprechende Erfahrung. Man sollte sie hier auf keinen Fall unterschätzen, sie haben den Willen, die Leute und das know kow. :)
Könnt ihr mich mal bei den Fremdwörtern aufklären?
Was ist ein TBDR?
TBR wird wohl Tile Based Renderer heißen.
Und was bitteschön ist ein Warps?
SIMD kenne ich.
LBR = Larabee?
Gar nichts ist klar. Es wurde behauptet es seine Pentium MMX, also P55C-Kerne (wie kommst du auf 386?), aber wenn überhaupt dann in einer starken Evolutionsstufe davon.
Naja, habe ich wohl falsch in Erinnerung.
Ich dachte es währen 386er Kerne.
Alles davon. Was Larrabee den derzeitigen GPUs vorraus hat ist Support für Traps (Hardware Exceptions) und MMU-Unterstützung mit Speicherpages.
Ok, beides sagt mir etwas.
Aber wo braucht man MMUs für die parrallele 3d Grafikbearbeitung?
Was ist ein TBDR?
Tile Based Deferred Renderer. Es wird bevor das Pixelshading und Texturierung durchgeführt wird bestimmt welche Pixel in einem Tile überhaupt sichtbar sind.
Und was bitteschön ist ein Warps?
Warp = Gruppe von Threads die parallel durch die Vec8-ALUs der Texture Processing Clusters laufen und auch Sprünge gemeinsam nehmen müssen - Bei Divergenz müssen beide Pfade abgearbeitet werden für alle Threads im Warp. Derzeit ist die Größe fix 32 Threads was z.B. 32 Pixeln oder 8 Quads entspricht.
Bei ATI ist das glaube ich eine "Wavefront". Die Größe ist dort aber je nach Chip unterschiedlich. RV670 hat z.B. eine Wavefront-Size von 64 Threads/Pixel oder 16 Quads. Für RV770 finde ich leider keine Quelle.
Für GT300 ist offenbar angedacht, dass die "Blasen" die durch Sprünge in einem Warp entstehen durch andere parallel laufende Warps "aufgefüllt" werden.
Aber wo braucht man MMUs für die parrallele 3d Grafikbearbeitung?
Kann man allgemein für virtuelle Resourcen benutzen, also z.B. Streaming von der Festplatte usw. Im Prinzip das was Carmack mit seinem Megatexture-Kram noch manuell macht.
Zudem kann man den Page-Fault-Handler ja selber setzen und damit z.B. dynamisch Texturen direkt dann generieren wenn die TMUs sie anfordern. Eine unendliche Mandelbrot-Fraktal-Textur mit 0 Speicherverbrauch wäre als Spielerei z.B. möglich.
reunion
2009-01-26, 07:51:19
Du könntest ja mal bestene GPUs mit in den Vergleich aufnehmen.
Also Geforce 8800 & CO.
Man sollte die Daten zumindest mal der Realität anpassen, 32nm für Larrabee ist völlig unrealistisch.
Sehe ich auch so. In 2009 kommt sehr sicher garnichts mehr in 32nm und in 2010 eher CPUs als Grafikchips. Die Umstellung einiger Fabs wird in 2009 noch beginnen, die Produktion wird sich also erstmal ausschließlich auf Westmare konzentrieren müssen. Also wird Larabree sehr sicher in 45nm kommen, oder er kommt in 32nm, aber dafür erst Ende 2010 (was ich persönlich für wahrscheinlicher halte).
Was mich an Intel Mopped so unglaublich skeptisch macht, ist, dass sie sich zu sehr auf ihre Software verlassen - das klappt mMn einfach nicht. Dazu hat Intel nicht genug Erfahrung mit 3D-Grafik. Ich denke, dass S3g bessere Treiber schreiben kann als Intel (so wie momentan, wenn man Intel-IGPs mit S3-Chrome vergleicht). Das wird sich mit Larabree kaum ändern.
Armaq
2009-01-26, 09:33:06
Aber was braucht es für gute Treiber, Manpower? Intel kann sich da unbegrenzt Zugang verschaffen. Vll. sind auch schon einige Top-Leute gewechselt und arbeiten seit geraumer Zeit bei Intel.
Ailuros
2009-01-26, 10:38:13
Da wäre ich mir nicht so sicher. Hardware-Patente gelten nicht unbedingt für Software.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6766278&postcount=34
Die Sache ist dass man das HSR ja in Software machen würde. Die PowerVR-Chips haben dafür dedizierte Logik.
Geht es hier darum wie und wo Daten verworfen werden oder ob LRB durch den Treiber das rendering verzoegert oder nicht? Denn beim Dilemma ob TBR oder TBDR geht es eher ums zweite. Ich frag nochmal nach mal mit genaueren Details, mal sehen was dabei heraus kommt.
Rein in Software kann es schon effizienter sein alles zu rendern bevor man anfängt nur sichtbare Geometrie zu rendern.
Andere Frage braucht man wirklich deferred rendering um redundante Geometrie selbst via SW zu verwerfen?
AFAIK enthalten die PowerVR-Bins auch nicht die zu rendernden Faces, sondern die zu rendernden Pixel.
Das macro/micro tiling Verfahren dass sie anscheinend in letzter Zeit verwenden wurde anscheinend noch um einen Schritt weiterentwickelt. Der groesste Kopfschmerz fuer einen TBDR ist parameter bandwidth.
http://v3.espacenet.com/publicationDetails/description?CC=US&NR=2008136816A1&KC=A1&FT=D&date=20080612&DB=EPODOC&locale=en_EP
Es gibt hier eine Reihe an Patenten u.a. auch fuer Kompressions-Verfahren und ein Patent dass noch kommen soll dass von dynamischer Tile-Groesse je nach Bedarft handelt. So wie ich mir das vorstelle gibt es keine festen Tile-Groessen mehr sondern es werden diese je nach Bedarf (egal ob bei macro- oder micro-tiling) dynamisch angepasst.
Aber was braucht es für gute Treiber, Manpower? Intel kann sich da unbegrenzt Zugang verschaffen. Vll. sind auch schon einige Top-Leute gewechselt und arbeiten seit geraumer Zeit bei Intel.
Was ich meine ist, dass die es nichtmal schaffen ihren popeligen IGP in den Griff zu kriegen... wie sollen die ein so komplexes Monster, dass von der Hardware her zudem auchnoch eher suboptimal für DX10/11 Grafik ist, konkurrenzfähig hinbekommen, wenn die das nichtmal beim IGP schaffen? Die jetzigen IGPs sind immernoch den Lösungen von NV (MCP7A) und AMD unterlegen, das zieht sich wie ein roter Faden durch die ganze Intel-Geschichte, angefangen beim i740. Deshalb bin ich da sehr, sehr skeptisch. Wenn die wirklich dran arbeiten und die Aktionäre das über 5 oder mehr Jahre der Entwicklung und die Veröffentlichung suboptimaler Lösungen mittragen, dann kann man vielleicht ein bisschen aufschließen, aber das, woran die jetzt arbeiten, wird mMn ein riesengroßer Flop. Ich lasse mich natürlich gern eines Besseren belehren. Meine Prognose: Ende 2010 in 32nm, dann also lower-Mainstream-Lösung mit grade so lauffähigen Treibern, mehr ist einfach nicht drin. Wie der i740 Damals eben.
mekakic
2009-01-26, 11:32:42
Bei den IGPs reichte das aber bisher, die hatten genug und jede Menge Marktanteile; weiteres dort reinzuinvestieren, war es ihnen wohl einfach nicht wert. Ich denke dies wird sich so langsam zwar auch bei den IGPs rächen, aber im Prinzip hatten sie dort alles was sie wollten.
Hier wollen sie aber jetzt in einen neuen Markt und ich denke nicht, daß sie sich dieses durch Arroganz und schlampige Einstellung bei den Treibern verbauen werden.
Dein Wort in Gottes Gehörgang :D.
Ein weiterer Marktteilnehmer ist sicherlich wünschenswert, aber ich denke, man sollte keinen Superchip, bei dem alles sofort funktioniert und der pünktlich erscheint erwarten. Sicherlich werden die da reinklotzen, ich zweifel eben nur, dass das reicht. Und ich glaube nicht, dass die schon bei den IGPs grossartig geschlampt haben ;).
Ailuros
2009-01-26, 12:13:52
HOT,
Das Larabee Team hat nichts mit dem IGP Team zu tun bei Intel; was aber vieles oder gar nichts heissen kann.
Bei den IGPs reichte das aber bisher, die hatten genug und jede Menge Marktanteile; weiteres dort reinzuinvestieren, war es ihnen wohl einfach nicht wert. Ich denke dies wird sich so langsam zwar auch bei den IGPs rächen, aber im Prinzip hatten sie dort alles was sie wollten.
IGPs wie wir sie heute kennen werden hoechstwahrscheinlich von integrierten GPU Einheiten in der CPU langfristig abgeloest. Viel aendert diese Tatsache aber theoretisch auch nichts. Der groesste Kopfschmerz bei den letzteren ist der Kampf um Bandbreiten-resourcen.
Hier wollen sie aber jetzt in einen neuen Markt und ich denke nicht, daß sie sich dieses durch Arroganz und schlampige Einstellung bei den Treibern verbauen werden.
Ich will bezweifeln dass Intel in absehbarer Zeit etwas wie Larabee in CPUs integrieren wird. Dafuer verbrutzelt die bisherige HW viel zu viel die-area und sie sind fuer einige Zeit besser aufgehoben mit IMG's IP. Poulsbo/GMA500 war der erste Schritt der Integration des SGX und wuerde ihnen auch um einiges das Leben leichter machen wenn sie weitere Varianten langfristig in ihre CPUs integrieren. Nur sind sie bis jetzt auch mit Poulsbo so bloed nicht einen anstaendigen Treiber liefern zu koennen.
Was ich meine ist, dass die es nichtmal schaffen ihren popeligen IGP in den Griff zu kriegen... wie sollen die ein so komplexes Monster, dass von der Hardware her zudem auchnoch eher suboptimal für DX10/11 Grafik ist, konkurrenzfähig hinbekommen, wenn die das nichtmal beim IGP schaffen?Ich sehe das als eine Technologiestudie für zukünftige (sehr zukünftige) Prozessoren. Außer bei spezialisierten Systemen bekommen wir die Mehrcpusysteme momentan nämlich nicht wirklich in den Griff. Schon 4 Kerne sind leicht problematisch. 4 Kerne mit jeweils HT wie beim i7 auszulasten gilt schon als sehr komplex, wenn wir hier über unsere Anwendung daheim reden.
Ein Dispatcher wie bei NV/ATI der es über die ALUs verteilt ist in dieser hocheffizienten Form auf x86 nicht möglich. Die obenerwähnten können drauf aufbauen, daß es einen Datenstrom zu berechnen gibt. Einen Stream. Darauf kann x86 2009 nicht aufbauen. Auch 2010 nicht.
Da sowas aber die effizienteste Art ist Daten zu verarbeiten, wird das eines Tages auch kommen. Vom den Betriebssystemen wie auch von den Programmen und Kompilern selbst. Scheint irgendwie beschlossene Sache zu sein. Sonst würde Intel mit dem Larrabee nicht das Krabbeln auf diesem Gebiet lernen. Denk ich mir.
Oder man will "nur" etwas IBM/Cell entgegensetzen. Das ist dann die gleiche Marschrichtung, nur bleibt eben in der Anwendung momentan eingeschränkt. Ein Linux für eine pure Cell Platform, selbst mit dem aktuellsten 3er SDK und Kompilern wäre m.M.n. noch extrem lahm ;) Andererseits fährt ein PowerXCell 8i bei FP jetzt schon alle "konventionellen" Prozessoren in Grund und Boden.
Auch die Gründe warum AMD den Streamingspezialisten ;) ATI erworben hat kann noch weitere Gründe haben als die, die der Stammtisch sonst aufführt.
Ich schätze nicht immer mehr SSE-Befehle werden die Zukunft sein, sondern eine Art build in Larrabee/Cell, die dann so nach und nach mit der Weiternetwicklung von Komilern, "Programmiersprachendialekten" und Anwendungen selbst die konventionellen ALUs verdrängen.
So ähnlich wie das bei den GPUs der Fall war und man unter Vista/Win7 den 2D-Teil nicht mehr benötigt. Und bei den x86 das A20-Gate ;)
Wollte Intel in irgendeiner übernächsten Generation SSE nicht wieder gegen etwas anderes tauschen? Irgendwas mit Vector im Namen? Erstmal sollen die Opcodes für SSE kompakter werden und dann kommt etwas was SSE nicht langsamer ausführt/emuliert als die dann vorherige letzte CPU-Generation, aber zusätzlich eine ganz neue Art der Streamingverarbeitung bietet. Klingelts bei euch?
Entweder hat man dann eine fettere GPU im System oder benötigt garkeinen IGP im Chipsatz :up: So wie ich das sehe wird die Northbridge soweiso aussterben und die Southbridge wie jetzt schon zu einem reinen Interfaceprozessor mutieren.
Wenn die wirklich dran arbeiten und die Aktionäre das über 5 oder mehr Jahre der Entwicklung und die Veröffentlichung suboptimaler Lösungen mittragen, dann kann man vielleicht ein bisschen aufschließenWie beim Itanium? =)
p.s.
Ich schätze nicht immer mehr SSE-Befehle werden die Zukunft sein, sondern eine Art build in Larrabee/Cell, die dann so nach und nach mit der Weiternetwicklung von Komilern, "Programmiersprachendialekten" und Anwendungen selbst die konventionellen ALUs verdrängen.Wobei natürlich zuerst die FPU dran glauben wird. Damit wird man wieder paar Transistoren mehr für das Budget haben.
Das alles wird aber noch paar Jährchen dauern.
deekey777
2009-01-26, 13:24:22
...
Bei ATI ist das glaube ich eine "Wavefront". Die Größe ist dort aber je nach Chip unterschiedlich. RV670 hat z.B. eine Wavefront-Size von 64 Threads/Pixel oder 16 Quads. Für RV770 finde ich leider keine Quelle.
... .
Strenggenommen entspricht "Wavefront" CUDAs "Block" (CUDA: Grid -> Blocks von Threads (Block pro Multiprozessor) -> Threads per SP (zusammengefasst zu Warps); Stream: Execution Domain (entspricht Grid) als Vielfaches von 8x8 -> Wavefronts; OpenCL (http://www.hardware.fr/articles/744-2/opencl-gpu-computing-enfin-democratise.html)).
Ich tippe mal ins Blaue: Beim RV770 sind die Wavefronts auch 64 Threads groß. Aber mich würde es nicht wundern, wenn sich herausstellt, dass der RV770 "CUDA-ähnlich" programmiert werden kann (also auch Blöcke von Threads (mindestens 64 Threads), die in LDS passen, wobei Threads dieser Blöcke zu Wavefronts zusammengefasst berechnet werden).
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6766278&postcount=34
Demirug ist auch kein Patentanwalt ;)
Andere Frage braucht man wirklich deferred rendering um redundante Geometrie selbst via SW zu verwerfen?
Wenn man es perfekt machen will schon. Sie machen ja auch Hier-Z, was vieles vorher verwerfen kann.
Armaq
2009-01-26, 18:48:03
Demirug ist auch kein Patentanwalt ;)
Wenn man es perfekt machen will schon. Sie machen ja auch Hier-Z, was vieles vorher verwerfen kann.
Zum Patent = die Software kann nur patentiert werden (ein Teil des Patents werden), wenn sie zwingend mit dem technischen Bauteil verknüpft ist. Ansonsten fällt Software unter das Urheberrecht, damit man das Ganze schützen kann, aber keiner auf ein paar Zeilen Code 20 Jahre lang rumsitzt.
loewe
2009-01-26, 19:18:11
Könnt ihr mich mal bei den Fremdwörtern aufklären?
Was ist ein TBDR?
TBR wird wohl Tile Based Renderer heißen.
Auch wenn andere es schon kurz erklärt haben, lies mal das hier:
http://www.mitrax.de/?cont=artikel&aid=35&page=5
Andere Frage braucht man wirklich deferred rendering um redundante Geometrie selbst via SW zu verwerfen?
Wie Coda schon sagt, wenn es perfekt sein soll, geht es nur deferred!
Natürlich ist es gut Objekte so früh wie möglich zu verwerfen, aber ein exakter Algorithmus muss immer auf die Pixelebene zurück.
Die schnellsten Pixel, sind die überhaupt nicht berechneten Pixel! :)
Die schnellsten Pixel, sind die überhaupt nicht berechneten Pixel! :)
Sobald eine Engine einen Z-First-Pass macht ist das ohnehin nicht mehr der Fall, deshalb finde ich deine Deferred-Propaganda manchmal etwas daneben ;)
loewe
2009-01-26, 19:31:58
Sobald eine Engine einen Z-First-Pass macht ist das ohnehin nicht mehr der Fall, deshalb finde ich deine Deferred-Propaganda manchmal etwas daneben ;)
Ja ich weiß! :)
Aber es hat durchaus immer noch einen Sinn, hängt aber davon ab, welche Resourcen durch den Z-First-Pass beansprucht werden.
Bei PowerVR macht diesen Z-First-Pass nun einmal der ISP, sprich die HSR Einheit, welche sich für gewöhnlich eher langweilt.
Sie blockiert dabei die Pipeline eigentlich nicht, "deferred" kann also durchaus noch von Vorteil sein. ;)
OT: Ich mag jede Form von guter Technologie, so nutze ich privat ausschließlich NV, auf Arbeit eher nur ATI und mag eben sehr PowerVR! :biggrin:
robbitop@work
2009-01-27, 09:12:01
Naja das HSR selbst ist ja nicht der einzige Vorteil eines TBDRs. Man spart zusätzlich noch enorm externe Bandbreite, weil ja alles in den Tilecache gerendert wird und nur zum Schluss, wenn das Tile fertig gerendert ist (und das Downsampling durch ist, sofern AA an war) nur noch 1x in den Framebuffer geschrieben werden muss. Außerdem blockiert man nur einen dedizierten Teil der GPU mit dem HSR-Pass. (hat man sich diesen eigentlich bei den embedded Dingern SGX/MBX gespart?) Auch haben die Dinger prinzipbedingt ja eine enorm hohe Z/Stencil Fillrate. Serie 3 hatte bereits 32x Z/Stencil Ops Output pro Takt. Und das im Jahr 2000.
Ailuros
2009-01-27, 09:16:44
Demirug ist auch kein Patentanwalt ;)
Du aber auch nicht :P Ich hab sicherheitshalber nachgefragt, hab aber noch keine Antwort bekommen.
Wenn man es perfekt machen will schon. Sie machen ja auch Hier-Z, was vieles vorher verwerfen kann.
Moment...
Sobald eine Engine einen Z-First-Pass macht ist das ohnehin nicht mehr der Fall, deshalb finde ich deine Deferred-Propaganda manchmal etwas daneben.
Der zweite Satz wiederspricht leicht dem obrigen oder? Spass beiseite ein z-first pass kostet weniger Bandbreite auf einem TBDR; noch dazu kommt die sehr hohe Z-Fuellrate die ein DR normalerweise hat. Pro ALU sind es je nach Bedarf entweder 8 oder 16 z-check Einheiten.
Ein z-first-pass muss es ja nicht sein in neuesten engines; ich hab das Gefuehl dass MRTs hier populaerer sein koennten.
Loewe,
Bei PowerVR macht diesen Z-First-Pass nun einmal der ISP, sprich die HSR Einheit, welche sich für gewöhnlich eher langweilt.
Beim durchlesen des oben verlinkten Patentes hab ich das Gefuehl dass das obrige auch nicht ganz stimmt, wenn es zu einem "partial render" eines macro-tiles kommt. Und auch:
A second stage of culling, in the parameter fetch stage of the ISP, occurs in a further embodiment. This is at the point at which object pointers are dereferenced, and parameter data is read from the display list memory. This works on a very similar principle to the first stage culling shown in FIG. 3. By storing a little additional information in the object pointer, and by testing this against depth range information maintained in the ISP, it is possible to avoid reading the parameter data for some objects altogether. This type of culling reduces the input bandwidth to the ISP, and the number of objects that the ISP must process, but it does not reduce the amount of data written into the display list memory.
Naja das HSR selbst ist ja nicht der einzige Vorteil eines TBDRs. Man spart zusätzlich noch enorm externe Bandbreite, weil ja alles in den Tilecache gerendert wird und nur zum Schluss, wenn das Tile fertig gerendert ist (und das Downsampling durch ist, sofern AA an war) nur noch 1x in den Framebuffer geschrieben werden muss. Außerdem blockiert man nur einen dedizierten Teil der GPU mit dem HSR-Pass. (hat man sich diesen eigentlich bei den embedded Dingern SGX/MBX gespart?) Auch haben die Dinger prinzipbedingt ja eine enorm hohe Z/Stencil Fillrate. Serie 3 hatte bereits 32x Z/Stencil Ops Output pro Takt. Und das im Jahr 2000.
http://www.imgtec.com/images/blockdiagrams/powervr/large/POWERVR_MBX_lrg.gif
SGX hat das macro-/micro tiling Verfahren afaik; SGX543 = 16z/SP (64 insgesamt), alle anderen SGX Varianten = 8z/SP.
N0Thing
2009-01-27, 12:27:49
Man sollte die Daten zumindest mal der Realität anpassen, 32nm für Larrabee ist völlig unrealistisch.
Warum? Intel produziert doch auch schon Flashspeicher in 32nm und die einzelnen Kerne von Larrabee sollten doch nicht so komplex sein, als daß man in knapp einem Jahr keine 32nm Fertigung verwenden kann.
Ailuros
2009-01-27, 12:32:58
Warum? Intel produziert doch auch schon Flashspeicher in 32nm und die einzelnen Kerne von Larrabee sollten doch nicht so komplex sein, als daß man in knapp einem Jahr keine 32nm Fertigung verwenden kann.
Was um Gottes Willen hat ein Flash-speicher mit einem hochkomplizierten chip fuer eine high end GPU genau gemeinsam?
Lord_X
2009-01-27, 12:52:17
Was um Gottes Willen hat ein Flash-speicher mit einem hochkomplizierten chip fuer eine high end GPU genau gemeinsam?
Ich denke es ist machbar. Larrabee ist keine 1 Die Monster Karte sondern besteht aus vielen einzelnen "normalen" cpu's. Diese bestehen nicht aus Millionen von Transistoren.
Ailuros
2009-01-27, 13:04:46
Ich denke es ist machbar. Larrabee ist keine 1 Die Monster Karte sondern besteht aus vielen einzelnen "normalen" cpu's.
Ach ja? Es wird ein ziemlich grosser die sein und keine Plastikbeute mit zich Legosteinen die man einfach in einen CPU slot Stueck fuer Stueck einsteckt.
Nein ehrlich erklaer mir mal wie das finale Produkt genau aussehen wird.
Diese bestehen nicht aus Millionen von Transistoren.
Nein sie bestehen aus magischen Sandkoernen. :|
Spasstiger
2009-01-27, 13:26:37
Warum? Intel produziert doch auch schon Flashspeicher in 32nm
34 nm.
Und das ist eine Kooperation mit Micron, in diesen Fabs werden ganz sicher keine GPUs hergestellt.
Du aber auch nicht :P
Habe ich nicht behauptet.
Der zweite Satz wiederspricht leicht dem obrigen oder?
Nö. Das eine ist Hardware und das andere Software.
Ein z-first-pass muss es ja nicht sein in neuesten engines; ich hab das Gefuehl dass MRTs hier populaerer sein koennten.
Das ergibt keinen Sinn.
Ich denke es ist machbar. Larrabee ist keine 1 Die Monster Karte sondern besteht aus vielen einzelnen "normalen" cpu's. Diese bestehen nicht aus Millionen von Transistoren.
Aua.
Ailuros
2009-01-27, 14:21:28
Das ergibt keinen Sinn.
Wieviele heutige engines benutzen denn einen z-first pass?
Wieviele heutige engines benutzen denn einen z-first pass?
Es wäre vielleicht einfacher rauszusuchen, welche es nicht in irgendeiner Form tut.
Ailuros
2009-01-27, 15:08:35
Es wäre vielleicht einfacher rauszusuchen, welche es nicht in irgendeiner Form tut.
Wenn man jegliche Form von deferred-wasauchimmer als 'z first pass' betitelt dann natuerlich schon.
Wieviele heutige engines benutzen denn einen z-first pass?
Praktisch alle Forward Renderer.
Wenn man jegliche Form von deferred-wasauchimmer als 'z first pass' betitelt dann natuerlich schon.
Da alle mir bekannten Deferred Verfahren den Z-First Pass leicht erweitert einsetzen, waeren die wohl auch so zu bezeichnen...
Bei Crysis wirds ja auch Deferred genannt. Dabei haben sie nen astreinen Z-First Pass...
Buzzler
2009-01-27, 19:55:47
Das Larabee Team hat nichts mit dem IGP Team zu tun bei Intel; was aber vieles oder gar nichts heissen kann.
Trotzdem finde ich die Annahme von vielen hier, man könnte einen guten Treiber from scratch einfach mal so mit genügend Manpower raushauen, irgendwie befremdlich. Die Treiber von ATI und NVidia sind mittlerweile über Jahre gereift und die Entwickler haben echte Erfahrung inkl. Feedback vom "Markt". Ich vermute mal, wenn ATI oder NVidia jetzt plötzlich bei Null anfangen müssten, würden die - trotz Erfahrung - das jetzige Niveau auch erst nach einiger Zeit erreichen.
Alles Andere als ein Drama mit den ersten Treiberversionen für den Larabee würde mich arg überraschen.
Ich will bezweifeln dass Intel in absehbarer Zeit etwas wie Larabee in CPUs integrieren wird.
Absehbar sicher nicht, aber wenn es wirklich irgendwann mal mit den Manycores so kommt, wie von Intel geplant, wird die Erfahrung mit dem Larabee Intel sicher sehr von Nutzen sein.
PCGH_Carsten
2009-01-27, 20:54:31
Ein z-first-pass muss es ja nicht sein in neuesten engines; ich hab das Gefuehl dass MRTs hier populaerer sein koennten.
Nutzen denn noch andere Games außer Starcraft II dessen Engine?
Ailuros
2009-01-28, 11:30:55
Trotzdem finde ich die Annahme von vielen hier, man könnte einen guten Treiber from scratch einfach mal so mit genügend Manpower raushauen, irgendwie befremdlich. Die Treiber von ATI und NVidia sind mittlerweile über Jahre gereift und die Entwickler haben echte Erfahrung inkl. Feedback vom "Markt". Ich vermute mal, wenn ATI oder NVidia jetzt plötzlich bei Null anfangen müssten, würden die - trotz Erfahrung - das jetzige Niveau auch erst nach einiger Zeit erreichen.
Intel's Problem ist weniger Erfahrung was die Treiber-Entwicklung betrifft und mehr der fehlende Druck konstant hoehere Leistung herauszuquetschen. Hier hocken fuer solche Projekte die Kerle bei ATI/NVIDIA keine Sekunde still und sie optimieren ihre Treiber auch eine ziemlich lange Zeit nach der Vorstellung. Bei Intel klingt das Ganze momentan viel zu gelassen; ach ja wir haben Ziel X erreicht das wird schon reichen...tut es aber nicht denn man weiss nicht wo die Leistung der Konkurrenz fuer A,B,C etc genau liegen wird.
Alles Andere als ein Drama mit den ersten Treiberversionen für den Larabee würde mich arg überraschen.
Wenn sich am obrigen nichts aendert, wofuer sie aber noch genuegend Zeit haben, kann es hoechstwahrscheinlich einen sehr lauwarmen ersten Eindruck bedeuten.
Absehbar sicher nicht, aber wenn es wirklich irgendwann mal mit den Manycores so kommt, wie von Intel geplant, wird die Erfahrung mit dem Larabee Intel sicher sehr von Nutzen sein.
Ueberhaupt nicht wenn sich die Grundlagen der Architektur mit den Generationen nicht aendert. Ich hab eine Antwort bekommen und ich muss mich korrigieren es handelt sich bis jetzt um TBR was aber nicht heissen koennte dass sie auch nicht TBDR einlegen koennten.
Die Sache ist anscheinend so: bei einem high end chip wie LRB ist dedizierte HW fuers tiling keine Notwendigkeit. Skaliert man sehr stark nach unten um dass man in den mobile/PDA gehen wuerde, braeuchte man wohl doch zusaetzliche Logik fuer's tiling. Es geht natuerlich auch so nur wird das Resultat eben zu viel die area einnehmen um konkurrenzfaehig zu sein. Ich weiss jetzt natuerlich nicht ob dieses auch IGPs betrifft (denn diese sind um einiges groesser als Handy chips), aber ich koennte mir vorstellen dass es u.a. der Grund ist warum TBR auf ihren IGPs nie richtig funktionierte.
Nutzen denn noch andere Games außer Starcraft II dessen Engine?
Wenn ich mich nicht irre basiert STALKER auf MRTs, ziemlich aehnlich nach dem Konzept wie PowerVR frueher in einem MRT demo illustrierten.
PCGH_Carsten
2009-01-28, 12:44:41
Wenn ich mich nicht irre basiert STALKER auf MRTs, ziemlich aehnlich nach dem Konzept wie PowerVR frueher in einem MRT demo illustrierten.
Wenn ich mir die Performance von Stalker anschaue, die bei voller Optikpracht erreicht wird, bezweifle ich, dass das irgendwann ein Grund für überbordende Popularität werden könnte.
Publisher wollen die Spiele auch verkaufen. :)
Ailuros
2009-01-28, 12:51:10
Wenn ich mir die Performance von Stalker anschaue, die bei voller Optikpracht erreicht wird, bezweifle ich, dass das irgendwann ein Grund für überbordende Popularität werden könnte.
Publisher wollen die Spiele auch verkaufen. :)
STALKER ist auch nicht der neueste Schrei auf dem Markt als engine; fortschrittlicher als Doom3 auf jeden Fall :smile:
deekey777
2009-01-28, 13:03:51
...
Wenn ich mich nicht irre basiert STALKER auf MRTs, ziemlich aehnlich nach dem Konzept wie PowerVR frueher in einem MRT demo illustrierten.
Es ist ja ein echter Deferred Renderer (dynamische Beleuchtung), da ist es doch normal, dass der G-Buffer als MRTs gespeichert wird (hier drei ARGB16-Texturen, hier kann man's nachlesen: http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter09.html*).
*Hm, im GPUGems2-Artikel steht, es sind vier Texturen, dagegen bei Gamedev.ru spricht man von drei (http://www.gamedev.ru/community/gamedev_lecture/articles/r_e_n_de_r) (siehe 20:19), der Gamedev-Artikel ist auch deutlich neuer, vielleicht wurde seit 2004 dies geändert.
Naja das HSR selbst ist ja nicht der einzige Vorteil eines TBDRs. Man spart zusätzlich noch enorm externe Bandbreite,
das war im jahr 2000 sicher der fall als man für jeden komplexeren effekt multipass verwenden musste. heutzutage ist die ersparniss sicher wesentlich geringer da man das meisten singlepass erledigen kann.
Auch haben die Dinger prinzipbedingt ja eine enorm hohe Z/Stencil Fillrate. Serie 3 hatte bereits 32x Z/Stencil Ops Output pro Takt. Und das im Jahr 2000.
ich würde nicht sagen, dass sie prinzipbedingt hohe Z-raten haben sondern, dass sie diese prinzipbedingt einfach brauchen.
Ailuros
2009-01-28, 13:52:58
Es ist ja ein echter Deferred Renderer (dynamische Beleuchtung), da ist es doch normal, dass der G-Buffer als MRTs gespeichert wird (hier drei ARGB16-Texturen, hier kann man's nachlesen: http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter09.html*).
*Hm, im GPUGems2-Artikel steht, es sind vier Texturen, dagegen bei Gamedev.ru spricht man von drei (http://www.gamedev.ru/community/gamedev_lecture/articles/r_e_n_de_r) (siehe 20:19), der Gamedev-Artikel ist auch deutlich neuer, vielleicht wurde seit 2004 dies geändert.
Wenn ich mich nicht irre braeuchte man theoretisch 10.1 um MSAA in STALKER einschalten zu koennen.
ich würde nicht sagen, dass sie prinzipbedingt hohe Z-raten haben sondern, dass sie diese prinzipbedingt einfach brauchen.
Stimmt auch. Erstens sind z-check Einheiten relativ billig und zweitens brauchen auch IMRs heutzutage obszoene z-Fuellraten um jeglichen >4xMSAA modus bewaeltigen zu koennen. NVIDIA greift eben zu coverage samples fuer hohe Sample-anzahlen, waehren ein typischer TBDR zumindest kein Problem mit der Speichermenge bzw. Bandbreite fuer hohe AA-sample Anzahlen hat.
PCGH_Carsten
2009-01-28, 14:16:04
STALKER ist auch nicht der neueste Schrei auf dem Markt als engine; fortschrittlicher als Doom3 auf jeden Fall :smile:
Deswegen wundert es mich, wenn du dies als Argument hernimmst, dass MRT-basierte Ansätze populärer sein könnten als klassische Deferred-Renderer mit einem Uber-Buffer.
Wenn ich mich nicht irre basiert STALKER auf MRTs, ziemlich aehnlich nach dem Konzept wie PowerVR frueher in einem MRT demo illustrierten.
Dir ist schon klar, dass man bei deferred rendering genausogut einen Z-First-Pass machen kann?
Das Shading wird dabei sowieso auch nur für die sichtbaren Pixel gemacht. Man spart sich damit halt höchstens noch etwas Texturload.
deekey777
2009-01-28, 14:19:50
Wenn ich mich nicht irre braeuchte man theoretisch 10.1 um MSAA in STALKER einschalten zu koennen.
... .
Richtige Kantenglättung gibt es auch mit D3D10 in STALKER CS (erst mit dem vorletzten Patch (http://www.pcgameshardware.de/aid,665475/Test/Benchmark/Stalker_Clear_Sky_im_D3D101-Test/?page=4) wird alles erfasst, hinzu kommen noch die Transparenz-AA-Modi), in STALKER nur per Treiber (NV). Per Konsolenbefehl kann man zwar mit dem Deferred Renderer die Kanten bluren, aber das sieht so schlecht aus.
Ailuros
2009-01-28, 14:46:01
Dir ist schon klar, dass man bei deferred rendering genausogut einen Z-First-Pass machen kann?
Die Frage ist eher wo die Daten eines MRTs gebuffert werden und wie es mit dem Speicher- und Bandbreitenverbrauch aussieht wenn man auch noch MSAA im Menu haben will.
Sorry, ich versteh nicht was du meinst und was das für eine Relevanz hätte.
robbitop@work
2009-01-28, 15:05:48
das war im jahr 2000 sicher der fall als man für jeden komplexeren effekt multipass verwenden musste. heutzutage ist die ersparniss sicher wesentlich geringer da man das meisten singlepass erledigen kann.
Sicher, dass nur 1x Framebufferzugriff notwendig ist? Das würde die abartig hohen RAM-Bandbreiten und deren Auslastung aber nicht erklären. 1x Schreiben in den Framebuffer und Texturen aus dem VRAM lesen kostet kaum Bandbreite.
Soweit ich das verstanden habe, ist schon eine Vielzahl an Lese und Schreibzugriffen pro Frame und Tile auf den FB notwendig. Und diese sind dabei sogar noch relativ fragmentiert.
ich würde nicht sagen, dass sie prinzipbedingt hohe Z-raten haben sondern, dass sie diese prinzipbedingt einfach brauchen.
Ja so meinte ich das. ;)
Ailuros
2009-01-28, 16:45:43
Sorry, ich versteh nicht was du meinst und was das für eine Relevanz hätte.
Damit wir uns nicht verwechseln ich bin der Laie hier :P
Bei multiple render targets buffert ein pixel shader in mehrere buffer zur gleichen Zeit ja oder nein? Ich fragte lediglich wo normalerweise die buffer hocken, was soll daran so schwer sein? Hat man on chip buffer spart man Leistung, Speicher und Bandbreite; verlegt man das Zeug in den Speicher gibt es einige Unkosten fuer die herumpufferei der Daten. Ich lass mich gerne korrigieren, aber es war ein ziemlich einfache Frage.
Leonidas @ Firefox
2009-01-28, 17:11:20
Was haltet ihr hiervon?
ATI hd5870x4
ATI
"Actually, it doesn't sound optimistic enough to me. If the die size of 205mm² is true, ATI could sell these things for really cheap. The Radeon HD 4830, with its 256mm² die size and 256-bit memory interface, is already selling for less than $130 USD. I'm thinking something more like this:
Radeon HD 5870 X4 (Dual MCM, 800MHz Core, 2GB 1200MHz GDDR5) - $649
Radeon HD 5870 X2 (MCM, 800MHz Core, 1GB 1200MHz GDDR5) - $349
Radeon HD 5870 (800MHz Core, 512MB 1200MHz GDDR5) - $199
Radeon HD 5850 (600-650MHz Core, 512MB 1100MHz GDDR3) - $129"
----------------------------------------------------------------------
"Today appeared new information about the RV870 chip . Associate reports that this 40 nm chip models will appear at the end of present year, and to the end of first quarter 2009 it will reach the series production .
The quantity of stream processors on RV870 chip can grow up to 1000 pieces. Their resulting computational performance can reach 1,5 teraflops.
The memory capacity on RV870 video card can reach 150-160 Gbit/s. If we considers that Radeon HD 4870 with 256- bit bus and 3600 MHz DDR memory frequency ensures a capacity at the level of 115,2 Gbit/s, RV870 can raise the memory frequency to 4800 MHz DDR with constant memory bus. Qimonda company already released GDDR5 microcircuits working at frequencies up to 5000 MHz DDR .
The RV870 core area will decrease from 256 sq. mm, in RV770, to 205 sq. mm. This will allow to create the two-chip graphical solutions easily."
----------------------------------------------------------------------
integrated memory controller
960 or 1000 shaders
~850 core clocks
~4800GHz ram clocks(can easily overclock to low 5GHz)
1-4GB ram configurations depending on how many GPUs
256 bit ram, 512 bit ram possible with revisions.
dx10.1 now with dx11 for refresh revision
----------------------------------------------------------------------
If you hear of more rumors, post here! This is exciting for those gaming at 1920x1080 or higher resolution and have the best overclocked core duo cpus. I wonder when they will have giant LCD monitors above 2560x1600? Otherwise the hd5870x4 is gonna be overkill!
Info:
HD 5450 -> 640 SP + 16 TMUs (1 master chip)
HD 5650 -> 1280 SP + 32 TMUs (1 master chip + 1 slave)
HD 5670 -> 1920 SP + 48 TMUs (1 master chip + 2 slaves)
HD 5850 -> 2560 SP + 64 TMUs (1 master chip + 3 slaves)
HD 5870 -> 3200 SP + 80 TMUs (1 master chip + 4 slaves)
http://img82.imageshack.us/img82/8985/20090116f000bad5de67db7ab0.gif
Was haltet ihr hiervon?
Nichts. Wurde auch schonmal gepostet irgendwo.
Bei multiple render targets buffert ein pixel shader in mehrere buffer zur gleichen Zeit ja oder nein? Ich fragte lediglich wo normalerweise die buffer hocken, was soll daran so schwer sein? Hat man on chip buffer spart man Leistung, Speicher und Bandbreite; verlegt man das Zeug in den Speicher gibt es einige Unkosten fuer die herumpufferei der Daten. Ich lass mich gerne korrigieren, aber es war ein ziemlich einfache Frage.
Bei Deferred Shading muss man zuerst einmal die Daten rausschreiben und dann im Deferred Pass am Ende dann wieder einlesen und entsprechend kombinieren.
Das kann man nicht alles auf dem Chip cachen. Rausschreiben muss man es so oder so.
Spasstiger
2009-01-28, 17:56:36
Nichts. Wurde auch schonmal gepostet irgendwo.
Jopp, das Gerücht mit den 1000 SPs beim RV870 stammt noch vom Mai 2008:
http://bbs.chiphell.com/viewthread.php?tid=22781&extra=page%3D1
Die MCM-Gerüchte wurden im Oktober 2008 diskutiert:
http://news.ati-forum.de/index.php/news/34-amdati-grafikkarten/83-rv870-neue-details?lang=de
Und das MCM-Dementi kam im November 2008:
http://www.fudzilla.com/index.php?option=com_content&task=view&id=10351&Itemid=1
Also kalter Kaffee, den da jemand ausgegraben hat.
reunion
2009-01-28, 18:11:52
Wir sprechen hier aber vom D3D11 Chip RV870 im Q4.
Spasstiger
2009-01-28, 19:31:00
Wir sprechen hier aber vom D3D11 Chip RV870 im Q4.
Trotzdem sind die Gerüchte, die Leonidas gepostet hat, genau die, die im letzten Jahr bezüglich des RV870 in der Diskussion standen.
Trotzdem sind die Gerüchte, die Leonidas gepostet hat, genau die, die im letzten Jahr bezüglich des RV870 in der Diskussion standen.
Ja, aber entscheidend ist doch, wer die Quelle dieser Gerüchte ist.
Spasstiger
2009-01-28, 22:05:40
Ja, aber entscheidend ist doch, wer die Quelle dieser Gerüchte ist.
Leonidas hat die Quellen überhaupt nicht angegeben.
Zu den untersten Gerüchten von Leonidas hab ich aber eine Quelle:
http://forum.beyond3d.com/showpost.php?p=1208228&postcount=137
Datum: August 2008. Das war noch vor dem MCM-Dementi. Zudem ist es komplett Speku, davon beruht rein gar nix auf Infos von AMD-Mitarbeitern.
Auch die anderen Gerüchte sind veraltet, was ja auch meine Links zeigen.
Ende 2008 sollen also die 40-nm-Chips kommen? Behauptet eine glaubwürdige Quelle? War wohl nix ...
][immy
2009-01-31, 23:46:23
hat intel eigentlich jemals eine angabe gemacht, wie viel der Larrabee denn verbrauchen wir so Pi mal daumen?
ich könnte mir bei der anzahl der prozessoren schon vorstellen (selbst wenn sie recht einfach gestrickt sind) das sie nicht gerade in die kategorie "engergie-sparer" fallen würden. Besonders wenn sie auch noch ziemlich hoch getaktet sind. immerhin sind es 32 Prozessoren, die nicht wirklich für grafik-verarbeitung optimiert sind. dementsprechend dürften sie beim normalen rendering auch mehr zu tun haben als normale gpus, was sie ja wiederum durch schiere masse und einen hohen takt abfedern müssten.
müsste intel nicht an sich auch mit einem ziemlichen synchronisations-overhead zu kämpfen haben. mehr oder minder sind das ja parallel arbeitende cpus.
Spasstiger
2009-01-31, 23:55:21
@][immy: Wenn ein Atom Z540 bei 1,86 GHz mit einer TDP von 2,4 Watt auskommt, sollten 32 Kerne eigentlich auch noch locker im Rahmen heutiger Performance-GPUs liegen.
y33H@
2009-02-01, 02:09:42
2,4 Watt TDP sind real halt dummerweise über 10 Watt ...
cYa
Spasstiger
2009-02-01, 02:18:18
2,4 Watt TDP sind real halt dummerweise über 10 Watt ...
cYa
Wie kommst du darauf? Beweise?
y33H@
2009-02-01, 03:25:25
http://pc.watch.impress.co.jp/docs/2008/0515/esec_16.jpg
cYa
Spasstiger
2009-02-01, 03:32:01
http://pc.watch.impress.co.jp/docs/2008/0515/esec_16.jpg
cYa
Was beweist das jezt genau? In den Leistungsmessern stecken Kaltgerätestecker, das spricht nicht gerade dafür, dass die Leistungsaufnahme der CPU alleine gemessen wird.
Captain Future
2009-02-01, 09:39:34
Komplettes System mit Platine und allem (Chipsatz!) != CPU-TDP.
Ailuros
2009-02-01, 10:07:27
Ich weiss zwar nicht was Ihr gerade ueber die letzten 2 Seiten im Hinterkopf habt, aber ich hab das Gefuehl dass hier manche zu vergessen scheinen dass LRB eine GPU ist. Neben all dem anderen zusaetlichem Schnickschnack hocken auf LRB auch eine gesunde Anzahl an ff TMUs.
***edit:
http://www.anandtech.com/video/showdoc.aspx?i=3507
Spasstiger
2009-02-01, 12:47:45
Ich weiss zwar nicht was Ihr gerade ueber die letzten 2 Seiten im Hinterkopf habt, aber ich hab das Gefuehl dass hier manche zu vergessen scheinen dass LRB eine GPU ist. Neben all dem anderen zusaetlichem Schnickschnack hocken auf LRB auch eine gesunde Anzahl an ff TMUs.
Logisch. Aber rund 80 Watt (32*2,4 Watt) für den Streamprozessorcore wären doch nicht zuviel. In diesem Bereich müsste auch ein RV770 oder ein GT200 liegen.
iceman.s
2009-02-01, 15:10:16
Ich sehe das als eine Technologiestudie für zukünftige (sehr zukünftige) Prozessoren. Außer bei spezialisierten Systemen bekommen wir die Mehrcpusysteme momentan nämlich nicht wirklich in den Griff. Schon 4 Kerne sind leicht problematisch. 4 Kerne mit jeweils HT wie beim i7 auszulasten gilt schon als sehr komplex, wenn wir hier über unsere Anwendung daheim reden.
...
Oder man will "nur" etwas IBM/Cell entgegensetzen. Das ist dann die gleiche Marschrichtung, nur bleibt eben in der Anwendung momentan eingeschränkt. Ein Linux für eine pure Cell Platform, selbst mit dem aktuellsten 3er SDK und Kompilern wäre m.M.n. noch extrem lahm ;) Andererseits fährt ein PowerXCell 8i bei FP jetzt schon alle "konventionellen" Prozessoren in Grund und Boden.
Auch die Gründe warum AMD den Streamingspezialisten ;) ATI erworben hat kann noch weitere Gründe haben als die, die der Stammtisch sonst aufführt.
Ich schätze nicht immer mehr SSE-Befehle werden die Zukunft sein, sondern eine Art build in Larrabee/Cell, die dann so nach und nach mit der Weiternetwicklung von Komilern, "Programmiersprachendialekten" und Anwendungen selbst die konventionellen ALUs verdrängen.
So ähnlich wie das bei den GPUs der Fall war und man unter Vista/Win7 den 2D-Teil nicht mehr benötigt. Und bei den x86 das A20-Gate ;)
Wollte Intel in irgendeiner übernächsten Generation SSE nicht wieder gegen etwas anderes tauschen? Irgendwas mit Vector im Namen? Erstmal sollen die Opcodes für SSE kompakter werden und dann kommt etwas was SSE nicht langsamer ausführt/emuliert als die dann vorherige letzte CPU-Generation, aber zusätzlich eine ganz neue Art der Streamingverarbeitung bietet. Klingelts bei euch?
Entweder hat man dann eine fettere GPU im System oder benötigt garkeinen IGP im Chipsatz :up: So wie ich das sehe wird die Northbridge soweiso aussterben und die Southbridge wie jetzt schon zu einem reinen Interfaceprozessor mutieren.
Wie beim Itanium? =)
Der Nachfolger von SSE heißt AVX(Advanced Vector Extensions) (http://en.wikipedia.org/wiki/Advanced_Vector_Extensions) und kommt zusammen mit Sandy Bridge Ende 2010.
Was viele nicht sehen, ist wie langfristig Intel plant. In in diesem Zusammenhang, macht auch Larrabee viel mehr Sinn. Ich denke Intel hat damit mehr vor, als nur 3D Daten durch die Gegend zu schieben. Richtig zünden wird das ganze, dann erst mit Sandy Bridge und nachfolgend.
SB wird sehr wahrscheinlich über ein integriertes PCIe 3.0 Interface verfügen, vermutlich mit 48 Lanes und mehr. Das für Intel interessante an 3.0 ist Cache coherence. Damit ist es praktisch möglich, eine PCIe 3.0 Karte, falls sie es unterstützt, als einen art Koprozessor zu nutzen. Und da kommt Larrabee ins Spiel. Dazu kommt noch, das AVX und Larrabbe Technologien teilen. Sollte also auf AVX als Ziel programmiert werden, dann dürfte dieser Code mit geringen oder sogar gar keinen Anpassungen unter Larrabee lauffähig sein. Intel dürfte über OpenCL auch sehr glücklich sein, kommt es doch dem sehr nahe, was sie schon seit Eininger Zeit in Hardware entwickeln.
Ich denke man sollte Larrabee eher als Intels Antwort auf IBM Power/CELL betrachten. Die Spieleunterstützung sollte man eher als Trojanisches Pferd Taktik sehen. In diesem Markt dürfte es ein leichtes Sein, eine mehrere hundert US$ teure Harde Hunderttausend fach in den Markt zu bekommen, scale of economy halt.
Leonidas
2009-02-01, 16:28:08
Danke für die Hinweise zu meinem Posting.
Und das MCM-Dementi kam im November 2008:
http://www.fudzilla.com/index.php?option=com_content&task=view&id=10351&Itemid=1
Also kalter Kaffee, den da jemand ausgegraben hat.
Hier stimme ich nicht zu. Seinerzeit ging man davon aus, daß der Sommer-Chip und der RV870 dasselbe sind - was, wie wir heute wissen, nicht zutrifft. Ergo muß die Frage gestellt werden, was *exakt* dementiert wurde: Daß der RV870 (explizite Chipnenennung vonnöten!) nicht MCM ist - oder daß der Sommer-Chip nicht MCM ist. Und Fudzilla ist leider das genaue Gegenteil von Exaktheit.
turboschlumpf
2009-02-02, 23:43:41
Habe Larrabee im ersten Posting jetzt mal auf 45 nm gesetzt.
Aber: Wenn die Mainstream-CPU Havendale im 1. Quartal 2010 nun schon in 32 nm kommen soll, dann halte ich auch Larrabee in 32 nm nicht für ausgeschlossen.
BlackBirdSR
2009-02-03, 13:23:33
Habe Larrabee im ersten Posting jetzt mal auf 45 nm gesetzt.
Aber: Wenn die Mainstream-CPU Havendale im 1. Quartal 2010 nun schon in 32 nm kommen soll, dann halte ich auch Larrabee in 32 nm nicht für ausgeschlossen.
Du musst bedenken, dass Larrabee ja nicht erst seit gestern in Entwicklung ist. Havendale ist ein bestehendes Design, welches speziell für diesen Prozess auf den Markt gebracht wird.
Larrabee befindet sich noch in der Entwicklung und eines der aller ersten Dinge, die man als Designteam festlegen sollte (und auch tut) ist der Targetprozess. Sobald das Design dann weit genug fortgeschritten ist, können freigewordene Mitarbeiter/Teams dann auf den nächsten Prozess angesetzt werden und damit gleich das Design neu optimieren. Bestes Beispiel? Siehe P4 und Prescott oder Katmai und Tualatin.
turboschlumpf
2009-02-03, 16:03:39
Ich möchte nicht widersprechen, aber trotzdem ein paar Gedanken in den Raum stellen:
Du musst bedenken, dass Larrabee ja nicht erst seit gestern in Entwicklung ist. Havendale ist ein bestehendes Design, welches speziell für diesen Prozess auf den Markt gebracht wird.Anscheinend hat man für Havendale mal geschwind von 45 nm auf 32 nm gewechselt. http://theovalich.wordpress.com/2009/01/31/exclusive-intels-cans-45nm-auburndale-and-havendale-fusion-cpus/
Larrabee befindet sich noch in der Entwicklung und eines der aller ersten Dinge, die man als Designteam festlegen sollte (und auch tut) ist der Targetprozess. Sobald das Design dann weit genug fortgeschritten ist, können freigewordene Mitarbeiter/Teams dann auf den nächsten Prozess angesetzt werden und damit gleich das Design neu optimieren. Bestes Beispiel? Siehe P4 und Prescott oder Katmai und Tualatin.War Larrabee nicht ganz am Anfang für Q4 2008 im Gespräch? Vielleicht hat man die 45-nm-Version ausgelassen und bringt gleich den 32-nm-Refresh auf den Markt?
robbitop@work
2009-02-03, 16:23:06
Es ergibt Sinn, das Mainstreamprodukt auf 32 nm zu verschieben. Bis dahin kann der Core 2 mit seinem kleinen DIE diesen Markt noch gut bedienen. Der Core i5 wäre doch relativ groß geworden in 45 nm. Da man diesen eh verzögerte, ergibt all das schon Sinn.
turboschlumpf
2009-02-03, 17:16:55
Meiner Meinung nach wäre es auch sinnvoll, Larrabee gleich in 32 nm zu fertigen. ;)
haifisch1896
2009-02-03, 19:42:55
Es ergibt Sinn, das Mainstreamprodukt auf 32 nm zu verschieben. Bis dahin kann der Core 2 mit seinem kleinen DIE diesen Markt noch gut bedienen. Der Core i5 wäre doch relativ groß geworden in 45 nm. Da man diesen eh verzögerte, ergibt all das schon Sinn.
Entweder kann ich Dir nicht folgen (bzw. sehe den Sinn nicht), oder Du spekulierst auf eine gemeinsame Vorstellung von i5 und Larrabee.
Wäre natürlich eine nette Sache, und man könnte es ja auch quasi als Plattform vorstellen, was an sich auch eine sinnige Sache darstellt.
BlackBirdSR
2009-02-03, 20:11:58
War Larrabee nicht ganz am Anfang für Q4 2008 im Gespräch? Vielleicht hat man die 45-nm-Version ausgelassen und bringt gleich den 32-nm-Refresh auf den Markt?
Möglich, aber wenn du die letzten Jahre verfolgst und siehst, wieviel Geld und Zeit die Entwicklung von neuen Designs und Architekturen verschlingt, dann scheint ein Wechsel mal eben so völlig absurd.
Zumal eines klar sein dürfte. Larrabee1 wird nicht viel mehr sein als Marktforschung und ein Testlauf. Bei den geringen Absätzen die ersten Monate, wird man nicht extra den Prozess wechseln. Zudem hat ja Microsoft gezeigt: Erfülle die Erwartungen für dein Hype-Produkt am besten nicht beim ersten Mal; Beim zweiten Anlauf fressen sie dir aus Dank die Haare vom Kopf.
robbitop@work
2009-02-04, 09:38:00
Meiner Meinung nach wäre es auch sinnvoll, Larrabee gleich in 32 nm zu fertigen. ;)
Mir gings nur darum, dass ich es für sinnvoll halte, den Core i5 erst in 32 nm zu bringen. Ob das mit Larrabee auch so ist, weiß ich nicht. Ich vermute eher nicht. Bei einem Prozesswechsel ist die Fertigungskapazität und die Yields anfangs noch recht ungünstig. Außerdem sind dort die Abschreibungen für die Investitionen noch am höchsten. Also nutzt man diesen Prozess für ein Produkt mit einer sehr hohen Marge. Und das wären IMO CPUs. Insbesondere High-End-CPUs. Bei GPUs ist die Gewinnmarge deutlich kleiner. (riesen DIE und viel geringerer Verkaufspreis pro Kern)
Ich vermute auch eher 45 nm für Larrabee.
turboschlumpf
2009-05-24, 02:08:29
Ich habe mal die Übersicht im ersten Posting aktualisiert:
Larrabee GT300 RV870
Q1 2010 Q4 2009 Q4 2009
45 nm 40 nm 40 nm
Chip 2,000 GHz 0,700 GHz 0,900 GHz
Shader 2,000 GHz 1,600 GHz 0,900 GHz
Speicher 1,000 GHz 1,100 GHz 1,100 GHz
Cores 32 16 12
VPUs/Core 1 4x8 20
VPU 16-wide 1-wide 5-wide
SP TFlop/s 2,048 2,458 2,160
512 MADD 512 MADD+MUL 1200 MADD
DP TFlop/s 0,512 0,410 0,540
128 MADD 128 MADD 300 MADD
TMUs 8 Quad 32 Quad 12 Quad
GTexel/s 64,0 89,6 43,2
256 bit 512 bit 256 bit
1024 MiB 2048 MiB 1024 MiB
GDDR5 GDDR5 GDDR5
128,0 GB/s 281,6 GB/s 140,8 GB/s
AnarchX
2009-05-24, 11:59:09
TMUs @ 2GHz mag man doch bezweifeln, eine eigene Clockdomain mit dem halben Takt wäre wohl realistischer.
Wenn man diese so einfach takten könnte, wäre Intels IGP-Zeug mit nur 2 TMUs wohl schon weit über 1GHz.
Sonyfreak
2009-05-24, 12:15:22
Die theoretische Rechenleistung der drei Chips scheint ja halbwegs auf einem Niveau zu liegen. Nur hat der GT300 fast die doppelte Speicherbandbreite der Kontrahenten. Meint es Nvidia damit einfach zu gut, oder werden die Gegner Probleme damit haben?
mfg.
Sonyfreak
Seraf
2009-05-24, 12:20:17
http://pc.watch.impress.co.jp/docs/2008/0515/esec_16.jpg
cYa
Ein COM Express Modul ist ein vollständiger Rechner mit Chipsatz und Zusatz-ICs wie HDA-Codecs usw.! Die Leistungsaufnahme ist nicht mit einer CPU vergleichbar.
http://www.pfu.fujitsu.com/prodes/product/som/am105.html
reunion
2009-05-24, 12:34:48
Die Frage ist ohnehin erstmal ob die Specs überhaupt stimmen. Speziell bei Ati wäre ich mir da momentan nicht so sicher. Bei nV scheint es schon praktisch fix zu sein, bei Intel könnte es auch noch Verschiebungen geben.
dargo
2009-05-24, 13:18:42
Meint es Nvidia damit einfach zu gut, oder werden die Gegner Probleme damit haben?
Wann hat NV den GPUs je zu viel Speicherbandbreite spendiert?
AnarchX
2009-05-24, 13:21:53
Die theoretische Rechenleistung der drei Chips scheint ja halbwegs auf einem Niveau zu liegen.
Wie schon gesagt, eine solch hohe Texelfüllrate bei LRB würde ich eher bezweifeln. Und auch so darf man bei ihm nicht vergessen, dass er die Rasterisierung in Software durchführen muss.
Im Endeffekt dürfte Ailuros Andeutung in Richtung RV7x0-Leistung nicht so verkehrt sein.
Nur hat der GT300 fast die doppelte Speicherbandbreite der Kontrahenten. Meint es Nvidia damit einfach zu gut, oder werden die Gegner Probleme damit haben?
Beim GT300 wird wohl aber auch die Rechenleistung entsprechend ansteigen, sodass diese Bandbreitensteigerung durchaus im Rahmen ist (NV sieht bis 2013 gar >1 TB/s auf einer GPU).
Beim RV870 könnte mit entsprechender Leistungssteigerung in der GPU die Luft mit 0.4ns Speicher an einem 256-Bit wohl durchaus etwas dünn werden. Vielleicht gibt es diesmal etwas oberhalb der 256-Bit, wie 320-Bit.
Oder die MCM-Gerüchte zum RV870 stimmen und er ist eine kleinere Steigerung gegenüber RV770/790 und landet dann aber in doppelter Ausführung auf einem Package und dann auf der X2 gar 4 GPUs.
reunion
2009-05-24, 13:27:52
Man darf ja auch nicht vergessen das RV870 nicht gegen GT300 antritt, sondern RV870 X2. Allerdings hat nV dann natürlich immer noch den Trumpf in der Hand wie jetzt mit GT200 ebenfalls eine X2 zu bringen.
AnarchX
2009-05-24, 13:41:22
Man darf ja auch nicht vergessen das RV870 nicht gegen GT300 antritt, sondern RV870 X2.
Nur könnte diese das Problem haben, wenn es bei 256-Bit bleibt, dass sie anders als 3870 und 4870 X2 nur gleichviel Bandbreite als die Single-GPU-Konkurrenz von NV hat.
Generell sieht es wohl diesmal besser für Nvidia und ihre Single-GPU-Strategie aus, aber das kann sich zum Launch hin auch noch etwas ändern, wie damals beim RV770.:D
Allerdings hat nV dann natürlich immer noch den Trumpf in der Hand wie jetzt mit GT200 ebenfalls eine X2 zu bringen.
Für Anfang 2010 spräche imo nicht soviel gegen eine G300GX2. Bis dahin sollten die Yields auf einem angenehmen Niveau sein und der Die ist ja fast so groß wie der G200b auf der aktuellen GTX 295, dazu dann noch 0.5ns GDDR5, der dann Massenware sein sollte.
Wenn man eine GTX 295 für knapp über 400€ zum Start verkaufen konnte, dann sollte eine solche exklusivere Lösung mit wohl höherem Abstand zur Konkurrenz für 500-600€ kein Problem sein.
GTX 395:
512SPs, 128 TMUs x 2
633MHz core
1450MHz ALUs
900MHz GDDR5@448bit x 2
162 GTex
4450 GFLOPs
400 GB/s
3584MiB
300W max. 220W avg.
So manche Hochschule würde sich sicherlich über 18 TFLOPs für ihre Desktop-Supercomputer freuen... ;)
Bei Intel könnte sich vielleicht auch die Frage nach einem Multi-GPU-LRB stellen, vielleicht auf der Basis von Lucid Logix' Hydra?
AffenJack
2009-05-24, 14:01:48
Damit nen g300x2 in 40nm kommt, müsste das ding aber schon wieder sehr enttäuschend sein. Ich glaube nicht, dass dies nen 2 mal passieren wird. 150% rv870 Leistung sollte man doch erreichen können und dann könnte man immernoch ne Ultra bringen gegen ne 5870x2. Ne g300x2 wäre dann eher für 32nm angesagt.
turboschlumpf
2009-05-24, 14:34:02
TMUs @ 2GHz mag man doch bezweifeln, eine eigene Clockdomain mit dem halben Takt wäre wohl realistischer.
Wenn man diese so einfach takten könnte, wäre Intels IGP-Zeug mit nur 2 TMUs wohl schon weit über 1GHz.Angenommen es handelt sich um Quad-TMUs und diese takten nur mit 1,0 GHz, dann hätte Larrabee aber eine ziemlich miese Texturierungsleistung. Wie sinnvoll ist es, einen solchen Monster-Chip durch die TMUs zu limitieren?
Ebenfalls etwas Kopfschmerzen bereitet mir die Speicherbandbreite. Besitzt Larrabee eventuell doch ein 512 bit breites SI? Oder kommt Larrabee als TBR mit deutlich weniger Speicherbandbreite aus?
AnarchX
2009-05-24, 14:45:16
Angenommen es handelt sich um Quad-TMUs und diese takten nur mit 1,0 GHz, dann hätte Larrabee aber eine ziemlich miese Texturierungsleistung. Wie sinnvoll ist es, einen solchen Monster-Chip durch die TMUs zu limitieren?
Wo ist LRB ein Monsterchip?
Wenn man von den 2 TFLOPs die virtualisierten FF-Einheiten abrechnet, die heutige GPUs und auch die kommenden noch haben werden, dann sehe ich LRB wohl nicht weit über einer 4870/4890, wenn überhaupt. Und diese haben ja auch nicht viel mehr als 30GTex/s.
Oder erwartest du, dass Intel mit LRB NV bei der Filterqualität überbieten will? :D
turboschlumpf
2009-05-24, 14:49:29
Monster nur im Hinblick auf die Die-Größe.
Wenn man von den 2 TFLOPs die virtualisierten FF-Einheiten abrechnet, die heutige GPUs und auch die kommenden noch haben werden, [...]So viele sind das doch überhaupt nicht mehr. Zumal wir bei dem Geschiss, der GT200 sei durch den Rasterizer limitiert, ja sehen, wie toll FF-Hardware ist.
So viele sind das doch überhaupt nicht mehr. Zumal wir bei dem Geschiss, der GT200 sei durch den Rasterizer limitiert, ja sehen, wie toll FF-Hardware ist.
Die Limitierung tritt natürlich bei gleicher Implementierung auch in Software auf. Da gibt es keine Unterschiede.
Oder andersrum: Alles was man in Software tun kann, kann man natürlich auch in Hardware implementieren. Wenn man solche grundsätzlichen Zusammenhänge nicht verstanden hat sollte man sich solche Kommentare sparen.
turboschlumpf
2009-05-24, 15:19:50
Alles was man in Software tun kann, kann man natürlich auch in Hardware implementieren.Bei Intel können sich theoretisch zeitweise 500 mm² ums Rasterizing kümmern, bei Nvidia nicht.
Bei Intel können sich theoretisch zeitweise 500 mm² ums Rasterizing kümmern, bei Nvidia nicht.
Das ist ungefähr ein so sinnvoller Vergleich wie in China können sich zeitweise 500 Bauern ums Reisernten kümmern, in den USA nicht (die haben dafür einen fetten Mähdrescher).
Oder erwartest du, dass Intel mit LRB NV bei der Filterqualität überbieten will?
Deckt das Lizenzaustauschabkommen mit AMD eigentlich A.I. Filtercheats ab? :weg:
Larrabbe ist in jeder Hinsicht eine Wundertüte, von Lags, über Mikroruckler reloaded bis zu einem Meilentstein in Sachen Sparfilter würde mich da überhaupt nichts wundern, andererseits kann es natürlich auch ein rundum überzeugender Auftritt werden. Hardware neuartig, Treiberteam neu, spannend. :)
reunion
2009-05-24, 15:45:13
Larrabee ist vorallem eines, nämlich keine Spielerkarte. Das nimmt man bestenfalls im vorbeigehen mit. Bis auf TMUs praktisch keine FF-Hardware zeigt ganz deutlich wo man stark sein will und das wohl auch sein u.a wird dank x86 Kompatibilität.
und das wohl auch sein u.a wird dank x86 Kompatibilität.
Und was bringt einem die x86 Kompatibilität als Entwickler? Damit es ordentlich läuft muss man es eh neu durch den Compiler jagen und dann macht es keinen Unterschied mehr ob x86 oder nicht.
Aquaschaf
2009-05-24, 15:57:40
und das wohl auch sein u.a wird dank x86 Kompatibilität.
Das "Argument" wird ja immer wieder gerne wiederholt, aber: die x86-Kompatibilität ist aus Entwicklerperspektive irrelevant. Bereits für x86 kompilierte Programme auf Larrabee auszuführen ist damit möglich, mehr nicht. Und das zu tun ist ziemlich sinnbefreit.
turboschlumpf
2009-05-24, 16:04:43
Das ist ungefähr ein so sinnvoller Vergleich wie in China können sich zeitweise 500 Bauern ums Reisernten kümmern, in den USA nicht (die haben dafür einen fetten Mähdrescher).Der Kern meiner Aussage war ein anderer. Larrabee kann dem Rasterizing (genau wie jedem anderen Rechenschritt, Texturierung ausgenommen) dynamisch die optimale Rechenleistung zuteilen. Intel treibt den Unified-Ansatz also auf die Spitze.
AnarchX
2009-05-24, 16:12:59
Vom Konzept ist das natürlich interessant, nur stellt sich die Frage wieweit ein LRB mit seinen spekulierten 2 TFLOPs davon profitieren kann und nicht an dieser Virtualisierunglast erdrückt wird.
Bei den kleinen USA-GPUs und R6xx mit seiner ROP-Notlösung hat man ja auch teilweise gesehen, dass der Ansatz nicht nur Vorteile bringen muss.
Aber mit ~32GTex/s und 128GiB/s würde ich doch den 32-Core-LRB gut beraten sehen. Immerhin soll Intel darüber auch noch eine XE-Version platzieren. Wobei hier sich die Frage stellt, ob die Texturleistung skaliert wird oder nur die Rechenleistung für die Profimärkte.
=Floi=
2009-05-24, 16:18:42
warum ist das sinnfrei? wenn ich 32x die selbe anwendung ausführen kann, dann sollte hier auch ein gewinn auf der habenseite stehen...
Aquaschaf
2009-05-24, 16:29:19
warum ist das sinnfrei? wenn ich 32x die selbe anwendung ausführen kann, dann sollte hier auch ein gewinn auf der habenseite stehen...
Larrabee wird beim ausführen von Programmen die für eine normale x86-CPU geschrieben wurden im Vergleich extrem lahm sein.
Die x86 Teile im LRB sind doch nur als Kontroll-CPUs für die Vektoreinheiten gedacht. Ohne Neukompilieren kann man die Vektoreinheiten nicht nutzen und die Performance säuft gnadenlos ab.
Trotzdem ist wohl das schon sinnvoll, wenn auch IMHO nicht so sinnvoll wie Intel gern tut, wenn sie die Kompatibilität als großen Vorteil hervorheben. Ist ja sicher nicht umsonst der schnellste Rechner der Welt ein x86/Cell Hybrid.
Kontroll-CPUs ist so nicht richtig. Die Vektoreinheiten sind ja nur zusätzöiche Einheiten von den x86-Kernen und auch das Instruction-Format ist auch x86.
Natürlich sind das keine "richtigen" Kontroll-CPUs. Aber IMHO deutet das Konzept stark in die Richtung. LRB ist eben insofern kein normaler x86 und anders als alle bisherigen, als er einen winzigen x86 Teil und einen riesigen Erweiterungsteil hat. Klar ist AVX (oder wars FMA?) eine Erweiterung zu x86 und LRB hat die x86 ISA, aber bei LRB wackelt der Schwanz mit dem Hund. Legacy code drauf laufen zu lassen macht keinen Sinn. LRB ist _nur_ für AVX code gedacht und zu gebrauchen.
turboschlumpf
2009-05-24, 23:07:42
FMA = Fused multiply-add
AVX = Advanced Vector Extensions
Das was du meinst sind hingegen die LRBni (= Larrabee New Instructions). ;)
Ah ja richtig ... Intel könnte sich ruhig mal ein paar Beschränkungen auferlegen, was das Raushauen von x86 Erweitungen angeht :-D
Ändert aber nix am Kern meiner Aussage.
reunion
2009-05-25, 18:20:49
Vielleicht nicht unwichtig für etweiige Refreshchips:
Globalfoundries to fight TSMC on 28nm (http://www.fudzilla.com/content/view/13833/1/)
Der Kern meiner Aussage war ein anderer. Larrabee kann dem Rasterizing (genau wie jedem anderen Rechenschritt, Texturierung ausgenommen) dynamisch die optimale Rechenleistung zuteilen. Intel treibt den Unified-Ansatz also auf die Spitze.
Und mein Ansatz war der, dass die "optimale Rechenleistung" für nicht-spezialisierte HW oft unter der von spezialisierter HW liegt.
Intel sagt ja selbst, dass das Hauptziel nicht maximale Rasterizing-Leistung ist, sondern möglichst keine HW-Einheit unterbeschäftigt zu haben, wenn Rasterisierung gerade nicht der Falschenhals ist.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.