News Larrabee so schnell wie GeForce GTX 285?

[FreddyMercury]

Ich bin mal gespannt ob Intel ueberhaupt support in den Treibern gibt. Denn wenn die Treiberpolitik sich von Intel nicht aendert, wird Larrabee genau so ein Muell werden, wie alle anderen Grafikkarten auch. Es wird ein haufen Zeugs an features unterstuetzt, aber keins davon findet sich in den Treibern wieder

Denn auch aktuelle Grafikhardware von Intel koennte um einiges besser und auch schneller sein.

 

[Naennon]

zum Thema theoretische Rechenleistung:

ich erinner an "Unleash 1 Tera", als die 4850 kam.. die Rohleistung vom RV770 war 1TF, die 4850 ist auch für das Preissegment eine gute Karte, aber im Endeffekt mit 1TF nur Mittelmaß, es fehlt an Bandbreite etc

die theoretische Rechenleistung interessiert erstmal herzlichst wenig, zumindest den User, der die "Grafikkarte" dafür nutzt, wofür sie entwickelt wurde, nämlich für bunte Bildchen

das jetzt GPGPU, CUDA und andere Dinge und die damit verbundenen irrsinnig hohen Rechenleistungen marketingstrategisch vermarktet werden, liegt einfach im Trend

ich denke das Larrabee der "Einstieg" in den "Highendmarkt" (eine GTX 285 ist sehr wohl Highend) seitens intel ist, aber dieser erste Chip nicht direkt einen GT300 oder R8XX verdrängen wird - ABER, intel zeigt wie so oft den Weg vor und die beiden Nachfolger zum GT300/R8XX werden ziemlich wahrscheinlich Multi GPU - Single-Die Versionen sein, Parallelisierung ist einfach DER Weg

egal was und wie es kommt, Hauptsache weg von 400W TDP und SLI/CF mit 2 oder mehr GPUs/PCBs, das kann einfach nicht die Lösung sein und ich denke genau dahin will intel und irgendwann auch Grün und Rot

ich persöhnlich schaue mir die Tests an und wenn es preislich passt und im oberen Drittel mitspielt, werde ich mir so ein Larrabienchen holen, denn ich mag es in meinem PC so wenig wie möglich verschiedene Hersteller zu verbauen

 

[gruffi]

naja, C oder C++ haben überhaupt nichts mit den Vorteilen/Nachteilen von x86 zu tun.

Das habe ich auch nirgendwo behauptet.

Und warum Intel den "Code" auf OpenCL aufbauen sollte würde mich wirklich interessieren

Dann verrate mir doch erstmal, wie du momentan mit ISO C oder C++ so parallel programmieren willst, dass der Compiler die Rechenlast problemlos auf die Larrabee Kerne verteilen kann. Ohne Spracherweiterung geht das nicht. Und Threads reichen dafür imo nicht aus.

CUDA /OpenCL sind Schnittstellen keine Spracherweiterungen.

Nope. OpenCL ist de facto eine Spracherweiterung für C.

•  Language Specification
-  C-based cross-platform programming interface
-  Subset of ISO C99 with language extensions - familiar to developers
-  Well-defined numerical accuracy - IEEE 754 rounding behavior with specified maximum error
-  Online or offline compilation and build of compute kernel executables
-  Includes a rich set of built-in functions

Dazu kommt noch eine Plattform und Runtime API. CUDA ist das gleiche in grün.

 

[Bullz]

zu 100 % Werbungs blabla

Das Ding ist unter Realanwendungen wahrscheindlich zur Zeit langsamer als ne Geforce der 5 er Generation...

das werden vielleicht theoretische Werte sein die die vergleichen. Ich will Screenshots oder sie können ihre Ansagen stecken lassen

 

[Lübke]

das ist abhängig von der engine. unter source könnte der larrabee eine ganz ordentliche figur machen, in crysis dürfte er dagegen nicht viel zu melden haben und froh sein, gegen eine 9600gt oder 3870 nicht ganz so alt auzusehn
der kampf wird sich zukünftig vor allem um die spieleengines drehn. man siehts ja schon ganz gut am beispiel geforce 7 gegen radeon x1k. zu der zeit war die architektur der gf7 sehr gut an die damaligen engines angepasst. die radeon x1k konnte trotz deutlich höherer shaderleistung schwer mithalten. die x1900xt reichte gegen die 7900gtx nicht aus und so musste ati eine x1900xtx nachlegen. auch die war in vielen tests (minimal) langsamer, so dass man mit der x1950xtx nochmal eins draufsetzen musste (allerdings war da die 7950gx2 schon da um den längsten balken in den benches für nv zu resrevieren). heute profitieren die engines stark von der shaderleistung, was damals atis stärke war. mittlerweile muss eine 7900gtx eine 1950pro fürchten. an eine 1950xtx ist da gar nicht mehr zu denken.

