Cebit 2011: Cloud-Raytracing mit vier Knights-Ferry-Karten in Aktion
Auf der Cebit brachte uns Intels Raytracing-Forscher Daniel Pohl auf den aktuellen Stand in Sachen Cloud-Raytracing, Neu hierbei war, dass vier Knights-Ferry-Karten in einem Host-System gleichzeitig arbeiteten, während zuvor noch vier einzelne Rechner dafür nötig waren.
Quelle: PC Games Hardware
Daniel Pohl (Intel) zeigt auf der Cebit 2011 Cloud-basiertes Raytracing mithilfe einer Workstation und vier Knights-Ferry-Karten.
Intel setzt offenbar weiterhin große Hoffnungen in die Raytracing-Technik und so sind wenig überraschend weitere Fortschritte auf diesem Gebiet der Grafikdarstellung zu vermelden. Bereits kurz vor der Cebit gab es einige neue Details zum Cloud-basierten Raytracing und auf der Hannover-Messe stellte die Intel-Forschung nun ein System vor, bei dem innerhalb eines Workstation-Gehäuses vier Knights-Ferry-Karten mit Intels Many-Integrated-Core-Architektur (MIC) zusammenarbeiten.
Nach wie vor werde die von herkömmlichen Multi-GPU-Systemen bekannte AFR-Technik genutzt, um einen möglichst großen Performance-Gewinn zu erzielen. Dabei arbeiten die Karten reihum an jeweils einem eigenen BIld, welches dann in die Renderreihenfolge eingefügt wird. Da es sich um eine Technik-Demo handelt, ist die kritische Latenz, also die Zeit, welche von der Eingabe eines Befehls bis zu dessen Ausführung via BIldschirmaktualisierung vergeht, nicht so entscheidend. In echten, zum Spieleeinsatz bestimmten Produkten sei die Aufteilung in Kacheln, das sogenannte Tile-Based-Rendering, sinnvoller und bei Intel ist man der Meinung, dass mit entsprechender Optimierung eine Leistung im Bereich von 90% der AFR-Performance erreichbar ist. Das sei aber lediglich eine Schätzung und noch nicht durch entsprechende Implementierung gestützt.
Auf die Frage, ob der Videodatenstrom von der Übertragung her ein Flaschenhals sei, konnte Daniel Pohl Entwarnung geben. Nicht einmal die Bandbreite des herkömmlichen PCI-Express sei am Limit, sodass eine deutliche Steigerung durch einen möglichen Umstieg auf PCI-Express 3.0 nicht zu erwarten sei. Wäre die Übertragungsrate zur Host-CPU ein gravierendes Problem, so Pohl weiter, könne man zunächst die Umwandlung in einen DXT1-komprimierten Datenstrom ebenfalls auf die Knights-Ferry-Karten verlagern.
Der gezeigte Rechner mit den vier Knights-Ferry-Karten war, wie es sich für eine Workstation gehört, stark durchlüftet, die Abluft aus den Slotblenden der Karten jedoch trotzdem ziemlich warm. Über die Details wurde geschwiegen, aktuelle Modelle der Knights-Ferry-Entwicklerkarten verfügen jedoch mit DVI und HDMI über konventionelle Displayausgänge neben einem Port unbekannter Art. Zur Erinnering: Eine Knighs-Ferry-Karte beherbergt neben dem lokalen Speicher einen Prozessor mit 32 skalaren x86-Kernen, die jeweils an eine SIMD--Einheit mit einer Instruktionsbreite von 16 gekoppelt sind. Die Prozessoren laufen in der aktuellen Knights-Ferry-Ausführung mit 1,2 GHz. Kommende, in 22-nm-Technik hergestellte Versionen, die den Codenamen Knights Corner tragen, sollen über 50 und mehr dieser Kerne verfügen.
Wir vermuten, dass auch bereits externe Entwickler über Raytracing-Beschleuniger des Typs Knights Ferry verfügen, zumal dieser besonders für Programmierer interessant sein dürfte, die ihre Spiele wirklich über Cloud-basierte Systeme ausliefern wollen. Diese müssten nämlich nicht auf das Vorhandensein einer hoch leistungsfähigen Hardware Rücksicht nehmen, sondern könnten die benötigte Rechenleistung direkt im Rechenzentrum bereitstellen.
Zu guter Letzt zeigte uns Daniel Pohl noch eine der Stärken des Raytracings in Aktion in der von ihm entwickelten Engine: Korrekte und dabei hochdetaillierte Spiegelungen, welche bei traditioneller Rasterisierungsgrafik üblicherweise über Cube-Mapping verwirklicht wird und dabei an der verwendeten Texturauflösung krankt.Diese ist bei Raytracing kein Limit.
Ich vermute mal, dass er damit die Knights-Ferry-Karten meinte. Sind natürlich deutlich platzsparender als große Cluster und vermutlich auch flexibler in der Programmierung als GPGPUs (Tesla etc.).
Der Rest klingt tatsächlich ziemlich wüst. Da wurde alles in einen Topf geworfen und mal kräftig drin gerührt. ^^ Aber natürlich ließen sich Raytracer und Rasteizer kombinieren. Man tract dann alle reflektierenden/brechenden Objekte (die man per space-partitioning Struktur z.B. kd-Tree ggf. schnell verwerfen kann) und rastert den rest. Die grobe Skizze sollte jedenfalls einfach umsetzbar sein (erst recht wo sich das durch DirectCompute leicht mit D3D verknüpfen ließe) aber im Detail mag's da durchaus einige Fallstricke geben, die Probleme bereiten könnten.
Daher ergibt Larabee für mich keinen Sinn...
In diesen Ausmaßen ist Raytracing wirklich Müll. Sieht ganz gut aus, verschlingt aber Leistung zum Frühstück. Warum nicht in Verbindung mit anderen Techniken? Spiegelungen und Lichtbrechungen über Raytracing, Spektralberchung über Post-Processing (wie in Crysis halt auch schon...), Schatten über Stencils oder Shadow Maps, volumetrische Effekte und globale Beleuchtung einfach drüberrastern oder Rauch per Voxels. Die Geometrie wird zu 100% gerastert und schon ist Anti-Aliasing kein Problem mehr. Das Programm müsste eben Wissen, wo es zu rastern und wo zu raytracen hat, aber das hat Nvidia ja auch schon geschafft. Das würde wohl genauso gut aussehen und nicht so abnorm viel Leistung schlucken...
Ich bin gespannt, wie du die Hardware auf diese """eine""" Aufgabe optimieren willst - und wie lange die Berechnung des wie&wo dauern soll. Um zu wissen, welches Pixel auf einer spiegelnden oder brechenden Fläche landet, musst du wohl oder übel erstmal jedes einzelne Pixel traycen. Dann willst du ausgerechnet die Raytracer-Vorzeigebeispiele aufwendige Brechung und Beleuchtung über konventionelle Verfahren machen (d.h. die gesamte Geometrie, einschließlich der spiegelnden Flächen)? Und zu guter letzt willst du getraycte nochmal für AA rastern?
Klingt irgendwie weder so effizient wie ein Rasterizer noch so einfach wie ein Raytraycer...
Voxel sind übrigens kein Verfahren zum rendern, sondern zur Geometriedarstellung - man kann Voxel rastern oder traycen (letzteres ist afaik deutlich sinnvoller), wie man Polygone rastern und traycen kann.
Zur Beschleunigung von Offline-Renderern mögen diese Larabee-Abkömmlinge natürlich durchaus sinnvoll sein.
Daher ergibt Larabee für mich keinen Sinn...
In diesen Ausmaßen ist Raytracing wirklich Müll. Sieht ganz gut aus, verschlingt aber Leistung zum Frühstück. Warum nicht in Verbindung mit anderen Techniken? Spiegelungen und Lichtbrechungen über Raytracing, Spektralberchung über Post-Processing (wie in Crysis halt auch schon...), Schatten über Stencils oder Shadow Maps, volumetrische Effekte und globale Beleuchtung einfach drüberrastern oder Rauch per Voxels. Die Geometrie wird zu 100% gerastert und schon ist Anti-Aliasing kein Problem mehr. Das Programm müsste eben Wissen, wo es zu rastern und wo zu raytracen hat, aber das hat Nvidia ja auch schon geschafft. Das würde wohl genauso gut aussehen und nicht so abnorm viel Leistung schlucken...
Zur Beschleunigung von Offline-Renderern mögen diese Larabee-Abkömmlinge natürlich durchaus sinnvoll sein.
allerdings ist Raytracing wirklich nix tolles, wenn man nicht das Maximum an Effekten aus dem Ärmel zaubert. Die Lichtbrechungen sehen zwar im Vergleich zu rasterisierten Games ganz schick aus, aber ohne Spektralbrechung (was immerhin auch Crysis schon RICHTIG gut immitiert hat) sind die Dinger wirklich nicht so toll. Auch Kaustiken wären nett, aber davon sieht man auch nichts. Auch von Volumetrischen Schatten bzw. Licht ist nichts zu sehen, was bei Raytracing auch verdammt natürlich rüber kommt.
Aber das alles ist für aktuelle Hardware eben Overkill. Ich bin froh darüber, dass für Offline-Renderings mitlerweile auch die GPU zur Rate gezogen werden kann, die Raytracing massiv beschleunigt. Von Echtzeit kann aber unter keinen Umständen die Rede sein...