Foren Aktuelles Erstellen Mitglieder Anmelden

PC Google Stadia

  • Ersteller Ersteller Gelöschte Mitglieder 617
  • Erstellt am Erstellt am

Benutzer, welche sich diesen Thread anschauen:

Das was sie heute auch schon (wahrscheinlich) mit der alten Hardware machen - decommission. Ich glaube Du hast keine Vorstellung was bei den Public Cloud Betreibern täglich an Hardware geschoben wird. Sie müssen auch die Balance zwischen der Power Consumption halte. Und wenn neue Hardware pro Board ein Watt sparrt, wird das sogar ziemlich schnell ausgetauscht.

Bzgl. Power Consumption hast du sicherlich Recht, aber wo liegt der Vorteil für Google nach einen Jahr ein 12,5 TFlop Stadia nachzuschieben?
Die werden schon aufrüsten aber halt auch erst nach 3-4 Jahren.
 
So wie PC Entwickler bekanntlich für jede einzelne PC Konfiguration der Welt entwickeln müssen?

@Cycron ich antworte dir heute abend ausführlich, wenn ich am PC bin, wie das nach meinem Kenntnisstand in RZ-Umgebungen aussieht. Ist zu mühsam auf dem Handy zu tippen.

Mach dir kein stress.
Bin aber jedenfalls gespannt auf deine Antwort.

Denn Eigentlich kann ich mir nicht vorstellen, dass Videospiele ähnlich parallelisiert - (über theoretisch unendlich vielen Instanzen laufen und jede Instanz gleichzeitig sogar gleich mehrere Anwendungen anteilig berechnen lassen kann) - wie andere Anwendungen die typischerweise über Rechenzentren parallelisiert laufen. Das kann ich mir für Videospiele nicht vorstellen. Sprich dass der Videospiel Code fließend je nach Auslastung anteilig über abweichend viele Instanzen berechnet wird.


Meiner Meinung nach gilt das nur für ganz spezifische Anwendungen. Sprich für Anwendungen die sich von ihrer Natur her gut parallelisieren lassen. Aber doch nicht für Videospiele. Instanz XYZ-a kümmert sich ums shading und die texturierung von Objekt XYZ und holt sich die Daten von der Instanz XYZ-b, eine weitere Instanz XYZ-c kümmert sich um die KI und synchronisiert seine Ergebnisse mit Instanz XYZ-d welche sich zusätzlich wiederum um die physik für Objek XYZ kümmert und diese wiederum mit Instanz XYZ-e abgleicht. Nee... so funktioniert das nicht.

Nee das sind geschlossene feste Instanzen für die Grafikberechnung. Man wird höchstens ne zweite Instanz für Aufgaben hinzuschalten können die sich für Parallelisierung eignet. Zum Beispiel Physikberechnungen von Wasser. diese Instanz kann aber für mehrere Spiele gleichzeitig diese form der Berechnung anfertigen. Aber die Grafikberechnung und alles andere das zusammengehörig und wichtig für die Spielanwendung ist wird in geschlossenen festen Instanzen laufen. Nicht für Programme die aus unzähligen mit einander verbundenen und miteinander agierenden Elementen bestehen und zudem auch noch in nahe zu Realtime berechnet werden müssen. Das ganze zu Synchronisieren und vernünftig flexible in einen Code zu programmieren wäre reine Hexerei.


Nicht umsonst wurde die zweite Instanz in der Demo auf der Stadia PK nur für eine reine Physikberechnung hinzugeschaltet. Exakt deswegen, weil der Großteil typischer Videospiel Berechnungen sich sehr schlecht für Parallelisierung eignen. @New Horizon hat schon recht, wenn er sagt "Dass sind hautpsächlich Konsolen/PC/SDK in einem Serverrack"
 
