Anmelden
?
  • Leider ist es in letzter Zeit wiederholt vorgekommen, dass Newsartikel von anderen Seiten als Ganzes im Forum gepostet wurden. Weil dies in dieser Form gegen das Urheberrecht verstößt und uns als Seite rechtliche Probleme beschert, werden wir von nun an verstärkt dagegen vorgehen und die entsprechend Benutzer verwarnen. Bitte verzichtet fortan auf das Kopieren von ganzen Newsartikeln und meldet diese über die Report-Funktion, falls euch ein entsprechender Artikel auffallen sollte. Vielen Dank!

ConsoleWAR Current Gen Konsolen und Ihre Technik dahinter

Con$olef@natic schrieb:
So soll SMS ihr PS5/X2 Konkurrent aussehen
https://twitter.com/x/status/1083557926944423936

https://www.t3.com/news/ps5-and-xbox-two-rival-mad-box-images-unmask-the-next-gen-console-killer
Klicken, um alles anzuzeigen...

Ich habe die Nachrichten diesbezüglich bisher nur überflogen.
ABER: Das Teil ist doch wohl schon von Anfang an zum Scheitern verurteilt.
Ich kapier nicht, wie man überhaupt so naiv sein kann um so ein Gerät auf den Markt schmeißen zu wollen.

Konsolen leben von
1. Günstigem Preis bei angemessener Hardware
2. Unterstützung vieler Publisher
3. Exclusivgames
4. einfache Bedienung.

Punkt 1 kann nur erfüllt werden, wenn abzusenen ist, dass eine hohe Anzahl von Geräten verkauft wird. Dann bekommt man auch die einzelnen Baugruppen zu günstigeren Preisen. Dazu kann man bei Bedarf auch noch subventionieren, denn man verdient an jedem Game, was auf der Konsole rauskommt durch Lizenzgebürhen.
Punkt 2 folgt auf Punkt 1. Denn nur wenn das Gerät ein Erfolg wird, springen auch die Publisher auf den Zug.
Punkt 3 ist selbterkärend
Punkt 4. Zwar nähern sich Konsolen den PCs immer mehr an, sind aber trotzdem noch wesentlich einfacher in der Bedienung.

Fast keinen Punkt kann eine Newcomer Konsole erfüllen, bei denen nicht ein großer Hersteller mit großem Budget und eigenen Entwicklerstudios dahinter steht.

Eine eigenständige Konsolenhardware, die speziell dafür angepasste Spiele benötigt wie bei derzeitigen Playern halte ich für völlig ausgeschlossen.
Hier würde höchstens Punkt 4 zutreffen. 1 bis 3 auf keinen Fall. Damit komplett aus dem Rennen.

Zweite Möglichkeit wäre eine zweite Steambox, also ein verkappter PC. Wie erfolgreich das Teil war, weiß man ja mittlerweile.
Das Prinzip hat nicht funktioniert, da schon prinzipbedingt der Preis viel höher war um aktuelle Konsolenleistung zu erreichen.
Punkt 3 war natürlich ebenfalls nicht vorhanden.

Nicht umsonst hat sich bisher noch nicht einmal ein Global Player dazu aufraffen können, eine weitere Konsole auf den Markt zu schmeißen, auch wenn sicherlich Google, Apple, Amazon und Co hinter den Kulissen an Konzepten dafür arbeiten.
Aber ein Noname hat da wohl kaum, ach was sage ich, definitiv keine Chance.
Oder habe ich da was übersehen?
 
Nullpointer schrieb:
Um mal ein paar Sachen, die hier oft erwähnt werden, klar zu stellen, greife ich mir mal exemplarisch eure Posts raus:


CPU:
Fast alle Spiele-Programmierer entwickeln und liefern Binärcode aus, der direkt mit der Hardware kommuniziert. Egal ob Konsole oder PC. Ausnahmen sind Skripte in Unity-Spielen oder welche die mit XNA/Monogame/Java entwickelt wurden, wo plattformunabhängiger IL-Zwischencode ausgeliefert wird, der auf der Zielplattform zur Laufzeit in Binärcode übersetzt wird.
Das funktioniert, weil x86 und x64 als Prozessor-Instructionset per Machart abwärtskompatibel sind. Deshalb laufen Spiele auf Pro und X unverändert ohne Recompile, weil sich am Instructionset der CPU nichts geändert hat. Ryzen hat ein erweitertes x64 Instructionset, was zu 99% kompatibel zu Jaguar ist. Die wenigen Unterschiede und gestrichenen Operationen betreffen hauptsächlich VM-Sachen und sollten für Spiele nicht von Belang sein. Ob das Probleme macht, wissen Sony und MS, denn die haben die binären Spielecodes ja auf ihren Servern. Für die CPU-seitige AK ist bei Konsolen genau so keine weitere Entwicklertätigkeit notwendig wie beim PC, kein Recompile etc.
Klicken, um alles anzuzeigen...