beim larrabee wird dieser effekt aufgrund der grundsätzlich verschiedenen technologien bedeutend gravierender ausfallen. wenn intel larrabeefreundliche engines durchboxen kann, haben ati und nvidia plötzlich das nachsehn. bei aktuellen engines wird intel mit der architektur meiner meinung nach aber niemals eine chance gegen die gehobenen modelle von ati und nvidia haben.

 

[Dario]

Intel wird es mit ihrer GPU wie AMD mit den CPU's halten: Im Mainstreammarkt wird einfach günstig verkauft !
Der High End Markt ist doch 'eh mehr fürs Prestige und im Endeffekt wird Intel seinen hohen Marktanteil bei
den Low End Lösungen auf dieses Segment ausweiten wollen.

Mehr kann man für den Anfang doch auch gar nicht verlangen ! Wie gesagt AMD hat es bei den CPUs vorgemacht.

 

[Wiesi21]

@gruffi

tut mir leid, aber das ist einfach nicht richtig. Außerdem brauch ich kein C um Software für nen x86 Proc zu schreiben. Die Sprache ist letztlich völlig egal, solange ich einen passenden Compiler hab

OpenCL wird ja nur benötigt, um die Hersteller dazu zu bringen ihre Grafikhardware um die benötigten Features zu erweitern, da sie bisher einfach noch zu eingeschränkt dafür sind. (Man hat dann einfach noch mehr mögliche Shader, da die Graka ja hierüber programmiert wird)
ein x86 Prozessor kann solche Berechnungen in Software ohnehin tätigen... (die DX10 Softwarerenderingschnittstelle läuft bereits auf allen Prozessoren, und Larrabee wird nur die Geschwindigkeit von unbrauchbar auf spielbar beschleunigen, da er pro Kern 4*mehr Ausführungseinheiten besitzt als ein heutiger i7, ne weit kürzere Pipeline, schnellere GRam Anbindung und einige beschleunigende special Function Units.)

OpenCL basiert auf C, was aber nur bedeutet, dass es sich ähnlich programmieren lässt, nicht mehr nicht weniger. Open CL kann man vielleicht in Zukunft auch in Java programmieren, ähnlich wie OpenGL jetzt bereits (arbeite schon länger ziemlich begeistert mit JOGL)
Ich bin jetzt zwar schon länger weg von C, aber ich frage mich wo du Probleme bei der Parallelprogrammierung siehst? Probleme hab ich nur dann wenn meine Arbeit sich nicht weit genug aufteilen lässt, aber für diese Berechnungen würd ich ohnehin nie die GPU nutzen

Die Rechenlast kann ich schon von der Programmierung her, auf viele Threads aufteilen, der Compiler "übersetzt" dann eben noch. dies reicht bei x86 eben schon aus, wenn ich etwas auf die Hardware Rücksicht nehme(die neueren Intel Compiler sind allerdings auch schon recht zuverlässig bei der automatischen Erkennung von Parallelität).

Bei den nVidia GPUs reicht dies natürlich nicht, da die Befehle über CUDA als Shader ausgeführt werden müssen und der Threadsheduler in der Hardware sitzt und nochmal ungleich mehr Threads benötigt werden.

Ich weiß natürlich nicht, wie Intel die Entwicklung auf Larrabee umsetzen wird, aber sie wären dumm aus x86 nicht die dahingehenden Vorteile zu nutzen.

 

[Dese]

faszinierend wieviele larabee experten hier schon abschätzen können, wie gut es wo drunter läuft. man, da hät ich mir meins tudium glatt schenken können. mal hier ins forum schaun und danach gleich bewerben.

 

[Lübke]

du hast studiert und kennst nichtmal den begriff "spekulation"? Oô
das hier ist ein forum. da wird spekuliert und über gerüchte diskutiert und erwartungen geäußert... dessen solltest du dir schon bewusst sein, wenn du hier schreiben möchtest. du kannst aber gern dein studiertes wissen zum besten geben, wenn du denkst, uns damit die erleuchtung zu bringen