Zuletzt bearbeitet von einem Moderator:
Bzgl. Power Consumption hast du sicherlich Recht, aber wo liegt der Vorteil für Google nach einen Jahr ein 12,5 TFlop Stadia nachzuschieben?
Die werden schon aufrüsten aber halt auch erst nach 3-4 Jahren.
Habe ich doch geschrieben, wenn die verbaute Hardware bei entweder gleicher Leistung, weniger verbraucht ggfs bei mehr Leistung und weniger verbrauch, erst recht.
Und Du gehst vom der Tatsache aus, das die Hardware exklusiv für Stadia reserviert wird - aber sorry, so funktioniert keine Cloud. Wenn da es keinen bedarf für Stadia Workload gibt, stehen die Hardware Ressourcen über die Automatisierung Sicht für andere Workloads zur Verfügung.
 
Wäre nicht der erste Flop, den Google produziert hätte ;)

Sind da glaube ich auch relativ schmerzlos. Was haben sie denn zu verlieren. Die Investition dürften sich in Grenzen halten.

Sicherlich, aber hier steckt halt schon ne Menge von dem drin, was Googles Kernkompetenz ausmacht. Mir würde jetzt auch hardwaremäßiges Einfallen, was technisch völlig unausgegoren gewesen wäre und zudem in dem großen Stil angekündigt wurde, aber ich mag da auch Dinge vergessen haben. Ich finds reichlich amüsant, wie hier wirklich alles angezweifelt wird. Ich bin ja nicht der Meinung, dass das alles 100%ig sitzen wird, aber was hier teilweise zu lesen ist, schreit einfach himmelhoch nach Internet-Experten, dass könnte man schon als Beispiel in den Duden knallen.

Edit: Ich will damit nicht sagen, dass da nicht ein paar interessante und mutmaßliche Kritikpunkte geäußert werden. Ich gehe nur davon aus, dass das Themen sind, die auch Google geläufig sind. Inwiefern die alle adressiert und/oder als Probleme behoben werden, muss sich zeigen. Aber wenn man der Presse glauben mag, habe sie ein durchaus gutes Produkt in der Hinterhand. Vielleicht für den Hardcore-Techie nicht ausreichend, aber auf den als Zielgruppe komme es am Ende nicht zwingend an.
 
Zuletzt bearbeitet von einem Moderator:
Wäre nicht der erste Flop, den Google produziert hätte ;)

Sind da glaube ich auch relativ schmerzlos. Was haben sie denn zu verlieren. Die Investition dürften sich in Grenzen halten.


Da wird nix Floppen.
Die planen ja auch nicht ab Launch den Markt zu Dominieren. Cloud-Gaming ist ein langzeit Investment, man legt so zusagen heute das Fundament für die Zukunft. Das ganze wird ganz organisch Jahr für Jahr wachsen. Hier wird massiv in eine Technologie Investiert die heute ausreichend akzeptable funktioniert. Und man wird Experten an Board haben die Prognosen Entwickelt haben wohin die Reise geht. Wie man durch neue Technik die Latenzen und die Qualität Jahr für Jahr weiter optimieren kann, durch schnellere Hardware fürs codieren des Streams (die für eine Verkürzung der Latenz sorgen wird) und durch in der Zukunft verbesserter Internetanbindungen welche für einen immer besseren Ping sorgen werden (welche wiederum für eine Verkürzung der Latenz sorgen werden) und durchs ausbauen von neuen Standorten die wiederum für eine bessere Latenz sorgen werden. Das sind langzeit Investments.

Das funktioniert heute ausreichend akzeptabel aber noch nicht perfekt, wird aber mit den Jahren immer besser.

Da wird Garantiert nix Floppen.
 
. Exakt deswegen, weil der Großteil typischer Videospiel Berechnungen sich sehr schlecht für Parallelisierung eignen.
Das muss ich mal schnell rausgreifen, weil es - sorry - absoluter Blödsinn ist.
Ein Großteil der Berechnungen bei Videospielen insbesondere in der Renderpipeline sind lange Vektor- und Matrizenberechnungen, die voneinander unabhängig sind. Daher sind Videospiele Anwendungen mit exzellenter Parallelisierbarkeit.
Das ist ja auch der Grund, wieso GPUs hunderte Rechenwerke (z. B. CUDA Cores) haben. Eben genau um das Potenzial in Sachen Parallelisierbarkeit auszunutzen.
 
