Larrabee (der Spekulationsthread)

[Coda]

ihr glaubt doch nicht wirklich das eine solche Architektur Effizienter sein soll als eine aktuelle GPU von NV/ATI die Speziell für sowas Entwickelt worden ist?
Larrabee ist auch für Grafik entwickelt worden.

Im Link oben wird ja gemeint das 40 Cores in 45nm etwa eine Fläche von einem GT200 in 65nm erreichen werden, sorry aber das wird nie und nimmer reichen um da mit zuhalten.
Woran machst du das fest?

Es kann ja sein, dass du recht hast, aber deine Argumentation ist sehr dünn.

[Gast]

4 TFLOPS könnte Larrabee mit 64 Cores und 2 GHz auch erreichen.

Und 64 Cores sind durchaus im Bereich des Möglichen:
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3367&p=6


"Vorbestellt für SGX vor Jahren"
Wie meinst du das? Versteh ich nicht, sry.
intel hat bei imgtech ja den SGX bestellt. sie haben dann ganz klare anforderungen gestellt, welche sich mit larabee überschneiden - ich denke darauf wollte er hinaus.

[BlackBirdSR]

Und so setzt x64 an noch ein weiteres Applikationsfeld zu erobern....
eigentlich sollten wir uns alle davor fürchten, dass x64 eines Tages ein Bewusstsein erlangt und uns aus dem ganz eigenen Marktsegment drängt ^^

Nein mal ernst: es ist wieder ein weiteres Feld das von x64 in Angriff genommen wird. Auf dem Papier glaubt man jetzt auch nicht unbedingt, dass Larrabee Nvidia und ATI sofort Konkurrenz machen könnte. Immerhin setzen diese auf spezielle Lösungen, und sind Ende 2009 auch einen Schritt weiter.
Ähnlich wie Atom hat Intel hier allerdings großes Potential sich zu etablieren. Mit neueren Fertigungsverfahren und Tricks kann man Larrabee mitunter leicht und effizient in der Leistung steigern. Am Ende muss nur eine Frage gestellt werden: Welcher Ansatz ist auf Dauer der günstigere um hohe Leistung zu erreichen?

Nicht ausschließen möchte ich die sehr wohl bestehende Möglichkeit, dass Atom und Larrabee den IA-64 Fluch erben.

Thema 2:
Jetzt redet natürlich wieder jeder vom Pentium ;). Nicht jeder fügt hinzu, dass die CPU lose darauf basiert, und nicht fast identisch ist.
Allerdings eine Frage: Eine InOrder CPU mit x64-Befehlssatz und SMT - ist die noch rein CISC oder lässt man die Instruktionen doch wieder in µops zerlegen? Schon das alleine wäre ein sehr großer Schritt weg vom originalen Pentium. Auf der anderen Seite: Würde man tatsächlich mit µops arbeiten, warum dann nicht Atom als Ausgangsbasis nehmen? Oder noch besser: bekommt den ganzen x64 Befehlssatz mit allen SIMD-Erweiterungen, einer neuen Vektoreinheit und 4-fach SMT auf unter 10 Stufen und ohne die Befehle zu zerlegen hin?

[Gast]

ihr glaubt doch nicht wirklich das eine solche Architektur Effizienter sein soll als eine aktuelle GPU von NV/ATI die Speziell für sowas Entwickelt worden ist?

Im Link oben wird ja gemeint das 40 Cores in 45nm etwa eine Fläche von einem GT200 in 65nm erreichen werden, sorry aber das wird nie und nimmer reichen um da mit zuhalten.Wenn Larrabee ein TBDR sein sollte und darüber hinaus tatsächlich hoch-effizient und dynamisch seine Rechenkraft für die verschiedenen Aufgaben (Grafik/Physik) einsetzt, dann könnten wir schon ein kleines Wunder erleben. Hängt natürlich alles von der Software ab, welche Larrabee erst zum Durchbruch verhelfen kann/muß. Intel wird wohl noch den einen oder anderen Kern des Hauptprozessors zur Unterstützung von Larrabee nutzen. In einem Maße, wie es die GPGPUs von ATI/NV nicht machen (können). Quadcores sollten bis dahin recht weit verbreitet sein. WoW3 wird darauf wohl laufen ;)

Die die offene Architektur ist Intel automatisch DX11 kompatibel, aber darauf kommt es ihnen bestimmt nicht an.

Als GPGPU ist Larrabee den GPGPUs von ATI/NV eine gute Dimension voraus. Alle Aufgaben, die du über CUDA oder STREAM erledigen könntest (und noch viel mehr) sind mit Larrabee um längen einfacher zu realisieren.

[_stephan_]

Und so setzt x64 an noch ein weiteres Applikationsfeld zu erobern....

Und so setzt das A20-Gate an noch ein weiteres Applikationsfeld zu erobern...
A20-Gate auf der "Grafikkarte" :ugly:

SCNR

Oder nicht?

[Coda]

A20 wäre sowieso das kleinste Problem bei einer In-Order-Architektur. Macht nicht immer so ein riesen Ding draus.

[Gast]

Und so setzt x64 an noch ein weiteres Applikationsfeld zu erobern....IA-32 hatte es aus Performance-Gründen nur an die wenig flexible aber dafür schnellere Fixed Function Unit in externer Hardware 'ausgeliehen'. Nun, als diese 'externe Hardware' sich anschickte, selbst immer weniger 'Fixed Function' zu sein und flexibel zu werden, und x64 vielfach (in jeder Beziehung) dazugelernt hat, konvergieren nun beide auf den Ursprung zurück. Wer wird hier wohl besser darstehen?

[AnarchX]

Intel scheint wohl schon ein paar Leistungsprojektionen herausgegeben zu haben:
So, to cut to the chase, they are claiming 10-25 "Larrabee cores" at 1GHz to run FEAR at 1600x1200 60fps with "4 samples" (is that 4xaa or 4xaf or what?)

Well, I guess it'd be more accurate to say they are claiming 25 1GHz cores to keep performance at a minimum of 60fps.

http://forum.beyond3d.com/showpost.php?p=1199513&postcount=156

[dildo4u]

Intel scheint wohl schon ein paar Leistungsprojektionen herausgegeben zu haben:

http://forum.beyond3d.com/showpost.php?p=1199513&postcount=156
http://i38.tinypic.com/8wwimw.jpg

Aus dem Paper der Siggraph Präsentation.Benötigte Larrabee Cores @1Ghz für 60fps bei 1600x1200 mit 4XAA bei FEAR/HL2 und 1600x1200 ohne AA bei Gears of War.

http://www.neogaf.com/forum/showpost.php?p=12254764&postcount=34

[Gast]

was brauch ich so vergleichbares an graka von ati/amd oder nvidia für dieselbe framrate? mit welchem modell ist diese leistung vergleichbar?

[Aquaschaf]

Um wirklich etwas zu sagen sind Zahlen zu diesen 3 Spielen viel zu wenig. Ganz, ganz grob heißt das meines Erachtens dass 25 Cores bei 1GHZ etwa einer Radeon 3870 entsprechen.

[AffenJack]

25 cores? eher die hälfte, also 12,13 würde ichs in etwa sehen.
zb fear ist so der durchschnitt 12,13 cores für 60 fps.
die 3870 hat bei den gleichen einstellungen mit af auch 60 fps, wenn ich mir zb den cb bench anseh.
nimmt man nun af dazu sollten 15 cores ausreichen für 60 fps.
Bei hl2 gehts wiederrum eher in die richtung 10 cores so schnell wie ne 3870

[Aquaschaf]

Wenn ich genauer darüber nachdenke macht es wohl überhaupt keinen Sinn das mit Benchmarks zu vergleichen. Die Tabelle gibt folgendes an: bei Intel hat man für 25 ausgewählte Frames simuliert wieviele Cores nötig sind um den Frame in 1/60 Sekunde zu rendern. Die durchgezogenen Linien machen das Diagramm etwas irreführend.

Ich habe bei meiner Abschätzung bei Fear und Gears of War mich an der größten Menge an Cores die gebraucht wird orientiert, also konservativer. Aber wirklich sinnvoll dürfte das nicht sein. Auch weiß man ja nicht wie es mit der Texturleistung aussieht bzw. ob die direkt an der Anzahl der Cores hängt und wenn ja ob sie linear skaliert wurde in der Simulation.

[AnarchX]

Hier gibt es die Erklärung, wie Intel diese Ergebnisse produziert hat:
http://forum.beyond3d.com/showpost.php?p=1199558&postcount=174

[S940]

Hier gibt es die Erklärung, wie Intel diese Ergebnisse produziert hat:
http://forum.beyond3d.com/showpost.php?p=1199558&postcount=174
Ok, DX9. Bis Larrabee draußen ist, gibts DX11.
Gäbs da vielleicht irgendwelche Hindernisse bei DX11 verglichen mit DX9, die nicht so einfach zu simulieren wären ?

ciao

Alex

[Spasstiger]

Wenn man die Performance in Fear heranzieht und davon ausgeht, dass die gemessenen 25 Frames einen Querschnitt des ingame-Benchmarks darstellen, dann wäre Larabee mit ~13 Core @ 1 GHz schon so schnell wie eine Radeon HD3870. Mit voraussichtlich 32 Cores @ 2 GHz (~ 2 Teraflops) käme man dann schon auf einen Faktor 4-5 gegenüber einer HD3870 und auch ein SLI-Verbund aus zwei GTX280 wäre geschlagen.
Und das mit einem Die, das kleiner ist als bei einer einzelnen GTX280.
Schön wärs ja, wenn es so kommt, aber ich denke, dass die Benchmarkwerte von Intel nicht so wirklich vergleichbar sind mit den üblichen Benchmarks aus Reviews.

[Gast]

Ok, DX9. Bis Larrabee draußen ist, gibts DX11.
Gäbs da vielleicht irgendwelche Hindernisse bei DX11 verglichen mit DX9, die nicht so einfach zu simulieren wären ?

ciao

AlexWorauf möchtest du hinaus? Bisher ist nur im Wesentlichen das grobe Konzept bekannt. Es sind noch zu viele Unbekannte in der Gleichung, als dass wir hier Performance Aussagen treffen sollten. 2010 sind auch Intels Herstellungprozesse und DX-Treiber ein ganzes Stück weiter gereift. Vielleicht sehen wir dann 64 Kerne mit 2,5 GHz an zwei breiteren Ringbussen. Performance ist gegenwärtig sekundär. Das Konzept soll Anhänger finden, die bereits sind, neue Wege zu gehen, und dabei das hohe Maß ein Gestaltungsmöglichkeiten vollständig auszureizen, und das möglichweise ohne DX/OGL. Entwickler außerhalb der Spieleindustrie sind hier natürlich auch angesprochen. Und dabei sind nicht nur ImageProcessing oder Video-Transcoding Apps von Interesse. Larrabee wird weit mehr können als man ihm gegenwärtig zutraut.

[dildo4u]

http://i35.tinypic.com/262vfc8.jpg

"The scene is a 1024x1024 frame with a 234k triangle scene with 1 light source, 1 reflection level, no AA. Around 4m rays per frame."

http://www.neogaf.com/forum/showpost.php?p=12256228&postcount=44

http://s8.directupload.net/images/080804/k6mqjc7n.jpg

Also, because of the arrangement of the processing cores on the chip, graphics and stream computing programs don't have to go through fixed function units if they don't need to. Data never needs to travel through the texture unit—that fixed function unit is called upon when needed, but the cores can access their cache and main memory without any data passing through fixed function FIFO units or data setup units or anything.

Why take this approach? Intel argues that it is very useful for more than just GP-GPU style applications. According to their research, the amount of time spent in various parts of the graphics pipeline can vary widely from game to game, and even from one to the next in the same game. To use one of their examples, F.E.A.R. spends a huge amount of time in rasterization, depth tests, and alpha blending.

By comparison, each frame of Gears of War is extraordinarily heavy on pixel shaders, but comparatively low on depth tests and rasterization. Performing almost all parts of the graphics pipeline in the same bank of general purpose processors allows for perfectly efficient load balancing: You're never "wasting silicon" in Gears of War if you have a bunch of render back-ends that sit largely idle while they would improve performance greatly in F.E.A.R.

The result, Intel says, is extraordinarily linear scaling to more cores. If you double the number of shader units in a typical modern GPU, you don't double performance because you haven't doubled the cache, render back-ends, texture units, pre-vertex setup, and other parts of the chip. You only double pixel peak pixel, vertex, and geometry shading performance (and in the case of ATI's shader-based AA resolve, some measure of AA performance). If you double the number of cores in Larrabee processor, you should in theory almost double performance. Provided that the fixed function texture unit isn't holding you back, a 64-core Larrabee processor should be almost eight times faster than an 8-core Larrabee

http://www.extremetech.com/article2/0,2845,2327046,00.asp

[(^_^)]

Fear ist doch uralt, wieviel Cores für z.B. Crysis oder GRID?

[dildo4u]

Man hat Fear und Gears of War genommen um zu zeigen das es egal ist ob das Spiel Textur oder Shaderlastig ist.Larrabee wird linear mit der Anzahl der Cores skalieren,weil es kaum Fixed Funktions gibt.

[Hvoralek]

Man hat Fear und Gears of War genommen um zu zeigen das es egal ist ob das Spiel Textur oder Shaderlastig ist.Ist FEAR nicht eher z/st- lastig? Eine hohe Texturlast hätte man wohl besser mit Gothic 3 haben können.

[BlackBirdSR]

Ist FEAR nicht eher z/st- lastig? Eine hohe Texturlast hätte man wohl besser mit Gothic 3 haben können.

Das kennt nicht jeder. Crysis und Grid könnten derweil Szenarien sein, in denen der Intel-Chip ohne spezielle Optimierungen kein Land sieht. Was bleibt also? Es muss sehr bekannt sein, und gut funktionieren ;)

[Gast]

Sehr interessant ist doch auch, dass Larrabee ein TBDR ist! Intel nennt das einen 'binning renderer'.

[Gast]

Das kennt nicht jeder. Crysis und Grid könnten derweil Szenarien sein, in denen der Intel-Chip ohne spezielle Optimierungen kein Land sieht. Was bleibt also? Es muss sehr bekannt sein, und gut funktionieren ;)Vielleicht liegt es aber auch daran, das Intel mit den Analysen vor einiger Zeit begonnen hatte. Vielleicht ca. 3 Jahre zurück?! Larrabee benötigt einige Zeit zum Design. Damals ware FEAR und GOW durchaus aktuell.

[Gast]

Das kennt nicht jeder. Crysis und Grid könnten derweil Szenarien sein, in denen der Intel-Chip ohne spezielle Optimierungen kein Land sieht. Was bleibt also? Es muss sehr bekannt sein, und gut funktionieren ;)Ist übrigens inhaltlich eine bösartige Unterstellung. Als Moderator nicht wirklich beispielhaft und niveauvoll.

[BlackBirdSR]

Ist übrigens inhaltlich eine bösartige Unterstellung. Als Moderator nicht wirklich beispielhaft und niveauvoll.

Wo siehst du da eine bösartige Unterstellung? Soll es etwa ein Geheimnis sein, dass ATI und Nvidia Unterstützung an Crytek geschickt haben, damit am Ende ein zufriedenstellendes Ergebnis für die eigenen Chips erziehlt wird? Ist es gar unerhört, das diese Praxis schon seit langer Zeit normal ist, da kein Entwickler alles alleine im Griff hat?
Ist es gar üble Nachrede das Intel, genau wie alle anderen, nicht nur auf knüppelharte Optimierung der eigenen Treiber auf jede erdenkliche Situation, sondern auch auf Rücksicht der Hersteller angewiesen ist? Crysis und Grid sind wohl ohne zweifel extrem optimierte Titel.
So und nicht anders war es gemeint!

Ich sehe deinen Post als nicht besonders niveauvoll, aber das liegt sicherlich und glücklicherweise im Auge des Betrachters. Allerdings ist es mir auch herzlich egal, was ein unbekannter denken mag.

@gleicher gast - post darüber: Guter Einfall. Stellt sich die Frage ob diese Ergebnisse aktuell, oder von damals sind.

[dildo4u]

Gears für den Pc ist so alt wie Crysis(Nov 2007).Fear hat man genommen um zu zeigen das die Architektur linear mit beiden extremen(Shader,z/st-lastig) skaliert darum gings whol bei den Tests.



..To use one of their examples, F.E.A.R. spends a huge amount of time in rasterization, depth tests, and alpha blending.

