Diskussion zu: Erste genauere Informationen zu Intels Larrabee

[Leonidas]

Link zum Artikel:
http://www.3dcenter.org/artikel/erst...ntels-larrabee

[MadManniMan]

Warum brauch man für Raytracing zwangsläufig eine Schnittstelle? Schließlich ist Raytracing doch "Software pur", oder nicht?

[Hübie]

Naja aber man kanns in verschiedenen Sprachen entwickeln. Vielleicht ist das gemeint (also im Sinne von "Interpreter").


bye Hübie

Zitat von MadManniMan

Warum brauch man für Raytracing zwangsläufig eine Schnittstelle? Schließlich ist Raytracing doch "Software pur", oder nicht?

Für Raytracing wird kein API benötigt. Auch muß DX oder OGL nichts zur Verfügung stellen. We Larrabee vollkommen nativ mit Intel-Compilern ausreizen möchte, der kann das wohl mit hoher Effizienz vom Start weg tun. Treiber für DX spielen, wie gesagt, keine Rolle.

Im Text ist wenig auf den deferred renderer Larrabee eingegangen worden. Es sind lediglich die Tiles als Rendering-Einheit pro Kern hervorgehoben worden. Larrabee arbeitet aber klar als deferred renderer, was aus Intel Dokument zur Siggraph hervorgeht. Damit sinkt der Bandbreitenbedarf doch erheblich!

Zitat von MadManniMan

Warum brauch man für Raytracing zwangsläufig eine Schnittstelle? Schließlich ist Raytracing doch "Software pur", oder nicht?

Rasterisierung auch. Man kann auch beides in Hardware implementieren.
Trotzdem ist Leos Annahme, dass Intel umbedingt Raytracing durchsetzen will nicht begründbar und eine Integration in einer Raytracing-API in DirectX auch nicht sinnvoll, weil eigentlich vom Objektmodell her unvereinbar.

Vielleicht sollten solche Artikel Leute mit mehr Einsicht in die Materie schreiben....

[Leonidas]

Klar kann man Raytracing auch ohne DX machen. Nur werden es die Spieleentwickler annehmen? Die müssten dann das Spiel entweder für Intel only schreiben oder faktisch doppelt für Intel und ATI/NV schreiben - was niemand machen wird. Nein, wenn Intel Raytracing durchdrücken will, muß man wohl oder übel so gestalten, daß für die Spieleentwickler kein bedeutender Mehraufwand oder Inkompatibilitäten entstehen.

[Hübie]

Ich dachte, da RT auf der x86-Architektur läuft gibt es keine Unterschiede im code? ...

bye Hübie

die situation mit larrabee als grafikkarte und cell be in der ps3 ist vergleichbar, es geht beide male darum, die stückzahl hochzuziehen und dabei erfahrungen zu sammeln.
jon stokes zum beispiel vermutet, dass larrabee ein allgemeiner beschleuniger wird, unter anderem eben auch in spielen mit rastergrafik und raytracing.

das spannende an dem design ist, dass es seine hardware sehr gut ausnutzen wird können, weil ja alles gleich ist und dynamisch neu zugewiesen werden kann.

das ganze teil, sagen wir ein 4 kern nehalem mit einem 32 kern larrabee ist ähnlich zu 4 cell be, wenn auch mit einer komplett anderen speicherarchitektur und ganz anderen interconnects.
denkt dran: sony wollte in die ps3 erst nur die cell be einbauen, keine grafikkarte. eine generation später (also 2-3 shrinks) scheint das total denkbar.

[aths]

Zitat von Leonidas

Klar kann man Raytracing auch ohne DX machen. Nur werden es die Spieleentwickler annehmen? Die müssten dann das Spiel entweder für Intel only schreiben oder faktisch doppelt für Intel und ATI/NV schreiben - was niemand machen wird. Nein, wenn Intel Raytracing durchdrücken will, muß man wohl oder übel so gestalten, daß für die Spieleentwickler kein bedeutender Mehraufwand oder Inkompatibilitäten entstehen.

Es gibt doch Compiler, die eine Hochsprache in maschinenlesbaren Code umwandeln. Das Drumherum würde eh auf der CPU laufen, die eigentlichen Raytracing-Berechungen auf einem anderen Chip. Hätte man das erst mal in einer Hochsprache, läge es an dem IHV, dafür einen Compiler zur Verfügung zu stellen wenn er möchte, dass die Applikation auch auf seiner Hardware läuft.