ich glaube jedem, der hier schreibt, ist klar, dass das noch keine getesteten fakten sind. ^^

 

[CockyBocky]

hallo
was meckert ihr alle rum^^
"sowas braucht doch keiner"
als ob
des is doch gut
und wenn der larrabee mit ATI und NV konkurieren kann, UMSOBESSER
wenn man dann ne neue graka kaufen will, lacht der geldbeutel

 

[Dese]

@lübcke: wie kommst du darauf, dass ich euch die erleuchtung bringen will? ich bin es doch nicht, der hier prognosen abgibt, dass larabee unter source ne dolle figur machen könnte und unter crysis eher abrauchen könnte.

ja, ich hab studiert und ich weiß was spekulationen sind. und ganz besonders weiß ich, wie man spekulationen auf basis von so gut wie keinen informationen nennt: heiße luft!

um es mal deutlich zu sagen. ich hab nix dagegen, wenn man hier seiner phantasie etwas freien lauf läßt. ist ja wie du sagst ein forum, aber was man heir so teiwleise liest is ja glatt zum kinder kriegen. das eine kann man nciht mit c programmieren, ist ne andere architektur (riesen bullshit), oder der larabee kakt aber unter crysis, nicht aber unter source (die informationsgrundlage ist erdrückend ). und und und. das geht eifnach über jeden verständliche spekulationsbedürfnisse hinaus.

bei den erleuchtungen hier bräuchten wir kein künstliches licht mehr.

 

[Lübke]

source ist cpu (x86) optimiert und crysis ist gpu (shaderarchitektur) optimiert. da is ein zusammenhang wohl nicht schwer zu erraten oder?

 

[theorist]

Ich bin mal gespannt ob Intel ueberhaupt support in den Treibern gibt. Denn wenn die Treiberpolitik sich von Intel nicht aendert, wird Larrabee genau so ein Muell werden, wie alle anderen Grafikkarten auch. Es wird ein haufen Zeugs an features unterstuetzt, aber keins davon findet sich in den Treibern wieder

Larabee ist ein Software-Rasterizer, entsprechend ist das Teil ohne im Treiber nachgebildete Funktionen keine Grafikkarte. Das Featureset wird auch vom Treiber bestimmt. Was unterstützt wird und was nicht, bestimmt alleine der Treiber. Brachliegende Spezialhardware wird es nicht geben, da alle API-spezifischen Funktionen nur in Software vorhanden sein werden.
Übrigens: Was willst du aus den IGPs von Intel noch rausholen? Selbst der Intel GMA X4500 von den Desktop-Boards hat nur 2 TMUs und 10 Unified-Shader-Einheiten @ 800 MHz, während z.B. eine Radeon HD 3300 (AMD 790GX) schon 4 TMUs und 40 SPs @ 700 MHz bietet. Kein Wunder, dass Intel im IGP-Bereich nicht hinterherkommt.

source ist cpu (x86) optimiert und crysis ist gpu (shaderarchitektur) optimiert. da is ein zusammenhang wohl nicht schwer zu erraten oder?

Für Crysis brauchst du aber eine deutlich stärkere CPU, um flüssig spielen zu können, als für Source-Spiele.

 

[Lübke]

aber bei crysis macht es einen unterschied, ob du eine 8800gt oder gtx295 hast

das crysis nicht mehr auf die minimal systemvorraussetzungen von css optimiert ist, ist wohl iwie logisch oder?^^

aber im ernst: css profitiert primär von der cpu, crysis primär von der gpu. dass beides bei beiden spielen benötigt wird und auch entsprechend zeitgemäß sein muss, sollte denke ich klar sein.

 

[theorist]

aber bei crysis macht es einen unterschied, ob du eine 8800gt oder gtx295 hast

Macht es auch bei Source-Engine-Spielen, wenn du mit 16xS-AA spielst, was jeder vernünftige Mensch tut, der die Leistung einer teuer erworbenen GTX 285 nicht brachliegen lassen möchte.

das crysis nicht mehr auf die minimal systemvorraussetzungen von css optimiert ist, ist wohl iwie logisch oder?^^