By comparison, each frame of Gears of War is extraordinarily heavy on pixel shaders, but comparatively low on depth tests and rasterization. Performing almost all parts of the graphics pipeline in the same bank of general purpose processors allows for perfectly efficient load balancing: You're never "wasting silicon" in Gears of War if you have a bunch of render back-ends that sit largely idle while they would improve performance greatly in F.E.A.R

http://www.extremetech.com/article2/0,2845,2327046,00.asp

Crysis ist lange nicht so Shaderlastig wie UE 3.0 Spiele von daher wärs whol nicht ideal um die Extreme zu zeigen.

[V2.0]

Naja, das seht technsich nicht schlecht aus, nur wird intel nun endlich mal einen echten Treibersupport liefern müssen und da habe ich Zweifel.

[Gast]

Wo siehst du da eine bösartige Unterstellung? Soll es etwa ein Geheimnis sein, dass ATI und Nvidia Unterstützung an Crytek geschickt haben, damit am Ende ein zufriedenstellendes Ergebnis für die eigenen Chips erziehlt wird? Ist es gar unerhört, das diese Praxis schon seit langer Zeit normal ist, da kein Entwickler alles alleine im Griff hat?
Ist es gar üble Nachrede das Intel, genau wie alle anderen, nicht nur auf knüppelharte Optimierung der eigenen Treiber auf jede erdenkliche Situation, sondern auch auf Rücksicht der Hersteller angewiesen ist? Crysis und Grid sind wohl ohne zweifel extrem optimierte Titel.
So und nicht anders war es gemeint!

Ich sehe deinen Post als nicht besonders niveauvoll, aber das liegt sicherlich und glücklicherweise im Auge des Betrachters. Allerdings ist es mir auch herzlich egal, was ein unbekannter denken mag.

@gleicher gast - post darüber: Guter Einfall. Stellt sich die Frage ob diese Ergebnisse aktuell, oder von damals sind.Gerade Larrabee mit seiner hohen Flexibilität kennt offensichtlich das Problem von unausgewogener 'Fixed Function'-Zusammenstellung weit weniger als es z.B. ATI mit 3970 zu spüren bekam. "... Ohne spezielle Optimierung kein Land sehen ..." ist also eher unwahrscheinlich. "... Was bleibt also? Es muss sehr bekannt sein, und gut funktionieren ..." Dildo4U hat darauf wohl die bessere Antwort gefunden.

Die interessante Frage ist doch, wieviel Overdraw Intel in z.B. Crysis durch das Defered Rendering vermeiden kann? Sind enorm hohe Bandbreiten-Anforderungen bei Crysis ein Problem? Kann vielleicht eine 16 Core Karte bereits Crysis in High Details laufen lassen?

[Gast]

Naja, das seht technsich nicht schlecht aus, nur wird intel nun endlich mal einen echten Treibersupport liefern müssen und da habe ich Zweifel.Nun, falls das John Carmack genaus sieht, dann wird er eben die 'Larrabee direct' Modus nehmen. Dann gibt es keine Treiber. Dann gibt es nur John und die GPGPU ;)

[Gast]

Anscheinend hat hier noch niemand den Link zum Larrabee PDF gepostet:

http://softwarecommunity.intel.com/articles/eng/3803.htm

Damit ihr mal über Infos aus erster Hand diskutieren könnt. ;)

[AnarchX]

Danke für den Link, gestern gab es das PDF leider nur auf einem Bezahlserver.

[Gast]

Also die gesamten Beispiele in dem PDF sind für einen "Sort-Middle" Software Renderer. Ergo ist der Larrabee ein TBDR nicht nur ein TBR (zumindest in diesen Beispielen)

Seite2
The PowerVR* MBX and SGX series [PowerVR 2008],
the Intel® Graphics Media Accelerator 900 Series [Lake 2005],
the ARM Mali* [Stevens 2006], and Talisman [Torborg & Kajiya
1996] have been generally classified as sort middle architectures.


Seite5
This section describes a sort-middle software renderer designed
for the Larrabee architecture that uses binning for load balancing.
Section 5 provides performance studies for this software renderer.

[deekey777]

Gears für den Pc ist so alt wie Crysis(Nov 2007). Fear hat man genommen, um zu zeigen, dass die Architektur linear mit beiden extremen (Shader, z/st-lastig) skaliert, darum gings whol bei den Tests.




http://www.extremetech.com/article2/0,2845,2327046,00.asp

Crysis ist lange nicht so Shaderlastig wie UE 3.0 Spiele von daher wärs whol nicht ideal um die Extreme zu zeigen.

Vielleicht überlese ich irgendwas, aber Crysis wird dort nirgendwo erähnt: Wie kommst du denn darauf, dass Crysis nicht so "shaderlastig" wie UE3-Spiele sei?

[Gast]

Sehr interessant ist doch auch, dass Larrabee ein TBDR ist! Intel nennt das einen 'binning renderer'.
nochmal, es ist kein TBDR, es ist ein TBR, kein Deferred!

[Gast]

Das kennt nicht jeder. Crysis und Grid könnten derweil Szenarien sein, in denen der Intel-Chip ohne spezielle Optimierungen kein Land sieht. Was bleibt also? Es muss sehr bekannt sein, und gut funktionieren ;)
Dem muss nicht so sein, crysis hat z.b. viel reine Z-buffer arbeit, z.b. ZPass, shadowmaps. da kann intel theoretisch dann 4mal schneller rechnen als mit Colorpass.
Weiter hat Crysis sehr viele posteffects, da kann intel theoretisch auch sehr glaenzen, weil dann alle einheiten nur shaden. keine Vertexbuffer Assembly, keine Rasterizer etc. transistoren die rumgammeln.

das haengt aber natuerlich davon ab wie gut intel es intern optimiert hat.

[Gast]

nochmal, es ist kein TBDR, es ist ein TBR, kein Deferred!
Nach den Pressemeldungen nein, aber nach dem Paper von Intel ja.
Wobei ich das weniger sensationell finde wie die praxistaugliche Lösung für artefaktfreie Shadowmaps.

[Gast]

was ich gerne wissen würde aber sehr wahrscheinlich wird das nie ans Tageslicht kommen.

Inwiefern bzw. inwieweit hat IMG/PowerVR Intel dabei geholfen einen guten effizienten TBDR-Software Renderer für Larrebee zu schreiben? Ich kann mir einfach nicht vorstellen das Intel sowas von alleine hinbekommt wo die Leute es doch noch nicht einmal schaffen gute Treiber für die X3100 zu schreiben.

[S940]

was ich gerne wissen würde aber sehr wahrscheinlich wird das nie ans Tageslicht kommen.

Inwiefern bzw. inwieweit hat IMG/PowerVR Intel dabei geholfen einen guten effizienten TBDR-Software Renderer für Larrebee zu schreiben? Ich kann mir einfach nicht vorstellen das Intel sowas von alleine hinbekommt wo die Leute es doch noch nicht einmal schaffen gute Treiber für die X3100 zu schreiben.
Irgendwo stand doch, dass die normalen Treiberentwickler weiterhin bei den IGPs code, und für Larrabee die Entwickler coden, die vor ein paar Jahren von nem GrafikWorkstation Hersteller übernommen wurden. Mir ist der Name leder gerade entfallen, vielleicht stehts auch schon hier im Thread ^^

ciao

Alex

[mko99]

hallo zusammen,

ich bin kein profi, was grafikkarten angeht, aber als ich mir gerade den kleinen artikel hier auf 3dcenter über intels larrabee gelesen habe, habe ich mich gefragt, ob die karte nicht als guter physikbeschleuniger zu gebruachen wäre. durch die architektur ist die karte ja sehr gut für gpgpu berechnungen. also wieso nicht auch physikberechnungen? was meint ihr dazu? gibts vielleicht noch eine kleine "überraschung" seitens intel zu dem thema?

[Abraxus]

Wirst du alles selber ausprobieren können, wenn du Lust, Nerven und Zeit dafür hast. Das ist das einzig schöne an Larrabee.

[mko99]

naja, erstmal ist da die frage des geldes ;)
und dann die frage, ob ich mich damit soweit beschäftigen will, dass sowas drauf läuft ;)

[BlackBirdSR]

hallo zusammen,

ich bin kein profi, was grafikkarten angeht, aber als ich mir gerade den kleinen artikel hier auf 3dcenter über intels larrabee gelesen habe, habe ich mich gefragt, ob die karte nicht als guter physikbeschleuniger zu gebruachen wäre. durch die architektur ist die karte ja sehr gut für gpgpu berechnungen. also wieso nicht auch physikberechnungen? was meint ihr dazu? gibts vielleicht noch eine kleine "überraschung" seitens intel zu dem thema?

keine Überraschung. Im offiziellen Bericht von Intel sind bereits Angaben zur Skalierung und Leistungsfähigkeit bei physikalischen Problemen.
Man braucht nur noch eine passende Physikengine und ein Interface. Entweder durch das eigene Havok, oder Microsoft.

[turboschlumpf]

Ich hatte der Übersichtlichkeit halber einen eigenen Thread zum Thema TBDR erstellt:

Ist Larrabee ein TBDR? (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=427389)

Schade, dass die Diskussion jetzt doch wieder total zerstreut ist. :(

[AnarchX]

Ich hatte der Übersichtlichkeit halber einen eigenen Thread zum Thema TBDR erstellt:

Ist Larrabee ein TBDR? (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=427389)

Schade, dass die Diskussion jetzt doch wieder total zerstreut ist. :(
TBDR oder nicht? - Diskussion bitte dort weiterführen.

[Hvoralek]

Das kennt nicht jeder. Crysis und Grid könnten derweil Szenarien sein, in denen der Intel-Chip ohne spezielle Optimierungen kein Land sieht. Was bleibt also? Es muss sehr bekannt sein, und gut funktionieren ;)Ja, und aus dem letztgenannten Punkt wollte man wahrscheinlich auch gar kein Spiel mit nennenswerter Filterlast :wink:

Irgendwie habe ich das Gefühl, dass Larrabee dabei und auch mit AF nicht gerade glänzen wird. Auch die Benchmarks von Intel sind nur mit AA.

Vielleicht liegt es aber auch daran, das Intel mit den Analysen vor einiger Zeit begonnen hatte. Vielleicht ca. 3 Jahre zurück?! Larrabee benötigt einige Zeit zum Design. Damals ware FEAR und GOW durchaus aktuell.GOW erschien für den PC wie schon erwähnt erst 2007, HL2 Ep2 ebenso.

[Gast]

IMG duerfte aber einen noch wichtigeren Deal gelandet haben den man eigentlich in der Vergangenheit stets NV zusprach. Ich vermute dass man dafuer den core der 555 ersetzen wird benutzen wird.
Hoffentlich meinst du damit die PSP 2. Ist bekannt, ob diese diesmal einen ARM Core bekommt oder ob sie bei MIPS bleiben?
Der ARMv7 (Cortex-Serie) ist in neuster Revision für einen embeded Prozessor ziemlich stark. Immerhin hat das Teil eine Spekulative Out of Order Execution.

[Coda]

Irgendwie habe ich das Gefühl, dass Larrabee dabei und auch mit AF nicht gerade glänzen wird. Auch die Benchmarks von Intel sind nur mit AA.
Worauf basiert diese Vermutung? Über die TMUs und deren Anzahl ist doch noch gar nichts bekannt.

[Hvoralek]

Worauf basiert diese Vermutung? Über die TMUs und deren Anzahl ist doch noch gar nichts bekannt.Intel vermarktet Larrabee mehr als Coprozessor denn als GPU, wofür TMUs vergeudete Chipfläche sind. Auch dass Intel dazu keine auch nur groben Daten nennt, spricht nicht gerade dafür, dass sie besonders berauschend sind. Schließlich sind Tests mit AA, aber ohne AF schon recht ungewöhnlich.

Eine niedrigere relative Filterleistung als bei heutigen GPUs erwarte ich bei Larrabee jedenfalls (ebenso wie bei AMD-/ Nvidia- GPUs in 1 1/2 Jahren). Wie viel niedriger, wird man sehen müssen.

[Coda]

Intel vermarktet Larrabee mehr als Coprozessor denn als GPU
Bisher habe ich nicht den Eindruck gewonnen. Spiele sind nunmal die Streamprocessing-Anwendung um in den Mainstream zu kommen und damit die nötigen Absatzzahlen zu erreichen.

[Gast]

Worauf basiert diese Vermutung? Über die TMUs und deren Anzahl ist doch noch gar nichts bekannt.Das stimmt nicht ganz. Intel sagt dazu im Siggraph-Dokument: "... The Larrabee texture filter logic is internally quite similar to typical GPU texture logic. It provides 32KB of texture cache per core and supports all the usual operations, such as DirextX 10 compressed texture formats, mipmapping, anisotropic filtering, etc. ..." Zwar können wir jeweils nichts über die genaue Implementierung sagen, aber soviel sollte man annehmen: Intel wird sicherlich daraus keinen Performance-Bottleneck machen und die Qualität der Filterung wird wohl nicht jener von ATI und NVidia sichtbar hinterhinken. Bis zur finalen Version der Hardware wird sicher noch einige Zeit vergehen. Für Intel besteht keine (finanzielle) Zwang mit unreifer Hardware/Software in den Markt zu gehen. Entsprechend sind auch die Angaben zum Markteintritt: Irgendwann in 2009/2010. Bis dahin wird die Hardware nur Entwicklern in Samples zur Verfügung stehen.

Die ersten Samples werden also kaum das Entstadium der Entwicklung der ersten Version darstellen. Larrabee soll als x86-basierter Streamprozessor die Sinnhaftigkeit/Notwendigkeit aktueller GPU-Designs (von ATI/NVidia) in Frage stellen. X86 soll zukünftig alle Anwendungsgebiete erobern, neben PDAs nun auch die Streaming-Aufgaben und damit letztlich den Grafikkarten-Sektor. Indirekt sterben damit auch die GPGPU-Versuche der Grafikchip-Konkurrenz!

[BlackBirdSR]

Indirekt sterben damit auch die GPGPU-Versuche der Grafikchip-Konkurrenz!

meinst du? bisher ist deren Absatz ja noch nicht besonders toll. Wenn Intel hinzukommt, könnte das den Markt beflügeln und gleichzeitig die Entwicklung beschleunigen. Statt die weiße Flagge zu zeigen, könnte die Sache dann endlich etwas ernster genommen werden. Ist aber nur ne mögliche Wendung.

[Coda]

Das stimmt nicht ganz. Intel sagt dazu im Siggraph-Dokument: "... The Larrabee texture filter logic is internally quite similar to typical GPU texture logic. It provides 32KB of texture cache per core and supports all the usual operations, such as DirextX 10 compressed texture formats, mipmapping, anisotropic filtering, etc. ..."
Naja. Das ist für mich "nichts". Alles davon (bis auf evtl. den Texture-Cache) sind einfach Voraussetzungen für die D3D-Kompatibilität.

Über die Filtergeschwindigkeit sagt das gar nichts aus. Und ich stimme dir zu, dass man bis zur finalen Hardware auch mit einem Provisorium an diesem Punkt auskommt.

[Gast]

Intel wird sicherlich daraus keinen Performance-Bottleneck machen und die Qualität der Filterung wird wohl nicht jener von ATI und NVidia sichtbar hinterhinken.In der Zeit, in der an Larrabee schon entwickelt wird, hatten wir allerdings schon bei den Herstellern klassischer GPUs recht interessante "Optimierungen". Von denen hätte sich Intel durchaus inspirieren lassen können. Daher ist das reine Tempo zumindest für mich eher unwichtig, so lange wir nichts über die Qualität von AA & AF wissen.

[Coda]

Beim Multisampling kann man eigentlich nicht cheaten. AF ist natürlich was anderes.

[Gast]

Beim Multisampling kann man eigentlich nicht cheaten.CSAA/FAA z.B. könnte man als cheaten beim MSAA bezeichnen. Eigentlich ist ja schon MSAA ein einigermaßen erträglicher Hack, um wenigstens an den Stellen AA zu bekommen wo es am meisten auffällt.

Flamebait beiseite, schon rein die mögliche Sampleanzahl (+Anordnung und Samplequalität) und die angebotenen Downfilter können die Kaufentscheidung beeinflussen.

[Ailuros]

CSAA/FAA z.B. könnte man als cheaten beim MSAA bezeichnen. Eigentlich ist ja schon MSAA ein einigermaßen erträglicher Hack, um wenigstens an den Stellen AA zu bekommen wo es am meisten auffällt.

Jegliches Antialiasing ist in diesem Fall ein "Hack", da in jedem Fall dem menschlichen Auge vorgegaukelt wird dass die Kanten etwas glaetter oder fast ganz glatt aussehen. Und nein es wird nicht "ge-cheatet" ausser Dir hat jemand erzaehlt dass 16xCSAA 16x Multisampling ist.

CSAA in der Form in der es NVIDIA praesentierte ist trotz allem qualitativ besser als einfaches 4x MSAA, da es dieses auch erstmal enthaelt. Die restlichen 12x samples glaetten in ihrer Mehrzahl schon einiges mehr als stink-normales 4xMSAA. Natuerlich sind es keine "vollen" 16x samples wie bei MSAA, aber gewinnt dahingegen so viel an Speicher und Bandbreite, dass man es locker anstatt 4xMSAA benutzen kann; schlechter als dieses ist es auf keinen Fall und nirgends nicht.

Custom filter sind ebensfalls um einiges effizienter als stinknormale box filter; AMD's einziges Unglueck momentan ist dass edge detect zu viel Leistung kostet. Sonst gibt es beim letzten nichts auszusetzen.

Flamebait beiseite, schon rein die mögliche Sampleanzahl (+Anordnung und Samplequalität) und die angebotenen Downfilter können die Kaufentscheidung beeinflussen.

Ich erinnere dass 3DLabs einen sehr intelligenten AA-Algorithmus hatte, aber das abscheulichste AF (ultra-super-duper-Sparmodus) das ich je gesehen habe (eher "noise" als Filterung).

[Coda]

CSAA/FAA z.B. könnte man als cheaten beim MSAA bezeichnen.
Wenn 8xMSAA generell CSAA sein würde bei G80: Ja.

Flamebait beiseite, schon rein die mögliche Sampleanzahl (+Anordnung und Samplequalität) und die angebotenen Downfilter können die Kaufentscheidung beeinflussen.
Die Sampleanordnung wird wohl kaum ordered sein ;)

