News Exakte Details zu Intels „Xeon-Phi“-MIC

[R4ID]

Genau die richtige Hardware um nachm harten Arbeitstag ne Runde Tetris zu spielen.

 

[Nai]

Wo wäre der Vorteil gegenüber GPUs? Raytracing lässt sich doch schon wunderbar darauf ausführen und die Rechenleistung der GPUs ist auf jeden Fall höher.

Mir kann keiner erzählen, dass es nicht auch möglich wäre den Code auf GPU Shadern zu berechnen. GPUs sind in der SP Leistung den CPUs um Welten überlegen und wachsen weiterhin sehr stark an. Selbst wenn auf GPUs merklich Effizienz verloren geht, können die in Zukunft sicher immer noch schneller.

Für Raytracing lohnt das nicht, dazu benötigt man nur single precision Genauigkeit und das ist die definitive Schwäche von Knights Corner durch das agressive 1:2 verhältnis.

Das Problem dabei ist wie immer, wieviel Performance in Endeffekt für die Anwendung übrig bleibt. Beim RayTracing verwendet man hierachische Datenstrukturen für die Szene, damit man jeden Strahl nicht mit jedem Dreieck überprüfen muss, sondern nur mit den Dreiecken aus den teilen der Datenstruktur, durch die der Strahl läuft.
Hier macht sich dann einer der Hauptnachteil der GPUs bei soetwas bemerkbar: Ineffizentes Branching
Viele Ausführeinheiten teilen sich eine Steuereinheit. Springt nur ein Teil der Ausführeinheiten einer Steuereinheit in eine Bedingung oder Schleife beim traversieren dieser Datenstruktur herein, so werden nur diese angesteuert, während sich die übrigen Ausführungseinheiten in der Zeit schlafen legen. Dies versucht man zwar zum Teil zu vermeiden, indem man das StrahlenBündel einer Ausführeinheit möglichst ebenfalls Lokal auf dem Bildschirm anordnet, jedoch komplett vermeiden lässt es sich dadurch ebenfalls nicht. Wenn man zusätzlich noch die Stärke des RayTracing ausnutzen und Reflectionen und Refractionen haben will, dann wird man bei der Verfolgung der sekundären tertiären und usw. Strahlen noch mehr Probleme haben, da sich das Strahlenbündel sehr schnell auffächert und die Datenstruktur sehr ungleichmässig durchlaufen wird, wodurch die GPUs einen Großteil ihrer Rechenleistung beim Raytracen einbüsen.

Bei Reflexionen und Refractionen wären wir schon beim nächsten Problem der GPUs:
Rekursion ist nicht möglich. GPUs haben keinen Stack wie eine CPU wo sie die Register bei Funktionsaufrufen sichern könnten, wodurch die Rekursion standardmässig nicht möglich ist. Man kann sie sich zwar etwas ercheaten, indem man die Register selbst oder den lokalen Speicher auf dem Chip dafür verwendet. Aber erstere werden benötigt um viele Threads gleichzeitig im Speicher der GPU zu aben; dh je mehr Register ein Thread benötigt desto weniger Threads können dort gleichzeitig sein. Man will aber viele Threads gleichzeitig am laufen haben, da diese benötigt werden um Zugriffszeiten auf den Speicher zu kaschieren. Denn während ein Teil der Threads auf den Hauptspeicher wartet und schläft, wird ein Teil der übrigen Threads von den Ausführeinheiten ausgeführt. Warten zu viele der aktiven Threads auf den Hauptspeicher, so können die Ausführeinheiten nicht ausgelastet werden. Lokaler Speicher dafür zu verwenden bringt ebenfalls nachteile, da dieser, sofern er vom Programm nicht verwendet wird, als L1 Cache fungiert.

Codekomplexität könnte man mE auch noch hinzufügen, aber ich habe keine Lust das noch zu erklären.

Dadurch verpufft je nach Anwendung ein großteil der GPU Performance, während die CPUs diese Nachteile nicht haben. Dadurch kann es sein, dass KNCs heutigen GPUs beim Raytracen von komplexeren Szenen deutlich überlegen ist.

 