Richtig. Erst bei tiefergreifenden Änderungen im Design gibts Probleme. Z.B. bei Änderung der Prozessorbitbreite oder Wechsel zu einer komplett anderen Architektur. So laufen PC Games, die für 16bit Systeme geschrieben worden sind, heute natürlich nur noch in einem Emulator. Meine Ausführungen bezogen sich auch hauptsächlich auf die GPU und eventuell andere Komponenten (Sound, usw), die auch beim PC per Treiber angesprochen werden. Die CPU ist natürlich beim Wechseln innerhalb der Architektur kein Problem

Nullpointer schrieb:
GPU:
Im Gegensatz zu CPUs ändern die GPU-Hersteller ihre Instructionsets der GPU-Cores oft und elementar. Die GPU-Pipeline erlaubt das. Dazu kommt, dass selbst heute Shadercode immer noch um mehrere Größenordnungen weniger komplex ist als CPU-Code.
In DirectX erzeugt der Compiler aus den Shader-Mikroprogrammen hardwareunabhängigen Zwischencode. Devs können entweder diesen oder den Source ausliefern. Die eigentliche Übersetzung des Zwischencodes in hardwareabhängigen Mikrocode der GPU-Architektur erledigt dann der Treiber der GPU (ist übrigens ein deutlich weniger rechenaufwendiger Prozess als eurer normaler C-Compiler). Deshalb könnt ihr eure GPU im PC austauschen und die Spiele laufen immer noch. Das erlaubt es GPU-Herstellern auch, bei einem neuen Spiel ihre Treiber anzupassen, um optimaleren Code für ihre (neue) Hardware zu erzeugen ohne das ein Spieleentwickler selber was machen muss. OpenGL funktioniert ähnlich und nicht wesentlich anders.
Bei Konsolen können Devs mWn den Shader-Binärcode direkt erzeugen und ausliefern. Macht ja auch Sinn, denn die Hardware ist fest und man will ja genau dafür die Performance analysieren und optimieren. Bei potentiell verändertem Instructionset in Navi bedeutet das für die AK keine direkt lauffähigen GPU-Programme mehr. Ein echtes Problem stellt das mMn aber nicht dar, da hier ein Recompile des Shader-Binärcodes kein allzu komplexes Problem ist und die neue Konsolenhardware evtl. dabei entstehenden suboptimale Performance im Code schlicht durch höhere Leistung abfängt.

gpucompilerpipeline91j8g.png
Klicken, um alles anzuzeigen...

Nichts anderes habe ich geschrieben.
Und hier ist eben der Unterschied zwischen Sony und MS.
Was du schreibst (fettgedruckt) ist ja genau das, was ich sagte, Es muss neu compiliert werden. Ob nun der ganze Quellcode oder nur Shaderseitig ist im Grunde genommen wurscht. Ohne Patch würde somit kein Game auf der PS5 laufen.
Anders bei MS. Hier gibts keine Probleme, da alles über die DX Schnittstelle läuft, deren Treiber teilweise eben in Soft- und teilweise in Hardware sich befinden
Softwareseitig wird einfach der Teil, der im Betriebssystem liegt aktualisiert und in die neue GPU fließt einfach hardwaremäßig der Teil rein, der sich bereits in der X befand, nur natürlich auf die neue Hardware angepasst. Dazu wie gesagt vermutlich noch mehr DX Befehle, die dann aber natürlich nur von Games angesprochen werden könnne, die diese auch nutzen. Also neue Games oder gepatchte alte Games.
Sehe ich als riesen Vorteil bzgl. AK ggü. Sony an.
 
Konsolenbaby schrieb:
Und hier ist eben der Unterschied zwischen Sony und MS.
Was du schreibst (fettgedruckt) ist ja genau das, was ich sagte, Es muss neu compiliert werden. Ob nun der ganze Quellcode oder nur Shaderseitig ist im Grunde genommen wurscht. Ohne Patch würde somit kein Game auf der PS5 laufen.
Anders bei MS. Hier gibts keine Probleme, da alles über die DX Schnittstelle läuft, deren Treiber teilweise eben in Soft- und teilweise in Hardware sich befinden
Softwareseitig wird einfach der Teil, der im Betriebssystem liegt aktualisiert und in die neue GPU fließt einfach hardwaremäßig der Teil rein, der sich bereits in der X befand, nur natürlich auf die neue Hardware angepasst. Dazu wie gesagt vermutlich noch mehr DX Befehle, die dann aber natürlich nur von Games angesprochen werden könnne, die diese auch nutzen. Also neue Games oder gepatchte alte Games.
Sehe ich als riesen Vorteil bzgl. AK ggü. Sony an.
Klicken, um alles anzuzeigen...
Ich kenne das SDK von Sony nicht, bezweifle da aber, dass es wirklich einen Unterschied gibt. Xbox Entwickler liefern GPU-Bytecode aus, der vom offline XBox Shader Compiler erzeugt wird. Das ist der gleiche binäre Output wie bei den GPU-Treibern vom PC. Das läuft nicht auf Navi. Sony macht sicher etwas ähnliches. Beide brauchen entweder Patches oder einen Recompile zur Laufzeit. Die Patches können auch automatisiert bei Sony oder MS auf den Servern ablaufen.
Die DX-Schnittstelle als API von Ansammlungen von CPU-Funktionsaufrufen hat mit dem Instructionset der GPU erstmal wenig zu tun.
 
Nullpointer schrieb:
Ich kenne das SDK von Sony nicht, bezweifle da aber, dass es wirklich einen Unterschied gibt. Xbox Entwickler liefern GPU-Bytecode aus, der vom offline XBox Shader Compiler erzeugt wird. Das ist der gleiche binäre Output wie bei den GPU-Treibern vom PC. Das läuft nicht auf Navi. Sony macht sicher etwas ähnliches. Beide brauchen entweder Patches oder einen Recompile zur Laufzeit. Die Patches können auch automatisiert bei Sony oder MS auf den Servern ablaufen.
Die DX-Schnittstelle als API von Ansammlungen von CPU-Funktionsaufrufen hat mit dem Instructionset der GPU erstmal wenig zu tun.
Klicken, um alles anzuzeigen...

Also so wie ich das bei der Box verstanden habe läuft es folgendermaßen ab.
Entwickler nutzen die DX12 Schnittstelle wie beim PC. GPU Befehle werden somit erst mal einmal einem Treiber übergeben.
Der Treiber setzt die Befehle in solche um, die die entsprechende Hardware beherrscht.
Beim PC übernimmt das komplett der GPU-Treiber auf Softwarebasis.
Bei der Box ist dieser Treiber aber geteilt. Manches wird in Software, anderes in Hardware realisiert.
Aber es gibt eben diesen Treiber.
Bei der PS4 ist es wohl so, wie du schreibst. Schon beim Compilieren wird der Code umgewandelt, so dass er sofort ohne Treiberzwischenstufe auf der entsprechenden GPU Hardware läuft.
Vorteil: Keine Zwischenstufe und damit Performancevorteil
Nachteil: Bei auch nur kleinen Hardwareänderungen nicht mehr ohne weiteres lauffähig.

Da bei der Box es über Treiber läuft, die aber in Soft- und Hardware aufgeteilt sind, ergeben sich Performancevorteile gegenüber rein in software ausgeführte Treiber, wie es bei PC der Fall ist.
Nachteil: Durch die teilweise noch in Software vorhandenen Treiberteile, etwas performanceärmer, als wenn man bereits beim Compilieren alles so umwandelt, dass es auf der GPU läuft.
Vorteil: Man braucht bei neuer Hardware eben nicht neu compilieren, so wie auch kein PC-Game neu compiliert werden muss um auf neuer Grafikhardware zu laufen.
Die Pro und die X bestätigen indirekt diese Vorgehensweise.
Die X spielt ohne Probleme und ohne Pachte ONE Games ab, obwohl ihre GPU mehr Shader hat, neue Befehle beherrscht, höher getaktet ist und sie kein eSRAM mehr hat. Der Abstraktionslevel dürfte somit höher sein als der bei der PS4