[Demirug]

Die Sampleanordnung wird wohl kaum ordered sein ;)

Und ist ab D3D 10.1 sowieso vorgeschrieben.

[turboschlumpf]

Und ist ab D3D 10.1 sowieso vorgeschrieben.
Nur im Bezug auf die EER oder wirklich exakt vorgeschrieben? Wie sehen die Sample-Muster bei D3D 10.1 genau aus?

Schon ein interessanter Ansatz, aber diese Softwarelastigkeit macht micht doch arg skeptisch. [Anm.: zitiert aus einem anderen Thread]
Nunja, man könnte es auch so sehen: Intel treibt den Unified-Ansatz auf die Spitze. Hoffentlich sind Sie damit Ihrer Zeit nicht ein paar Jahre voraus.

[Gast]

Nur im Bezug auf die EER oder wirklich exakt vorgeschrieben? Wie sehen die Sample-Muster bei D3D 10.1 genau aus?


Nunja, man könnte es auch so sehen: Intel treibt den Unified-Ansatz auf die Spitze. Hoffentlich sind Sie damit Ihrer Zeit nicht ein paar Jahre voraus.

Vielleicht kreiert auch Intel diese Zeit. Wenn ein großer Spieler in den Markt kommt, könnte sich der Markt stark ändern.

[reunion]

Nur im Bezug auf die EER oder wirklich exakt vorgeschrieben? Wie sehen die Sample-Muster bei D3D 10.1 genau aus?


Da AMD schon D3D10.1-Chips hat sollte diese Frage nicht schwer zu beantworten sein. Es gibt aber AFAIK mehrere mögliche Sample-Muster.

Nunja, man könnte es auch so sehen: Intel treibt den Unified-Ansatz auf die Spitze. Hoffentlich sind Sie damit Ihrer Zeit nicht ein paar Jahre voraus.

Das denke ich nicht. Wir reden hier immerhin von eine Chip der laut Roadmap erste Ende 2009/Anfang 2010 kommen soll. Und es gibt auch von AMD und nV bereits entsprechende Patente. Abwarten wie es bis dahin aussieht.

[Mike11]

Wurde eigentlich definitiv gesagt das Larrabee ein 45nm Chip wird? Ich meine wenn der Chip im offiziellen 2009/2010 Zeitfenster eher später als früher kommt was spricht dann gegen 32nm im ersten Halbjahr 2010? Intel will 32nm ein halbes Jahr vorher einführen und die benötigten Stückzahlen sollten winzig sein im Vergleich zu Intels sonstigen Chips.

[reunion]

Wurde eigentlich definitiv gesagt das Larrabee ein 45nm Chip wird? Ich meine wenn der Chip im offiziellen 2009/2010 Zeitfenster eher später als früher kommt was spricht dann gegen 32nm im ersten Halbjahr 2010? Intel will 32nm ein halbes Jahr vorher einführen und die benötigten Stückzahlen sollten winzig sein im Vergleich zu Intels sonstigen Chips.

Ja wurde gesagt. Intel hält die besten Prozesse natürlich den Prozessoren vor. Dort sind die Margen wesentlich höher.

[Mike11]

Ja wurde gesagt. Intel hält die besten Prozesse natürlich den Prozessoren vor. Dort sind die Margen wesentlich höher.
Danke für die Info. Damit spielt dann wohl Intels berüchtigter Fertigungsvorsprung kaum ein Rolle. V.a. wenn man sich anschaut das die anderen Anfang 2010 schon in 40nm fertigen wollen...

[BlackBirdSR]

Danke für die Info. Damit spielt dann wohl Intels berüchtigter Fertigungsvorsprung kaum ein Rolle. V.a. wenn man sich anschaut das die anderen Anfang 2010 schon in 40nm fertigen wollen...

Selbst dann sollte man nicht unterschätzen, dass Intels 45nm Prozess jedem anderen 45nm Prozess teils weit überlegen sein kann. Mitunter selbst dem 40nm Prozess von TSMC etc.
Das bleibt eine Wildcard. Eventuell spielt es auch keine Rolle. Müsste ich jedoch meinen nichtexistenten Hut darauf verwetten - ich würde darauf setzen, dass Intel selbst bei 45nm noch ordentlich Vorteile verbuchen kann. Vor allem: Der Prozess ist bis dahin zu Tode optimiert.

[reunion]

Selbst dann sollte man nicht unterschätzen, dass Intels 45nm Prozess jedem anderen 45nm Prozess teils weit überlegen sein kann. Mitunter selbst dem 40nm Prozess von TSMC etc.
Das bleibt eine Wildcard. Eventuell spielt es auch keine Rolle. Müsste ich jedoch meinen nichtexistenten Hut darauf verwetten - ich würde darauf setzen, dass Intel selbst bei 45nm noch ordentlich Vorteile verbuchen kann. Vor allem: Der Prozess ist bis dahin zu Tode optimiert.

Eben. Und mit den Taktraten mit denen Intel momentan hantiert (es wird von um die 2Ghz für den gesamten Chip gesprochen) ist man jedem anderen GPU-Hersteller weit voraus.

[Gast]

Eben. Und mit den Taktraten mit denen Intel momentan hantiert (es wird von um die 2Ghz für den gesamten Chip gesprochen) ist man jedem anderen GPU-Hersteller weit voraus.
Das dürfte aber daran liegen das die reinen gpus einen wesentlich komplexeren Aufbau haben

[Gast]

Eben. Und mit den Taktraten mit denen Intel momentan hantiert (es wird von um die 2Ghz für den gesamten Chip gesprochen) ist man jedem anderen GPU-Hersteller weit voraus.


Wenn die 5 Pipeline-Stages stimmen wie von Anandtech gemeldet bezweifle ich die 2 GHz sehr stark. Will mal sehen wie man das hinbekommen will. Im PDF wird wahrscheinlich nicht umsonst immer von 1GHz gesprochen. Vielleicht ist das ja wirklich die angepeilte Geschwindigkeit (vielleicht aber auch nur ein Smokescreen).

[BlackBirdSR]

Wenn die 5 Pipeline-Stages stimmen wie von Anandtech gemeldet bezweifle ich die 2 GHz sehr stark. Will mal sehen wie man das hinbekommen will. Im PDF wird wahrscheinlich nicht umsonst immer von 1GHz gesprochen. Vielleicht ist das ja wirklich die angepeilte Geschwindigkeit (vielleicht aber auch nur ein Smokescreen).

Können ja auch gar nicht stimmen würde ich sagen. Man braucht ja immerhin neue Stufen für die VPU und das Multithreading.
Dann kommt noch die Frage ob reines CISC oder RISC über µops...

Lassen wir uns mal überraschen.

[Sorkalm]

Erstmal schauen ob Intel den Chip in Eigenregie fertigt. Klingt zwar naheliegend bei den Massen an Fabriken, aber es wurde doch in Vergangenheit öfter mal geschrieben, dass TSMC genutzt werden soll?

[Lenon]

Das ist zwar leicht ot - aber AMD/ATI könnte doch durch die vorhandene X86 Lizenz auch etwas ähnliches bauen oder ? Dann wäre nVidia aber im Hintertreffen, falls sich soetwas durchsetzt. Sehe ich das richtig ?

[Sorkalm]

Wenn AMD die Ressourcen hat... ;)

[BlackBirdSR]

Das ist zwar leicht ot - aber AMD/ATI könnte doch durch die vorhandene X86 Lizenz auch etwas ähnliches bauen oder ? Dann wäre nVidia aber im Hintertreffen, falls sich soetwas durchsetzt. Sehe ich das richtig ?

Könnte AMD durchaus. Allerdings muss man hier im Gegensatz zu Intel den entsprechenden Kern und das benötigte I/O noch entwickeln. Das ist schon extrem viel Aufwand für ein noch unsicheres Geschäft.

Wenn Intel damit aber gut ankommt, und AMD wieder etwas Luft hat, warum nicht? :)

[Coda]

Erstmal schauen ob Intel den Chip in Eigenregie fertigt. Klingt zwar naheliegend bei den Massen an Fabriken, aber es wurde doch in Vergangenheit öfter mal geschrieben, dass TSMC genutzt werden soll?
Intel hat noch nie irgendwas extern gefertigt. Ich wüsste nicht warum sie jetzt damit anfangen sollten.

[Gast]

Itanic beweist doch etwas absolut eindeutig. Intel kann es sich leisten eine sicher nicht profitable Architektur lange Zeit durchzufüttern. So verhält es auch mit Larrabee, der in der ersten Version nicht zum Erfolg verdammt ist. Intel wird bestimmt das große Potential von Larrabee im Supercomputing erkennen(/erkannt haben). Mit SandyBridge/Larrabee(2) Hybrid-Rechnern sollte hier ein gewaltiger Schritt in Richtung 10 Petaflops Rechner möglich sein und die dann sicher nicht mehr konkurrenzfähige Itanic-Architektur wird letztlich doch in Rente gehen müssen.

Der Markt für Streaming-Prozessoren steht Intel auch bei einem Misserfolg als Grafikkarte offen. Larrabee ist weit mehr als alle anderen bisherigen GPGPUs von ATI und NVIDIA eine solche. Hauptsächlich durch seine hohe Flexibilität gepaart mit vollwertigen X86-Kernen.

Intel hat das Geld exklusiv für Larrabee 10 Top-Titel anpassen/parallel entwicklen zu lassen. Statt einer Raster-Engine wird dem Spiel eben eine spezielle Raytracing-/Raster-(Kombi-)Engine untergeschoben. Intel-Entwickler werden hierzu Pate stehen und Tips geben, und die Spiele-Schmieden lassen sich doch gerne dafür bezahlen. Schon einmal haben viele Zocker eine Grafikkarte gekauft, für die es kaum ein Spiel bzw. nur schlechte Anpassungen zu kaufen gab. Man erinnere sich an die Zeiten der Monster3D von 3dfx ;) In 2010 bekommt man zusätzlich noch eine ausgewachsene 'GPGPU' hinzu(eigentlich mehr eine dedizierter Streaming-Prozessor als eine dedizierte GPGPU), für die Realtime-Transcoding/-Raytracing/-Bildbearbeitung/-Audiobearbeitung/-... eine 'Nebentätigkeit' ist.

[GASTurbine]

übernimmt eigentlich einer der Prozessoren die Steuerung über die anderen?



könnte man mit Larrabee schon Multichip-karten bauen, die wie ein einziger Chip arbeiten?

[roidal]

Also so direkt würd ich das nicht sagen, es gibt dann halt eine Anwendung welche die einzelnen Threads verteilt (so wie es jetzt auch ist, das macht das OS) und diese wird dann halt auch auf einen der Kerne laufen.

[AnarchX]

übernimmt eigentlich einer der Prozessoren die Steuerung über die anderen?



könnte man mit Larrabee schon Multichip-karten bauen, die wie ein einziger Chip arbeiten?

Wenn dann müsste Intel die Renderingpipeline über die verschieden Chips laufen lassen, was dann ab dem Punkt wo man den Chip verlässt nicht ganz unkritisch sein wird.

Jedoch hat Intel schon in Startup investiert, was sich mit entsprechenden Lösungen beschäftigt:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=424996

[dust]

man sollte nicht die aussage vergessen Intel: prepare for 'thousands of cores' http://www.forum-3dcenter.org/vbulletin/showthread.php?t=423545

interessante frage ist ob es den larrabee auch mit normaler prozessorfassung geben wird. kombiniert mit onboard grafik brächte es ca. das gleiche wie eine extra grafikkarte. der vorteil man kann ihn nicht nur für grafik einsetzen sondern für alle anderen mathematischen aufgaben ebenfalls, zb. sound, physik usw. das ganze verbunden mit zb. Common System Interface (CSI) könnte die renaissance für die trennung von prozessor und mathematischen coprozessor einläuten, zeit wird es eh.

[=Floi=]

das ganze muß aber programmiert werden und dann würde es ja nur auf dem larrabee laufen...

[dust]

das ganze muß aber programmiert werden und dann würde es ja nur auf dem larrabee laufen...

intel baut auch eigene compiler und larrabee verwendet x86. ich traue denen zu eine option einzubauen und larrabee wird einfach automatisch unterstützt.

das ganze ist eine wirklich gute idee von intel. amd/ati sollte dringend in die gänge kommen...

[GASTurbine]

vor allem hat man, wenn man 2009 eine Larrabee kauft vielleicht eine DX10-Karte

einige Monate später muss man nur neuste Treiber installieren und hat eine DX11-Karte

[Gast]

rein theoretisch kann das auch die konkurrenz. die frage ist halt immer, wie hoch der verlust durch die emulierung ist. z.b. konnte man bei der v5 auch T&L aktivieren, es wurde halt einfach in software ausgeführt.

wenn intel jedoch so eine flexible architektur hat - die trotzdem performant genug ist...

[Gast]

rein theoretisch kann das auch die konkurrenz. die frage ist halt immer, wie hoch der verlust durch die emulierung ist. z.b. konnte man bei der v5 auch T&L aktivieren, es wurde halt einfach in software ausgeführt.

wenn intel jedoch so eine flexible architektur hat - die trotzdem performant genug ist...Es läuft fast die ganze Pipeline in Software. T&L auf der V5 mußte durch die CPU emuliert werden. Wenn Features der nächsten DX-Version übernommen werden sollen, dann wird dies höchstvermutlich auf Larrabee laufen und nicht auf der CPU.

[AnarchX]

Hier gibt es nun den offiziellen Standpunkt von Nvidia zu Larrabee:
http://www.pcper.com/images/news/A%20viewpoint%20from%20NVIDIA.pdf

[Gast]

http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf

für den fall, dass das noch nicht geposted wurde.

für mich erscheint diese architektur als zukunfstweisend,
da defakto so ziemlich alles darauf laufen kann und man
programmiertechnisch quasi jedes spiel und jede engine
optimieren kann.

mein nächster pc wird diesen intel beschleuniger haben.

[Exxtreme]

Hier gibt es nun den offiziellen Standpunkt von Nvidia zu Larrabee:
http://www.pcper.com/images/news/A%20viewpoint%20from%20NVIDIA.pdf
Ist zwar viel Marketing-Blabla aber recht haben sie trotzdem. Intel als "Retter" der Spieleentwickler, denen sie z.Zt. mit ihren ultraschrottigen IGPs dauernd eine reindrücken. X-D

[Undertaker]

Vielseitigkeit wird immer ein Feind der Ausführungsgeschwindigkeit sein, deswegen ist wohl eher zu bezweifeln, dass gerade im Bereich des klassischen Renderings die Performance wirklich konkurrenzfähig sein wird.