Die Umstellung auf Raytracing bedeutet erst mal Mehraufwand. Es handelt sich nicht nur um eine ganz ander Art der Berechnung, man muss auch die 3D-Daten anders verwalten (und sortieren.) Man kann Raytracing nicht halbwegs effizient ausführen und so gestalten dass es ohne bedeutenden Mehraufwand statt Rastering genutzt wird.



"So gehört zu jedem Kern eine Textureneinheit - welche jedoch mit 8 Bit Breite erstaunlich klein ausfällt. Heutzutage üblich sind durchgehend 32bittige Texturen, ob das Larrabee-Design diese ohne Peformance-Verlust verarbeiten kann, ist noch nicht klar."

Gemeint sind 8 Bit pro Kanal. 32-Bit-Texturen RGBA (oder RGBX) haben auch 8 Bit pro Kanal.


"Nicht unbeachtet werden soll der Punkt, daß Intel mit Larrabee mindestens zweigleisig fährt, weil Larrabee für Intel auch Anteile im rasch wachsenden GPGPU-Geschäft sichern soll."

Im Kontext sollte nicht von GPGPU gesprochen werden, da nicht die GPU für General-Purpose-Aufgaben herangezogen wird, sondern der Chip in seiner Eigenschaft als Streamprozessor.

[Exxtreme]

Zitat von Hübie

Ich dachte, da RT auf der x86-Architektur läuft gibt es keine Unterschiede im code? ...

bye Hübie

Der Befehlssatz ist x86-kompatibel. Das Teil muss trotzdem separat programmiert werden.

[betasilie]

Ganz informativ, aber schon recht viele Rechtschreibfehler drin für eine Veröffentlichung. Außerdem findet man extrem viele Bindestriche, die teilweise völlig deplaziert und/oder schlicht falsch gesetzt sind. "Dass" wird übrigens nicht mir "ß" geschrieben.

Zwar bleiben weiterhin viele Fragen unbeantwortet und ist vor allem die Schlagkraft der Larrabee-Architektur bislang kaum einzuschätzen, dies wird dann die Zukunft zeigen müssen. {der Satz ist nicht korrekt aufgebaut}

Generell kann man Larrabee als ManyCore-CPU (mit wohl 32 Kernen) sehen, welche "nur" virtuell als Grafikkarte arbeitet. Denn arbeitet, denn die typischen Elemente eines Grafikchips fehlen fast vollständig, Intel vollständig. Intel bildet ...

Wie schon genannt, ist daß das ganze ein stark CPU-nahes Design und hat auf den ersten Blick wenig mit einem Grafikchip zu tun.

Intel geht hier einen wirklich anderen Weg, als (derzeit) ATI und nVidia

Heutzutage üblich sind durchgehend 32bittige Texturen, obTexturen. Ob das Larrabee-Design diese ohne Peformance-Verlust verarbeiten kann, ist noch nicht klar.

Zu den anderen "fixed function" Einheiten kann derzeit mangels Informationen noch nichts gesagt werden, Intel werden - Intel hat hier schlicht noch nichts bekanntgegeben. {Hier würde ein Gedankenstrich ausnahmsweise mal passen oder aber ein Punkt}


Und da ist leider noch einiges mehr sehr seltsam geschrieben, habe jetzt aber keine Zeit mehr die 2. Hälfte zu korrigieren. Die Fehler mit den Gedankenstrichen lasse ich mal ganz rausfallen.

Inhaltlich jedenfalls ganz nett zusammengefasst, auch wenn der Text hätte korrektur gelesen werden müssen. Und vielleicht hätte es dem Text sprachlich ganz gut getan, wenn man sich 2-3 Stunden mehr Zeit genommen hätte.

[Hübie]

Hhahahaaa. Geiler Kommentar. Wo er Recht hat, hat er Recht
@Exxtreme: Ja aber ich meinte, dass es doch eigentlich keine Schnittstelle im Sinne von D3D erfordert oder wie jetzt? Ein software-renderer läuft ja auch auf jeder CPU.



bye Hübie

Zitat:

Laut Intel skaliert Larrabee derzeit mit bis zu 32 Kernen nahezu linear, bei 32 bis 48 Kernen liegt die Effizienz immer noch sehr hoch und erst darüber geht diese dann spürbar zurück (bei 64 Kernen nur noch das 5,5fache der Performance von 8 Kernen).

die grafik geht nur bis 48 kerne, mit diesen skaliert das design angeblich mit dem faktor 5,5 (im verhältnis zu 8 kernen) und ist damit immer noch nicht weit vom theoretischen maximum von 6 entfernt.

Zitat:

Ohne aber einer standarisierten Schnittstelle für Raytracing in Direct3D11 wird Raytracing in den nächsten Jahren nicht über den Status einer technischen Spielerei hinauskommen können.

man kann raytracing mit der standardisierten (das 'd' fehlt übrigens) schnittstelle namens DirectX10 bereits auf heute erhältlichen GPUs ohne probleme durchführen (prinzipiell sogar mit SM3.0 und DX9.0c, wenn auch nicht sehr effizient) und natürlich wird das auch mit DirectX11 möglich sein.

was raytracing braucht um sich durchsetzen zu können wäre ein besseres performance-optik-verhältnis im vergleich zu rasterizing, die API-schnittstelle ist bereits vorhanden.

[WinterBorn]

Mich interessiert es viel mehr, wie viel Energie diese Chips verbrauchen werden. Leider haben AMD und Nvidia hier sehr schlechte "Grenzwerte" gesetzt...

"bei 64 Kernen nur noch das 5,5fache der Performance von 8 Kernen"

passt irgendwie nicht zur Grafik. Laut dieser wird die 5,5fache Performance von 8 Kernen bereits mit 48 Kernen erreicht und nicht mit 64. Was stimmt denn nun?

[tomvos]

Zitat von Leonidas

Klar kann man Raytracing auch ohne DX machen. Nur werden es die Spieleentwickler annehmen? Die müssten dann das Spiel entweder für Intel only schreiben oder faktisch doppelt für Intel und ATI/NV schreiben - was niemand machen wird. Nein, wenn Intel Raytracing durchdrücken will, muß man wohl oder übel so gestalten, daß für die Spieleentwickler kein bedeutender Mehraufwand oder Inkompatibilitäten entstehen.

Wäre das nicht ein passendes Einsatzgebiet für LLVM? Die Raytracing Engine schreibt man in C und mittels LLVM wird daraus optimaler Code für Larrabee, nVidia oder ATI generiert. Selbst der Einsatz auf Konsolen wäre - bzw. beim Cell ist - denkbar.

Zitat von tomvos

Wäre das nicht ein passendes Einsatzgebiet für LLVM? Die Raytracing Engine schreibt man in C und mittels LLVM wird daraus optimaler Code für Larrabee, nVidia oder ATI generiert.

Jein. Wenn man faul wäre, könnte man das als Lösung sehen. Solch kritische Codeabschnitte optimiert man besser von Hand. Vorallem ist es nicht so extrem viel kritischer Code und der profitiert nicht von JIT-Compiling.

Zitat:

Selbst der Einsatz auf Konsolen wäre - bzw. beim Cell ist - denkbar.

Cell mit Linux != Cell mit PS3 OS

[robobimbo]

Etwas holprig fomuliert meiner Meinung nach:

Zitat:

...von Larrabee ins Spiel zu bringen - und zum die unbestreitbare Eignung...

Soll das: ...und zu dem die... heissen?

Ansonsten sehr Informativ, danke dafür!

[aths]

Zitat von robobimbo

Etwas holprig fomuliert meiner Meinung nach:

Soll das: ...und zu dem die... heissen?

Bitte!! Heißen mit ß. Sonst schreibt Leo wieder heißen mit ss.

[betasilie]

Ich denke mal, das Konzept wird für den normalen Spieler wieder nicht sehr interessant, wie es Intel typisch bzgl. der Leitung wird, aber dafür könnte es ein nette Spielerei werden für Hobbyporgrammierer. Im Grunde ist das ganze ja einem Cell von IBM recht nahe und Sony wollte den Cell ja eigentlich auch als Grafikchip einsetzen.

Also ich finde das Konzept irgendwie geil, auch in Hinblick auf Spielereien (nicht Spiele) mit Echtzeitraytracing. Mal schauen, ob das Konzept langfristig sogar richtungsweisend ist.