Ich gehe jede Wette ein, dass die ONE2 AK dem der PS5 weit überlegen sein wird eben aus den oben genannten Gründen.
Vor allem braucht es 100pro bei der ONE2 keinen Patch, um ONE Games abspielen zu könnnen. Ein Patch ist natürlich möglich, um auch ältere Games von den neuen Features der ONE2 profitieren zu lassen. Aber allein durch die höhere Shaderanzahl und Taktfrequenz werden ältere Games auch so schon von der Mehrleistung profitieren.
Bei der PS5 sehe ich wie gesagt eher eine Art Emulator oder Patchorgie.
Ein Emulator wäre natürlich wesentlich ineffizienter, da viel Leistung für die Emulation flöten geht.
 
Das XBox SDK entspricht nicht 100% dem PC-SDK für DirectX12. Neben anderen unterstützten Formaten zum Beispiel beim Shader-Compiler. Der erzeugt beim PC Zwischencode, bei der XBox direkt Binärcode für die GPU.
In der Hinsicht sehe ich keinen Unterschied zwischen PS und XBox. Beide liefern GPU-spezifischen Binärcode aus.
Und was die CPU-seitigen API-Aufrufe angeht. Klar, das sind unterschiedliche APIs. Und? Ein Funktionsaufruf ist ein Funktionsaufruf. Was soll da auf XBox-Seite die AK vereinfachen?

Ich sehe nicht wirklich wo da ein Unterschied sein soll. Nur auf der Playstation gibt es "coding to the metal" ist halt ein PR-Märchen. Die größte Hürde bei AK wird für die nächste Gen vermutlich nicht technisch bedingt sein, sondern lizenzrechtlich.
 
Nullpointer schrieb:
Das XBox SDK entspricht nicht 100% dem PC-SDK für DirectX12. Neben anderen unterstützten Formaten zum Beispiel beim Shader-Compiler. Der erzeugt beim PC Zwischencode, bei der XBox direkt Binärcode für die GPU.
In der Hinsicht sehe ich keinen Unterschied zwischen PS und XBox. Beide liefern GPU-spezifischen Binärcode aus.
Und was die CPU-seitigen API-Aufrufe angeht. Klar, das sind unterschiedliche APIs. Und? Ein Funktionsaufruf ist ein Funktionsaufruf. Was soll da auf XBox-Seite die AK vereinfachen?

Ich sehe nicht wirklich wo da ein Unterschied sein soll. Nur auf der Playstation gibt es "coding to the metal" ist halt ein PR-Märchen. Die größte Hürde bei AK wird für die nächste Gen vermutlich nicht technisch bedingt sein, sondern lizenzrechtlich.
Klicken, um alles anzuzeigen...

Wenn bei der Box der Compiler direkt GPU Code erzeugen würde, dann wüsste ich nicht, warum in der ONE GPU extra DX Treiberbefehle direkt in Hardware vergossen sind. Das wäre ja völlig unnötig. Aber genau das ist der Fall und als Begründung eben, dass die Ausführung somit schneller ist als komplett über Softwaretreiber.

Was die CPU angeht. Wo habe ich denn da was über AK Probleme gesagt?
 
Montalaar schrieb:
This, manche Lizenzen laufen ja schon innerhalb der Gen aus und das wird wohl nicht besser in Zukunft.
Klicken, um alles anzuzeigen...

Es lässt sich aber nicht verbieten, dass eine Software auf eine neuen Maschine läuft, wenn die Software selber hier nicht verändert wird. Schließlich laufen auch alle PS2 Games noch auf der Ur-PS3, da hier eben die gesamte PS2 Hardware mitverbaut wurde. Die Games laufen ja plötzlich nicht mehr, nur weil eine Lizenz ausläuft. Anders beim Verändern des Gamecodes oder einer Neucompilierung, wie es z.B. bei den 360 Games erfolgt. Hier wird ja der Gamecode einem Reverse Engineering unterzogen und neu compiliert. Der eigentliche Quelltext wird aber nicht angerührt. Trotzdem braucht es dafür die Zustimmung des Entwicklers.

Wenn also PS4 und ONE Games ohne Veränderung auf den Nachfolgekonsolen laufen sollten, sehe ich da kein Lizenzproblem.
 