[Matzegr]

@Matzegr

Was genau klingt da nach Intel-Marketing-Geblubber? Informiere dich einfach genauer.

Folgender Satz

Und bevor hier wieder Vergleiche zu GPUs kommen... die 1 TF soll kein Peakwert sein, sondern die durchschnittliche Leistung bei variierenden Matrixgrößen.

Ich zweifel ja nicht die Durchschnittsleistungs an, es klingt aber so als ob GPUs ihren Peakwert nur unter ganz bestimmten Bedingungen erreichen, ansonsten aber einfach einbrechen und das bezweifel ich.

Ich hät halt gerne ein DP-Matrixgrößen-Diagramm zwischen Xeon-Phi und GPUs.

 

[domidragon]

Dadurch verpufft je nach Anwendung ein großteil der GPU Performance, während die CPUs diese Nachteile nicht haben. Dadurch kann es sein, dass KNCs heutigen GPUs beim Raytracen von komplexeren Szenen deutlich überlegen ist.

Danke für die Erklärung, sah denn Vorteil dieses Intel Teils nicht.
Kann man sagen, ob sich diese Karte im Rendern befürworten könnte? Also Videoschnitt, 3D Rendering in Cinema 4D, 3Ds Max, Vue etc.?

Ich frag mich eh, wieso GPUs nicht solche Szenen rendern können, dass sind ja mehr als extreme parallele abläufe?

 

[[F]L4SH]

@Nai

Was du beschreibst sind voll und ganz Architektur Probleme. Und die lassen sich "problemlos" beheben.

Als Beispiel:
Als der Wechsel von 2D auf 3D vollzogen wurde, filenen viele GPU Hersteller raus. Ihre Architekturen lieferten wunderbare 2D Leistung - waren aber absolut unfähig 3D richtig zu berechnen.
Für 3D wurde vieles an der Architektur gedreht. Den letzten Sprung gab/gibt es mit GPGPU - die SIMD Blöcke bekommen eigenen L1 und L2 Cache und besseren Speicher und allgemein wird die Architektur über den Haufen geworfen.

Den selben Wandel kann es auch innerhalb von 1-2 Generationen bei den GPUs wieder geben, wenn Raytracing eine Rolle spielt. Dann sorgt man eben dafür, dass die Parrallele Rechenleistung bei GPUs steigt und mehr einzelne Threads berechnet werden können. Spricht ja nichts dagegen (je nachdem wie sich die Bedürfnisse entwickeln) jedem Shaderblock eigene Register und großzügigen Cache beizustellen und das ganze so zu verwirklichen, dass jeder Block seine eigene Aufgabe bearbeiten kann.
GPUs können im Moment nur kein Raytracing, weil es absolut unnötig ist. Ändert sich das, ändert sich auch die Architektur.

@nVentor

Du hast es echt (wie so oft alle hier) geschafft die unbedeutendsten Aussagen aus meinem Post herauszufiltern und per Quote ohne Kontext zu blamieren
Natürlich wird geraytraced (bei diesem Wort rollen sich mir die Fußnägel hoch). Aber das sind oftmals Anwendungen, wo es nicht auf die Zeit oder "fps" sondern das Endergebnis ankommt. Diese typischen Automodelle sind ein gutes Beispiel dafür. Rendering eben. Aber das machen 1000 Leute (?). Raytracing spielt im PC und auch Server Markt noch eine so winzige Rolle, dass es sich eben nicht lohnt für AMD oder nVidia da eine eigene GPU zu entwickeln bzw. die aktuellen GPUs damit auszurüsten. Was will man mit Schaltungen, die kein Mensch nutzt? Das ist ja fast wie AMDs 3DNow!
Mir ging es nur darum, dass ich der Meinung bin es ist "kein" Problem GPU Architekturen komplett auf Raytracing umzustellen. Man muss es eben nur entsprechend angehen und optimieren. Eine Aussage zur aktuellen Bedeutung von Raytracing wollte ich nicht mal treffen. Wobei ich auch in Zukunft im Echtzeit Bereich absolut keinen Vorteil in Raytracing sehe. Rasterisierung kann fast alles, was auch Raytracing kann - nur viel schneller und schöner. Raytracing trumpft wirklich nur im Bereich Licht, Transparenz und Spiegelungen auf. Und das reicht einfach nicht. Es ist ein unerhörter Aufwand jede "Kacktextur" mit irgendwelchen Strahlenbündeln zu beschießen und kompliziert auszurechen, wenn man sie auch einfach "hinstellen" kann.

 