[hardtech]

später wird alles nicht so heiß gegessen wie es gekocht wird. bevor nicht echte werte erscheinen ist der marketing maschinerie nichts zu glauben.

[Gast]

gibt es doch: du brauchst (/) 25 cores zu 1ghz für 100% sichere 60 fps in allen szenen bei fear, gow, hl2.

wobei ein test mit crysis interessanter gewesen wäre.

[Aquaschaf]

gibt es doch: du brauchst (/) 25 cores zu 1ghz für 100% sichere 60 fps in allen szenen bei fear, gow, hl2.

Das stimmt so nicht. Simulierte 25 Cores reichen für 60 FPS in 25 einzelnen ausgewählten Frames. Zwar kann man davon ausgehen dass versucht wurde möglichst repräsentative Frames zu wählen, aber 100% sichere 60 FPS in allen Szenen bedeutet das überhaupt nicht.

[Magnificus]

Was mich an Larrabee fasziniert sind die Möglichkeiten die man bei den Bildverbesserungsmassnamen hinzugewinnt. Spezielle angepasste Optimierungen für die Anisotropischen Filter (z.b ein Muster für Indoor mit 90° Wänden eins für Outdoor in 100% winkelunabhängig) oder getrennt für level geometrie und Figuren. Oder eigene Kompressionsalgorithmen für Texturen und Geometrie im Gegensatz zu den DxT Dingern.
Auch eigene Antialiasing Modi sollten kein Problem sein, entweder extrascharf oder mit leichtem Blur (für Zwischensequenzen) je nach wunsch.
Und man hat API unabhängige sich nicht ändernde Hardware dh. die Skalierung wird einfacher und man muss sich nicht mehr mit den Features rumschlagen die fehlen könnten.

Wenn Intel das ausnutzt und von Highend bis Chipset, wobei das ja anscheinend direkt in den Nehalem Nachfolger wandert anbietet, könnte Nvidia in die Situation kommen in der Creative Labs derzeit ist. Nämlich das es schwer wird den Mehrwert zu finden den man durch die bessere Karte hat.

Und dann gibt Intel einfach Rabatt wenn man alles von einem Hersteller kauft:
- Mainboard/Chipset
- Cpu
- Grafikkarte
- wahlweise noch SSD bis dahin

[Aquaschaf]

Ich weiß nicht wie du dir das mit der Texturfilterung vorstellst. Dafür benutzt doch auch Larrabee fixed function hardware, genau wie es GPUs tun (womit sich auch "eigene Kompressionsverfahren für Texturen" erledigen, mal abgesehen davon dass das sowieso relativ sinnfrei wäre). Und eigene AA-Filter sind auch kein Problem bei GPUs.

[Magnificus]

Laut dem Intel PDF Dokument gibt es 8bit Texturfilter als fixed Function auf den Dies. Ich schätze das sie die einfach über Software so einsetzen wie sie es für richtig halten.
Und so wie ich das verstanden habe sind das vermutlich schlicht und ergreifend nur bilinieare Filter, dass würde bedeuten das alles darüber trilinear, mipmapping, anisotropie, antialiasing nur software lösungen sind. Unterstützt durch die neuen Befehle die die Simd Einheiten spendiert bekommen haben.

[Gast]

So ist das auch bei allen GPUs.

[Magnificus]

Also subpixelpositionen kann man eigentlich nicht beliebig wählen die Raster sind ja bereits vorgegeben. Ob man bei den neusten Karten das generell nicht kann oder ob das nur eine API Einschränkung ist weiß ich nicht.

[Gast]

für mich erscheint diese architektur als zukunfstweisend,
da defakto so ziemlich alles darauf laufen kann und man
programmiertechnisch quasi jedes spiel und jede engine
optimieren kann.

mein nächster pc wird diesen intel beschleuniger haben.
Nur werden das nur Spielentwickler machen, die dafür von Intel bezahlt werden.
:rolleyes:
Ansonsten lohnt sich der Aufwand nicht.

[Gast]

Ist zwar viel Marketing-Blabla aber recht haben sie trotzdem.Ich finde es immer wieder erstaunlich, wieso erfahrene und intelligente Foren-User es geistig nicht schaffen, den Begriff Marketing in den richtigen Kontext einzuordnen.

Es ist ungefähr so, wie wenn ein 3dcenter-Fremder alles was in diesem Thread passiert als "Computer-Geschwätz" abtun würde: Im Gröbsten richtig, nur völlig allgemein gehalten.

Deswegen: Pressemitteilungen und Statements sind PR, Public Relations, Offensichtliche Werbetexte Promotion. Dass beide als Bestandteile des Marketings verstanden werden können, rettet den unbedarften Foren-Poster, der von "Marketing-Blabla" schreibt, nicht davor, selbst als "Blabla" abgetan zu werden. Es gibt übrigens zahlreiche andere Bestanteile des Marketing, Yield-Management beispielweise, die hier im Forum absurderweise nicht so negativ beladen sind.

In diesem Sinne: Bitte konkreter posten und nicht ständig einen Begriff vergewaltigen, der scheinbar inhaltlich hier nicht angekommen zu sein scheint.

MfG

[Ailuros]

Laut dem Intel PDF Dokument gibt es 8bit Texturfilter als fixed Function auf den Dies. Ich schätze das sie die einfach über Software so einsetzen wie sie es für richtig halten.
Und so wie ich das verstanden habe sind das vermutlich schlicht und ergreifend nur bilinieare Filter, dass würde bedeuten das alles darüber trilinear, mipmapping, anisotropie, antialiasing nur software lösungen sind. Unterstützt durch die neuen Befehle die die Simd Einheiten spendiert bekommen haben.


Die wichtigere Frage im gegebenen Fall ist wie AMD/NVIDIA ihre D3D11 Architekturen entwickelt haben. Es sieht tatsaechlich danach aus als ob auch diese hoechstwahrscheinlich bei diesen einige fixed function HW losgeworden sind (bzw. vom shader core aufgeschluckt).

Die naechste Frage ist dann natuerlich wie viel genau genug ist, denn wenn man zu stark fuer die Zukunft entwickelt besteht stets die Gefahr dass man auf die Nase faellt, da ich schaetze dass von zu gewagten Schritten aeltere Spiele dann keinen besonderen Unterschied machen werden.

[deekey777]