Konsolenbaby schrieb:
Wenn bei der Box der Compiler direkt GPU Code erzeugen würde, dann wüsste ich nicht, warum in der ONE GPU extra DX Treiberbefehle direkt in Hardware vergossen sind. Das wäre ja völlig unnötig. Aber genau das ist der Fall und als Begründung eben, dass die Ausführung somit schneller ist als komplett über Softwaretreiber.

Was die CPU angeht. Wo habe ich denn da was über AK Probleme gesagt?
Klicken, um alles anzuzeigen...
Der Shader-Compiler erzeugt den Code der Shader-Mikroprogramme, der auf der GPU ausgeführt wird.
DirectX ist als API hauptsächlich eine Sammlung von CPU-Funktionsaufrufen.

Wenn nun einzelne DirectX-Funktionen intern durch Hardware unterstützt werden, merkt der Entwickler des Usercode davon nichts oder weiß es nicht einmal. Es ist also für AK auch kein Recompile oder Patch des Usercodes notwendig.
Konsolenbaby schrieb:
Es lässt sich aber nicht verbieten, dass eine Software auf eine neuen Maschine läuft, wenn die Software selber hier nicht verändert wird.
Klicken, um alles anzuzeigen...
Das ist eine extrem mutige Aussage, wo du doch den Lizenztext gar nicht kennst.
Es würde ja schon reichen, eine Änderung der Software nicht zu erlauben. Dann kann MS/Sony z.B. keinen Recompile des GPU-Codes machen.
 
Zuletzt bearbeitet:
@Konsolenbaby
Sie werden ohne Neulizenzierung zumindest aus den "Läden" verschwinden, also nicht mehr als Neukauf zugänglich sein, auch wenn es Hardwarebezogen keine Probleme geben würde. Wie z.B. Alan Wake, oder auch schon FH2, weil Musiktitel, oder Fahrzeuglizenzen verfallen sind.
Wie es mit nativ auf der HW laufender AK rein rechtlich aussieht weiss ich nicht. aber wie früher "einfach" die alte Konsole in HW vorlag und gedeckelt war, könnte man evtl auch mit einer SoftwareOne/PS4 als Umgebung für AK-Titel arbeiten wo diese darin ohne Änderungen laufen können und rechtlich sicher sind.
Aber wie gesagt, kenne da die Fallstricke nicht.
 
Nullpointer schrieb:
Der Shader-Compiler erzeugt den Code der Shader-Mikroprogramme, der auf der GPU ausgeführt wird.
DirectX ist als API hauptsächlich eine Sammlung von CPU-Funktionsaufrufen.
Klicken, um alles anzuzeigen...

Nur wird bei DX ja mit der HLSL (High-Level-Shading-Language) gearbeitet. Und die damit programmierten Shader werden erst beim Start des Spiels in Maschinencode umgewandelt. Der Treiber ist hier von entscheidener Bedeutung, denn nach ihm richtet sich die Art und Weise dieser Compilierung.
So funktioniert es jedenfalls beim PC.
Und da die Box auch DX nutzt, wird es ähnlich laufen.
Es ist also egal, ob sich die Hardware der Box ändert. Die Shader werden einfach unter den neuen Treibern dann in die für die neue Hardware lesbare Form compiliert. Ich denke nicht, dass bei der PS4 auch erst zur Laufzeit die Shader compiliert werden und somit gibts eben mehr oder weniger Probleme bei der Änderung der Hardware.

Nullpointer schrieb:
Wenn nun einzelne DirectX-Funktionen intern durch Hardware unterstützt werden, merkt der Entwickler des Usercode davon nichts oder weiß es nicht einmal. Es ist also für AK auch kein Recompile oder Patch des Usercodes notwendig.
Klicken, um alles anzuzeigen...
Ja was denn nun?
Keine AK ohne Patch oder nun doch nicht?
Die Unterstützung in Hardware ist ja nur für die Geschwindigkeitsoptimierung nicht für die AK. Es könnten auch wie beim PC alle Treiberfunktionen in Software realsiert sein. Aber das kostet natürlich ein Quentchen Performance.


