Intel Larrabee: Pentium 1 inside
- Ersteller Opteron
- Erstellt am
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Das Ganze liest sich zwar wie die Intel Version des letzten P3D April Scherzes, aber lest selbst:
Bin gespannt, wie lange es dauert bis AMD mit Bazooka kontert
http://www.planet3dnow.de/vbulletin/showthread.php?t=336791
Update: 5.8:
Offizielles Intel pdf zu Larrabee verfügbar:
http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf
Update:
Angeblicher Videoausschnitt eines Larrabee Spiels:
http://www.youtube.com/watch?v=rRgKMso1rGA
ciao
Alex
http://www.heise.de/ct/08/15/022/
Bin gespannt, wie lange es dauert bis AMD mit Bazooka kontert
http://www.planet3dnow.de/vbulletin/showthread.php?t=336791
Update: 5.8:
Offizielles Intel pdf zu Larrabee verfügbar:
http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf
Update:
Angeblicher Videoausschnitt eines Larrabee Spiels:
http://www.youtube.com/watch?v=rRgKMso1rGA
ciao
Alex
Zuletzt bearbeitet:
TAL9000
Grand Admiral Special
Und schließlich ist das ein P3D-Aprilscherz, da muß man immer vorsichtig sein, es als Unfug abzutun.Immerhin gabs hier scherzweise auch den ersten DualCore, ein lockeres Jahr bevor er tatsächlich kam.
Leute wenn ihr so weiter Vorhersagen macht, gebt mit doch die Lottozahlen der nächsten Ziehung
Aber wie realistisch ist das nun
von dem Interna der Intel CPUs hab ich so gut wie keine Ahnung.TAL9000
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Der Artikel ist vom Adreas Stiller, der kennt die Intel Chefentwickler seit mehreren Jahren persönlich ... die Wahrscheinlichkeit wird also schon über 75% liegen.Aber wie realistisch ist das nun
Was ich aber nicht ganz kapier... wieso nimmt Intel nicht gleich nen Atom Kern ?
Da gabs vor längerem ja auch Gerüchte, dass Atom ein Pentium1 wäre, wegen des in-order Designs. Vielleicht hat er da was falsch verstanden. Aber naja .. abwarten.
ciao
Alex
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Der Pentium 1 mit MMX war in der IPC ("Instructions per Clock") im Vergleich zum PentiumPro, bzw. zu dem Pentium II nahezu gleichwertig ...
Von daher kann ich mir derzeit beim besten Willen nicht vorstellen, dass da nun beim "Atom" gegenüber einem PentiumM nur die halbe Rechenleistung bei gleichen Takt herauskommt.
Aber für "unmöglich" halte ich das natürlich auch nicht. Wenn die Vorgabe lautete so viel Energie pro vorgegeben Takt einzusparen, auch wenn dabei die IPC dann in den Keller geht.
Der K6 war bezogen auf Integer-Rechenleistung pro Takt sogar besser als ein K7 ... der K6 konnte aber nicht so leicht auf höhere Taktraten geprügelt werden.
Die FPU beim K6 war ohne Pipeline, so dass bei ständig wechselnden FPU-Anweisungen die so schlecht gar nicht war.
Es stellt sich aber die Frage, ob AMD überhaupt derzeit in der Lage ist die Resourcen zugunsten eines derartigen AMD-"Larrabee-Klon" mit aufgebohrten K6-Kernen zu schultern.
Ein verschlankter K8-Kern könnte da ebenso gute Dienste leisten (weniger Ausführungseinheiten + verschlanktes "Out of Order-Design").
Oder AMD konzentriert sich auf ATI-GPU-Kerne und entwirft Emulatoren/Wrapper, um mit derartigen GPU-Multicores auch x86-64 Code damit auszuführen ...
Irgendwie gefallen mir alle Möglichkeiten nicht so recht ... Muss denn AMD einen Larrabee-Klon herstellen? AMD hat doch schon eine GPU-Multicore-Familie (wenn auch nicht mit x86-64 ISA)
MFG Bobo(2008 )
Von daher kann ich mir derzeit beim besten Willen nicht vorstellen, dass da nun beim "Atom" gegenüber einem PentiumM nur die halbe Rechenleistung bei gleichen Takt herauskommt.
Aber für "unmöglich" halte ich das natürlich auch nicht. Wenn die Vorgabe lautete so viel Energie pro vorgegeben Takt einzusparen, auch wenn dabei die IPC dann in den Keller geht.
Der K6 war bezogen auf Integer-Rechenleistung pro Takt sogar besser als ein K7 ... der K6 konnte aber nicht so leicht auf höhere Taktraten geprügelt werden.
Die FPU beim K6 war ohne Pipeline, so dass bei ständig wechselnden FPU-Anweisungen die so schlecht gar nicht war.
Es stellt sich aber die Frage, ob AMD überhaupt derzeit in der Lage ist die Resourcen zugunsten eines derartigen AMD-"Larrabee-Klon" mit aufgebohrten K6-Kernen zu schultern.
Ein verschlankter K8-Kern könnte da ebenso gute Dienste leisten (weniger Ausführungseinheiten + verschlanktes "Out of Order-Design").
Oder AMD konzentriert sich auf ATI-GPU-Kerne und entwirft Emulatoren/Wrapper, um mit derartigen GPU-Multicores auch x86-64 Code damit auszuführen ...
Irgendwie gefallen mir alle Möglichkeiten nicht so recht ... Muss denn AMD einen Larrabee-Klon herstellen? AMD hat doch schon eine GPU-Multicore-Familie (wenn auch nicht mit x86-64 ISA)
MFG Bobo(2008 )
Zuletzt bearbeitet:
Ihr wisst schon...K8-Larrabee 
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Ich zitier daraus mal:Ihr wisst schon...K8-Larrabee
Betreff der Watt Zahl sag ich nur .. von der Wirklichkeit überrollt ^^Edit4: Das einzige was mir nur ein wenig Kopfzerbrechen machen würde, wäre die TDP...der Winchester hat (nach alter AMD-Worstcase-Rechnung) 67Watt...machen wir darauß "realistische" 50Watt...runter auf 45nm rechnen wir (diesmal nicht großzügig, sondern realistisch) mit einer "1/3-telung" der realistischen TDP auf ~17Watt...mal 8 macht das 136Watt. Hmm....bissl viel
.
EDIT :
.
Ne das passt schon so, Fusion gefälllt mir besser, ne dicke CPU plus viele "simple" SPUs, also quasi das Cell Prinzip.
Halbstarke Kernchen sind für GPUs ganz brauchbar, aber bei GPGPU .. hmmm naja mal schauen, was noch so über Larrabee rauskommt. Vom Hocker reist es micht auf alle Fälle erstmal nicht. 32 Kerne ... 300W ... da haben ATi & Nvida sicherlich besseres zu bieten, bis das Teil rauskommt.
Und zum Thema einfacheres programmieren wegen x86 hab ich schon was im News Artikel geschrieben, ich kopiers mal hier rein:
------------------
Abgesehen davon gibts sowas:
http://www.ddj.com/architect/199501192
http://www.rapidmind.com/
Fragt sich natürlich wie effektiv das ist, hat jemand da schon was drüber gelesen ?
Unterstützt wird übrigens (fast) alles was viele Kerne hat, Cell, nV/ATI GPUs, und x86 Multikern CPUs. Fehlen nur non-x86 Multikerner.
Beste Skalierung im Werbe PDF:
-----------------------
Zwar muss man die Software anpassen, aber der Arbeitsschritt beschränkt sich auf parallelisiserbare Codeabschnitte zu suchen/finden. Das muss eh immer gemacht werden, wenn man mutlicores nutzen will egal ob jetzt x86, VLIW, oder sonstwas. Danach drückt man aufs Knöpfchen und hinten kommt der Code raus ... schaut eigentlich ideal aus. Bin mal gespannt, ob es irgendwelche Nachteile gibt.
Für so einen Ansatz ist dann natürlich auch Cell/Fusion optimal, der serielle Codeanteil wird durch den starken Hauptkern geschleust, der parallele in den SPUs vernichtet ^^
ciao
Alex
Ach, babbel! Meine Idee ist brilliant! Wir haben ja heute auch schon 130W TDPs...da machen die 6W den Kohl auch nemmer fett
(R.I.P.)
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Öhm ... das meinte ich doch ... der neue Phenom 9950BE hat doch 140W, da ist Deine Lösung locker drinAch, babbel! Meine Idee ist brilliant! Wir haben ja heute auch schon 130W TDPs...da machen die 6W den Kohl auch nemmer fett
ciao
Ale
kenny1988
Admiral Special
Öm Soweit ich weis HAt doch inlket auch einen C2D in beto wo 150W Verbrät der QX9770 vwebrät auch sate 150W TDP also von dahwer Hat intel imernoch die Energie verschwänder krone.
Oder Der Alte Q6700 B2 @ 2,67 Ghz hate Auch 130W ich frag mich hir nur warum sich alle über AMD 125W modelle aufregen?
Also Für mich wär Das doch klasse Nur für bonic Aber für dern Regulären Tages Gebrauch einfach ungeeignet.
Wer bite Brauch Als oto normal verbraucher 4Core wo nicht gerade viedeo bearbeitung macht und das machen ja die wenigsten.
Zum Zocken Reichen 2-4cors inmoment locker aus es wär doch intere santer wen Quads rauskomen die wo weniger als 25W leistungsaufnahme haben bei gleichzeitig gestiegener leistung.
Das wär mal was interesanter und mal gut für die umwelt.
Bedenkt mal bitte Es ist nicht alles Gold was glänzt.
Also das sit meine meinung Aber das mit den intel Prozis ist Die warheit intel Quads wurden erst ab den G0 steping mit 95W TDP ausgeliefert.
mfg Kenny
Oder Der Alte Q6700 B2 @ 2,67 Ghz hate Auch 130W ich frag mich hir nur warum sich alle über AMD 125W modelle aufregen?
Also Für mich wär Das doch klasse Nur für bonic Aber für dern Regulären Tages Gebrauch einfach ungeeignet.
Wer bite Brauch Als oto normal verbraucher 4Core wo nicht gerade viedeo bearbeitung macht und das machen ja die wenigsten.
Zum Zocken Reichen 2-4cors inmoment locker aus es wär doch intere santer wen Quads rauskomen die wo weniger als 25W leistungsaufnahme haben bei gleichzeitig gestiegener leistung.
Das wär mal was interesanter und mal gut für die umwelt.
Bedenkt mal bitte Es ist nicht alles Gold was glänzt.
Also das sit meine meinung Aber das mit den intel Prozis ist Die warheit intel Quads wurden erst ab den G0 steping mit 95W TDP ausgeliefert.
mfg Kenny
Stichwort Raytracing...(um mal nur das Interesse der "Zocker" zu wecken...der Larrabee soll ja schließlich kein Crunchmonster werden - dafür zahlen große Firmen gerne auch mehrere 5-7stellige Summen, damit da die Power da ist...da juckt die Firma doch nicht, was Intel/AMD in dem Bereich erfinden)
Woerns
Grand Admiral Special
- Mitglied seit
- 05.02.2003
- Beiträge
- 2.983
- Renomée
- 232
Das Pentiumdesign P54C ging angeblich ans Pentagon, damit die daraus ein strahlensicheres Design für militärische Anwendungen machen, und kam später zu Intel zurück, um jetzt Basis für Larrabee Cores zu werden.
http://arstechnica.com/news.ars/pos...-gpu-based-on-secret-pentagon-tech-sorta.html
Daraus:
"...Intel will claim that Larrabee has 20x the performance per watt of a Core 2 Duo and half the single-threaded performance..."
MfG
http://arstechnica.com/news.ars/pos...-gpu-based-on-secret-pentagon-tech-sorta.html
Daraus:
"...Intel will claim that Larrabee has 20x the performance per watt of a Core 2 Duo and half the single-threaded performance..."
MfG
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Das angeblich ist in diesem Fall (halb)falsch.
Intel hat für US-Institutionen ihr P54C-Design freigegeben. Das war nicht begrenzt aufs Militär (auch wenn das nahe zusammen liegt), sondern ebenso die NASA durfte daran arbeiten.
Intel ging jedoch nicht so weit ihr Design freizugeben, wie es Sun mit einem OpenSource UltraSPARC T1 tat. Kommerzielle Konkurrenz wollte Intel damit nicht schaffen, was mit Suns UltraSPARC T1 und T2 durchaus passieren könnte.
MFG Bobo(2008 )
Es hat zwar (noch) nichts direkt mit Intels Larrabee zu tun, da aber Intel eine Stange Geld in das Unternehmen investiert hat und es um Grafik geht poste ich es mal hier:
Die israelische Firma Lucid meint eine Technologie entwickelt zu haben, welche dem Betriebssystem mehrere GPUs als einen vorgaukeln kann und das ganze soll dann auch noch toll skalieren.
Deren Chip scheint so etwas wie der VSU Chip der 3DLabs-Karten zu sein und übernimmt damit hardwarebeschleunigt das Load-Balancing. Falls die Technologie tatsächlich so gut funktioniert könnte das für Intel wie gerufen kommen um später Larrabee-MultiGPU-Systeme zu machen, auch wenn das dann N mal 300W Leistungsaufnahme ergibt.
Link zur Herstellerseite
Passend zum Larrabee: der CEO kennt den 486 und P-MMX auch von innen
Die israelische Firma Lucid meint eine Technologie entwickelt zu haben, welche dem Betriebssystem mehrere GPUs als einen vorgaukeln kann und das ganze soll dann auch noch toll skalieren.
Deren Chip scheint so etwas wie der VSU Chip der 3DLabs-Karten zu sein und übernimmt damit hardwarebeschleunigt das Load-Balancing. Falls die Technologie tatsächlich so gut funktioniert könnte das für Intel wie gerufen kommen um später Larrabee-MultiGPU-Systeme zu machen, auch wenn das dann N mal 300W Leistungsaufnahme ergibt.
Link zur Herstellerseite
Passend zum Larrabee: der CEO kennt den 486 und P-MMX auch von innen
Zuletzt bearbeitet:
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Interessant ... im Moment hört sich das aber eher nach nem Xfire / SLi Mix an:
ciao
Alex
P.S: Inquirer hat auch ne Meldung
http://www.theinquirer.net/gb/inquirer/news/2008/07/16/ati-nvidia-lucidlogix
Aber nichts Weltbewegendes ...
Aber dazu braucht man ne extra hardware ... also zum Nachrüsten seh ich da keine Chance ...
ciao
Alex
P.S: Inquirer hat auch ne Meldung
http://www.theinquirer.net/gb/inquirer/news/2008/07/16/ati-nvidia-lucidlogix
Aber nichts Weltbewegendes ...
kenny1988
Admiral Special
Multi Gpu Lösungen will Ja jeder Hersteller heraus bringen bzw. bringt es auch.
Das bekannte ist wo jeder kennt ist SLI,CF Multi crome.
Dann giebt es noch die möglichkeit mehrere Gpu Kerne in einer Gpu unterzu bringen so wie bei den cpu's Wo ich bis jetzt gehört HAb Vor längerem solte Angeblich ATI und S3 an so was entwickeln aber wie lange es dauert bis es zur marktreife komt oder überhaupt auf den markt komt ist fraglich.
Das würde dan heißen das Neue treiber speziele für diese Grafikkarten serien angepast werden müssen usw.
Das bekannte ist wo jeder kennt ist SLI,CF Multi crome.
Dann giebt es noch die möglichkeit mehrere Gpu Kerne in einer Gpu unterzu bringen so wie bei den cpu's Wo ich bis jetzt gehört HAb Vor längerem solte Angeblich ATI und S3 an so was entwickeln aber wie lange es dauert bis es zur marktreife komt oder überhaupt auf den markt komt ist fraglich.
Das würde dan heißen das Neue treiber speziele für diese Grafikkarten serien angepast werden müssen usw.
Ich entschuldige mich schonmal für meinen flachen Witz und das ellenlange OT, aber bei der Vorlage kann ich nicht anders.
Meine Antwort: Das ist wohl unter den Bulldozer gekommen
OT:
So und jetzt BTT Larrabee
Meine Antwort: Das ist wohl unter den Bulldozer gekommen
OT:
Mal im Ernst: Ich habe zwar gehofft, dass sowas möglich ist, aber bei genauerer Betrachtung machte es für eine bestehende Architektur keinen Sinn. (Das Gerücht besagte ja anfänglich man rüste Reverse-HT bei bestehenden Prozessoren per Software nach *hust*)
Das ganze würde im Falle von AMDs beschränkten Kapazitäten wohl eher funktionieren, wenn man zwei vorhandene (also entwickelte) Kerne nimmt und quasi die Instruction Control-Stufen zusammenführt und dann die Befehle auf die einzelnen Funktionseinheiten "der beiden Kerne" verteilt. Beim K10 wären das dann die Reorder Buffer, die man irgendwie mit einer Logik versehen muss welche verhindert, dass unter Vollast einer der beiden ROB bevorteilt wird und man die Funktionseinheiten ungleichmäßig mit Befehlen aus beiden Kernen bestückt. Das Synchronisieren welche Befehle in der ROB bereits "retired" sind ist bei einer doppelt so großen Funktionseinheitenmenge natürlich auch ungleich schwerer und verursacht auch Hardwareaufwand.
Am Ende der Pipeline müsste man das ganze dann wieder richtig sortieren (man braucht dafür ja quasi nur ein Bit welches den Befehl dem Kern zuordnet) und dann hat man im besten Fall eine Verdopplung des (FP-)Peak-Durchsatzes für einen Kern und im Schlimmsten Fall eine doppelt so große Menge Silizium die auf vollem Arbeitstakt und mit voller Kernspannung betrieben werden muss und zu 80% rumidled. Der zusätzliche Verbrauch einer so komplexen ICU ist natürlich auch nicht zu verachten.
Das ganze würde dann in etwa so aussehen:
http://img232.imageshack.us/img232/9530/reversehtspekulationpf4.png
bzw.
http://img99.imageshack.us/img99/2948/k8l2cj4.jpg
Dass man sich mit Garantie auch noch 2-3 zusätzliche Pipelinestufen einhandelt ist klar. Vorne weil es eine extrem komplexe Einheit wird und hinten weil man ja die Befehle wieder den entsprechenden LSU-Einheiten der jeweiligen Kernteile zuordnen muss. Anschließend kann man sie ja wieder mit den zwei bestehenden Einheiten weiterverarbeiten, wobei die LSU aufgrund der maximalen Peakdurchsatzwerte auch noch mehr Zwischenspeicherplatz braucht. Mehr Freiheit für das Neuanordnen der Speicherzugriffe hat außerdem auch noch niemandem geschadet.
Da die Kerne beide noch eigene Caches haben und die Außenverbindung quasi unverändert bleibt hätte man auch weiterhin für jeden Thread/Kernteil einen eigenen Zugriff auf SRQ/Crossbar und würde dort somit auch wenig Bandbreitenprobleme bekommen. Erst wenn ein Kernteil exzessiv 128Bit SSE-Berechnungen auf 2 FP-Einheiten durchführt deren Operanden linear aus dem RAM kommen und die Ergebnisse dann auch noch dahin zurück müssen wird es unschön.
Speziell den L1 D-Cache müsste man aber wieder deutlich beschleunigen um mit der möglichen Anfragen- und Speicherflut mitzukommen. Das dann die übliche AMD-Baustelle "exklusiver Cache" beim Rückschreiben in den L2 auch wieder aufgerissen wird ist eine weitere Folge. Die Decoder müssten auch zumindest um je eine Einheit erweitert werden um den Maximaldurchsatz nicht zu bremsen, auch wenn man da natürlich von den Fortschritten beim K10 profitiert (immer mehr Befehle sind schnelle Direct-Path Befehle mit z.T. nurnoch einer MacroOp). Damit wird dann der ROB auch wieder größer (4 Reihen) und die ICU noch komplexer.
Fazit: Letztlich hat man dann doch bis auf die Ausführungseinheiten alles neu gemacht und ich glaube, dass diese Variante im Vergleich zu einem SMT-Prozessor, der die benötigte Hardware geteilt nutzt und nicht dupliziert nur in seltenen Fällen von Vorteil ist. Reverse-HT macht AMD also mit großer Sicherheit nicht. Für eine definitive Aussage über die Sinnhaftigkeit müsste man es halt mal mit den Originaldaten simulieren können
Die Möglichkeit wegen Speicherzugriffen ungenutze Funktionseinheiten für sinnvolle Dinge zu nutzen wäre aber trotz allem schon eine tolle Sache, gerade für die bisher etwas "zu schmalen" AMD-Kerne. Mal sehen was AMD beim K11 nun für eine tolle Architektur zusammenschustert. Vll. ist es ja ein breiter Kern mit "Reverse HT" oder wenigstens irgendetwas SMT-mäßiges.
Das ganze würde im Falle von AMDs beschränkten Kapazitäten wohl eher funktionieren, wenn man zwei vorhandene (also entwickelte) Kerne nimmt und quasi die Instruction Control-Stufen zusammenführt und dann die Befehle auf die einzelnen Funktionseinheiten "der beiden Kerne" verteilt. Beim K10 wären das dann die Reorder Buffer, die man irgendwie mit einer Logik versehen muss welche verhindert, dass unter Vollast einer der beiden ROB bevorteilt wird und man die Funktionseinheiten ungleichmäßig mit Befehlen aus beiden Kernen bestückt. Das Synchronisieren welche Befehle in der ROB bereits "retired" sind ist bei einer doppelt so großen Funktionseinheitenmenge natürlich auch ungleich schwerer und verursacht auch Hardwareaufwand.
Am Ende der Pipeline müsste man das ganze dann wieder richtig sortieren (man braucht dafür ja quasi nur ein Bit welches den Befehl dem Kern zuordnet) und dann hat man im besten Fall eine Verdopplung des (FP-)Peak-Durchsatzes für einen Kern und im Schlimmsten Fall eine doppelt so große Menge Silizium die auf vollem Arbeitstakt und mit voller Kernspannung betrieben werden muss und zu 80% rumidled. Der zusätzliche Verbrauch einer so komplexen ICU ist natürlich auch nicht zu verachten.
Das ganze würde dann in etwa so aussehen:
http://img232.imageshack.us/img232/9530/reversehtspekulationpf4.png
bzw.
http://img99.imageshack.us/img99/2948/k8l2cj4.jpg
Dass man sich mit Garantie auch noch 2-3 zusätzliche Pipelinestufen einhandelt ist klar. Vorne weil es eine extrem komplexe Einheit wird und hinten weil man ja die Befehle wieder den entsprechenden LSU-Einheiten der jeweiligen Kernteile zuordnen muss. Anschließend kann man sie ja wieder mit den zwei bestehenden Einheiten weiterverarbeiten, wobei die LSU aufgrund der maximalen Peakdurchsatzwerte auch noch mehr Zwischenspeicherplatz braucht. Mehr Freiheit für das Neuanordnen der Speicherzugriffe hat außerdem auch noch niemandem geschadet.
Da die Kerne beide noch eigene Caches haben und die Außenverbindung quasi unverändert bleibt hätte man auch weiterhin für jeden Thread/Kernteil einen eigenen Zugriff auf SRQ/Crossbar und würde dort somit auch wenig Bandbreitenprobleme bekommen. Erst wenn ein Kernteil exzessiv 128Bit SSE-Berechnungen auf 2 FP-Einheiten durchführt deren Operanden linear aus dem RAM kommen und die Ergebnisse dann auch noch dahin zurück müssen wird es unschön.
Speziell den L1 D-Cache müsste man aber wieder deutlich beschleunigen um mit der möglichen Anfragen- und Speicherflut mitzukommen. Das dann die übliche AMD-Baustelle "exklusiver Cache" beim Rückschreiben in den L2 auch wieder aufgerissen wird ist eine weitere Folge. Die Decoder müssten auch zumindest um je eine Einheit erweitert werden um den Maximaldurchsatz nicht zu bremsen, auch wenn man da natürlich von den Fortschritten beim K10 profitiert (immer mehr Befehle sind schnelle Direct-Path Befehle mit z.T. nurnoch einer MacroOp). Damit wird dann der ROB auch wieder größer (4 Reihen) und die ICU noch komplexer.
Fazit: Letztlich hat man dann doch bis auf die Ausführungseinheiten alles neu gemacht und ich glaube, dass diese Variante im Vergleich zu einem SMT-Prozessor, der die benötigte Hardware geteilt nutzt und nicht dupliziert nur in seltenen Fällen von Vorteil ist. Reverse-HT macht AMD also mit großer Sicherheit nicht. Für eine definitive Aussage über die Sinnhaftigkeit müsste man es halt mal mit den Originaldaten simulieren können
Die Möglichkeit wegen Speicherzugriffen ungenutze Funktionseinheiten für sinnvolle Dinge zu nutzen wäre aber trotz allem schon eine tolle Sache, gerade für die bisher etwas "zu schmalen" AMD-Kerne. Mal sehen was AMD beim K11 nun für eine tolle Architektur zusammenschustert. Vll. ist es ja ein breiter Kern mit "Reverse HT" oder wenigstens irgendetwas SMT-mäßiges.
So und jetzt BTT Larrabee
Zuletzt bearbeitet:
hendrikhey
Commodore Special
Mal nebenbei gesagt, ist es noch immer ein Gerücht.
Das mal dazu, nun aber wieder zum Larrabee bitte.
Das mal dazu, nun aber wieder zum Larrabee bitte.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Nur nebenbei (und OT ^^^),
@lil:
Das Thema rHT hatten wir hier im Forum natürlich schon
Mach mal ne boardsuche, dann solltest Du draufstoßen, irgendwann 2005/2006 oder so, als es halt gerade hochkochte. Dresdenboy hatte damals dazu auch AMD Patente ausgegraben, da ist relativ gut beschrieben, wie das läuft(bzw. laufen soll ^^). Die Patente kann jeder runterladen und anschauen, link sollte im Thread auch mit bei stehen
Falls noch Fragen sind, dann kannst Du den thread wieder hoch holen, oder falls er geschlossen ist, dann nimm den K11 - Bulldozer Thread, den ich erstellt habe.
ciao
Alex
@lil:
Das Thema rHT hatten wir hier im Forum natürlich schon
Mach mal ne boardsuche, dann solltest Du draufstoßen, irgendwann 2005/2006 oder so, als es halt gerade hochkochte. Dresdenboy hatte damals dazu auch AMD Patente ausgegraben, da ist relativ gut beschrieben, wie das läuft(bzw. laufen soll ^^). Die Patente kann jeder runterladen und anschauen, link sollte im Thread auch mit bei stehen
Falls noch Fragen sind, dann kannst Du den thread wieder hoch holen, oder falls er geschlossen ist, dann nimm den K11 - Bulldozer Thread, den ich erstellt habe.
ciao
Alex
rkinet
Grand Admiral Special
http://www.computerbase.de/news/hardware/grafikkarten/2008/juli/intel_larrabee_gddr5_12-layer-pcb/
DDR5 klingt realistisch.
Aber 12-Layer für eine Grafikkarte ?
Könnte bedeuten, dass noch breitere Anbindung an den Speicher entsteht, also 1024 oder 1526 (3* separate 512 Bit Channel oder 24* 64 Bit)
DDR5 klingt realistisch.
Aber 12-Layer für eine Grafikkarte ?
Könnte bedeuten, dass noch breitere Anbindung an den Speicher entsteht, also 1024 oder 1526 (3* separate 512 Bit Channel oder 24* 64 Bit)
Also ich war mir sicher schonmal was gelesen zu haben wie das mit dem Speicherinterface beim Larrabee ist. Auf die schnelle konnte ich aber nur die alte Folie mit >150GB/s finden, was bei GDDR5 ja gerade einmal 256-Bit wären.
Bei Fudzilla meint man jetzt wieder, dass doch kein DirectX unterstützt werden wird und die Entwickler ihren Code extra umschreiben müssen für den Larrabee. Da aber Rasterisierung weiterhin als Rendermodus gedacht ist, bedeutet das ja schon fast zwangsläufig eine neue eigene API parallel zu OpenGL und DirectX. Macht das Sinn?
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Das ist so sinnvoll wie die Itanium Linie ... in einem klitzekleinen Nischenmarkt zu gebrauchen ... aber sonst schauts sehr dunkel aus ...
Falls das stimmen sollte kann nV zusammen mit AMD ne Party geben.
Intel hat zwar genügend Entwickler und kann es sich leisten zu den großen Spieleschmieden Leute auf eigene Rechnung zu schicken .. aber bei allen Spielen geht das nicht.
Wobei hmmm ... wenn man die populären Engies programmiert ... das könnte vielleicht sogar aufgehen
Edit:
Auf den 2ten Blick ist die Meldung eigentlich Käse. ATi & Nvidia wandeln die DX Befehle ja auch auf ihre Architektur um. Ich glaube da hat der Fuad was falsch verstanden, Intel bastelt wohl noch an nem DX -> Larabee Compiler (Treiber).
Natürlich könnte Intel trotzdem sein eigenes Ding machen . .aber wozu ... ?
ciao
Alex
Zuletzt bearbeitet:
LinuS
Vice Admiral Special
Da hast du falsch gelesen. Fudzilla meint, dass Larrabee kein dX braucht sondern auch direkt angesprochen werden kann
Ergo, das bedeutet gar nichtsDa hast du falsch gelesen. Fudzilla meint, dass Larrabee kein dX braucht sondern auch direkt angesprochen werden kann
Ich finde es halt komisch, dass in der Meldung steht, dass es nur 6 Spiele gibt, auf welche "have been specifically designed to take advantage of the features on offer from Larrabee" zutrifft. Sicherlich kann das auch heißen, dass die "alten" Schnittstellen weiterhin unterstützt werden, aber dann gibt man zumindest zu, dass man mit denen den Larrabee nicht so nutzen kann wie Intel es sich vorstellt. Das macht sogesehen volkommen Sinn, da Intel bereits in der Vergangenheit erfolgreich demonstriert hat, dass sie keine alle Features nutzenden DX/OpenGL-Treiber für ihre integrierten Lösungen zeitnah (kleinergleich 2 Jahre) hinbekommen.
Aber ob es jetzt Sinn macht, dass die Hersteller für ein "besseres" Spielerlebnis ihren Code nochmal auf den Larrabee optimieren müssen.
Zuletzt bearbeitet:
