G
Gast20141208
Guest
Kann das über DX laufen?
Und ändere bitte das mit der PS3, sonst ist das wieder ein gefundenes Fressen für manche.
Xbox One versus Playstation 4: Entwickler sieht Leistungsunterschied schwinden
- Ersteller PCGH-Redaktion
- Erstellt am
Und ändere bitte das mit der PS3, sonst ist das wieder ein gefundenes Fressen für manche.
cl55amg
BIOS-Overclocker(in)
Kann das über DX laufen?
Und ändere bitte das mit der PS3, sonst ist das wieder ein gefundenes Fressen für manche.
Danke ^^
Man kann vieles über eine API abstrahieren (dafür sind sie ja da), um den Zugriff auf bestimmte Hardware Funktionen zu vereinfachen.
Aber eine API kann nicht leisten, dass jede komplexe Folge von Berechnungen immer möglichst effizient für die Hardware "übersetzt" wird. Wobei dafür nicht nur die API verantwortlich ist, die GPU/CPU selbst hat dafür eine Logik.
Hier kommt dann spezifische Optimierungen ins Spiel, die dann dafür sorgen das die Instruktionen und Operanden die wahrscheinlich bald gebraucht werden, schon vorab im Cache stehen und dann schnell den Rechenwerken zur Verfügung stehen. (Caching) Das kann eine API alleine nur bedingt leisten.
Ich glaube schon das Sony mit der PS4 das einfachere Desgin hat und das die Entwickler dieses bevorzugen. Auch weil sie immer engere Deadlines haben um neue (unfertige-) Spiele auf den Markt zu werfen.
ruyven_macaran
Trockeneisprofi (m/w)
Zwischenberechnungen kann man garantiert nicht in die Cloud auslagern, selbst wenn man mit 1 ms ankäme. Deswegen musst du den Teil mit Rücksicht auf die Spiellogik betrachten: Was kann man komplett außerhalb berechnen? Z.B. in Multiplayertiteln würden sich alle Berechnungen anbieten, deren Ergebnisse ohnehin für jeden Client vorliegen müssen (z.B. die Geometrie einer zerstörbaren Umgebung). Ob ich die vor Ort berechne und dann aufwendig synchronisiere oder zentral - die Latenzprobleme habe ich so oder so. Bei langsamen Spielen oder für nicht-interaktive Abschnitte kann man z.B. auch die gesamte Grafikberechnung auslagern und nur das Ergebnis streamen, ohne dass man die Probleme gewisser Streamingdienste hat.
Potential ist da durchaus vorhanden - aber eben Szenario-selektiv. Und für beide Konsolen in gleichem Maße.
Die angekündigten CPU-Entlastungen des PC-DX12 machen jedenfalls keinerlei Sinn, denn die hat das low-level-optimierte System der Konsolen ohnehin schon in viel weitreichenderem Maße integriert. Ich tippe auch darauf, dass es um die zusätzlichen Features von DX12 geht, um Portierungen zwischen den Plattformen zu erleichtern. (Vermutlich nützt es den Konsolen gar nichts, aber M$ kriegt mehr DX12 Titel, um den Win9 Verkauf anzukurbeln)
Der DDR3 hat keine sonderlich kurzen Latenzen. Das mag in Speichertaktzyklen so aussehen, weil er schlichtweg langsamer taktet, aber in ms (oder CPU-Zyklen) gemessen dürfte er in ähnlichem Bereich liegen, wie der GDDR5 der PS4. (Wie schon vielfach angemerkt wurde.)
Als Wunderwaffe kommt nur der SRAM in Frage - und da muss man halt abwarten, was die Entwickler draus machen. Für gpGPU ist er definitiv Gold wert, aber dafür muss man erstmal die Grafikressourcen frei haben...
Bisheriges DX erlaubt gar keine gezielte Speicherverwaltung. Die low-level-Optionen der X1 geben den Entwickler aber wesentlich weiter reichende Optionen, dazu zählen auch Überlegungen, wie man den Cache einsetzt. Wenn M$ eine sinnvolle, automatische Cache-Kontrolle im normalen X1-DX11/12 integriert hat, könnte das System als solches aber die Nachteile der geringen DDR3-Bandbreite zu großen Teilen kompensieren. Man gucke sich hierzu die Maxwell-Benchmarks an, bei denen 2 MiB Cache eine klare Senkung der Speicherbandbreite ganz locker kompensieren können.
(Noch extremer wirds bei Tile Based Rendering, man erinnere sich an das Duell, dass die Kyro II der Gf3 in einigen Spielen geliefert hat. Da waren die Bandbreitenunterschiede noch weitaus größer, aber weil die Kyro die kompletten Berechnungen einer Kachel ohne VRAM durchfüren konnte, war es egal - fürs Streaming der Rohdaten und Endergebnisse braucht man halt viel weniger Bandbreite. Stellt sich die Frage, ob Spieledesigner einen Weg finden, wieder Tile-Based-Rendering zu nutzen.)
Die Latenz unterschiede zwischen DDR3 und GDDR5 sind minimal, Interface ist schließlich das gleiche, ND hat bereits ja gesagt wie die Latenzen bei der Ps4 Cpu sind nämlich 22 Zyklen, der FX-8350 als Vergleich hat eine Latenz von 20 Zyclen. Wenn wir annehmen das diese 20 Zyklen auf die X1 zutreffen hat sie genau einen Vorteil in dem Bereich von 5%. Hinzukommt das die Speicherarchitektur bei der Ps4 dank hUMA der von der X1 überlegen ist da viele Kopiervorgänge zwischen GPU und Cpu entfallen, wenn man die benötigte Zeit für eben solche Kopiervorgänge miteinberechnet lößen sich die 5% garantiert sehr schnell in Luft auf.
Den eSRAM als Cache zu nutzen ist genausowenig hilfreich da dieser immernoch eine zu hohe Latenz hat und auch nicht nur an einem Ort vorliegt, DIE anschauen
. Hinzu kommt das der DDR3 zuwenig Bandbreite liefert um die GPU auszunutzen.Hier ein guter Artikel der durchaus zeigt das CPU´s bei weitem nicht von besseren Latenzen profitieren wie manche meinen, die GPU interessiert es aufgrund ihrer Parrallelisierung noch weniger, aber die zusätzliche Bandbreite durch GDDR5 sehr deutliche Leistungsvorteile bietet.
http://www.redgamingtech.com/ps4-vs-xbox-one-gddr5-vs-ddr3-latency/
Edit: Laut dem Substance Engine Benchmark ist die Ps4 Cpu sogar schneller als die X1 Cpu
http://gamingbolt.com/substance-eng...eneration-speed-to-14-mbs-12-mbs-respectively
Zuletzt bearbeitet:
cl55amg
BIOS-Overclocker(in)
Mit steigender Taktfrequenz erhöht sich die Cas Adress Strobe und dies macht sich ja vor allem bei GDDR5 bemerkbar. Aber ja, die Vorteile sollten sehr gering sein in dem Bereich. Der ESRAM ist da schon interessanter.
Er hat eine zu hohe Latenz um ihn als weitere Cache Stufe zu nutzen? Wie hoch ist denn seine Latenz?Den eSRAM als Cache zu nutzen ist genausowenig hilfreich da dieser immernoch eine zu hohe Latenz hat und auch nicht nur an einem Ort vorliegt, DIE anschauen
@ ruyven_macaran
GDDR5 hat größere Prefetch Buffer, was natürlich ein Vorteil ist gegenüber DDR3, aber eben nur bei sequentiellen Auslesen. Bei random Zugriffen sah ich DDR3 bisher im Vorteil, aber korrigier mich wenn ich falsch liege bzw. wenn sich das mittlerweile geändert hat.
Zuletzt bearbeitet:
http://www.extremetech.com/wp-content/uploads/2013/11/XB1SOC-2.jpg
Schau dir an wo der eSRAM liegt und vergleiche wo die Caches liegen. Das Caches geringe Latenzen haben liegt an ihrer Nähe zum jeweiligen Prozessor, weswegen z.B. Speicher Controller mittlerweile in den Chip mit der Cpu gewandert sind während sie früher noch beim Ram lagen.
Hier liegt der Großteil des eSRAMs aber weiter von der Cpu entfernt als der Speicher Controller mit dem man direkt in den DDR3 schreiben könnte, der Weg zum DDR3 würde da natürlich auch noch hinzukommen. Allein durch logisches Denken kommt man nun darauf das die Latenz für den eSRAM deutlich höher sein muss als die Latenz zu den jeweiligen Caches. Dadurch das der eSRAM aber im Chip ist lassen sich sehr schnell, da geringere Latenz als wenn man über DDR3->Controller->Cache geht, Daten in den eSRAM reinschreiben und rauslesen. Weswegen ja schon seid der Ps2 und früher Intel sowie heute wieder Intel eingebetteten Speicher in ihren Chips nutzt. Dennoch willst du das dein Code über die deutlich schnelleren Caches läuft, meisstes davon im L2 Cache da groß genug und nicht zu langsam während im schnelleren aber kleineren L1 Cache Branch Prediction läuft, L3 Cache haben beide Konsolen bekanntermaßen nicht.
Alle Caches takten bekanntermaßen im gleichen Takt wie die Cpu, die Latenz ist also nur dadurch beeinflusst wie nah der Cache zur CPU liegt, der eSRAM hingegen taktet auf GPU Takt was weniger als 50% des Cpu taktes sind und somit als Cache allein aus diesem Grund bereits keine gute Wahl ist.
Wir wissen auch das die Latenz zwischen Cpu und L2-Cache auf dem man den großteil Code laufen lässt bei der Ps4 bei 20+ Zyklen liegt, vergleich hier da gleiche Cpu Architektur, während die Latenz zum L1-Cache grademal 3 Zyklen beträgt und das direkte schreiben in den Speicher zu einer Latenz von über 200 Zyklen führt. Logischerweiße wird also bei der X1 die Latenz zwischen 20 und 200 liegen, nun da der großteil des Speichers aber sehr weit von der Cpu entfernt ist wird es nicht bei 30 oder so liegen oder wie bei L3-Caches bei AMD Cpu´s wie den FX-8350 die auch noch deutlich näher sind als der eSRAM bei um die 80 sondern wohl eher 100+ Zyklen. Was willst du denn sinnvollerweiße auf dem eSRAM machen wenn du ihn als Cache nutzen willst, willst du das die Cpu nach jedem Aufruf 100 Zyklen rumidelt bis sie eine Antwort bekommt? Das wäre vergeudete Rechenleistung und würde eher dazu führen das die Box noch langsamer läuft als sie es ohnehin schon tut.
cl55amg
BIOS-Overclocker(in)
@ Grunkera
Es hat doch niemand geschrieben das man den ESRAM als Cache Stufe alleine für die CPU nutzen soll. Deine ganze Argumentation stützt sich darauf, das der SRAM näher an dem GPU Teil ist als am CPU Teil. Daher kann man den ESRAM gut als GPU Cache Stufe nutzen (z.B. für den Shadercode). (Davon reden wir hier)
@ CPU Teil
Natürlich könnte man den ESRAM theoretisch auch als CPU Cache nutzen, denn auf on DIE SRAM kann ich immernoch mit mehr als einem 10er Faktor schneller zugreifen als auf sehr lahmen DRAM, bei dem ich auch noch warten muss bis der Bus frei wird. (Er wäre dann als eine Art L3 Cache anzusehen)
Das ist das tolle dieser Architektur, die Flexibilität.
Also nochmal:
Ich kann on DIE SRAM nicht als Cache Stufe nutzen? Natürlich kann ich das, da die Latenz weitaus besser ist als stattdessen auf den DRAM zuzugreifen. (Auch wenn der SRAM näher an der GPU liegt als an der CPU)
Und das liegt nicht nur daran, dass der DRAM weiter entfernt ist, sondern auch an der Bauart von SRAM, die sich stark von DRAM unterscheidet und deshalb deutlich schneller ist. (Ich schätze der Unterschied auf Transistor Level sollte Dir bekannt sein)
Es hat doch niemand geschrieben das man den ESRAM als Cache Stufe alleine für die CPU nutzen soll. Deine ganze Argumentation stützt sich darauf, das der SRAM näher an dem GPU Teil ist als am CPU Teil. Daher kann man den ESRAM gut als GPU Cache Stufe nutzen (z.B. für den Shadercode). (Davon reden wir hier)
@ CPU Teil
Natürlich könnte man den ESRAM theoretisch auch als CPU Cache nutzen, denn auf on DIE SRAM kann ich immernoch mit mehr als einem 10er Faktor schneller zugreifen als auf sehr lahmen DRAM, bei dem ich auch noch warten muss bis der Bus frei wird. (Er wäre dann als eine Art L3 Cache anzusehen)
Das ist das tolle dieser Architektur, die Flexibilität.
Also nochmal:
Ich kann on DIE SRAM nicht als Cache Stufe nutzen? Natürlich kann ich das, da die Latenz weitaus besser ist als stattdessen auf den DRAM zuzugreifen. (Auch wenn der SRAM näher an der GPU liegt als an der CPU)
Und das liegt nicht nur daran, dass der DRAM weiter entfernt ist, sondern auch an der Bauart von SRAM, die sich stark von DRAM unterscheidet und deshalb deutlich schneller ist. (Ich schätze der Unterschied auf Transistor Level sollte Dir bekannt sein)
Zuletzt bearbeitet:
Schau dir mal bitte an wie eine Engine funktioniert und wie auch eine GPU aufgebaut ist, denn die GPU besitzt selbst nochmal eigene Caches welche die gleichen Vorteile bieten wie auch bei der Cpu die Vorteile sind also auch bei der GPU wieder nicht vorhanden für den eSRAM als Cache.
Du nennst es Flexibilität ich finde es dumm... 1/3 der DIE Fläche geht für 32MB Speicher drauf welcher zwar genug Bandbreite bietet aber nicht groß genug ist für defferred Rendering bei 1080p während gleichzeitig der DDR3 groß genug ist aber nicht genug Bandbreite bietet und dann hat man nicht genug Platz für ne halbwegs ordentliche GPU. Am Ende kommste doch egal wie dus drehst darauf hinaus das du den eSRAM als Framebuffer nutzt, inwiefern das Flexibel sein soll verstehe ich nicht.
Ich habe nicht gesagt das man es nicht kann sondern das es nicht hilfreich ist, auch greift kein Entwickler der auch nur halbwegs Ahnung hat von dem was er macht direkt auf den Ram zu sondern lässt alles über die Caches und die Speichercontroller laufen, da diese viel häufigere Zugriffe auf den Main Ram haben. Das SRAM schneller ist als DRAM stellt keiner zur Abrede, schließlich findet man ihn ja auch als L1, L2 Cache usw. dafür hat er eine geringere Dichte und braucht daher ein vielfaches an Platz. Die Latenz ist besser sein als direkt auf den DRAM zuzugreifen aber bei weitem nicht gut genug um darauf tatsächlichen Code laufen zu lassen da die Caches immernoch um mehrere Faktoren schneller sind.
ruyven_macaran
Trockeneisprofi (m/w)
GDDR5 und DDR3 gehören zur gleichen Generation und arbeiten iirc beide mit 4er Prefetchs.
Äh - nein? Und doppelt nein?
Caches haben so geringe Latenzen, weil sie im Vergleich zu DRAM wesentlich kleiner sind und mit einer wesentlich einfacheren, schnelleren Ansteuerung auskommen und natürlich weil sie auf SRAM setzen, auf den jederzeit zugegriffen werden kann. Selbst der externe L4 Cache von IRIS Pro ist um welten schneller, als Speicherzugriffe.
Und Speichercontroller sind ebenfalls nicht wegen der räumlichen Nähe aufs DIE gewandert, sondern wegen der Anbindung ohne Kontaktprobleme, insbesondere ohne Steckkontakte wie bei einem Sockel, die eine saubere Datenübertragung deutlich erschweren und deswegen den Flaschenhals FSB erforderten. Den einzusparen hat niedrigere Latenzen ermöglicht - nicht die geringere Entfernung. Wenn du einen P45 direkt hinter den Sockel aufs Board gelötet hätte, so dass die Leitungslänge nur wenige mm beträgt, wäre diese Verbindung immer noch lahmer gewesen, als auf einem hypothetischen 5 cm langen DIE.
Guck dir die Größe dieser Caches und die Größe des Programmcodes an...
Da passt verdammt wenig rein.
Können wir langsam mal mit den Frame Buffern aufhören?
30-60 mal in der Sekunden (bzw. 90 bis 180, wenn dir die mehreren Buffer von deffered-Rendering so wichtig sind) einen HD-Frame speichern, also rund 350 MB/s, könnte ich mit dem Hauptspeicher des Rechners, an dem ich gerade sitze. Und das ist ein Slot1 System...
Die mathematische Formel will ich doch gerne mal sehen wo eine geringe Speichergröße zu kürzeren Latenzzeiten führt. Zur Info, das eine hat mit dem andern nichts zu tun. Ein 1GB Sram hat die gleiche Latenz wie ein 1KB Sram. Und wie ich schon sagte kein Entwickler greift direkt auf den Speicher zu sondern lässt alles über die Speichercontroller an die Caches liefern.
Zum Speichercontroller ja ich weiß ist ein Wiki Zitat ändert aber nichts an der richtigkeit:
Der Vorteil einer Unterbringung des Speicherkontrollers im Prozessor liegt in den kürzeren Wegen der Zugriffe. Der Chip kann so, im Vergleich zur Unterbringung auf dem Mainboard, direkt adressiert werden – ohne den Umweg über die Northbridge. Allerdings unterstützt ein Speicherkontroller nur bestimmte Speichertypen, somit legt seine Wahl und Bauweise den Speichertyp des Systems fest. Ist der Speicherkontroller im Prozessor integriert, hängt der unterstützte Speichertyp vom Prozessor ab; ist er hingegen auf dem Mainboard integriert, ist der verwendete Speicher vom Prozessor unabhängig, lediglich das Mainboard und dessen Chipsatz bestimmen den Speichertyp.
Die nähe ist durchaus wichtig Licht braucht bekanntlicherweiße 3ns für 1 cm selbst bei einem 1 Ghz Prozessor würde dies schon zu einer Latenz von 3 Zyclen führen, bei einem modernen 3 GHZ Prozessor wären es schon 10 Zyklen, allein durch den Datenweg, da ist noch nichtmal die Latenz des eig. Speichers mit drinne welcher auch bei SRAM bei min. 5 ns liegt. Das wäre eine Effizienz von 10%, wenn ich nun aber den Weg auf 1mm reduziere, dann hab ich nurnoch 1 Zyklus wo der Prozessor rumidlet und er somit alle 2 Zyclen Daten verarbeiten kann was zu einer Effizienz von 50% führt. Also allein dadurch das der Weg kürzer ist, habe ich die Leistung um 500% gesteigert.
Du speicherst nicht deinen kompletten Programmcode in die Caches... sondern lediglich die einzelnen Funktionen welche aktuell gebraucht werden man kann natürlich schlecht programmieren und für jede Funktion 100MB Speicher benötigen oder man programmiert anständig und splittet die Funktionen weiter auf so das sie in den schnellen Cache passen und hat dafür viele kleine Funktionen. Da kommt es dann darauf an wie gut die Entwickler die Hardware verstehen für Memory Fragmentation, Cpu Pipelining, Branch Predicition etc. pp. so kann man z.B. in einer Schleife anstatt 1 IF zu benutzen um 2 Fälle abzudecken, 2 IF´s außerhalb der Schleife schreiben jeweils für Fall a und b und somit ganz klar die Fälle definieren was dazu führt das die Branch Prediction deutlich besser ist und man keine plötzlichen Leistungseinbrüche bekommt und nicht weiß woher. Oder man wissen muss das wenn man ein Byte aus dem Speicher in den Cache lädt 64 Bytes auf dem Cache belegt. Also warum nicht direkt 64 Bytes aus dem Speicher nehmen und damit den Cache auch sinnvoll befüllen. Mit sowas kann man schon aussehen wie ein Superstar und sagen heey mein Code läuft 10x mal schneller als zuvor, aber ansig ist es nur simples Wissen darüber wie die Hardware funktioniert. Als Beispiel um dir das zu verdeutlichen um z.B. von einem Cpu Cluster auf den anderen L2 Cache Cluster zuzugreifen werden 190 Zyklen bei der Ps4 benötigt, bei der X1 wirds kaum anders aussehen da gleiche Cpu, ist es also schlau auf den anderen Cache Cluster zuzugreifen? Eher nein.
Du betrachtest nur die Endmenge an Daten die nur für das letzendliche Bild da sind... das ist so nicht gut, du hast eine Menge Berechnungen und damit Speicherabfragen wie Kollisionsabfragen, Audio Simulation, Animationen etc. pp. wo viele Zwischenergebnisse benötigt werden und nichts mit dem Pixel Output zu tun haben und somit eine hohe Bandbreite, nur den finalen Frame anschauen ist gradezu ignorant, auch musst du die Farbtiefe von Texturen miteinbeziehen, die X1 benötigt z.b. eine Bandbreite von min. 109GB/s für RGBA16F Texturen. Die Performancesteigerungen bei GDDR5 zu DDR3 bei Gpu´s kommt nicht irgendwoher. Die ersten GDDR5 Gpu´s haben häufig fast 50% besser performed als die gleiche Karte mit doppelt soviel DDR3 Speicher. Hinzu kommt und da ist das Problem des eSRAM als Framebuffer, wie groß jeder einzelne Frame ist z.B. ein Bf3 bei 1080p ohne AA mit seinen knapp 40MB pro Frame passt einfach nicht in den eSRAM, das ist eine Mathematische Tatsache.
Die Qualität wird sich bei der X1 sicherlich steigern aber die Auflösung wird bei deffered Rendering wird zwischen 720p und 900p liegen, je nachdem wie anspruchsvoll der Titel ist.
ruyven_macaran
Trockeneisprofi (m/w)
Das will ich mal sehen, wie du Mathematiker ein Adressierungssystem für eine Milliarde Speicherzellen baust, dass so schnell arbeitet, wie eins für 1000....
Nettes Zitat. Und was steht drin? Nichts von Entfernung, sondern von direkter Anbindung ohne eine FSB<->DRAM-Wandlung ala Northbridge.
In meinem Universum legt Licht (im Vakuum) knapp 300.000 km/s zurück, d.h. 30 cm pro Nanosekunde. Nicht 3 ns pro Zentimeter. Bei einer 3 GHz CPU wären pro Takt also 10 cm drin. Strom ist nicht ganz so schnell, aber sollte es immer noch problemlos innerhalb eines Taktes 2-3 mal quer übers X1-DIE schaffen. Und du willst aus ein paar mm Entfernugnsunterschied in der Anordnung eine Latenz berechnen??
Und was heißt "aktuelle"? Je nach Cache-Größe irgendwas zwischen "die nächsten 10 Zyklen" bis "die nächsten 1M Zyklen". Oder, wenn man nochmal 32 MB extra hat, ggf. auch alles, was in der nächsten halben Minute an ausführbaren Code benötigt wird, so dass der "lahme" Speichercontroller nur noch die zu verarbeitenden Rohdaten bewältigen muss, während er bei der P4 alle naslang andere Programmteile nachlädt. Man kann mit Caches verdammt viel machen, wenn man den Programmcode an jede Stufe anpasst und da liegt bei der X1 eben enormes Potential. Denn wenn ich es schaffe, mein Spiel in einen Spiellogikteil von <32 MB (aber >2 MB) und einen Datenteil von mehreren GB aufzuteilen (und sehr viele Spiele haben bereits eine derartige Verteilung zwischen einer .exe von einigen MB und einer riesigen Sammlung an Textur-, Level-,....... Daten), dann arbeitet sie effektiv mit 60% mehr Speicherbandbreite, als die PS4, bei der auch sich ständig wiederholende Anfragen nach Programcode-Anteilen über das primäre Speicherinterface abgewickelt werden, so dass am Ende mehrere tausend Mal der gleiche Inhalt transferiert wird.
Du hast bislang ausschließlich von Framebuffern gesprochen. Die heißen nicht ohne Grund so - da speichere ich einen kompletten Frame zwischen. Gerade im Rahmen von Defferedrendering auch durchaus Zwischenstufen, weil ich eben schon eine komplette Berechnungskategorie für das ganze Bild abgeschlossen habe.
Diverse Zwischenergebnisse (allerdings nicht Audio, Kollision und auch nur Beschränkt Animation, weil das keine GPU-Aufgaben sind
) sind dagegen eben ein Paradebeispiel für Caching. Im Gegensatz zum Inhalt der Framebuffer, die letztlich das Ausgabebild ergeben und solange erhalten bleiben müssen, brauche ich die enorme Menge an Zwischenergebnissen nämlich nur sehr, sehr kurzzeitig.Wenn ich Z-Tests für einen bestimmten Bereich des Bildes mache, um zu bestimmen, was eigentlich zu sehen ist, dann kann ich die dafür berechneten Informationen wegschmeißen, nachdem die zu rendernde Geometrie ermittelt wurde. Der Cache muss also nicht die gesamte, unsortierte Geometrie zusätzlich zu den Texturen aufnehmen können. Letztere kommen erst ins Spiel, wenn erstere schon wieder raus sind. Genauso muss ich, wenn ich für eine Reflektion das Level in eine Cube-Map rendere, diese nur solange Zwischenspeichern, bis ich die spiegelnde Oberfläche mit dem passenden Ausschnitt texturiert habe. Danach ist der Cache wieder frei.
Genau für solche Aufgaben ist der SRAM der X1 prädestiniert und kann das primäre Speicherinterface extrem entlasten, denn die PS4 spammt mit all diesen Daten ihre großzügigen 176 GB/s dicht, während die X1 ihre mickrigen 68 GB/s tatsächlich nur dafür benutzen muss, Texturen und Geometrie-Basisdaten zu bewegen - und halt die paar MB Framebuffer
.(WENN die Enginge diese komplexe System angemessen berücksichtigt. Ob das automatisch möglich ist, wage ich zu bezweifeln. Intel hat im Rahmen von Iris Pro gesagt, dass 64 MB Cache "mehr als genug" für alle Renderaufgaben waren, aber das dürfte umgekehrt heißen, dass 32 MB nicht alles cachen können. Es braucht also einen Entwickler, der eindeutig zwischen Daten trennt, bei denen cachen sinnvoll ist, und Daten, die sowieso nicht wieder benötigt werden. Macht man sich diesen Aufwand nicht, läuft der Cache halt über und verliert seine Wirkung - bzw. man muss die Gesamtdatenmenge pauschal mit Auflösung und LOD drücken, wie es die aktuelle Spielegeneration meist macht)
CrimsoN 2.0
Volt-Modder(in)
Die ganze Diskussion is sinnlos !
Die X-Box One is einfach langsamer und die PS4 schneller.
Daran wird auch keine Dx12 was ändern oder sonst was für Lösungen.
Wenn M$ gleich ziehen will sollte die eine X-Box one v2 machen mit mehr eSRAM also nur 32MB und dem DDR3 Speicher gegen GDDR5 Tauschen und schon kann FullHD oder villt sogar mehr kommen.
Das ganze solle aber dann so gemacht werden das es mit den Spielen für die "Alte" X-Box One noch geht.
Die X-Box One is einfach langsamer und die PS4 schneller.
Daran wird auch keine Dx12 was ändern oder sonst was für Lösungen.
Wenn M$ gleich ziehen will sollte die eine X-Box one v2 machen mit mehr eSRAM also nur 32MB und dem DDR3 Speicher gegen GDDR5 Tauschen und schon kann FullHD oder villt sogar mehr kommen.
Das ganze solle aber dann so gemacht werden das es mit den Spielen für die "Alte" X-Box One noch geht.
Caun
Freizeitschrauber(in)
Und was machen dann die besitzer der alten xbox one ?
bekommen keine neuen spiele mehr ? oder nur noch in einer abgespeckten version wo null optimiert wurde ? Die Xbone kann man echt vergessen wenn man das maximum in der Konsole will muss man zur PS4 greifen 
Nicht umsonst bekommt man in so manchem Cash center gleich mehrere nagel neue und noch orginal verpackte Xbone mit voller Garantie das stück zu 400-450,-Eur , wer also eine Sparkonsole was Leistung und Preis angeht haben will sollte zugreifen
Nicht umsonst bekommt man in so manchem Cash center gleich mehrere nagel neue und noch orginal verpackte Xbone mit voller Garantie das stück zu 400-450,-Eur , wer also eine Sparkonsole was Leistung und Preis angeht haben will sollte zugreifen
tolga9009
Freizeitschrauber(in)
Ihr dürft nicht vergessen, dass nicht nur Microsoft per Software optimieren kann - das kann Sony ebenfalls! Die PS4 Firmware basiert auf FreeBSD, für die es vorher noch nie offizielle Grafikkartentreiber von AMD gab; da wird es bestimmt noch den einen oder anderen Durchbruch geben in den folgenden Jahren. Alles in allem dürfte es in dem Hardware-Vorsprung enden, der bereits gegeben ist. Ob man als Endnutzer jedoch irgendwelche Unterschiede wahrnehmen wird, daran darf gezweifelt werden. Eine Spielefirma entwickelt für die eine Platform und portiert auf die andere; grafische Unterschiede werden nach wie vor minimal sein, trotz Hardware-Vorsprung seitens der PS4. Interessant könnten jedoch Exklusiv-Titel werden, die sich jedoch auf den anderen Seite schlecht vergleichen lassen.
banned4life
PC-Selbstbauer(in)
Nur das Sony außer Rootkits keine Ahnung von Software hat. 
Ripcord
Volt-Modder(in)
Nur das Sony außer Rootkits keine Ahnung von Software hat.
Sony muss keine Ahnung haben, AMD wird da schon gewaltig helfen was die Software betrifft, alleine schon aus eigenem Interesse.
Trotzdem würde ich jetzt nicht sagen Sony hätte keine Ahnung, die bauen Konsolen seit über 20 Jahren. Das wäre ja so, als würde man Microsoft vorwerfen kein anständiges OS auf die Beine stellen zu können.... ups
SchumiGSG9
PCGH-Community-Veteran(in)
Die sollten am besten eine neue X-Box One rausbringen wo ich auch weiterhin meine X-Box 360 Games spielen kann wie Forza 4, Forza Horizon und GTA 5.
Ähnliche Themen