Unter Source-Engine fällt auch Episode 2 und das kam im gleichen Zeitraum wie Crysis. Und Episode 2 stellt sowohl an die GPU als auch an die CPU deutlich höhere Anforderungen als CS:S. Trotzdem muss man für Crysis die stärkere CPU haben, um irgendwas reißen zu können. Mit einem Singlecore-Prozessor (z.B. Pentium 4 3,8 GHz) ist Ruckeln in Crysis an vielen Stellen vorprogrammiert, bei Episode 2 ist das nicht zwangsweise so. Eine z.B. Radeon X1800 XT ist aber stark genug für beide Spiele bei passend gewähltem Detaillevel.

 

[MountWalker]

...
Ich bin jetzt zwar schon länger weg von C, aber ich frage mich wo du Probleme bei der Parallelprogrammierung siehst? Probleme hab ich nur dann wenn meine Arbeit sich nicht weit genug aufteilen lässt, aber für diese Berechnungen würd ich ohnehin nie die GPU nutzen
...

Du denkst noch im letzten Jahrhundert - bei der Manycore-Entwiclung geht man schon seit Jahren davon aus, dass es abgesehen von Multi-Processing-Systemen unmöglich ist Manycore-Designs mit "handgestrickten Threads" auszulasten.

 

[theorist]

die theoretische Rechenleistung interessiert erstmal herzlichst wenig, zumindest den User, der die "Grafikkarte" dafür nutzt, wofür sie entwickelt wurde, nämlich für bunte Bildchen

Larabee ist zunächst mal ein universeller Multiprozessor. Die Anwendung als Rasterizer-Grafikkarte wird erst durch entsprechende Funktionalitäten im Treiber möglich. Larabee ist kein Grafikchip im klassischen Sinn. Für Computing ist Larabee genauso ausgelegt.

 

[FreddyMercury]

Larabee ist ein Software-Rasterizer, entsprechend ist das Teil ohne im Treiber nachgebildete Funktionen keine Grafikkarte. Das Featureset wird auch vom Treiber bestimmt. Was unterstützt wird und was nicht, bestimmt alleine der Treiber. Brachliegende Spezialhardware wird es nicht geben, da alle API-spezifischen Funktionen nur in Software vorhanden sein werden.

Richtig und genau DA hab ich bei Intel meine Bedenken! Wenn die Treiberpolitik bei Intel nicht gewechselt wird, bleibt Larabee einfach ein billiger Nachgaenger der X4500.

Übrigens: Was willst du aus den IGPs von Intel noch rausholen?

Ich haette gerne mal einen GLSL Compiler im Treiber. Gibts weder fuer Windows, noch fuer Linux. Ich kann unter Linux mit nem Hack Doom3 auf einer Voodoo5 besser spielen, als auf einer GMA X3500. Denn die startet das Spiel erst gar nicht.

 

[Lübke]

intel grafik ist bis heute auch nicht zum spielen gedacht. die grafikchips sollen lediglich ein bild darstellen können, dass für word und co ausreicht
der support von larrabee wird sicher ganz anders aussehn, da intel an diesem völlig andere ansprüche hat.

 

[pezli]

faszinierend wieviele larabee experten hier schon abschätzen können, wie gut es wo drunter läuft. man, da hät ich mir meins tudium glatt schenken können. mal hier ins forum schaun und danach gleich bewerben.

http://download.intel.com/technology/architecture-silicon/Siggraph_Larrabee_paper.pdf
publiziert an der Siggraph August 2008: lesen, verstehen, eigene Meinung bilden. Es gibt auch andere Möglichkeiten sich zu informieren als die Gerüchteküche.

Ich meinerseits werde wohl sicherlich eine Karte holen, einfach nur um mehr Luft zu haben mit dem Gebastel am Raytracer, mit den 20 MFlop/s von einer E6600 kommt man je nach dem was man haben will sagen wir auf 8 FPS. Da nimmt man doch gern die 1 Teraflops vom Larrabee, man hat einfach mehr Luft für lustigere Sachen Wenn man den Code schon darauf ausgerichtet, dass man die Register auf 16 Floats ausweiten kann usw - und das ist das Schöne an Larrabee - braucht man grob gesagt nur neu zu kompilieren und es läuft, nur ne Runde schneller. Dass die 16-weiten Register komplett ausgelastet sind bei einem Direktumstieg von SSE auf Larrabee behaupt ich nicht, aber man kann viel viel leichter Anwendungen beschleunigen als z.B. mit CUDA. Ich mein, Hände hoch, wer hat nicht schon versucht damit irgendwas zu machen und hat nicht wochenlang geflucht?