Das muss ich mal schnell rausgreifen, weil es - sorry - absoluter Blödsinn ist.
Ein Großteil der Berechnungen bei Videospielen insbesondere in der Renderpipeline sind lange Vektor- und Matrizenberechnungen, die voneinander unabhängig sind. Daher sind Videospiele Anwendungen mit exzellenter Parallelisierbarkeit.
Das ist ja auch der Grund, wieso GPUs hunderte Rechenwerke (z. B. CUDA Cores) haben. Eben genau um das Potenzial in Sachen Parallelisierbarkeit auszunutzen.


Diese kommunizieren aber alle untereinander auf dem selben Motherboard (SDK) oder besser gesagt dem selbem Die (SoC). Die performance durch mehrere von einander getrennte GPU's nimmt selbst in einem gemeinsamen SDK bei Videopspielanwendungen rapide ab, weil es hier eben keine schnelle und direkte Kommunikation untereinander wie in einem Speziell dafür angefertigten Chip gibt (sprich mehrere CUDA Cores oder Compute Units) und Videospielanwendungen eignen sich eben nicht perfekt für Parallelisierungen (nicht in der benötigten Echtzeit). Da wird auch Infinity Fabric nicht viel nach helfen können.

Und du meinst jetzt sogar noch, dass all diese GPU's noch über getrennte SDK's übers Netzwerk miteinander arbeiten sollen. Nee, einfach nee
 
Zuletzt bearbeitet von einem Moderator:
Dann noch mal ein schneller Zwischeneinwurf vom Handy: wenn das alles so unmöglich ist, wie erklärst du dir dann Multi-GPU Setups mit 2-4 Grafikkarten in einem Rig, die sich die Berechnungen aufteilen?
Wie erklärst du dir den neuen Mac Pro, der explizit Infinity Fabric für die Kommunikation zwischen den GPUs nutzt?
Wie erklärst du dir externe GPUs, die über Thunderbolt an einen PC anschließbar sind? Die Übertragungsrate von Thunderbolt 3 ist immer noch ein Witz gegenüber den Bussystemen in einem RZ.

Und nochmal: der Grund für die Compute Units ist exakt die superbe Parallelisierbarkeit von Renderanwendungen.

Und zum Schluss: Löst euch von dem Gedanken, dass ein Rechenzentrum einfach nur viele PCs sind, die in einer Lagerhalle stehen. Das ist anders und viel komplexer.
 
Zuletzt bearbeitet:
Dann noch mal ein schneller Zwischeneinwurf vom Handy: wenn das alles so unmöglich ist, wie erklärst du dir dann Multi-GPU Setups mit 2-4 Grafikkarten in einem Rig, die sich die Berechnungen aufteilen?
Wie erklärst du dir den neuen Mac Pro, der explizit Infinity Fabric für die Kommunikation zwischen den GPUs nutzt?
Wie erklärst du dir externe GPUs, die über Thunderbolt an einen PC anschließbar sind? Die Übertragungsrate von Thunderbolt 3 ist immer noch ein Witz gegenüber den Bussystemen in einem RZ.

Und nochmal: der Grund für die Computer Units ist exakt die superbe Parallelisierbarkeit von Renderanwendungen.

Und zum Schluss: Löst euch von dem Gedanken, dass ein Rechenzentrum einfach nur viele PCs sind, die in einer Lagerhalle stehen. Das ist anders und viel komplexer.

Du kennst also die vor und nachteile von Multi-GPU Setups nicht?
Zwei GPU's im System kosten dich zwar das doppelte an Geld, aber bringen dir nicht die doppelte Leistung. Aus zwei Stadia Instanzen mit 10,7 TFlops GPU's wird nicht plötzlich eine 21,4 TFlop GPU (wahnsinnige Ressourcen Verschwendung). Für Videospielberechnungen brauchst du einfach ultra kurze Latenzen und möglichst direkte Kommunikation. Schließlich soll hier kein 2 Stunden Film in 1 Woche gerendert werden sondern eine Spielanwendung mit 60 Bildern die Sekunde in nahezu Echtzeit berechnet werden. Da macht es einfach einen wahnsinnigen Unterschied ob die CUDA Cores oder Compute Units im selben ultra schnellen Chip sitzen oder verteilt auf verschiedenen SDK's sitzen und man erstmal lange Umwege über eine Landstraße nehmen muss.