[GuaRdiaN]

[...]um als Grafikkarte zu dienen, oder scheitert es rein auf Software Ebene?

Wenn ich dich richtig verstehe zielst du mit deiner Frage auf eine normale diskrete Grafikkarte ab. Sehe ich das richtig?

@Matzegr
[...]Das, was Intel vorhatte, benötigt sehr viel mehr an Rechenleistung... vielleicht gibt es in ein paar Jahren einen erneuten Versuch.[...]

Falls ist das richtig sehe, dann scheitert es prinzipiell an nichts, außer dem nicht vorhandenen RAMDAC, der die Pixel zu einem Bild zusammensetzt. Aber die KNC ist eine gänzlich andere Architektur. Das heißt konkret, dass aktuelle OpenGL oder DirectX APIs nichts mit der Hardware anfangen könnten. Daher ist die Möglichkeit hier nicht gegeben. Die Rechenleistung ist in der Tat mehr als Ausreichend dafür.

Was calluna anspricht war vermutlich das Vorhaben, Raytracing umzusetzen. Dafür ist die Leistung tatsächlich nicht ausreichend. Dabei würden aber auch SLI- oder Corssfireverbünde der aktuellen Grafikkarten nicht weiterhelfen. Weil Raytracing von der Mechanik ganz anders arbeitet, sodass die Hardware dafür einfach nicht potent genug ist.
Normale Rastergrafiken mit der gesamten Renderingpipeline, sollten kein Problem darstellen. (Aber hier stütze ich mich nur auf mein Verständnis der Materie - dass fehlender RAMDAC und falsche Architektur es unmöglich machen, ist vollkommen klar.)

 

[twilight]

Die urspüngliche Idee von Larrabee war eine reine Software Rendering Pipeline auf einer General Purpose Throughput Architecture. Intel hätte sich dann daran versucht einen Grafiktreiber für DirectX und OpenGL bereitzustellen um "Legacy" Anwendungen zu unterstützen. Letztendlich sollten aber Engines direkt für Larrabee entwickelt werden, die dann ohne Umwege über DirectX oder OpenGL ausgekommen wären. Somit hätte man den Entwicklern die absolute Freiheit gegeben, welche nur durch den Aufwand einer Implementierung begrenzt worden wäre, aber nicht durch den von z.B. DirectX bereitgestellten Funktionsumfang.
Prinzipiell muss man für GP im Vergleich zu Fixed Function immer Energieeffizienz für einen erweiterten Funktionsumfang opfern. Die Ax Steppings waren von der Rohleistung her mit den dGPUs zu der Zeit wie z.B. der GTX 280 ganz gut aufgestellt, aber bis ein Release-würdiges C0 Stepping, das schließlich als Knights Ferry Development Kits verteilt wurde, fertig war, hatte sich bei den GPUs eben einges getan. Software-seitig hat sich Intel was Grafiktreiber angeht bisher auch nicht wirklich mit Ruhm bekleckert und bevor native Engines für Larrabee erschienen wären, hätte sich die Hardware erst mal gegen GPUs behaupten müssen, wobei alles von Intels Grafiktreiber abgehangen hätte. Zusammenfassend kann man sagen, dass einiges schief gelaufen ist und die Zeit für einen rein softwarebasierten Ansatz noch nicht reif war. Vielleicht sehen wir in der Skylake Microarchitecture eine MIC-basierte iGPU und somit ein knappes Jahrzehnt später eine Wiederkehr der Grundidee hinter Larrabee.

 

[nVentor]

GPUs können im Moment nur kein Raytracing, weil es absolut unnötig ist. Ändert sich das, ändert sich auch die Architektur.

Erzähl das mal den GPU-Raytracern

