Archiv verlassen und diese Seite im Standarddesign anzeigen : Grafikkarte durch Rechen-Cluster ersetzbar?
mofhou
2005-12-20, 23:13:43
Hallo,
ich hatte vorhin mit einem Freund eine interessante Diskussion:
Kann ein Rechencluster (nur x86-CPUs ohne Erweiterungen wie SSE, keine Grafikkarten integriert, Rest beliebig) einen High-End Rechner (2x Dual 7800gt, Dualcore CPU etc) in Echtzeitgrafikberechnung schlagen?
Treten beim Cluster durch die höheren Latenzen nicht Probleme auf?
mfg
mofhou
StefanV
2005-12-20, 23:15:15
Theoretisch ja, aber in der Praxis sind spezialisierte Recheneinheiten immer effizienter als universelle, das dürfte in diesem Falle ähnlich sein.
Es ist aber immer alles eine Frage des Aufwandes...
mofhou
2005-12-20, 23:19:51
Theoretisch ja, aber in der Praxis sind spezialisierte Recheneinheiten immer effizienter als universelle, das dürfte in diesem Falle ähnlich sein.
Es ist aber immer alles eine Frage des Aufwandes...
Gibt es da keine Probleme aufgrund längerer Schaltwege etc?
Neomi
2005-12-20, 23:35:18
Nein, keine Chance.
1. Es entsteht ein Lag dadurch, daß die berechneten Daten wieder zusammengesammelt werden müssen. Außerdem ist der Rückkanal für das fertige Bild ein Problem. Das sind bei 1600x1200 in 32 Bit mit 60 Frames/s schon 460 MB/s, die zu einem einzigen Rechner übertragen werden müssen, den Overhead gar nicht mal berücksichtigt.
2. Die Pixelpipes kann man schlagen, indem man nur genug von den langsamen den paar wenigen schnellen einer Grafikkarte entgegenstellt. Texturfilterung usw. ist auch kein Thema, das läßt sich prima parallelisieren. Das Problem ist die Geometrieleistung. Schon bei SLI wächst sie nicht mit. Da beide Karten nicht wissen, welche Dreiecke in die für die jeweilige Karte relevanten Bereiche fallen, muß jede Karte alle Dreiecke transformieren. Genau das wird auch passieren, wenn man nur einen einzigen Pixel von einem einzelnen Rechner berechnen lassen will, er müßte alle Dreiecke transformieren. Und da kann keine CPU mit einer dedizierten Grafikkarte mithalten.
Demirug
2005-12-21, 00:19:59
Neomi, beide Probleme sind in einem Cluster lössbar.
Neomi
2005-12-21, 12:52:06
Neomi, beide Probleme sind in einem Cluster lössbar.
Theoretisch bestimmt, aber rein praktisch wird es da einige Kommunikationsprobleme zwischen den Rechnern geben. Man müßte gleich einige Rechner bereitstellen, die nur für die Berechnung der Geometrie und die Verteilung an die anderen Rechner zuständig sind. Und für Dinge wie Alphablending müssen die transformierten Dreiecke immer noch in der richtigen Reihenfolge bei jedem Rechner ankommen bzw. von ihm in die richtige Reihenfolge gebracht werden können. Bei einer 1:1-Emulation einer jetzigen GPU sehe ich da keine große Chance, zumindest nicht für Echtzeitrendering.
Demirug
2005-12-21, 13:57:11
Ich habe das Konzept dafür noch in der Schublade liegen. Es ist vollkommen konform zu einer normalen API (OpenGL/D3D) und skaliert recht gut. Echtzeitrendering ist kein Problem damit. Lediglich die Verzögerung kann zum Problem werden wenn man kein Hochgeschwindigkeitsnetzwerk hat.
Armaq
2005-12-21, 14:05:57
Ein Konzept in der Schublade liegen? Sag mal Demirug, was machst du eigentlich beruflich? Von mir aus auch per PM. Das interessiert mich ja mal brennend.
Für mich stellt sich nur die Frage wie viele Einheiten in dem Cluster wären nur für das verteilen und koordinieren zuständig?
Demirug
2005-12-21, 14:31:23
Ein Konzept in der Schublade liegen? Sag mal Demirug, was machst du eigentlich beruflich? Von mir aus auch per PM. Das interessiert mich ja mal brennend.
Vieles (manchmal zu viel)
- www.nonatainment.de
- Autor für die PCGH
- Kommunikationssoftware für Leitwartensysteme in der Industrie (Kraftwerke, Chemie, ...). Im wesentlichen den Problemkomplex der Echtezeitdatenverarbeitung aus dem Prozess.
Für mich stellt sich nur die Frage wie viele Einheiten in dem Cluster wären nur für das verteilen und koordinieren zuständig?
Bei dem System was wir entworfen (aber nicht gebaut haben) zwei oder alle. Hängt von der Sichtweise ab. Ich muß mal schauen ob ich die Grafik dafür noch habe.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.