Nullpointer schrieb:
Das ist eine extrem mutige Aussage, wo du doch den Lizenztext gar nicht kennst.
Es würde ja schon reichen, eine Änderung der Software nicht zu erlauben. Dann kann MS/Sony z.B. keinen Recompile des GPU-Codes machen.
Klicken, um alles anzuzeigen...
Ich sagte doch, dass die Sofware nicht verändert werden darf bzw. auch kein Reverse Engineering mit anschließender Neu-Compilierung. Dafür braucht und brauchte man schon immer das OK des Entwicklers.
Aber bei der ONE2 wird eben kein Recompilieren oder Patchen notwendig sein um ONE Games auf ihr laufen zu lassen.

However, potentially the most exciting aspect surrounding the CPU revamp doesn't actually relate to the processor blocks at all, but rather to the GPU command processor - the piece of hardware that receives instructions from the CPU, piping them through to the graphics core.

"We essentially moved Direct3D 12," says Goossen. "We built that into the command processor of the GPU and what that means is that, for all the high frequency API invocations that the games do, they'll all natively implemented in the logic of the command processor - and what this means is that our communication from the game to the GPU is super-efficient."

Processing draw calls - effectively telling the graphics hardware what to draw - is one of the most important tasks the CPU carries out. It can suck up a lot of processor resources, a pipeline that traditionally takes thousands - perhaps hundreds of thousands - of CPU instructions. With Scorpio's hardware offload, any draw call can be executed with just 11 instructions, and just nine for a state change.

"It's a massive win for us and for the developers who've adopted D3D12 on Xbox, they've told us they've been able to cut their CPU rendering overhead by half, which is pretty amazing because now the driver portion of that is such a tiny fraction," adds Goossen.

[UPDATE 7/4/17 20:44: Microsoft's Andrew Goossen has been in touch to clarify that D3D12 support at the hardware level is actually a part of the existing Xbox One and Xbox One S too. "Scorpio builds on the Command Processor capability present in the original Xbox One," we're told. "Our implementation of D3D12 supports all Xbox Ones, and games have already shipped that use it. When a game using D3D12 starts up, we reprogram the GPU's Command Processor front-end. The 50 per cent CPU rendering overhead improvement was reported by shipping games. The amount of win is dependent on the game engine and content, and not all games will see that size of improvement. Scorpio's Command Processor provides additional capability and programmability beyond what Xbox One/Xbox One S can do. We plan to take advantage of this in the future."]
 
Zuletzt bearbeitet:
Con$olef@natic schrieb:
Die AMD "Next Gen" Architektur, wird wohl sehr interessant.

https://www.resetera.com/threads/ne...uces-spicing-2019.91830/page-75#post-17096891

Vielleicht was für die Next Gen Upgrades um nach 3 Jahren nochmal gut Leistung raus zu holen.
Klicken, um alles anzuzeigen...
Erst mal abwarten, was denn genau in die Next-Gen einfließen wird.
Bisher war es eigentlich immer so, dass die Konsolen die ersten Profiteure neuer Architekturen waren. PC Karten erschienen erst einige Monate später
Da Navi wohl schon dieses Jahr für PC Karten rauskommt müssten die Next-Gen Konsolen somit auf einen Nachfolger aufbauen. Auch wenn gerüchteweise Navi eigentlich für die PS5 entwickelt wurde. Es sei denn, die PS5 erscheint noch vor der diesjährigen E3, wenn Navi-Grafikkarten wohl angekündigt werden :)
 
PS4 und ONE bassierten doch auf ca. 1Jahre alten Karten (Pitcairn) oder? PS4 hatte selbe ROPs und mehr ACE wie in der Folge Generation.
So hab ich es jetzt gerade im Kopf.

Edit:

Ja die GPUs kamen anfang 2012 also soger mehr als 1 Jahr vor den Konsolen ;) würde also Perfekt mit Navi Passen.
 
Zuletzt bearbeitet:
kerv schrieb:
Altes Thema, hier schon durchgekaut.
Aber um auf deine Frage zu antworten: Etwas ähnlich starkes verbauen.
Klicken, um alles anzuzeigen...


Es handelt sich hier um einen Octacore-Prozessor auf Basis der CPU-Architektur Zen+- oder Zen-2.
AMD scheint auf seine neue Navi-Bauweise zu setzen.
​

Echt das wusste man schon?
Zen2 wäre mir neu, jetzt verdichten sich die Infos.
 
Du musst dich anmelden oder registrieren, um zu antworten.
Zurück
Top Bottom