Klar geht das. Die GPUs sind frei programmierbar und arbeiten wunderbar parallel. Das sind SIMD Prozessoren. Die sind für solche parallelisierten Aufgaben ausgelegt!

Übrigens ist das Fehlen von Rekursionen kein Argument. Alles was rekursiv gelöst werden kann, lässt sich auch als Schleife formulieren! Rekursionen dienen nur der einfacheren Programmierbarkeit, weil sich damit mathematische Konstrukte direkt in die Implementation übertragen lassen. Im Gegensatz zu Schleifen liefern sie sogar schlechtere Performance, eben weil dieser Stack benutzt werden muss. Es ist also einfach nur tendenziell anspruchsvoller, für (GP-)GPU zu entwickeln, aber prinzipiell geht alles.

Was calluna anspricht war vermutlich das Vorhaben, Raytracing umzusetzen. Dafür ist die Leistung tatsächlich nicht ausreichend. Dabei würden aber auch SLI- oder Corssfireverbünde der aktuellen Grafikkarten nicht weiterhelfen. Weil Raytracing von der Mechanik ganz anders arbeitet, sodass die Hardware dafür einfach nicht potent genug ist.

Genau das ist das Problem. Echtzeitrendering mit Raytracing erfordert einfach verdammt schnelle Hardware. Aber das ist ja auch nur eine Frage der Zeit, bis sich das erübrigt. Photorealistische Szenen mit der GPU zu raytracen ist bei nicht-zeitkritischen Anwendungen kein Problem und gar nicht mal so unüblich. Wird ja auch schon von Hobby-Anwendern mit kostenlosen Tools wie Blender (mit zusätzlichen Renderer-Modulen) seit längerem gemacht.

 

[r4yn3]

@GuaRdiaN: Ja genau, danke hier für die Antwort, so etwas in der Richtung habe ich gemeint. Mir geht es prinzipiell darum, zu sehen, dass Larrabee letzendlich nicht der rießen Reinfall ist, für den ihn alle hielten. Auch wenn keine diskrete Grafikkarte daraus wird, so hat es doch sehr viel Potential.

 

[Fishlike]

Theoretisch sollte das super zum rendern sein aber das Limit an Speicher ist da wieder ein riesen Problem. Szenen für Filme verwenden schnell mal 50GB an Texturen etc. Das müsste alles in den Ram ausgelagert werden was die Geschwindigkeit wieder extrem bremst und man könnte gleich bei normalen CPUs bleiben.
GPU rendering wird auch oft Diskutiert und "Gegner" sagen immer wieder, dass GPUs für finale Render nichts taugen, genau aus diesem Grund.

 

[Nai]

Klar geht das. Die GPUs sind frei programmierbar und arbeiten wunderbar parallel. Das sind SIMD Prozessoren. Die sind für solche parallelisierten Aufgaben ausgelegt!

Eben nicht wegen branching; siehe zB http://www.tml.tkk.fi/~timo/publications/aila2009hpg_paper.pdf
Hier werden je nach Strahlentyp und Implementierung ungefähr ~40% Rechenleistung beim Traversieren und Schnittpunktberechnen eingebüst, bei Szenen mit gerade einmal 300 k Dreiecken. Würde man die Szenenkomplexität erhöhen würde sich das Branching nocheinmal verstärken.

Übrigens ist das Fehlen von Rekursionen kein Argument. Alles was rekursiv gelöst werden kann, lässt sich auch als Schleife formulieren! Rekursionen dienen nur der einfacheren Programmierbarkeit, weil sich damit mathematische Konstrukte direkt in die Implementation übertragen lassen. Im Gegensatz zu Schleifen liefern sie sogar schlechtere Performance, eben weil dieser Stack benutzt werden muss. Es ist also einfach nur tendenziell anspruchsvoller, für (GP-)GPU zu entwickeln, aber prinzipiell geht alles.