SIGGRAPH 2008: Beyond Programmable Shading (http://s08.idav.ucdavis.edu/)
Hier sind zwei PDFs zum Larrabee (und weitere sehr interessante Präsentationen) zu finden.
In der aktuellen c't ist auch ein Artikel zum Larrabee zu finden.

Was die TMUs angeht: Diese sind für 8-bit-Zeug gemacht bzw. "optimiert", wie es bei "HDR-Texturen" aussieht, ist nicht klar.

[AnarchX]

GC 2008: Intel ist sicher - Larrabee weitaus schneller als alle aktuellen GPUs (http://www.pcgameshardware.de/?article_id=656921)

Die noch produktlose Larrabee-Architektur, von Intel generell als durchsatzoptimierte x86-Architektur betrachtet, sei, so Aaron Coday, von vornherein als Angriff auf den High-End-Markt im Grafikkartenbereich konzipiert worden. Und zwar nicht, wie immer wieder zu lesen ist, mit dem heutigen High-End als Maßstab. Intel habe dazu die erwartete Leistung der High-End-Modelle von AMD und Nvidia für den erwarteten Zeitrahmen des Larrabee-Launches extrapoliert und seine Performance-Ziele entsprechend abgesteckt. [...]

[Adam D.]

Mutig, mutig ... Hoffentlich (?) schaffen sie es.

[reunion]

Planen kann man viel. Zählen tut was 2010 auf dem Platz ist.

Mutig, mutig ... Hoffentlich (?) schaffen sie es.

Hoffentlich nicht. Intel hat schon in zu vielen Dingen die Finger im Spiel. Hoffentlich bindet Larrabee wenigstens einige gute Ingenieure damit AMD im CPU-Markt wieder etwas aufschließen kann.

[Sorkalm]

Hoffentlich nicht. Intel hat schon in zu vielen Dingen die Finger im Spiel. Hoffentlich bindet Larrabee wenigstens einige gute Ingenieure damit AMD im CPU-Markt wieder etwas aufschließen kann.

Wäre aus Kundensicht jedenfalls zu wünschen. Ein übermächtiges Intel muss echt nicht sein.

[Avalox/Gast]

GC 2008: Intel ist sicher - Larrabee weitaus schneller als alle aktuellen GPUs (http://www.pcgameshardware.de/?article_id=656921)

Was will man damit sagen?

Interessieren tut doch nur, ob es auch die schnellste und qualitativ beste 3D Grafik in dann üblichen Standard Softwareumgebungen geben wird.

[dust]

GC 2008: Intel ist sicher - Larrabee weitaus schneller als alle aktuellen GPUs (http://www.pcgameshardware.de/?article_id=656921)

Grafikeffekte, welche heute so nicht machbar wären, seien dank der x86-kompatiblen Architektur des Larrabee kein Problem mehr. Als Beispiele führte er korrekte, sortierungsunabhängige Transparenz an, welche dann außerdem keine Vorarbeit der CPU mehr benötige.

Den primären Fokus von Larrabee hat Intel seit Beginn der Entwicklung auf Spiele unter DirectX und OpenGL gelegt. Dass die Intel-Software-Group von der guten Eignung für Raytracing so angetan war, dass Gerüchte über eine reine Raytracer-Karte entstanden, kommentierte er mit einem Lachen. Einige "Software-Guys" seien wohl etwas zu begeistert gewesen, meinte er.

hört sich gut an

[Exxtreme]

hört sich gut an
Was zählt ist aber die Praxis.

Es ist echt fraglich ob Intel hier was reissen kann. Sie müssten sowohl bei der Performance wie auch bei der Kompatibilität mindestens ebenbürtig mit AMD und Nvidia sein. Und hier fehlt Intel einfach die Erfahrung.

Intel muss dann entweder über den Preis gehen (subventionieren) und/oder irgendwelche OEMs unter Druck setzen.

[Coda]

SIGGRAPH 2008: Beyond Programmable Shading (http://s08.idav.ucdavis.edu/)
Hier sind zwei PDFs zum Larrabee (und weitere sehr interessante Präsentationen) zu finden.
In der aktuellen c't ist auch ein Artikel zum Larrabee zu finden.

Was die TMUs angeht: Diese sind für 8-bit-Zeug gemacht bzw. "optimiert", wie es bei "HDR-Texturen" aussieht, ist nicht klar.
HDR Texturen sind doch sowieso uninteressant. Gibt's ja nichmal komprimierte Formate für.

Hat ATI mit RV770 ja auch zurückgebaut, weil's niemand verwendet.

[Demirug]

HDR Texturen sind doch sowieso uninteressant. Gibt's ja nichmal komprimierte Formate für.

Für Direct3D 11 schon.

[Coda]

Wusste ich nicht. Gibt's da schon Infos drüber?

[AnarchX]

Wusste ich nicht. Gibt's da schon Infos drüber?
Hier gibt es die Game Fest Folien mit den Infos über die neuen Formate BC6 und BC7:
http://we.pcinlife.com/thread-981287-1-1.html
... musst dich nur registrieren. ;)

[dust]

HDR Texturen sind doch sowieso uninteressant. Gibt's ja nichmal komprimierte Formate für.

Hat ATI mit RV770 ja auch zurückgebaut, weil's niemand verwendet.
http://www.openexr.com/

meinst du sowas?

[Coda]

Das ist nicht komprimiert.

[DaBrain]

http://www.openexr.com/

meinst du sowas?

OpenEXR würde man eher zum lagern der Quelltexturen verwenden, nicht direkt im Spiel.


Bis jetzt wird es hauptsächlich für (nicht real-time) Renderings eingesetzt.


Das ist nicht komprimiert.

Ich glaube man kann RLE Kompression verwenden... (Oder sogar noch andere Verfahren?)

Aber natürlich nichts womit die Grafikkarte etwas anfangen kann.

Edit: RLE, ZIP und PIZ.

[dust]

Das ist nicht komprimiert.
# Multiple lossless image compression algorithms. Some of the included codecs can achieve 2:1 lossless compression ratios on images with film grain.
# Extensibility. New compression codecs and image types can easily be added by extending the C++ classes included in the OpenEXR software distribution. New image attributes (strings, vectors, integers, etc.) can be added to OpenEXR image headers without affecting backward compatibility with existing OpenEXR applications.
oder was meinst du?

[DaBrain]

Coda meinte mit Sicherheit, dass es keine Kompression wie DXT oder 3dc verwendet, die von der Grafikhardware unterstützt wird.

[Coda]

Das ist keine Texturkompression. Es gibt in D3D bisher kein komprimiertes FP-Format. Fertig aus.

[Gast]

GC 2008: Intel ist sicher - Larrabee weitaus schneller als alle aktuellen GPUs (http://www.pcgameshardware.de/?article_id=656921)
Mit 2 Gigaflops ganz sicher nicht.Bis 2010 werden die Karten von Nvidia und Co das doppelte an Rechenleistung bieten.

[GASTurbine]

kann man es nicht so sehen, dass eine Larrabee selbst bei gleicher Rechenleistung noch langsamer sein müsste, als eine "normale" Grafikkarte?

[dust]

http://www.pcgameshardware.de/?article_id=656921
Die noch produktlose Larrabee-Architektur, von Intel generell als durchsatzoptimierte x86-Architektur betrachtet, sei, so Aaron Coday, von vornherein als Angriff auf den High-End-Markt im Grafikkartenbereich konzipiert worden. Und zwar nicht, wie immer wieder zu lesen ist, mit dem heutigen High-End als Maßstab. Intel habe dazu die erwartete Leistung der High-End-Modelle von AMD und Nvidia für den erwarteten Zeitrahmen des Larrabee-Launches extrapoliert und seine Performance-Ziele entsprechend abgesteckt.

ob das reine pr oder ernstgemeint ist wird sich weisen...

[anddill]

Irgendwie hab ich die Vorahnung, daß das Ding erst mal ein 8MiB-Bios laden muß, um überhaupt den POST anzuzeigen. Und dann muß zwischen eigentlichem (3D-)Treiber und Hardware ja noch eine Art Wrapper, denn die ganze Art, 3D zu berechnen hat überhaupt nichts mit der Architektur von Larrabee zu tun.
Und wenn ich das jetzt mal mit den Grafiktreibern, die Intel bisher so abgeliefert hat zusammenbringe, dann sehe ich schwarz.
Der große Vorteil ist natürlich die extreme Flexibilität. Dem Ding ist es schlicht egal, ob es DX10, DX10.1 oder DX12 berechnet, oder Physix, Havok oder Folding@Home.

[AnarchX]

Irgendwie hab ich die Vorahnung, daß das Ding erst mal ein 8MiB-Bios laden muß, um überhaupt den POST anzuzeigen. Und dann muß zwischen eigentlichem (3D-)Treiber und Hardware ja noch eine Art Wrapper, denn die ganze Art, 3D zu berechnen hat überhaupt nichts mit der Architektur von Larrabee zu tun.

Das ist nicht korrekt ein Teil der Rendering Pipeline ist offenbar in HW:
http://img371.imageshack.us/img371/236/kaigai087533080zx4.jpg (http://imageshack.us)

Aber die freie Programmierbarkeit der Renderpipeline scheint einige interessante Möglichkeiten zu geben:
http://img361.imageshack.us/img361/1710/kaigai187576602vl9.jpg (http://imageshack.us)
http://img361.imageshack.us/img361/714/kaigai197579458je5.jpg (http://imageshack.us)
http://pc.watch.impress.co.jp/docs/2008/0822/kaigai461.htm?ref=rss

[Coda]

Das ist nicht korrekt ein Teil der Rendering Pipeline ist offenbar in HW:
Nur die TMUs, ansonsten gar nichts. Das Diagram bedeutet nur dass Larrabee Teile des Treibers auf Larrabee selber ausführt.

Irgendwie hab ich die Vorahnung, daß das Ding erst mal ein 8MiB-Bios laden muß, um überhaupt den POST anzuzeigen.
Aus welchem Grund?

Und dann muß zwischen eigentlichem (3D-)Treiber und Hardware ja noch eine Art Wrapper, denn die ganze Art, 3D zu berechnen hat überhaupt nichts mit der Architektur von Larrabee zu tun.
Es ist in der Tat ein Software-Rasterizer. Da sind schon fast alle Details bekannt.

Und wenn ich das jetzt mal mit den Grafiktreibern, die Intel bisher so abgeliefert hat zusammenbringe, dann sehe ich schwarz.
Ganz anderes Team von Leuten.

[anddill]

Aus welchem Grund?
Weil das Ding nun mal keine Grafikkarte im klassischen Sinne ist. Wird Intel wirklich eine Hardwarefunktion einbauen, die einen Framebuffer oder sogar einen festen Zeichensatz in 4 Farben auf den Bildschirm malt?


Es ist in der Tat ein Software-Rasterizer. Da sind schon fast alle Details bekannt.
Das Teil soll ja nicht den RefRast auf seinen 32(?) x86 Kernen rechnen, sondern dafür sind ja die SIMD-Recheneinheiten vorgesehen, und für die muß erst mal eine Programmiersprache + Compiler geschrieben werden.


Ganz anderes Team von Leuten.
Das kann gut oder schlecht sein. :cool:

[dust]

Weil das Ding nun mal keine Grafikkarte im klassischen Sinne ist. Wird Intel wirklich eine Hardwarefunktion einbauen, die einen Framebuffer oder sogar einen festen Zeichensatz in 4 Farben auf den Bildschirm malt?
das muss ja nicht im chip sein. einerseits könnten sie verschiedene chips bauen, einen mit integrierten einen anderen ohne integrierten der zb. onboard grafik beschleunigt.

Das Teil soll ja nicht den RefRast auf seinen 32(?) x86 Kernen rechnen, sondern dafür sind ja die SIMD-Recheneinheiten vorgesehen, und für die muß erst mal eine Programmiersprache + Compiler geschrieben werden.
möglicherweise habe ich es falsch verstanden aber sollen das nicht x86 simd einheiten werden? also bestehende software wie zb. software renderer einfach mit neuem compiler neu compilieren und fertig. (ja es werden sicher darüber hinausgehende optimierungen gemacht.) zumindest sehe ich so ihre grosse strategie auf allen ebenen und plattformen x86 duchzusetzen. sonst würde x86 für diesen prozessor nicht viel sinn machen wenn die software entwickler alles neu programmieren müssten und intel nur eine weiter möglichkeit neben stream und cuda wäre. in dem zusammenhang sehe ich die aussage mit tausenden cores und den bemühungen von intel möglichst viel automatisch durch den compiler zu parallelisieren.

[ShadowXX]

möglicherweise habe ich es falsch verstanden aber sollen das nicht x86 simd einheiten werden? also bestehende software wie zb. software renderer einfach mit neuem compiler neu compilieren und fertig. (ja es werden sicher darüber hinausgehende optimierungen gemacht.) zumindest sehe ich so ihre grosse strategie auf allen ebenen und plattformen x86 duchzusetzen. sonst würde x86 für diesen prozessor nicht viel sinn machen wenn die software entwickler alles neu programmieren müssten und intel nur eine weiter möglichkeit neben stream und cuda wäre. in dem zusammenhang sehe ich die aussage mit tausenden cores und den bemühungen von intel möglichst viel automatisch durch den compiler zu parallelisieren.
Ja.

Die neuen SMID-Einheiten können ganz "normal" wie die momentanen SSEx-Einheiten mit jeden beliebigen C++ Compiler angesprochen werden.
Ich gehe sogar davon aus, das die Larrabee-SMID- bzw. Vector-Einheiten identisch oder sehr ähnlich denen sein werden die in einem der nächsten Intel -Kerne verbaut werden soll..

Um genau zu sein in die Sandy Bridge CPUs und heißen soll das Zeug: Advanced Vector Extensions (AVX) (http://en.wikipedia.org/wiki/Advanced_Vector_Extensions).
Und jetzt rate mal wann diese CPUs kommen? Genau: 2010. Genau dann wann auch Larrabee kommen soll (2009/2010).

[reunion]

Ja.

Die neuen SMID-Einheiten können ganz "normal" wie die momentanen SSEx-Einheiten mit jeden beliebigen C++ Compiler angesprochen werden.
Ich gehe sogar davon aus, das die Larrabee-SMID- bzw. Vector-Einheiten identisch oder sehr ähnlich denen sein werden die in einem der nächsten Intel -Kerne verbaut werden soll..

Um genau zu sein in die Sandy Bridge CPUs und heißen soll das Zeug: Advanced Vector Extensions (AVX) (http://en.wikipedia.org/wiki/Advanced_Vector_Extensions).
Und jetzt rate mal wann diese CPUs kommen? Genau: 2010. Genau dann wann auch Larrabee kommen soll (2009/2010).

AVX ist AFAIK "nur" 256-bit breit (was noch immer doppelt so breit ist wie aktuelle Vektorerweiterungen inkl. SSE5), die Vektoreinheiten von Larrabee aber 512-bit.

[dust]

AVX ist AFAIK "nur" 256-bit breit (was noch immer doppelt so breit ist wie aktuelle Vektorerweiterungen inkl. SSE5), die Vektoreinheiten von Larrabee aber 512-bit.
http://en.wikipedia.org/wiki/Advanced_Vector_Extensions
Future

* Built-in future scalability.
* 256- and 512-bit vector integers.
* 512- and 1024-bit vector FPs.


also eher nach dem motto, je nachdem was unsere konkurrenz macht schustern wir einmal schnell was zusammen und solange uns die anderen nicht davonziehen, lassen wir uns zeit und heben das geld vom bankkonto ohne neues produkt ab, fliesst eh genug rein mit dem was wir derzeit verkaufen.

ist mir gerade so eingefallen bei der erwähnung der larrabee kommt erst 2009/2010, bis dahin gibt es schöne bunte powellpoint ahh powerpoint... und die leute sind beschäftigt und diskutieren das 32 seiten lang. ;D intel :P

[=Floi=]

intel informiert eben die kunden eher über produkte. Ich finde das immer noch gut und es schafft auch planbarkeit. Das ganze ist so wesentlich übersichtlicher und man sieht auch was auf einem zukommt und nicht der big bang eine woche nachdem man sich dann für ein produkt entschlossen hat. Genau so war es auch mit dem Q6600 G0 oder andere produkten. Die neue extreme ssd von intel ist da auch so ein tolles teil hardware und die ersten tests werden zeigen wie sie sich im vergleich mit der neuen mtron schlagen wird.

larrabe könnte in manchen bereichen auch sehr gut werden und auch ati und nv zu neuen höchstleistungen anspornen.

[ShadowXX]

larrabe könnte in manchen bereichen auch sehr gut werden und auch ati und nv zu neuen höchstleistungen anspornen.
Genau dieses hoffe ich am meisten....nV und AMD/ATI haben dann endlich mal wieder einen ordentlichen Konkurrenten.
Der dazu noch so eine Marktmacht und Bekanntheit hat, das die beiden wirklich was tun müssen.

[dust]

Genau dieses hoffe ich am meisten....nV und AMD/ATI haben dann endlich mal wieder einen ordentlichen Konkurrenten.
Der dazu noch so eine Marktmacht und Bekanntheit hat, das die beiden wirklich was tun müssen.
theoretisch könnte amd/ati sowas wie larrabee ebenfalls machen. ich befürchte nur die stellt es finanziell gerade auf und sie betreiben zuwenig f&e und suchen sich märkte aus wo sie möglichst viel verdienen bei möglichst wenig konkurrenz und damit risiko.

ich hoffe das beste, vor allem weil sie open source treiber massiv unterstützen sind sie für mich absolut erste wahl!

[deekey777]

NV trollt etwas:
NVISION: Larrabee "like a GPU from 2006" (http://www.pcpro.co.uk/news/220947/nvision-larrabee-like-a-gpu-from-2006.html)
"As [blogger and CPU architect] Peter Glaskowsky said, the 'large' Larrabee in 2010 will have roughly the same performance as a 2006 GPU from Nvidia or ATI."

Der Artikel hat mehrere interessante Aussagen, was Larrabee angeht.

[Trap]

Weil das Ding nun mal keine Grafikkarte im klassischen Sinne ist. Wird Intel wirklich eine Hardwarefunktion einbauen, die einen Framebuffer oder sogar einen festen Zeichensatz in 4 Farben auf den Bildschirm malt?
Das kann man in Software lösen, genauer gesagt in der Firmware. Bei Starten des Rechners lädt man ein Mini-OS auf dem Larrabee und das implementiert dann die ganzen Grafikkarten-Basisfunktionen.

[Avalox]

Ich dachte immer, dass Post Meldungen eh mit EFI bzw. UEFI nicht mehr gewünscht sind. Machen ja auch nicht wirklich Sinn und nur den unbedarften Nutzer kirre.

[Gast]

Nvidia hat Glaskowski falsch interpretiert:
http://news.cnet.com/8301-13512_3-10024280-23.html

[Gmax]

GC 08: Larrabee und Quake Wars Ray Traced (http://www.golem.de/0808/61949.html)

[dust]

GC 08: Larrabee und Quake Wars Ray Traced (http://www.golem.de/0808/61949.html)
nicht schlecht, das heisst id spiele werden mit zu den ersten gehören die rt einsetzen werden.

[Aquaschaf]

nicht schlecht, das heisst id spiele werden mit zu den ersten gehören die rt einsetzen werden.

Wie kommst du darauf? Das Projekt hat doch mit id gar nichts zu tun.

[dust]

Wie kommst du darauf? Das Projekt hat doch mit id gar nichts zu tun.
ich denke id hat intel den source code gegeben, id wäre dumm würden sie die erkenntnisse von intel nicht verwenden.

es können also nur beide gewinnen wenn sie zusammenarbeiten und gemeinsam ein spitzen spiel mit dazupassender hardware rausbringen als "state of the art" und "musst du haben".

[Gast]

Ich fühlte mich beim Anschauen dieses Videos heftig an die alten Zeiten vor den 3D-Beschleunigern erinnert. Da fehlen noch massiv Effekte und so wirklich nachvollziehbar ist es für mich nicht, wo die ganze Rechenpower versumpft.

Die Effektarmut gabs bis jetzt noch in jeder RT-Demo zu sehen. Wo bleiben denn die vielen Lichteffekte, die mit RT ja ach so einfach und billig umzusetzen sind?
Die Spiegelkugeln sind nett, aber sonst ist das Stromverschwendung:/

[Aquaschaf]

ich denke id hat intel den source code gegeben, id wäre dumm würden sie die erkenntnisse von intel nicht verwenden.

Carmack hat in einem Interview doch zum Ausdruck gebracht wie wenig er von diesem Projekt hält und dass sein Ansatz RT zu benutzen ziemlich anders aussehen wird.

[Coda]

ich denke id hat intel den source code gegeben, id wäre dumm würden sie die erkenntnisse von intel nicht verwenden.
Haben sie nicht. Die Dateiformate der Levels für Quake Wars sind nur recht einfach zu verwenden weil sie menschenlesbar sind.

[Avalox/Gast]

Carmack hat in einem Interview doch zum Ausdruck gebracht wie wenig er von diesem Projekt hält und dass sein Ansatz RT zu benutzen ziemlich anders aussehen wird.

Ich frage mich die ganze Zeit nach der Motivation von Carmack und wie er sich entscheiden wird.
Mit dem Larabee hat Intel ein Stück auch proprietäre Hardware an dem Start. Neben den etablierten APIs, wird Larrabee auch einen individuellen Weg ermöglichen. Natürlich wird Intel dort auf die grossen Engines schielen. Multipliziert sich doch dort der Effekt. So wird ID ganz sicher im Fokus von Intel liegen.
Nun stand Carmack schon mal vor einer ähnlichen Entscheidung. Mit Quake1 hat Carmack 3DFX gepusht und gleichzeitig an Ihrem Untergang mitgewirkt. Ich denke Carmack Intension Quake keinen Glide Pfad zu spendieren liegt allein in der Förderung des Wettbewerbs. Ich könnte mir vorstellen, dass Carmack immer noch so denkt. Es sei denn, er sieht den Larrabee Lösung als so zukunftsträchtig und vor allen so offen, dass er diese fördern möchte.
Ich denke aber vermutlich wird er einen Bogen um eine direkte Programmierung machen.

[dust]

Haben sie nicht. Die Dateiformate der Levels für Quake Wars sind nur recht einfach zu verwenden weil sie menschenlesbar sind.
in jeden quakewars level kann man echtes rt einbauen?

[Gast]

in jeden quakewars level kann man echtes rt einbauen?

Wieso nicht?

[Aquaschaf]

in jeden quakewars level kann man echtes rt einbauen?

Man baut nicht "RT in ein Level ein", sondern die haben einen Raytracer der das Levelformat lesen kann.

[dust]

Man baut nicht "RT in ein Level ein", sondern die haben einen Raytracer der das Levelformat lesen kann.
woher diese info?

die ersten tests mit rt haben sie mit einer im sourcecode veröffentlichten id engine gemacht.

[Aquaschaf]

woher diese info?

Dafür braucht man keine spezielle Information, deine vorherige Ausdrucksweise - "RT in ein Level einbauen" ergab einfach keinen Sinn.

[Gast]

woher diese info?

die ersten tests mit rt haben sie mit einer im sourcecode veröffentlichten id engine gemacht.
Hat Pohl nie gemacht.
Er nen Mapimporter geholt und die Quakemaps importiert und mitm nem Raytracer gerendert. Damals mit OpenRT und heute mit der Intel-API.
Der einzige Fortschritt von ihm besteht im Austauschen des Maploaders. :up:
Ein richtiges Spiel hat er nie gebaut...

[Coda]

in jeden quakewars level kann man echtes rt einbauen?
Was ist unechtes Raytracing?

[dust]

Was ist unechtes Raytracing?
dieses faken mit rastern...

[dust]

Hat Pohl nie gemacht.
Er nen Mapimporter geholt und die Quakemaps importiert und mitm nem Raytracer gerendert. Damals mit OpenRT und heute mit der Intel-API.
Der einzige Fortschritt von ihm besteht im Austauschen des Maploaders. :up:
Ein richtiges Spiel hat er nie gebaut...
habe ich dann falsch in erinnerung, du hast recht ich habs mir wieder rausgesucht.

http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/
Ray Tracing In 3D Egoshooters



Until now every 3D Shooter has been completly rendered in software or using common rasterization hardware. As a scientific study Saarland University developed in cooperation with Erlangen University the worlds first completly ray traced 3D Shooter.

As base for this kind of game Quake 3: Arena Demo from id Software has been choosen.

The game engine was written from scratch and supports player and bot movement including shooting and jumping, collision detection, and many sepcial effects like jump-pads and teleporters. The main development was done by Daniel Pohl in less than six months with contribution for shading by several other students (see feature list). The engine builds upon the OpenRT-API, which manages the ray tracing.

danke für die gedächtnishilfe ;)

[Coda]

dieses faken mit rastern...
Raytracing ist genauso "fake". Hör endlich mit diesem Unsinn auf.

[dust]

Raytracing ist genauso "fake". Hör endlich mit diesem Unsinn auf.
da gibt es auch unterschiedliche varianten...

[Coda]

Das was in den Spielen in den nächsten Jahren zu sehen sein wird ist maximal simples forward Raytracing und das ist NICHT physikalisch korrekter als Rasterisierung. Nicht die Bohne.

Die Lichtberechnung ist immer noch lokal und approximiert. Das einzige was gewonnen wird sind korrekte Reflexionen auf Kugeln. Ganz großes Kino. Mir fällt spontan absolut kein Effekt ein der die enorme Rechenleistung die für Raytracing nötig ist rechtfertigen würde.

[dust]

Das was in den Spielen in den nächsten Jahren zu sehen wird ist maximal simples forward Raytracing und das ist NICHT physikalisch korrekter als Rasterisierung. Nicht die Bohne.
ich erwarte mir morgen nicht die filmreif gerenderten spiele aber eine entwicklung in diese richtung. genauso wie in der vergangenheit rastern immer besser wurde, wird es auch mit rt sein und rt hat eine physikalisch korrekte basis.

[Coda]

ich erwarte mir morgen nicht die filmreif gerenderten spiele aber eine entwicklung in diese richtung.
Das allermeiste "filmreife" wird auch gerastert.

genauso wie in der vergangenheit rastern immer besser wurde, wird es auch mit rt sein und rt hat eine physikalisch korrekte basis.
Hat es NICHT. Raytracing wird erst annährend physikalisch korrekt wenn man backward raytracing inkl. Photon Mapping und mehren Wellenlängen macht. Das tun nicht mal die Offline-Renderer. Red keine Pappe. Das ist in den nächsten 10 Jahren nicht in Echtzeit möglich.

Außerdem geht es nicht darum etwas "physikalisch korrekt" darzustellen sondern so dass es gut aussieht. Wen interessiert es dass die Godrays inkl. Refraction in Crysis nicht mit Photon Mapping gerendert sind?

[dust]

Die Lichtberechnung ist immer noch lokal und approximiert. Das einzige was gewonnen wird sind korrekte Reflexionen auf Kugeln. Ganz großes Kino. Mir fällt spontan absolut kein Effekt ein der die enorme Rechenleistung die für Raytracing nötig ist rechtfertigen würde.
kommt auf das raytracing verfahren an aber ich denke zuerst an schatten und in zweiter linie an die komplette beleuchtung. speziell so dinge wie wetter, wolken, nebel, vollmond usw.

bis wir echte regenbögen sehen werden wird es wohl noch eine zeit dauern...

[Coda]

kommt auf das raytracing verfahren an
Kommt es nicht, weil wir hier von Echtzeit reden. Und da kommt alles andere außer Forward Raytracing nicht in Frage. Auch nicht in fernerer Zukunft.

aber ich denke zuerst an schatten und in zweiter linie an die komplette beleuchtung. speziell so dinge wie wetter, wolken, nebel, vollmond usw.
Hast du schonmal Crysis gespielt oder nicht? Das führt im Hintergrund eine komplette Atmosphärensimulation durch. Das ist weitaus realistischer als diese Kugeln-In-Der-Luft-Quake-Wars-Demo.

Wolken, Nebel und Vollmond gibt es dort nämlich schon. Und zwar nach realen physikalischen Modellen. (http://developer.amd.com/assets/D3DTutorial_Crytek.pdf)

[dust]

Kommt es nicht, weil wir hier von Echtzeit reden. Und da kommt alles andere außer Forward Raytracing nicht in Frage. Auch nicht in fernerer Zukunft.
sag niemals nie...

[Coda]

sag niemals nie...
Doch sage ich. Weil wir hier von einem Faktor ~100.000 reden, den kann auch Moores Law in den nächsten 10 Jahren niemals überbrücken. Außerdem ist Photon Mapping praktisch nie in einem Spiel einzusetzen, weil es langsamer wird je größer das Level ist. Freie Welten kann man dann gleich mal vergessen.

In der Zwischenzeit kann man mit der ~100 Raster-Leistung das praktisch realistische Bild genauso rendern. Und ich sag's nochmal: Das was Crysis da im Hintergrund an Atmosphärensimulation rechnet ist realistischer als die ganze Quake-Wars-Demo zusammen.

[dust]

Doch sage ich. Weil wir hier von einem Faktor ~100.000 reden, den kann auch Moores Law in den nächsten 10 Jahren niemals überbrücken. Außerdem ist Photon Mapping praktisch nie in einem Spiel einzusetzen, weil es langsamer wird je größer das Level ist. Freie Welten kann man dann gleich mal vergessen.
vor 10 jahren war crysis "undenkbar und unmöglich"...

In der Zwischenzeit kann man mit der ~100 Raster-Leistung das praktisch realistische Bild genauso rendern. Und ich sag's nochmal: Das was Crysis da im Hintergrund an Atmosphärensimulation rechnet ist realistischer als die ganze Quake-Wars-Demo zusammen.
du vergleichst eine technologie demo mit einem durchentwickelten endprodukt...

[Gast]

danke für die gedächtnishilfe ;)
Lies doch mal was da steht. Da hat einer ohne große Programmiererfahrung in 6 Monate für seine Bachelorarbeit etwas zusammengehackt und bezeichnet es als Gameengine. Selbst wenn ich den Quellcode nicht gesehen hätte, wäre mir vollkommen klar, dass das von einer richtigen Gameengine soweit weg ist, wie ein Malen nach Zahlen von Picasso.

Man konnte in dem Level rumlaufen und rumschießen. Das wars im groben auch schon. Die imo spektakulären Effekte waren nichtmal von ihm selbst.
Seit dieser Q3 Demo seh ich keinen wirklichen Fortschritt, der auf seiner Arbeit beruht. Von den richtig guten Leuten hintendran sieht und hört man leider nichts. Wenn du den irgendwo nen großen Forschritt siehst, kannst du ihn mir ja bestimmt genauer erläutern.

Die Diskussion Raytracing vs Rasterisierung wird sich in wenigen Jahren allerdings in Luft auflösen. Keins von beiden wird sich komplett durchsetzen. Mit der neu gewonnenen Flexibilität werden wir neue Renderverfahren sehen, die sich den bekannten Grundformen erheblich unterscheiden werden. Die letzten Konferenzen haben schon ein paar Sachen hervorgebracht, wie einen zuerstmal zum Schleudern bringen, weil sie neue Wege aufzeigen und nicht in das alte Denkmodell passen.

p.s.: Ich hab gestern abend im Sneak die "Stiefbrüder" gesehen. Mit deiner bisherigen Argumentation hättest du da ne Hauptrolle übernehmen können.

[dust]

Lies doch mal was da steht. Da hat einer ohne große Programmiererfahrung in 6 Monate für seine Bachelorarbeit etwas zusammengehackt und bezeichnet es als Gameengine. Selbst wenn ich den Quellcode nicht gesehen hätte, wäre mir vollkommen klar, dass das von einer richtigen Gameengine soweit weg ist, wie ein Malen nach Zahlen von Picasso.

Man konnte in dem Level rumlaufen und rumschießen. Das wars im groben auch schon. Die imo spektakulären Effekte waren nichtmal von ihm selbst.
Seit dieser Q3 Demo seh ich keinen wirklichen Fortschritt, der auf seiner Arbeit beruht. Von den richtig guten Leuten hintendran sieht und hört man leider nichts. Wenn du den irgendwo nen großen Forschritt siehst, kannst du ihn mir ja bestimmt genauer erläutern.

er ist deswegen so bekannt geworden weil das wort quake vorkam, ob bewusst oder unbewusst er hat damit cleveres marketing gemacht. seine arbeit war die erkenntnisse des instituts und ihren ganzen forschungen mit quake zu verknüpfen. saarbrücken, das sind die mit dem echtzeitraytracing.

Die Diskussion Raytracing vs Rasterisierung wird sich in wenigen Jahren allerdings in Luft auflösen. Keins von beiden wird sich komplett durchsetzen. Mit der neu gewonnenen Flexibilität werden wir neue Renderverfahren sehen, die sich den bekannten Grundformen erheblich unterscheiden werden. Die letzten Konferenzen haben schon ein paar Sachen hervorgebracht, wie einen zuerstmal zum Schleudern bringen, weil sie neue Wege aufzeigen und nicht in das alte Denkmodell passen.

und genau deswegen ist dieser hype wichtig.

[Gast]

seine arbeit war die erkenntnisse des instituts und ihren ganzen forschungen mit quake zu verknüpfen. saarbrücken, das sind die mit dem echtzeitraytracing.
Den Ruhm erntet er allein. Das würde mich als verdammt fuchsen.
Er hat auch nicht die ganzen Forschungen mit Quake verknüpft. Mehr als die Grundlagen hat er schon damals nicht genutzt. Heute haben wir aber endlich spiegelnde Donuts statt spiegelnder Kugeln. :crazy:

und genau deswegen ist dieser hype wichtig.
Der Hype nutzt keinem was. Manche sind seelig und andere ärgern sich drüber. Die wichtigen Leute kennen eh beiden und werden in Zukunft auch das machen was verünftig ist.
Mir ist jetzt auch die Zeit zu schade sinnlos zu diskutieren. Fachlich kommt bei ner Diskussion mit dir eh nichts raus.

[Coda]

vor 10 jahren war crysis "undenkbar und unmöglich"...
Die hohle Phrase brauchst du hier nicht bringen. Es gibt einen Unterschied zwischen in absehbarer Zeit in Echtzeit machbarer Algorithmen wie Crysis und Dingen wie Photon Mapping mit unvorhersehbarer und unkontrollierbarer Laufzeit.

Und nein, es hat in der Industrie niemand bezweifelt dass Crysis möglich sein wird. Das Offline-Rendering zeigt den Weg doch Jahre voraus.

und genau deswegen ist dieser hype wichtig.
Dieser Hype ist total hohl, weil von jedem der ernsthaft in der Industrie tätig ist ungefähr das gleiche kam wie von Carmack.

Vor allem das "bessere physikalische Grundlage"-Geschwafel geht mir tierisch auf die Nerven. Nicht nur dass sie total falsch ist, es interessiert am Ende auch sowieso keine Sau wie ein Bild gerendert wurde und bisher hat man noch für jedes Problem eine weitaus effizientere Approximation mit Rasterisierung gefunden die effektiv genauso gut aussieht.

Wir wollen sowieso eine möglichst perfekte Immersion der Realtität, keine völlig unnötige Simulation.

[dust]

Die hohle Phrase brauchst du hier nicht bringen. Es gibt einen Unterschied zwischen in absehbarer Zeit in Echtzeit machbarer Algorithmen wie Crysis und Dingen wie Photon Mapping mit unabsehbarer Laufzeit.


Dieser Hype ist total hohl, weil von jedem der ernsthaft in der Industrie tätig ist ungefähr das gleiche kam wie von Carmack.

Vor allem das "bessere physikalische Grundlage"-Geschwafel geht mir tierisch auf die Nerven. Nicht nur dass sie total falsch ist, es interessiert am Ende keine Sau wie ein Bild gerendert wurde und bisher hat man noch für jedes Problem eine weitaus effizientere Approximation mit Rasterisierung gefunden die effektiv genauso gut aussieht.
http://www.heise.de/newsticker/Nvidia-setzt-auf-die-3D-Revolution--/meldung/114869
Die Konkurrenz bereitet Huang dabei wenig Kopfzerbrechen. Schon im Vorfeld der Nvision hatte Nvidia Larrabee, den kommenden Multicore-Chip von Intel mit speziellen Grafikkernen, abfällig beurteilt. Intel habe Larrabee mit Grafikchips von 2006 verglichen. Bei der Pressekonferenz am Montag betonte Huang noch einmal: "Bis Larrabee auf den Markt kommt, ist unsere Technologie diesem Niveau bereits weit voraus."

Zur Bekräftigung verriet Senior Vice President Tony Tamasi danach einige Details über Nvidias kommende GPU-Generationen. Das Programmiermodell soll bedeutend erweitert werden, was den Kreis der Entwickler vergrößern dürfte. Außer den Grafikprogrammiermodellen (OpenGL, DirectX) wird jetzt auch C unterstützt, danach folgen C++ und Fortran. Grafik- und allgemeine Berechnungsaufgaben können "frei weg in einem Thread gemischt" werden, erklärte Tamasi. In fünf Jahren soll eine Nvidia-GPU damit eine Gleitkommaleistung von mindestens 20 TFLOPS erreichen. Die Speicherbandbreite werde bei über 1 TByte pro Sekunde liegen. Die heutige Spitzenleistung der GeForce GTX 280 liegt bei rund 1 TFLOPS und zirka 140 GByte pro Sekunde. (Erich Bonnert) (mfi/c't)

mir geht das hochloben des rasterns auf die nerven, hauptsache viele optische effekte aber zuwenig physik für die welt dahinter, sei es optisch wie sie aussieht oder mechanisch wie sie funktioniert.

[dust]

Wir wollen sowieso eine möglichst perfekte Immersion der Realtität, keine völlig unnötige Simulation.

und genau da sind unsere auffassungsunterschiede. ohne einer simulation kann es keine "möglichst perfekte Immersion der Realtität" geben.

[Coda]

und genau da sind unsere auffassungsunterschiede. ohne einer simulation kann es keine "möglichst perfekte Immersion der Realtität" geben.
Sehr wohl kann es das. Sie muss es sogar, weil wir auf einem 500mm²-Chip natürlich niemals die komplette Welt simulieren können. Das wiederspricht allein schon der Physik an sich.

Es muss somit immer eine Approximation herhalten, und Forward Raytracing auf Polygongeometrie ist keine die wir haben wollen, weil wir die Rechenzeit sehr viel sinnvoller investieren können. Die Raytracing-Romantik von der angeblich "besseren Realtität" wird in der Industrie höchstens zu müdem Lächeln führen.

Und überhaupt ist der Vorwurf dass die Grafik sich nicht immer mehr physikalischen Modellen annähernd völlig lachhaft. Die Engines die auf Realismus aus sind machen da inzwischen von einigem Gebrauch, vor allem was Atmospähreneffekte angeht.

[Gast]

... und bisher hat man noch für jedes Problem eine weitaus effizientere Approximation mit Rasterisierung gefunden die effektiv genauso gut aussieht . ...Gilt das auch für Schatten? Ein Rückzieher ist keine Schande und niemand ist allwissend!

[pixelguy]

http://www.heise.de/newsticker/Hot-Chips-Details-zum-Ringbus-von-Larrabee--/meldung/114943

[Exxtreme]

Gilt das auch für Schatten? Ein Rückzieher ist keine Schande und niemand ist allwissend!
Schonmal die Schatten bei Crysis gesehen? Zumal man halbwegs realistische Schatten eh' nur bei einzelnen großen Objekten braucht. Bei komplexeren oder vielen Objekten reicht nur eine halbwegs korrekte Approximation und keiner bemerkt den Unterschied. Genauso bei Spiegelungen.

[Gast]

Schonmal die Schatten bei Crysis gesehen? Zumal man halbwegs realistische Schatten eh' nur bei einzelnen großen Objekten braucht. Bei komplexeren oder vielen Objekten reicht nur eine halbwegs korrekte Approximation und keiner bemerkt den Unterschied. Genauso bei Spiegelungen.Das ist wohl kaum eine Antwort auf die Frage, ob sich Schatten mit Raytracing oder Rasterization besser lösen lassen. Coda hat gesagt, dass ihm keine Effekt einfiele, der über Raytracing besser oder einfacher zu lösen sei.

[Exxtreme]

Das ist wohl kaum eine Antwort auf die Frage, ob sich Schatten mit Raytracing oder Rasterization besser lösen lassen. Coda hat gesagt, dass ihm keine Effekt einfiele, der über Raytracing besser oder einfacher zu lösen sei.
Soft Shadows sind per RT sogar sehr viel teurer als per Rasterization da du vieeeeele Extra-Passes brauchst. :)

[Aquaschaf]

Gilt das auch für Schatten?

Wenn du etwas besseres als harte Schatten willst: ja.

[GASTurbine]

wie sieht es denn aus, wenn man mal richtig viele Lichtquellen hat?
lohnt sich Raytracing ab einer bestimmten Anzahl Lichtquellen?

[Gast]

Soft Shadows sind per RT sogar sehr viel teurer als per Rasterization da du vieeeeele Extra-Passes brauchst. :)
Bei komplizierter Beleuchtung und sehr vielen Polygonen brechen Softshadows in der Performance gnadenlos ein. Nicht so die harten Schatten des Raytracing.

[Aquaschaf]

wie sieht es denn aus, wenn man mal richtig viele Lichtquellen hat?
lohnt sich Raytracing ab einer bestimmten Anzahl Lichtquellen?

Nein, das ist orthogonal.

Bei komplizierter Beleuchtung und sehr vielen Polygonen brechen Softshadows in der Performance gnadenlos ein. Nicht so die harten Schatten des Raytracing.

Was meinst du mit komplizierter Beleuchtung? Wenn du dich auf die Anzahl der Lichtquellen beziehst: Shadow Mapping skaliert schön linear in jedem Fall.

[GASTurbine]

Bei komplizierter Beleuchtung und sehr vielen Polygonen brechen Softshadows in der Performance gnadenlos ein. Nicht so die harten Schatten des Raytracing.
wenn man sowieso schon die Schatten durch die GraKa "soft" machen kann,
kann man dann nicht auch auf viele Polygone bei Schatten verzichten?

[Exxtreme]

Bei komplizierter Beleuchtung und sehr vielen Polygonen brechen Softshadows in der Performance gnadenlos ein. Nicht so die harten Schatten des Raytracing.
Bei komplexer Beleuchtung und vielen Polygonen kannst du zumindest in Spielen schön mit Approximationen arbeiten. :) Ist völlig egal, ob der Schatten des Waldes am Boden wirklich den Bäumen entspricht oder nicht solange der Winkel Lichtquelle -> Schattenwurf korrekt ist. :) Und sobald man mit solchen Approximationen arbeitet, braucht man kein RT mehr.

[Gast]

Wolken, Nebel und Vollmond gibt es dort nämlich schon. Und zwar nach realen physikalischen Modellen. (http://developer.amd.com/assets/D3DTutorial_Crytek.pdf)

Seh ich das richtig das die Fog-Volumes via Ray-Tracing gemacht werden? sieht so aus als ob wir quasi schon hybrid ansätze in games haben :)

[Gast]

Seh ich das richtig das die Fog-Volumes via Ray-Tracing gemacht werden? sieht so aus als ob wir quasi schon hybrid ansätze in games haben :)
Welche Erkenntnis...
Was glaubst du was parallax occlusion mapping, reliefmapping, cone step mapping etc sind?
Alles 2,5D Raytracing.

[GASTurbine]

Bei komplexer Beleuchtung und vielen Polygonen kannst du zumindest in Spielen schön mit Approximationen arbeiten. :) Ist völlig egal, ob der Schatten des Waldes am Boden wirklich den Bäumen entspricht oder nicht solange der Winkel Lichtquelle -> Schattenwurf korrekt ist. :) Und sobald man mit solchen Approximationen arbeitet, braucht man kein RT mehr.
genau das war es, was ich am Ende der letzten Seite wissen wollte :)

[Coda]

Gilt das auch für Schatten? Ein Rückzieher ist keine Schande und niemand ist allwissend!
Ja das gilt auch für Schatten. Raytracing ist gerade dort extrem teuer sobald man etwas anderes verwendet als harte Schatten ohne Penumbra.

Seh ich das richtig das die Fog-Volumes via Ray-Tracing gemacht werden? sieht so aus als ob wir quasi schon hybrid ansätze in games haben :)
Man rekonstruiert am Ende des Renderings für jeden Pixel die World-Space-Position über die Szenentiefe und berechnet dann welche Fog-Volumes zwischen diesem Punkt und der Kamera liegen. Mit Raytracing hat das nur entfernt was zu tun auch wenn das Ergebnis in diesem Fall (homogene Volumes) das gleiche ist.

Man könnte aber auch anfangen an dieser Linie entlang zu Samples der Volumes zu nehmen. Das wäre dann eher wieder Raytracing.

[Gast]

Bei komplexer Beleuchtung und vielen Polygonen kannst du zumindest in Spielen schön mit Approximationen arbeiten. :) Ist völlig egal, ob der Schatten des Waldes am Boden wirklich den Bäumen entspricht oder nicht solange der Winkel Lichtquelle -> Schattenwurf korrekt ist. :) Und sobald man mit solchen Approximationen arbeitet, braucht man kein RT mehr.Ist die Approximation nur zu sehr vereinfacht wegen zu hoher Komplexität, dann sieht lächerlich und falsch aus. Das ist die ober Schranke der Approximation. Hier könnten über RT Bilder folgen, die einer neuen Dimension angehören und einen wahren Vorteil darstellen.