Das sollte dir doch aber klar sein.


Edit: Sorry Blödsinn ist tatsächlich das was du gerade hier von dir gibst.
 
Ja das ist mir natürlich klar und ich weiß auch um die Leistungsabnahme bei Multi GPU Setups.

Aber momentan dazu nur: RZ und PC sind 2 paar Schuhe.

Nachher mehr :D
 
Du kennst also die vor und nachteile von Multi-GPU Setups nicht?
Zwei GPU's im System kosten dich zwar das doppelte an Geld, aber bringen dir nicht die doppelte Leistung. Aus zwei Stadia Instanzen mit 10,7 TFlops GPU's wird nicht plötzlich eine 21,4 TFlop GPU (wahnsinnige Ressourcen Verschwendung). Für Videospielberechnungen brauchst du einfach ultra kurze Latenzen und möglichst direkte Kommunikation. Schließlich soll hier kein 2 Stunden Film in 1 Woche gerendert werden sondern eine Spielanwendung mit 60 Bildern die Sekunde in nahezu Echtzeit berechnet werden. Da macht es einfach einen wahnsinnigen Unterschied ob die CUDA Cores oder Compute Units im selben ultra schnellen Chip sitzen oder verteilt auf verschiedenen SDK's sitzen und man erstmal lange Umwege über eine Landstraße nehmen muss.

Das sollte dir doch aber klar sein.

Zwei GPUs bringen auch im Heimgebrauch ca. 170% Performance in Videospielen (bei gleichbleibender restlicher Hardware). Vergleich einfach mal Benchmarks von Grafikkarten im SLI-Mode. Das ist praktisch doppelte Leistung.
 
Ja das ist mir natürlich klar und ich weiß auch um die Leistungsabnahme bei Multi GPU Setups.

Aber momentan dazu nur: RZ und PC sind 2 paar Schuhe.

Nachher mehr :D


Gerne. Vielleicht ist das ja tatsächlich etwas was ich so in meiner Ignoranten Haltung einfach noch nicht begreife.
Lass mich da gerne eines besseren belehren.
 
Zwei GPUs bringen auch im Heimgebrauch ca. 170% Performance in Videospielen (bei gleichbleibender restlicher Hardware). Vergleich einfach mal Benchmarks von Grafikkarten im SLI-Mode. Das ist praktisch doppelte Leistung.

+ @el_barto


Hab mir gerade nochmal ein paar NVLink Benchmarks rein gezogen (hätte ich lieber vorher machen sollen bevor ich das Mowl aufreiße). Es sind sogar teilweise bis zu 180% und die meisten Spiele sind nicht mal super aufwändig für Multi GPU's optimiert. Mit Infinity Fabric dürfte das wohl ähnlich gut klappen. Ihr hattet absolut recht und ich hab mein ahnungsloses Mowl mal wieder zuweit aufgerissen. :fp:

Skeptisch bleibe ich aber weiterhin bei Workflow Aufteilungen auf mehrere GPU's die eben nicht über den selben SDK verbunden sind. Das ein Rack über meterlange Thunderbold Schnittstellen mit einem anderem Rack in vernünftigen Latenzen für Echtzeit Grafikberechnungen miteinander kommunizieren kann - Kann und will ich erstmal nicht glauben.

Edit: Ach man... Glasfaser. :fp:
 
@el_barto also mir brauchst es es zumindest nicht mehr erklären.

Ich bin jetzt tatsächlich ein Believer

Edit: Hätte ich mal nicht meine klappe aufgerissen.
 
Zuletzt bearbeitet von einem Moderator:
Wer mal wirklich tief einsteigen möchte :
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.


Gerade die ersten 7min sind super spannend, wie schnell das alles wächst. Und das ist bei AWS und Google genau so. So einen Scale bekommt man mit 08/15 Hardware nicht hin.
 
Zuletzt bearbeitet:
Zurück
Oben