Das Fehlen der Rekursion war auch kein Argument, sondern die Performanceeinbussen bei einer "iterativen" Implementierung von Rekursion.
Der Stack wird auch auf der CPU in Schleifen verwendet, falls die Register nicht mehr für die Temporären Variablen ausreichen. Gerade wenn du eine "Rekursion" über eine Schleife implementieren willst, welche dann meist eine Wachsende Datenmenge hat, musst du entweder auf den Heap ausweichen, oder vor der Schleife auf den Stack dir genügend Speicherplatz allokieren. Bei der GPU gibt es beides nicht in der Art, dh der benötigte vor der Schleife allokierte Speicher ist meist Registerspeicher; alternativ lokaler Speicher. Reichen die nicht mehr aus, fängt die GPU an die Register in den globalen Speicher auszulagern (Register Spilling), was Architekturbedingt viel Performance kosten kann. Das ganze ist allerdings nicht ein spezielles Problem von "iterativer" Rekursion, sondern ein allgemeines bei zu komplexen Code.

@Nai

Was du beschreibst sind voll und ganz Architektur Probleme. Und die lassen sich "problemlos" beheben.

Es sind in dem Sinn keine Architekturprobleme, sondern Architekturoptimierungen auf ShaderCode, welcher meist eine niedrige Komplexität hat, und einfache peinlich parallele Problemstellungen.
Würde man nun den Chip auf Codekomplexität trimmen, würde man gleichzeitig viel an Performance bei einfachen Code verlieren; denn jede Optimierung auf Komplexität, wie zB eine Ausführungseinheit pro Recheneinheit, Threadingfunktionalitäten, oder Speicherfunktionalitäten, kostet Chipplatz, was die Zahl der parallelen Einheiten wieder reduzieren würde. Würde man die Optimierung in der Art weiter fortsetzen, hätte man wohl eine GPU, welche das wäre was der Larabee einmal fast geworden ist: Vergleichsweise langsam beim Shaden und leichten Problemen, gut bei etwas komplexeren parallelen Berechnungen.
Ähnliche Vorkommnisse konnte man ausserdem bereits seit langem in der GPU entwicklung beobachten:
So toppte die Radeon 5870er Serie beim sehr einfachen Bit Coin Hashing, noch mehrere Generationen an zukünftigen Karten, weil sie eben einfach aufgebaut war und viele Rechenwerke hatte.
Alternativ könnte man den Fermi erwähnen, welcher für eine GPU sehr gut in Codekomplexität war, und deshalb in GPGPU anwendungen sehr beliebt war, während seine Shaderleistung für viele enttäuschend war. Der Nachfolger Kepplar, zumindest wie er in der 680er verbaut ist, hat viel mehr und einfachere Rechenwerke. Diese toppen beim Shaden aber sind bei den meisten GPGPU Problemen schlechter als der Vorgänger.

Zusammengefasst will ich damit sagen: KNC wird wohl seine Existenzberechtigung neben den heutigen GPUs bekommen.
Eventuell teilen sich letztere ja noch auf in komplexere Variante für komplexeres GPGPU und RT, welche dann KNCs Konkurrenz machen werden, während eine einfachere Variante Rasterisierung Shading und einfaches GPGPU übernimmt. Vielleicht kann man ja den Beginn bei der aktuellen NVIDIA Generation schon beobachten: die 680er GTX ist einfach und für Shading getrimmt, während der nachfolgende Kepplar wieder auf Komplexiät optimiert werden soll. Aber der Spagat eine gute GPU zu bekommen, die ebenfalls beim Rasterisieren und Shaden in Spielen top ist und beim Raytracing KNC Konkurrenz macht, wird nicht gelingen.

 

[oldmanhunting]

@Nai
Könnte stundenlang lesen, was Du da schreibst. Danke Dir für die Einblicke, die man sonst so nicht hat.

 

[ice-breaker]

Klar geht das. Die GPUs sind frei programmierbar und arbeiten wunderbar parallel. Das sind SIMD Prozessoren. Die sind für solche parallelisierten Aufgaben ausgelegt!

FPGAs sind frei programmierbar, aber nicht GPUs. Du bist bei GPUs immer noch auf die Instruktionen der GPU angewiesen und da findet nur Einzug was Nvidia oder AMD für sinnvoll erachten. Und SIMD ist keine Allheillösung, denn wenn es keine passende SIMD-Instruktion für das gibt, was du machen willst, bringt dir SIMD auch nicht.