[Gast]

Zum Thema Raytracing, Rasterisierung und Schatten habt ihr schon etwas verfaßt. Hier zum Nachlesen:
http://www.3dcenter.org/artikel/echtzeit-raytracing-der-universit%C3%A4t-des-saarlandes

[Coda]

Damit stimmte ich schon damals nicht überein. Vor allem das mit den Softshadows ist einfach Käse.

[Exxtreme]

Ist die Approximation nur zu sehr vereinfacht wegen zu hoher Komplexität, dann sieht lächerlich und falsch aus. Das ist die ober Schranke der Approximation. Hier könnten über RT Bilder folgen, die einer neuen Dimension angehören und einen wahren Vorteil darstellen.
Du kannst eine sehr gute Approximation mit sehr billigen Mitteln erreichen. Und diese Mittel sind um ganze Grössenordnungen schneller als RT.

[Gast]

Du kannst eine sehr gute Approximation mit sehr billigen Mitteln erreichen. Und diese Mittel sind um ganze Grössenordnungen schneller als RT.Vielleicht solltest den absolutistischen Anspruch 'Softshadows Rasterizer ist immer viel schneller als Softshadows Raytracer' ein wenig mit der Realität vergleichen. Beim RT Verfahren ist noch sehr viel Potential zur Optimierung durch leistungsfähigere Algorithmen. Viele Passes können gegen wenige ausgetauscht werden und schon kann man Softshadows auch auf Raytracern physikalisch korrekt in hoher Geschwindigkeit wiedergeben. Auch ist das nur ein Anfang, der im Laufe der Zeit bis Larrabee in den Markt eintritt, noch erheblich verbessert werden kann. Dies gilt eigentlich für alle Effekte. In dieser Diskussion wird strikt vom aktuellen Stand der Kenntnis ausgegangen. Potential zu erheblicher Optimierung wird weitestgehend ignoriert. Insbesondere die Software-Implementation eine Raytracers ermöglicht die Entwicklung von Optimierungen in viel kürzeren Intervallen als bei den Rasterizern mit ihrer GPU-Hardware Abhängigkeit.