Übrigens ist das Fehlen von Rekursionen kein Argument. [...] Im Gegensatz zu Schleifen liefern sie sogar schlechtere Performance, eben weil dieser Stack benutzt werden muss. Es ist also einfach nur tendenziell anspruchsvoller, für (GP-)GPU zu entwickeln, aber prinzipiell geht alles.

schonmal von tail-recursion gehört? Jede Plattform die sinnvoll Rekursion nutzen soll hat tail-recursion.

Genau das ist das Problem. Echtzeitrendering mit Raytracing erfordert einfach verdammt schnelle Hardware. Aber das ist ja auch nur eine Frage der Zeit, bis sich das erübrigt.

Eigentlich erfordert es massiv parallele Hardware. 100 Prozessoren mit niedriger Geschwindigkeit sind da sinnvoll als 20 Prozessoren mit höherer Geschwindigkeit. Unter der Annahme dass der Geschwindigkeitsvorteil der schnellen Prozessoren von X nicht dazu führt, dass 20 * X > 100.
Und hier tritt dann das aktuelle Problem auf, die heutige Softwareentwicklung ist kaum darauf ausgelegt massiv parallel zu entwickeln. Weil man sich die ganzen Jahre nur darum gekümmert hat, alles sequentiell schneller zu machen, oder einen Hauch von Parallelität durch SIMD zu ermöglichen. Aber gerade das massiv parallele wird die nächsten Jahre immer wichtiger. Und die Programmiersprachen müssen darauf reagieren, dabei gibt es funktionierende Modelle wie das Aktoren-Modell in Erlang schon seit 40 Jahren. Sie sind nur nie Mainstream geworden, weil sie der Zeit einfach ein halbes Jahrhundert voraus waren.

 

[Nai]

@MikelMolto
Danke, aber so besonders oder selten ist das Wissen darüber auch nicht; nur ein wenig Grundlagen über den Aufbau von Prozessoren und Graphikkarten und deren Programmierung und die daraus folgernde Interpretation von verschiedenen Benchmarks. Für den Aufbau von Prozessoren sollte Wikipedia reichen, das Wissen über die Graphikkarten stammt weitestgehend aus folgenden wenigen Dokumenten:

http://developer.download.nvidia.co.../html/OpenCL/doc/OpenCL_Programming_Guide.pdf (Am wichtigsten)

http://developer.download.nvidia.co...ml/OpenCL/doc/OpenCL_Programming_Overview.pdf

http://developer.download.nvidia.co...ml/OpenCL/doc/OpenCL_Best_Practices_Guide.pdf

Diese Guides sind (im Gegensatz zu diverser anderer Standardliteratur im OpenCL Bereich) relativ gut erklärt, hardwarenah, und ziemlich kurz gehalten , wodurch man sich diese Grundlagen, sofern man die Grundlagen der normalen Programmierung beherrscht, in kurzer Zeit aneignen kann. Ohne Programmierkenntnisse aber mit diversen Hardwarewissensgrundlagen wird es bedauerlicherweise deutlich schwerer die Guides und zu verstehen. Gerade die sich ergebenen Auswirkungen und Beschränkungen der dort beschriebenen Architektur in Bezug auf deren Programmierung sind in den Guides leider nicht explizit genannt und man wird sie ohne Programmierkenntnisse wohl auch nicht folgern können. Hier würden sich eventuell diverse OpenCL Tutorials aus dem Internet besser eignen, da man dadurch die Beschränkungen besser kennen lernt. Dennoch denke ich, sofern ich das als "Halblaie" für "Laien" überhaupt richtig beurteilen kann, dass es sich auf alle Fälle lohnt in die Guides einfach mal reinzuschauen, sofern es einen sehr interessiert.

Wenn man Nvidia nicht "mag" kann man sich alternativ auch die OpenCL GPU AMD Guides aus dem Internet heraussuchen. Diese Guides habe ich zwar nicht gelesen, aber sie sollen laut einem Bekannten, ebenfalls sehr hardwarenah und gut erklärt sein.