http://graphics.cs.lth.se/research/papers/soft2005/

[Coda]

Beim RT Verfahren ist noch sehr viel Potential zur Optimierung durch leistungsfähigere Algorithmen.
Das ist nicht wahr.

Es wird bereits massiv im groben (Multithreading) und feinen (SIMD) parallelisiert, dazu sind vorberechnete KD-Trees als Beschleunigungsstruktur und Ray-Traversal praktisch schon optimal. Und dennoch ist es für spielerelevante Polygonmengen mit LOD weitaus langsamer.

http://graphics.cs.lth.se/research/papers/soft2005/
Das ist doch dann auch nur noch Pfusch. Wozu dann Raytracing? Solche Verfahren gibt es auch für Shadowmaps.

[deekey777]

Voxel ray tracing vs polygon ray tracing (http://raytracey.blogspot.com/2008/08/voxel-ray-tracing-vs-polygon-ray.html)

[Aquaschaf]

Beim RT Verfahren ist noch sehr viel Potential zur Optimierung durch leistungsfähigere Algorithmen. Viele Passes können gegen wenige ausgetauscht werden und schon kann man Softshadows auch auf Raytracern physikalisch korrekt in hoher Geschwindigkeit wiedergeben.

Weißt du eigentlich wovon du redest? Raytracing ist kein neu entdecktes Verfahren was noch schlecht erforscht wäre. Und vergiss "physikalisch korrekte Softshadows" und "hohe Geschwindigkeit" in einem Satz. Unabhängig vom Verfahren.

[Gast]

Das ist nicht wahr.

Es wird bereits massiv im groben (Multithreading) und feinen (SIMD) parallelisiert, dazu sind vorberechnete KD-Trees als Beschleunigungsstruktur und Ray-Traversal praktisch schon optimal. Und dennoch ist es für spielerelevante Polygonmengen mit LOD weitaus langsamer.

Nicht auf dieser Ebene!


Das ist doch dann auch nur noch Pfusch. Wozu dann Raytracing? Solche Verfahren gibt es auch für Shadowmaps.
Die einen nennen es Optimierung, die anderen Pfusch. Aus deiner Sicht müßte sogar die Rasterisierung selbst schon Pfusch sein.

Aber vielleicht zählt hier auch nur das Ergebnis!?! Damit erreicht die RT in Bezug auf Soft Shadows eine hohe, realtime-taugliche Performance bei hervoragendem visuellem Ergebnis.

Tja, die zwei Seiten deiner Medaille. Beim Rasterizer darf optimiert (gepfuscht) werden, beim RT nicht.

[Gast]

Weißt du eigentlich wovon du redest? Raytracing ist kein neu entdecktes Verfahren was noch schlecht erforscht wäre. Und vergiss "physikalisch korrekte Softshadows" und "hohe Geschwindigkeit" in einem Satz. Unabhängig vom Verfahren.Mein liebes Aquaschaf. Zunächst mäßige deine unflätigen Ton, und im Anschluß vernehme bitte, daß Realtime-Raytracing in der Tat ein recht neues Forschungsgebiet ist.

[Coda]

Nicht auf dieser Ebene!
Welche Ebene? Softshadows?

Die einen nennen es Optimierung, die anderen Pfusch. Aus deiner Sicht müßte sogar die Rasterisierung selbst schon Pfusch sein.
Ist sie auch. na und?

Aber vielleicht zählt hier auch nur das Ergebnis!?! Damit erreicht die RT in Bezug auf Soft Shadows eine hohe, realtime-taugliche Performance bei hervoragendem visuellem Ergebnis.
Genau meine Rede. Und deshalb ist Raytracing auf Polygongeometrie für Spiele einfach nicht brauchbar. Rasterisierung ist deutlich schneller und wenn man dann doch mal paar secondary rays braucht um schönere Spiegelungen zu haben dann sag ich auch nichts.

Tja, die zwei Seiten deiner Medaille. Beim Rasterizer darf optimiert (gepfuscht) werden, beim RT nicht.
Hab ich nicht behauptet. Nur ein gewisses Member hier (dust) meint dass man mit Raytracing auf einmal alles dolle realistisch ist und darum ging die Diskussion auf den letzten Seiten auch.

Mein liebes Aquaschaf. Zunächst mäßige deine unflätigen Ton, und im Anschluß vernehme bitte, daß Realtime-Raytracing in der Tat ein recht neues Forschungsgebiet ist.
Realtime wurde es nur weil genügend Rechenleistung zur Verfügung steht. Die Algorithmen sind immer noch die gleichen.

[Aquaschaf]

und im Anschluß vernehme bitte, daß Realtime-Raytracing in der Tat ein recht neues Forschungsgebiet ist.

Real time oder nicht real time macht überhaupt keinen Unterschied.

[Ganon]

Wenn ich mir das angucke:

http://www.golem.de/0808/61949.html

http://scr3.golem.de/screenshots/0808/Quake_Wars_Raytraced/qwrt_0011.jpg


dann frage ich mich immer noch, warum darüber so ein Hype veranstaltet wird? Ich meine, es ist zwar nett, dass er das da mit RayTracing in 720p mit 20-30fps dahingeruckelt bekommt, aber er benötigt dazu auch 24 CPU-Kerne (4x6 Core). Und damit zeigt er eine Grafik, die, bis auf die Spiegelungen, auch eine PS2 hinbekommt. Da fehlt ja z.B. sämtliche Beleuchtung...

... und wenn ich dann weiterdenke und mir angucke, was ein jetziger 300 EUR PC mit dem Originalspiel, oder z.B. Crysis so "schafft"... wozu noch weiter daran arbeiten? Und ob Larrabee da hilft wage ich auch zu bezweifeln. Denn hier arbeiten ja schon 24 "echte" Kerne.

Die Spielereien mit der Glaskugel sind zwar ganz nett, aber das geht auf normalen Wege doch schon seit Ewigkeiten. Zwar nicht 100%ig physikalisch korrekt, aber das interessiert doch in dem Sinne nicht. Keiner sitzt da und misst das im Spiel nach, oder?

Und das Wasser... nunja. Ich weiß ja nicht wie oft der Mensch Wasser sieht, aber Gewässer in der Größe spiegeln bei weitem nicht so stark. Die spiegeln nämlich fast gar nicht... man braucht sich ja nur mal Fotos angucken.

[Gast]

Welche Ebene? Softshadows?


Ist sie auch. na und?


Genau meine Rede. Und deshalb ist Raytracing auf Polygongeometrie für Spiele einfach nicht brauchbar. Rasterisierung ist deutlich schneller und wenn man dann doch mal paar secondary rays braucht um schönere Spiegelungen zu haben dann sag ich auch nichts.


Hab ich nicht behauptet. Nur ein gewisses Member hier (dust) meint dass man mit Raytracing auf einmal alles dolle realistisch ist und darum ging die Diskussion auf den letzten Seiten auch.


Realtime wurde es nur weil genügend Rechenleistung zur Verfügung steht. Die Algorithmen sind immer noch die gleichen.
Dieser Algorithmus stammt aus dem Jahr 2005 und nicht aus dem letzten Jahrhundert. Forschung für Realtime-Raytracing findet vermehrt im 21 Jahrhundert und nicht im letzten Jahrtausend statt. Die Ausrichtung ist nicht auf Qualität, die ohnehin schon verfahrensimmanent ist, sondern auf Performance. Natürlich steigt die Rechenleistung dazu parallel. Das ist u.a. die Motivation schlechthin sich an intelligenten realtime-Raytracing Algorithmen zu versuchen.

Ich rede auch nicht von der Ebene des Hardware-/Software-Scheduler sondern den möglichen Opmitierungen durch intelligente Verfahren, von dem du hier eines hast nachlesen dürfen. Wenn du es Pfusch nennst - Gut! Ich sehe hier, wie eine konzeptionell auf Raytracing ausgelegter Renderer in Bezug auf Softshadows mindestens mithalten kann in Qualität und Geschwindigkeit. Darum geht es doch u.a. in der Larrabee Diskussion. Ist dies möglich? Kann Larrabee per Raytracing überzeugen? Das Verfahren ist zumindest physikalisch korrekt, selbst wenn Aquaschaf lautstark eine andere Meinung vertritt.

Es gibt noch in der Quake-RT-Engine von Daniel Pohl unglaublich viel Optimierungspotential. Insbesondere wenn das Rendering von den CPUs näher an den Grafikkern gebracht werden kann (duch Larrabee), wird wieder ein Bottleneck eleminiert sein. Ich bin jedenfalls gespannt, wie sehr Larrabee die Forschung um realtime-RT wird antreiben können. So manchen Hardcore-Rasterization Fan wird noch das eine oder andere Blaue Wunder erleben.

Und nun Vorsicht bei deiner Antwort. Du kennst definitiv nicht alle möglichen Optimierungen für einen RT-Renderer. Du kennst nur, was du bisher nachlesen konntest, und selbst hier bezweifele ich die Vollständigkeit deines Wissens.

[Aquaschaf]

Das Verfahren ist zumindest physikalisch korrekt, selbst wenn Aquaschaf lautstark eine andere Meinung vertritt.

Das verlinkte Softshadow-Verfahren ist nicht physikalisch korrekt.

Dieser Algorithmus stammt aus dem Jahr 2005 und nicht aus dem letzten Jahrhundert. Forschung für Realtime-Raytracing findet vermehrt im 21 Jahrhundert und nicht im letzten Jahrtausend statt. Die Ausrichtung ist nicht auf Qualität, die ohnehin schon verfahrensimmanent ist, sondern auf Performance.

Qualität ist nicht mehr oder weniger "verfahrensimmanent", wenn man ray tracing verwendet. Und noch ein Irrtum: es ging schon immer darum auf Performance zu optimieren. Das ist nichts neues. Ich bezweifle nach wie vor dass du wirklich verstehst um was es geht. Es gibt keinen simplen Dualismus zwischen ray tracing und rasterization. Sondern eine riesige Menge an existierenden und möglichen Algorithmen zur Darstellung von Computergrafik die neben anderen Techniken mit ray tracing und rasterization arbeiten. Physikalisch korrekt ist davon kein einziges.

[Gast]

Das verlinkte Softshadow-Verfahren ist nicht physikalisch korrekt.Dann haben wir ein unterschiedliches Verständnis von physikalisch korrekt. Darf ich dich Fragen, ob du zumindest die Einleitung des PDF-Dokuments gelesen hast?

[Aquaschaf]

Dann haben wir ein unterschiedliches Verständnis von physikalisch korrekt. Darf ich dich Fragen, ob du zumindest die Einleitung des PDF-Dokuments gelesen hast?

"Physically based" ist etwas anderes als "physikalisch korrekt".

[Ganon]

"Physically based" ist etwas anderes als "physikalisch korrekt".

Ich denke mal er meint den Part hier:
This paper describes a new soft shadow volume algorithm ... to produce physically correct shadows

[Aquaschaf]

Ich denke mal er meint den Part hier:

Tut mir leid, diesen Satz habe ich tatsächlich überlesen. Es ändert jedoch nichts daran worüber sich die Diskussion auf den letzten Seiten gedreht hat. Dieses Verfahren ist auch "nur" eine Approximation.

[Exxtreme]

Vielleicht solltest den absolutistischen Anspruch 'Softshadows Rasterizer ist immer viel schneller als Softshadows Raytracer' ein wenig mit der Realität vergleichen. Beim RT Verfahren ist noch sehr viel Potential zur Optimierung durch leistungsfähigere Algorithmen. Viele Passes können gegen wenige ausgetauscht werden und schon kann man Softshadows auch auf Raytracern physikalisch korrekt in hoher Geschwindigkeit wiedergeben. Auch ist das nur ein Anfang, der im Laufe der Zeit bis Larrabee in den Markt eintritt, noch erheblich verbessert werden kann. Dies gilt eigentlich für alle Effekte. In dieser Diskussion wird strikt vom aktuellen Stand der Kenntnis ausgegangen. Potential zu erheblicher Optimierung wird weitestgehend ignoriert. Insbesondere die Software-Implementation eine Raytracers ermöglicht die Entwicklung von Optimierungen in viel kürzeren Intervallen als bei den Rasterizern mit ihrer GPU-Hardware Abhängigkeit.

http://graphics.cs.lth.se/research/papers/soft2005/
Lies das mal durch was du gepostet hast (auch wenn der Link grad down ist). Denn streng genommen approximieren auch die. Denn rekonstruieren ist nicht wirklich "in echt" berechnen auch wenn das Ergebnis vergleichbar ist.

[deekey777]

First Larrabee to have 48 cores (http://www.fudzilla.com/index.php?option=com_content&task=view&id=10089&Itemid=65)

Bisher ging man von 32 Cores aus (siehe zB diverse Meldungen bei heise).

(Damit jetzt keine Sprüche wie "GT200 hat 240 Cores" oder ähnlicher Unsinn kommt: Mit einem Core ist beim Larrabee ein IA32 gemeint, der wiederum eine "VPU" verwaltet, die wiederum die eigentlichen Rechenaufgaben übernimmt, indem sie bis zu 16 Gleitkommaoperationen parallel ausführt.)

[Avalox]

First Larrabee to have 48 cores (http://www.fudzilla.com/index.php?option=com_content&task=view&id=10089&Itemid=65)

Bisher ging man von 32 Cores aus (siehe zB diverse Meldungen bei heise).



Oh, ha. Dann scheint man bei Intel aber ganz schön zu kämpfen um ein einigermaßen konkurrenzfähiges Produkt auf dem Markt zu bekommen.

48 Kerne sollte es doch erst geben, wenn man diese in einem feineren Prozess auf einen kleineren DIE bekommt. Oder verspätet sich der Larrabee soweit, dass dort schon im 32nm Prozess gefertigt wird. Dort waren ja 48 Kerne schon lange im Gespräch.

[Coda]

Intel will naturally want to use Larrabee for CUDA and GPGPU like general purpose processing as it wants a piece of this potentially profitable market.
Na da hat mal wieder jemand Ahnung...

[deekey777]

Na da hat mal wieder jemand Ahnung...

Nicht für CUDA, sondern für CUDA like.

Sinn ergibt das nicht, aber das, was er meinte, wird deutlicher.

[Coda]

Ah okay, dann sei ihm nochmal verziehen.

[deekey777]

Ah okay, dann sei ihm nochmal verziehen.
Das bringt mich aber auf einen Gedanken:
http://www.beyond3d.com/content/articles/106/4
one of the big new features in CUDA 2.0 has nothing to do with GPUs: you will now be able to compile CUDA code into highly efficient SSE-based multithreaded C code to run very efficiently on the CPU. That’s right, not just device emulation; the genuine goal is to make it run as fast as possible on Intel and AMD CPUs. In a way, that’s quite similar to Rapidmind.

Und dann lässt man diesen CPU-Code auf dem Larrabee laufen. :biggrin:

[Coda]

Larrabee ist halt nur schnell, wenn man auch die 512-Bit-Vector-Instructions verwendet. Aber gehen wird es wohl, dürfte dann halt nur 1/4 der Leistung bringen.

[AnarchX]

Larrabee für Workstation schon im H2 2009? (http://www.fudzilla.com/index.php?option=com_content&task=view&id=10346&Itemid=1)

Bei der Consumervariante brauch man wohl noch etwas Zeit für die 3D-Treiber.

[Hvoralek]

Wieso "schon"? Larrabee war doch zuletzt um den Jahreswechsel 09/10 erwartet worden. Das würde mit Workstation 2H 09 und Consumer 1H 10 doch gut hinkommen.

[dust]

das wichtigste sind gute open source opengl treiber und ein günstiger preis. dann kann die karte ein sehr grosser erfolg werden.

[Coda]

Für den Markt sind "gute Open-Source-OpenGL-Treiber" völlig irrelevant.

Was zählt ist Windows und Direct3D.

[dust]

Für den Markt sind "gute Open-Source-OpenGL-Treiber" völlig irrelevant.

Was zählt ist Windows und Direct3D.

http://www.fudzilla.com/index.php?option=com_content&task=view&id=10346&Itemid=1
... Intel wants to attack the most profitable market, which is obviously Nvidia's cash cow....

Workstation drivers are a complex thing but based on OpenGL as this is what most of the workstation application use but you still need to optimise this driver to perfection to get the desired results from it and to hope to performance leadership in this market.

Workstation market is very attractive as the margins on these products are as high as sixty percent, while when you sell a high-end graphics card you can only hope to get a fifteen percent margin. This gives you a clear idea why companies want to be the part of this lucrative market.

The desktop, gaming Larrabee comes later, in 2010.

[Gast]

Was zählt ist Windows und Direct3D.

Tellerrand zu hoch für dich?

[JaDz]

Larrabee might not have a Windows XP driver / Just Vista and Windows 7 (http://www.fudzilla.com/index.php?option=com_content&task=view&id=10349&Itemid=34)

[Sorkalm]

Spricht auch dafür, dass das Ding als Spielegrafikkarte noch nicht 2009 kommt. ;)

[dust]

Larrabee might not have a Windows XP driver / Just Vista and Windows 7 (http://www.fudzilla.com/index.php?option=com_content&task=view&id=10349&Itemid=34)

Since the first products will go after the professional market it's highly likely that we will see Linux driver as some of the professional guys use Linux
gute neuigkeiten! :biggrin:

[Coda]

Tellerrand zu hoch für dich?
Was hat das mit Tellerrand zu tun? Es ist nunmal Fakt, dass der allergrößte Markt für GPUs der für Spieler ist, und da ist Windows/D3D wichtig und der Rest eine absolute Nische.

http://www.fudzilla.com/index.php?option=com_content&task=view&id=10346&Itemid=1
Auch im Profisegment werden keine Open-Source-Treiber verwendet. OpenGL != Open Source.

[Gast]

Es ist nunmal Fakt, dass der allergrößte Markt für GPUs der für Spieler ist, und da ist Windows/D3D wichtig und der Rest eine absolute Nische.
Aber der größte Profit steckt in den Nischen-Märkten. Intel will nicht nur Umsatz sondern auch Gewinn erzielen. NVidia braucht unbedingt den Gamer-Markt, damit die Nischen-GPUs (auf den Nischen-Karten) nicht zu teuer werden. Intel nutzt wohl die eigenen Herstellungskapazitäten und CPUs bringen bis auf die Nischen-GPUs offensichtlich mehr Profit. Es ist schon richtig, Larrabee zunächst in Richtung Workstation, GPGPU und HPC zu positionieren. Der gewöhnliche Nutzer kommt auch mit einer Onboard-Grafik aus. Alles andere außer Games wird Larrabee sehr wahrscheinlich vom Stand weg besser cruchen als der Rest der GPGPUs.

[|MatMan|]

Aber der größte Profit steckt in den Nischen-Märkten.
Profit/Marge pro Karte ja, aber ich denke nicht beim Gesamtumsatz/Gesamtgewinn. Oder hast du da eine Quelle mit konkreten Zahlen? Selbst bei nVidia nimmt man an im HPC Markt erst in einigen Jahren wirklich Geld verdienen zu können (das ist natürlich eine Prognose, kein Gesetz) - die Aussage gabs mal in einem CUDA-Interview von David Kirk.
Man verdient Geld durch den Absatz von Millionen GPUs und nicht mit ein paar Quadros für 2000 €.

Das gilt genauso für Intel. Außer sie zielen wirklich nur auf den HPC Markt von morgen und können es sich leisten die ersten Jahre Verluste zu machen. Das glaube ich aber kaum. Außerdem will Intel ja noch gerne die eigenen CPUs im HPC Markt mit hoher Marge verkaufen.

[deekey777]

"Larrabee" Architecture Details For Future "Visual" Computing
Aligning to Intel's 'Terascale' performance vision, Intel described features and capabilities of its first-ever forthcoming "many-core" blueprint or architecture codenamed "Larrabee." The first product based on Larrabee targets the PC's graphics market and is expected in 2009 or 2010.

http://www.intel.com/pressroom/archive/releases/20081118fact.htm?iid=pr1_releasepri_20081118f

[Sorkalm]

The first product based on Larrabee targets the PC's graphics market

Ahja? Das war ja bisher anders überlegt wurden. Dann kommt die neue Konkurrenz ja bald...

[Gast]

Ganz viele neue Infos zur Architektur!

http://pc.watch.impress.co.jp/docs/2008/1125/kaigai477.htm

[robbitop@work]

omg die Bins werden "off-chip" also im VRAM gespeichert? Bandbreite und Latenz ahoi. Warum hat man dafür nich Caches vorgesehen wie in PowerVR Designs?

[Coda]

Hat man doch. Die Bins sind exakt so groß dass sie genau in die normalen Caches der Cores passen. Das passiert halt automatisch und nicht manuell. Das ist ja überhaupt erst der Grund warum man überhaupt binnt.

Die Infos sind übrigens nicht neu, sondern standen schon alle im Siggraph-Paper.

[Gast]

Hat Larrabee eigentlich auch MMX Einheiten?


Gab's die nicht schon beim Pentium 1?

[Gast]

Und was ist mit den Stromsparfeatures vom Pentium M?

Verfügt Larrabee über irgendwelche modernen Stromsparfeatures?
Ich will nämlich keine 200 W Karte in meinem Rechner haben.
Das Design des Larabee finde ich ansonsten interessant.

[Ailuros]

Das wichtigste "Stromsparfeature" von LRB wird wohl 32nm sein. Generell klingt mir LRB eher danach als ob es mehr die area bei gleichem Herstellungsprozess brauchen wuerde als die Konkurrenz; in diesem Fall wird es wohl keinen deutlichen Nachteil gegen zumindest GT3xx@40nm haben. Nach einem 2009 Launch sieht es aber nicht gerade aus.

Ansonsten will ich hoffen dass sich Intel's Philosophie was Grafik-leistung betrifft aendern wird bis zum Launch. Wenn man durch die Entwicklung Ziel X was die Leistung betrifft erreicht, heisst es nicht dass man dort stecken bleibt sondern versucht konstant bis zum launch jeden Brocken an Leistung herauszuquetschen, ueberhaupt wenn man noch nicht weiss wo die Leistung der Konkurrenz genau liegen wird in der Zukunft.

[haifisch1896]

Dafür müsste man dann aber auch mal ordentliche Treiber entwickeln und nicht 1.5 Jahre unter Verschluß halten.

[Coda]

Wie meinst du das? Der Larrabee-Treiber hat wohl nicht sehr viel mit denen für die GMAs zu tun.

[reunion]

Trotzdem muss ihn irgend jemand schreiben, und gute Treiberprogrammierer wachsen auch nicht auf Bäumen. Außerdem wird es sicher seine Zeit dauern bis man diese völlig neue Architektur entsprechend beherrscht.

[Coda]

Sehe ich anders.

[dust]

ich denke intel wird ziemlich rasch ganz gute treiber veröffentlichen. mich würden open source treiber zumindest für opengl und zumindest linux nicht wundern.

zuerst planen sie die karten für den professionellen bereich, da können sie sich miese qualität einfach nicht leisten...

[Coda]

Intel hat eine Policy, dass für jede Hardware Open-Source-Treiber veröffentlich werden, außer es liegt ein triftiger Grund dagegen vor.

Bei Larrabee könnte der sein, dass viel Know-How eben nicht mehr in der Hardware sondern in der Software liegt und man dieses dadurch verraten könnte.

[dust]

umgekehrt haben open source treiber den vorteil, er ist ein besseres studienobjekt und damit können andere, zb. forschungsprojekte, leichter ihre ideen implementieren. dadurch kann der treiber die besten sachen beinhalten, speziell wenn intel das fördert und wettbewerbe auf den unis für die besten lösungen veranstaltet. der input würde die leistung des pakets, hardware und treiber, verbessern. bessere benchmarks ergeben mehr verkauf bei niedrigeren entwicklungskosten.

wir werden sehen...

[Abraxus]

umgekehrt haben open source treiber den vorteil, er ist ein besseres studienobjekt und damit können andere, zb. forschungsprojekte, leichter ihre ideen implementieren. dadurch kann der treiber die besten sachen beinhalten, speziell wenn intel das fördert und wettbewerbe auf den unis für die besten lösungen veranstaltet. der input würde die leistung des pakets, hardware und treiber, verbessern. bessere benchmarks ergeben mehr verkauf bei niedrigeren entwicklungskosten.

wir werden sehen...
Auf die Unis kann Intel verzichten, die kaufen sich schon die Rosien vom Markt weg. Auch die anderen 0815 Programmierer sind eher uninteressant.

[dust]

Auf die Unis kann Intel verzichten, die kaufen sich schon die Rosien vom Markt weg. Auch die anderen 0815 Programmierer sind eher uninteressant.
ob jemand eine rosine oder eine niete ist sieht man am code. bekanntes beispiel daniel pohl und sein realtime raytracing, zuerst ein paar sachen veröffentlicht und dann von intel eingekauft.

niemand im hightech bereich kann auf unis verzichten!

[Aquaschaf]

bekanntes beispiel daniel pohl und sein realtime raytracing, zuerst ein paar sachen veröffentlicht und dann von intel eingekauft

Daniel Pohl hat selbst nichts weltbewegenes geschaffen.. den würde ich nicht als Beispiel verwenden.

[dust]

Daniel Pohl hat selbst nichts weltbewegenes geschaffen.. den würde ich nicht als Beispiel verwenden.

er hat es bekannt gemacht, intel ist auf ihn aufmerksam geworden...

[Coda]

Pohl ist ein Idiot.

[san.salvador]

Pohl ist ein Idiot.
Kannst du das auch argumentativ untermauern? :D

[Coda]

Kannst du das auch argumentativ untermauern? :D
Natürlich kann ich das.

Was er getan hat ist ein paar Quake-Levels in den Saarland-OpenRT-Raytracer gespielt das ganze in einer Studienarbeit publiziert und nachher unglaublich Bullshit in Interviews rausgelabert. Der Typ hat doch nichtmal etwas an dem Raytracer implementiert.

Wer eine ordentliche Meinung dazu hören will soll sich mal anschauen was Carmack dazu gesagt hat und das mit seinem Geschwätz vergleichen. Auf die Probleme mit dynamischer Geometrie ist er erst gar nicht eingegangen - das sagt schon alles.

[Ailuros]

Mein voriger Beitrag war auf eine off the record Aussage von jemand im LRB Treiber team gezielt. Es geht hier nicht um's "koennen" sondern ums "wollen" und der Wille ist garantiert da im vorerwaehnten Team; nur sind anscheinend manche die das Sagen haben bei Intel viel zu locker was das Thema "gut genug" betrifft.

Es gibt noch genug Zeit bis zum Launch und ich will auch hoffen dass sich daran etwas aendert. Wenn nicht wird wohl der erste Eindruck ins Klo fallen...

[deekey777]

Larrabee for HPC: Not So Fast (http://www.hpcwire.com/blogs/Larrabee-for-HPC-Not-So-Fast-36336839.html)
What I didn't mention from that conversation is that while Dracott was trash talking accelerators, he also managed to diss Larrabee -- at least as a scientific computing architecture. Although Larrabee would at least offer an x86 compatible ISA, the problem, he said, was that the implementation contains some of the same drawbacks as the traditional GPU for scientific computing -- namely the lack of ECC memory to protect against soft errors and a shortage of double precision floating point capability. From his perspective that would prevent Larrabee or GPUs to be deployed more generally in high performance computing, "But," Dracott added, "we are working on products that will meet that need.
Versucht da Intel die deutlich teurere CPU-Flotte vor Kanibalismus durch Larrabee zu schützen? Den letzten Satz finde ich interessant und denke dabei an Sandy Bridge mit deren AVX.

[Coda]

Larrabee kann kein double precision? Das halte ich für ein Gerücht. Kann sein, dass es nicht auf das 512-Bit-Vektorformat anwendbar ist, aber SSE2/x86 kompatibel sollte das Ding eigentlich sein.

[deekey777]

"Shortage" ist ja nicht gleich "Lack", vielleicht nicht vollständig IEEE 754 compliant (wie der RV670/770). Mit der DP-Fähigkeit des GT200 (IEEE 754) hat NV sich keinen Gefallen getan, sondern den Chip noch komplizierter gemacht.