[Sammelthread] Grafikkarten - Technikdiskussion

In welcher Auflösungund welchen Qualitätseinstellungen soll denn was genau gespielt werden ?

Für mehr als niedrigste Einstellungen wird das nicht reichen, sind sehr viele Spiele die mehr als nen dualcore brauchenwerden nichtmal angehen.
Hauptproblem sind die 2GB Ram, das ist sehr sehr wenig..

wenn ich den RAM auf 4GB aufstocke und übertackte würden aktuelle Spiele auf kleiner Einstellungen gehen, oder starten aktuelle Spiele gar nicht mehr auf so einem alten System?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Es kommt auf das Spiel an, manche gehen, andere nicht..
Ob man bei dem WIE die laufen Spass hat ist die Frage des eigenen Anspruchs.

Allgemein lohnt das Sys eher noch für Office.
 
Ich hab mir gerade ne R9 280X gegönnt und habe nun sorge, dass durch die neuen HBM2-Karten diese überproportional veraltert :fresse:

Ist diese Sorge berechtigt (ich plane eigentlich so 3-4 Jahre diese Grafikkarte zu nutzen) oder wird HBM2 nur im Highend-Segment eine Rolle spielen und ich kann mit meiner Grafikkarte noch ein wenig länger "hohe" und "Ultra" Setting spielen? :fresse2:
 
hat es denn nich mit der anbindung etc. was zu tun wie schnell die karten den mist durch den ram schieben? ich mein wäre doch an sich klar das der schneller angebundene vram in der selben zeit mehr daten durchjucht und dementsprechend entweder weniger ausgelagert wird oder halt bei der selben auslastung mehr texturen etc. durchjagt wo dann bei dem langsamer angebundenen irgendwo texturen im hintergrund aufpoppen ?


BITTE NICHT SCHLAGEN :d will nur was lernen

Nein, denn die Anbindung des VRAMs ist eher nebensächlich, sofern genügend Bandbreite bereit steht. Das Problem ist eher der PCIe Slot, denn das ist der Uplink zum System. Im VRAM Limit, egal welcher Art, müssen die Daten dort durch. Das heist im Optimalfall, ~16GB/sec auf dem Papier, was sogar noch weniger ist, als der achte Speichercontroller alleine bei der 970er stemmen kann.
Das die VRAM Belegung bei verschiedenem VRAM Ausbau auch unterschiedlich ist, ist auch logisch. Der Speicher wird als Cache genutzt. Sprich genutzte Texturen bleiben im Cache, auch ohne dass diese direkt in Verwendung sind/sein müssen... Um so mehr VRAM da, desto mehr Texturen kann man also cachen. Im Bedarfsfall muss also die Karte mit weniger VRAM die Daten über den langsamen PCIe Slot beziehen. Die mit mehr VRAM muss das nicht -> die stehen ja schon im VRAM und sind schnell verfügbar.

Das Problem dabei ist nur, es gibt keine dedizierte Logik der man haarklein beibringen kann, welche Daten auf absehbare Zeit benötigt werden und welche nicht. Die Hardware agiert somit eher als Datensammelkrake und stopft alles in sich rein, was sie kriegen kann.

Auch sollte man heute wissen, dass sich die Spiele bzw. die Engines gewandelt haben im Vergleich zu den Anfängen. Früher, als das mal losging mit dem 3D Spielen, hat man die Daten bei Bedarf angefordert. -> rein in den VRAM, nutzen und ggf. danach wieder raus. Man hat also mit dem Platz, der als VRAM verfügbar war, haushalten müssen. Überbuchung des VRAMs wärend der Spielzeit führte oft zum VRAM Limit, weil einfach nicht bekannt ist/war, was für Daten gelöscht werden können.
Heute ist das etwas anders. Die Engines/Spiele streamen "intelligent" ihre Daten. Wir erleben heute eine teils drastische Überbuchung des VRAMs und das Spiel steuert selbst, welche der Daten während der Spielzeit in den VRAM sollten und welche nicht. Bspw. anhand eines gewissen Sichtradius der Spielfigur oder ähnlichem. Bewegt sich nun die Figur, werden die Daten im Hintergrund schon geladen, die im Radius sind -> alte fallen weiterhin möglicherweise raus. Der Spieler bekommt davon wenig mit, weil die Datenmenge, die übertragen wird, nicht sonderlich hoch ist. -> es limitiert nicht der PCIe Slot dieses Streaming, weswegen die FPS Raten idR konstant bleiben.

Es geht sogar soweit, dass dieses Streaming aktiv Nachladeruckler verhindern kann, weil die Objekte dann einfach während der Fahrt aufpoppen... Sieht dabei noch total kacke aus. Verhindert jegliche sinnvolle Benches/Vergleiche zwischen der Hardware, wenn man nicht den Output dediziert mit vergleicht usw. Vorteil ist aber klar, es ruckelt halt nicht. Auch bei eigentlich zu "schwacher" Hardware und macht damit den Spieler glücklich.
Ausschauen tut das übrigens so (Beispiel, FC4 mit vollen Details in FHD auf 2x 780TI mit 3GB im SLI)
unbenanntr0b6c.jpg


Es popt dabei der ganze Turm auf. Teils sogar ganze Berge oder Teile der Berge... Das sieht wirklich unschön aus. Andererseits wäre es wohl klar ein Problem, denn es würde wohl stark ruckeln, wenn die Karte nicht genügend VRAM hätte. Die 3GB meiner beiden 780TIs sind allerdings brechvoll.
Auch gibt es noch ne ganze Menge anderer Titel, die ein ähnliches Verhalten zeigen... Das Problem ist nur, man muss es erstmal "erkennen", das die Spiele da etwas bescheißen... Denn FC4 eignet sich durch diesen Umstand in keinster Weise für einen Benchmarkvergleich, da die Bedingungen schlicht NIE gleich sind, vor allem nicht im VRAM Limit. Was auf so ziemlich alle Karte bis einschließlich 3GB zutreffen dürfte... Ggf. auch auf die 970 bzw. die 4GB Karten.
 
Mich würde da mal der Vergleich von den gleichen Screenshots, bei gleicher Einstellung, mit einer 780ti, 970, 980, 290 und 390 interssieren, ob da eventuell aufgrund des weniger RAMs teile entfernt wurden. Screenshots könnte man ja theoretisch mittels Savegame und Laden ohne die Maus zu bewegen machen.
Über ein Diff der Screenshots sollte sich evtl fehlende Objekte erkennen lassen, problematisch könnten die Blätter im Wind sein... müsste man mal testen.

Ganz früher gabs ja auch Tests mit verschiedene AA modis zwischen Verschiedenen GPU Generationen... die ganzen Tests gibts heute nicht mehr, es werden nur noch ein Paar Balken gezeigt und das wars...
 
Aus der Diskussion hier: http://www.hardwareluxx.de/community/f306/grafikkarte-fuer-lg-34um95-1105075-3.html

Ich kom da nicht ganz mit warum der Vram Einfluss auf die FPS hat. Die FPS Anzahl bleibt doch gleich wenn Texturen nachgeladen werden müssen, es kommt dadurch halt zu einer "Verzögerung" (Nachladeruckler) des Bildes, die Berechneten FPS bleiben doch aber dennoch gleich?
Deshalb ist die Aussage das der GTX 970 der Vram in höheren Auflösungen ausgeht mit der Begründung die FPS seien niedriger als bei der R9 390 doch schwachsinn. Die 390 hat schlicht mehr recheneinheiten und kann diese in der höheren Auflösung besser nutzen wäre dort meine Erklärung.
Bitte hier mal um Aufklärung, Danke :)
 
Mich würde da mal der Vergleich von den gleichen Screenshots, bei gleicher Einstellung, mit einer 780ti, 970, 980, 290 und 390 interssieren, ob da eventuell aufgrund des weniger RAMs teile entfernt wurden. Screenshots könnte man ja theoretisch mittels Savegame und Laden ohne die Maus zu bewegen machen.

Das funktioniert leider so nicht... Denn die Objekte poppen dynamisch auf. Sprich ich war dort mit dem Heli unterwegs... Flieg ich zurück und dreh die gleiche Runde nochmal, ist der Turm schlicht IMMER zu sehen. Dafür poppen möglicherweise an anderen Stellen die Objekte dann auf.
Auffallend bei FC4 ist zumindest, dass mir der Spaß bis dato nur mit dem Heli aufgefallen ist. Vor allem, wenn man weitere Strecken fliegt -> wo sich dann teils sichtbar auch die Umgebung ändert (andere Texturen und so)
Roproduzierbar ist das Verhalten zweifelsfrei. Nur die Stellen sind schlicht IMMER woanders und damit kann man keine Bilder übereinander legen.


Ich kom da nicht ganz mit warum der Vram Einfluss auf die FPS hat. Die FPS Anzahl bleibt doch gleich wenn Texturen nachgeladen werden müssen, es kommt dadurch halt zu einer "Verzögerung" (Nachladeruckler) des Bildes, die Berechneten FPS bleiben doch aber dennoch gleich?

Nein, da die FPS eben eine Berechnungsgröße sind, die die Bilder pro Sekunde zählen. Wartet die GPU nun auf den VRAM -> weil Daten umgeschaufelt werden müssen, rechnet sie nicht in der Zeit. Die Load sinkt, die FPS sinken damit normal auch. Das Problem ist aber die Messmethode. FPS werden normal gemittelt gemessen. Heist wie viele Bilder in einer Zeiteinheit kommen im Framebuffer an -> Anzahl durch Zeiteinheit = FPS. Bedeutet aber auch, dass kurze Hänger im Berechnungsfluss nicht sonderlich viel am FPS Wert ändern. Das Spielempfinden aber massiv stören können.
FPS eignen sich zwar grob für eine Einschätzung der Performance des Spiels, sagen aber nichts über das Spielverhalten bzw. Spielgefühl aus. Hier sind die Frametimes besser geeignet.

Simples Beispiel. Deine GPU haut sagen wir 60 Bilder die Sekunde raus -> macht 60 FPS. Optimalerweise bedeutet das ~16,67ms Abstand zwischen den Bildern. -> jetzt hast du nen Ruckler, weil sich massiv Daten im VRAM ändern und du hast sagen wir dort ne Wartezeit von 50ms drin, bedeutet das, dass du knapp 3 Frames auf die Sekunde gerechnet, verlierst. Für diese eine einzige Messung würde da nicht 60 FPS stehen, sondern nur 57. Schon in der nächsten Sekunde wären es wieder 60 FPS. -> das geht unter.
Passieren dir aber alle Nase lang solche Hänger, nervt es den Spielfluss ungemein ;) Man spricht von Nachladerucklern und ist damit im VRAM Limit. Da können die FPS noch so hoch sein... Es ist nicht gut.

Deshalb ist die Aussage das der GTX 970 der Vram in höheren Auflösungen ausgeht mit der Begründung die FPS seien niedriger als bei der R9 390 doch schwachsinn. Die 390 hat schlicht mehr recheneinheiten und kann diese in der höheren Auflösung besser nutzen wäre dort meine Erklärung.
Bitte hier mal um Aufklärung, Danke :)

Den ersten Teil der Aussage kann ich nicht nachvollziehen. Woher stammt das?
Den letzten Teil unterschreibe ich aber... Denn das sollte durchaus so sein... War eigentlich auch schon immer bei AMD GPUs der letzten Jahre der Fall... Viel Rohpower gepaart mit mäßigen DX Optimierungen = im Vergleich steigende FPS um so höher die Last.
Ist halt eine Frage der Sichtweise... Von FHD auf höhere Auflösung brechen die GPUs in den FPS ein. Wenn natürlich die niedrigen Auflösungen im CPU (nahen) Limit agieren, dann ist die Höhe des Einbruchs natürlich geringer, weil in der niedrigen Auflösung die FPS Rate gar nicht voll ausgefahren werden kann. Was nun besser/schlechter ist, muss jeder für sich selbst definieren ;)
 
Den ersten Teil der Aussage kann ich nicht nachvollziehen. Woher stammt das?
Ich hätte schwören können das ich es im verklinkten Thread gelesen habe, finde ich selbst jetzt aber nicht mehr. Das muss ich mir dann wohl selbst zusammengereimt haben... :fresse:

Danke fürs aufklären und erklären :)
 
Naja, hätte MS was davon sowas einfach zu erfinden? Es ist ja klar dass dies erst mit echter Software untermauert und getestet werden muss.
Dein Argument mit dem Cache macht recht viel Sinn, das stimmt.
Hmm.. Eventuell hebt man dieses Prinzip aber doch auf.

Neja, ich sag mal so. MS hat da ja nix erfunden ;)
SFR ist ein alter Hut. Älter sogar als AFR... Sprich das Prinzip ist seit Ewigkeiten bekannt und funktioniert auch (im Rahmen seiner Möglichkeiten)

Das Problem ist wie so oft, man lässt sich vom Marketinggeblubber verleiten... Wenn es ein günstiges Szenario gibt, bspw. bei quasi statischem Kontent, dann kann man schon annähernd mit einer VRAM "Verdopplung" im Vergleich zu AFR rechnen. Wichtig dabei ist rein logisch eigentlich nur, dass man den Kontent so günstig wählt, das möglichst beide GPUs annähernd gleich viel Arbeit haben und es in den meisten Situationen nicht dazu kommen sollte, dass der Kontent mal links, mal rechts berechnet wird.
Mir fallen da spontan Strategiespiele ein. Sowas wie Anno und Co. -> Ja auch Civilization. Dort hat es eine Draufsicht und man kann prinzipbedingt gewisse Teile von GPU A) und andere Teile von GPU B) berechnen. Durch die statische Draufsicht wird sich am Verhältnis, welche GPU was macht, nicht sooo drastisch viel ändern und das Prinzip KANN! durchaus aufgehen.

Stell dir das aber mal in einem Shooter vor. Du hast als Spieler die Welt völlig in der Hand. Je nachdem, wohin du dich drehst, ändert sich der Kontent. Volldynamisch und nicht vorhersehbar. Zwar kannst du nun ebenso Objekte oder Gruppierungen von Objekten auf die GPUs festpinnen, aber das klappt nur dann, wenn es wieder ein gewisses Gleichgewicht im Aufwand gibt. Dreht sich der Spieler, rutschen Teile aus dem Sichtfeld -> die GPU hat weniger zu tun, dafür kommen andere Objekte dazu usw. Um so häufiger dieser Wechsel, desto höher die Warscheinlichkeit, dass JEDE GPU im System mal mit ALLEN Objekten in Berührung gekommen ist und damit auch von ALLLEN Objekten die Texturdaten im VRAM hat.

Was DX12 auf jeden Fall können wird, ist die Idee der Master und Slave Karten (glaub die Begriffe wurden nicht genutzt, aber das trifft es sehr gut).
Eine Karte hat die Kontrolle, die anderen stellen nur standardisiert Rechenleistung bzw. Recheneinheiten.
Damit sollen ja auch NV und AMD Karten und sogar Intel IGPs zusammen funktionieren können, wenn sich die Firmen nicht quer stellen.

Basierend auf dieses Prinzip könnte man in Games, bestimmte Render-Objekte fix an eine bestimtme Grafikkarte binden so dass nur diese die Texturdaten, etc. in ihrem vRam braucht.
Das wäre auch eine Art SFR nur nicht auf Pixel-Basis sondern auf Basis der Game Objekte. Eventuell fällt das auch unter der hardwarenahen Programmierung, welche MS so anpreist.
Auch die Grakas selbst bzw. der Treiber könnte das optimieren/übernehmen, denn die Meshes und zugehörigen Grafiken sind in sich abgeschlossen und der Grafikkarte ja bekannt.

Genau das ist wohl sogar eher die Grundvorraussetzung, damit das überhaupt funktioniert. Der Pferdefuß bei SFR ist doch klar die Skalierung... Bei einer Bildzerhackstücklung welcher Art auch immer hast du immernoch das Problem, dass du nicht die Aufwände kennst. -> Berechnungszeit kannst du erst nach der Berechnung ermitteln. Dann ist es aber schon zu spät. Man teilt also mehr oder weniger "blauäugig" Teile des Bildes auf die GPUs. -> bescheidene Leistungsskalierung.
Das ganze auf Objektbasis zu machen ist aus meiner Sicht fast Grundvorraussetzung, denn damit hast du als Entwickler den Part in der Hand.
Leider ändert sich damit am Grundproblem ja nix.
Was helfen kann, wenn gewisse Objekte wirklich statisch an GPUs gebunden werden, sodass diese NIEMALS NIE auf eine andere GPU kommen. Um so mehr man das aber treibt, desto höher wohl das Auslastungsungleichgewicht -> wieder bescheidene Leistungsskalierung ;)

Der MGPU Ansatz ist ja nicht schlecht. Nur ist er eben auch schweine teuer... Kein Schwein kauft sich 2x 800€ GPUs, wenn er nur 20 oder 30% Leistungsgewinn daraus erziehlt. Damit sich MGPU für die Zukunft (gerade auch in DX12) lohnt, muss eine Leistungsskalierung von 60-80% minimum vorhanden sein. AFR macht das schon ganz brauchbar. Nur eben überwiegen auch dort teilweise die Nachteile immernoch, trotz aktivem Gegensteuern ala Frame Pacing und Co.
 
Hmm, klingt wohl in der tat nicht so als ob man damit massiv Speicher einsparen können wird...
Könnte mir aber gut vorstellen dass solch ein System zumindest aktiviert ist und z.B. bei besonders masiven Objekten, Vorteile bringt.

Der MGPU Ansatz ist ja nicht schlecht. Nur ist er eben auch schweine teuer... Kein Schwein kauft sich 2x 800€ GPUs, wenn er nur 20 oder 30% Leistungsgewinn daraus erziehlt. Damit sich MGPU für die Zukunft (gerade auch in DX12) lohnt, muss eine Leistungsskalierung von 60-80% minimum vorhanden sein. AFR macht das schon ganz brauchbar. Nur eben überwiegen auch dort teilweise die Nachteile immernoch, trotz aktivem Gegensteuern ala Frame Pacing und Co.
Das ist ja grade ein Grund für SFR - Framepacing braucht man dann nicht mehr. Ob sich andere Nachteile (neben der Skalierung) auftun, wird sich wohl zeigen müssen.
 
Ich würde fast behaupten, man fährt eine Art mixed Mode. Sprich pinnt definierte Objekte an die GPUs ggf. auch gewisse andere Berechnungen (Physik, KI und was weis ich noch) -> dafür/damit erhält man klar auch den möglichen VRAM Vorteil. Die anderen Objekte, welche sich im Berechnungspool befinden, nutzen den restlichen freien Speicher.
Denkbar wäre sowas bspw., wenn in einem Shooter irgendwie IMMER die Waffe im Bild zu sehen ist -> kann man bequem pinnen und dann damit zumindest diesen VRAM Bedarf auf eine GPU beschränken. Sicher gibts noch andere Möglichkeiten. Ist ja immer so eine Sache der rangehensweise.

Ich denke aber auch, dass man in Zukunft nicht mehr so einfach vom Texturcacheverhalten wegkommt. Dafür ist der Zug lange bereits abgefahren. Das hätte vielleicht vor 5-7 Jahren noch funktioniert. Heute wird der VRAM derart massiv während der Spielzeit überbucht, dass man schon Mittel und Wege erfinden muss, damit die Software zur richtigen Zeit wenigstens die notwendigen Daten im Zugriff hat und nicht alten Mist von vorherigen Szenen den schnellen Speicher blockieren. Abhilfe schaft da freilich nur, die Texturqualität massiv zu senken und/oder die VRAM Kapazität massivst auszubauen. Vielleicht baut man auch in Zukunft dedizierten Texturspeicher auf die Grafikkarten oder ähnliches... Also billiger, dafür kapazitätreicher Speicher. Muss ja keinen TB/sec Datenraten erreichen... Ähnliche Ansatze gibts ja heute schon -> wo den GPUs sehr schneller xxxMB großer Cache beiseitegestellt wird anstatt den vollen VRAM Pool mit xxxGB/sec anzubinden. (XBox One, Intel Iris Pro, möglicherweise die kommenden AMD HBM GPUs usw.)
 
Die Lösung für V-Ram Probleme gibs schon länger. Zur Zeiten der Geforce 2 GTS gab es die STM Kyro II (u.a. 3D Prophet 4500). Leider hat die es nicht geschafft sich ins Gedächtnis der Spieler einzubrennen.
 
Hi, hier gabs doch mal die Diskussion vor ein paar tagen, bzgl. das Grafik nur noch gestreamt wird un nicht mehr vergleichbar sei. Hab das hier die Tage gefunden.


Ist das normal, das bei Nvidia weniger Effekte gezeigt werden?
Relativ deutlich zu sehen bei den Triebwerken der Raumschiffe und den Rauchschwaden der Granaten.
Auch bei 5:20 fehlt irgendwie der Nebel in der Schlucht, ...


Liegt das jetzt an AotS oder tritt das auch in anderen Spielen oder sogar Benchmarks wie 3DMark auf? Wie sieht es bei denen aus, wo Nvidia verhältnismäßig besser abschneidet?
Ist das ggf. sogar Absicht und lässt sich mit Umbenennen der exe "fixen"?

Kann das einer ggf. mal nachstellen?
 
Also die beiden Bildern laufen definitiv nicht mit selben Settings oder es gibt Elemente die die auf NV Grakas aus irgendwelchen Gründen schlicht nicht laufen.

Wobei ich auch sagen muss dass die "flares" der Triebwerke und Raketen auf der AMD Seite optisch zu intensiv sind. Das lenkt doch viel zu sehr von den schönen Details der Schiffe selbst ab.
Das Game ist aber natürlich auch noch nicht fertig.

Glaube in Benchmarks wie 3Dmark würde solch ein gravierender Unterschied jedenfalls auffallen...
 
Zuletzt bearbeitet:
Ich unterstelle nVidia trotzdem das die garantiert wieder mal cheaten....

Das Video spricht Bände....
 
Hi, hier gabs doch mal die Diskussion vor ein paar tagen, bzgl. das Grafik nur noch gestreamt wird un nicht mehr vergleichbar sei. Hab das hier die Tage gefunden.


Ist das normal, das bei Nvidia weniger Effekte gezeigt werden?
Relativ deutlich zu sehen bei den Triebwerken der Raumschiffe und den Rauchschwaden der Granaten.
Auch bei 5:20 fehlt irgendwie der Nebel in der Schlucht, ...


Liegt das jetzt an AotS oder tritt das auch in anderen Spielen oder sogar Benchmarks wie 3DMark auf? Wie sieht es bei denen aus, wo Nvidia verhältnismäßig besser abschneidet?
Ist das ggf. sogar Absicht und lässt sich mit Umbenennen der exe "fixen"?

Kann das einer ggf. mal nachstellen?

Ich würde mich ebenfalls freuen, wenn dieser Test reproduziert werden würde. Bei diesem Video kann man sich nämlich nicht ganz sicher sein, ob hier nun Nvidia absichtlich schlecht dargestellt wird oder es sich tatsächlich um einen weiteren Skandal handelt :confused:

Aber schonmal danke an unl34shed für das Finden und Posten dieses Videos.
 
Schon Krass. Wir hatten seit dem Jahr 2000 bis zur HD6000 Gen jedes Jahr einen Shrink, so gut wie jedes. Längstens hat es mal 2 Jahre gedauert für eine Struktuverkleinerung.

2013 Hab ich in dem Thread hier gepostet, das die 28nm HD7970 schon über 2 Jahre alt ist, und was wir doch für einen Krassen Technischen Stillstand hatten.
Dann hier im Thread fleißig weiter Spekuliert, das es doch garnicht so lange dauern kann bis die ersten Shrinks kommen.

Aber was haben wir bekommen ?
2014 kein Shrink
2015 kein Shrink
und jetzt 2016 hoffen alle auf Sommer. Und ich hab jetzt gelesen, das AMD zuerst nur Midrange Karten bringt, und die High End Karten im Shrink erst ende 2016 bzw Anfang 2017 kommen.

5 Jahre also quasi nur die Gleiche Technik mit mehr Shadern aufgebohrt. (Auf Architektur bezogen nicht auf HBM). So einen Stillstand hatten wir noch nie.
 
Wohl wahr...
Aber die Leistungssteigerung und auch die Effizienzsteigerungen waren trotzdem ganz passabel. Also so schlimm ists nicht. Bzw. das zeigt dass noch viel mehr getan werden kann, als "nur" zu schrinken.

Genau genommen zeigt sich langsam dass das Shrinken auch kaum noch was bringt. Intel hat jedenfalls nicht die Leistung und nicht mal die Effizienz durch ihren letzten Shrink signifikant verbessern können.

Hoffe allerdings dass dies bei den Grakas anders als bei den CPUs sein wird.
 
Und wieviele der vorherigen shrinks waren full-node shrinks? So weit ich weiß keiner. Vor 2 Jahren hätte 20nm released werden sollen, aber das wurde ja verbockt und deswegen gibt es immer noch 28nm.

In Zukunft wird es aber vermutlich wieder länger zum schrink dauern, da man sich einfach an physikalischen Grenzen bewegt.
 
Genau genommen zeigt sich langsam dass das Shrinken auch kaum noch was bringt. Intel hat jedenfalls nicht die Leistung und nicht mal die Effizienz durch ihren letzten Shrink signifikant verbessern können.

Also soweit ich informiert bin, konnte Intel die benötigte Die-Fläche pro Mrd. Transistoren von 22nm auf 14nm doch deutlich senken, damit dürfte auch die GFLOP pro mm² Leistung deutlich gestiegen sein. Zunehmend problematischer dürfte nur die Wirtschaftlichkeit kleinerer Strukturen werden.
 
Also soweit ich informiert bin, konnte Intel die benötigte Die-Fläche pro Mrd. Transistoren von 22nm auf 14nm doch deutlich senken, damit dürfte auch die GFLOP pro mm² Leistung deutlich gestiegen sein. Zunehmend problematischer dürfte nur die Wirtschaftlichkeit kleinerer Strukturen werden.
Das stimmt sicher (sonst wäre das Shrinken ja vollends absurd), aber was genau bringt das, wenn keine positiven Auswirkungen davon im Endprodukt ankommen?
Bisher bedeutete ein Shrink auch immer eine deutliche Effizienzsteigerung, aber dies scheint halt auch abzuflachen.
 
Nenn mir mal bitte ein Beispiel. Bin mir nicht sicher worauf du hinaus willst oder was du genau meinst.
 
Nenn mir mal bitte ein Beispiel. Bin mir nicht sicher worauf du hinaus willst oder was du genau meinst.

Er meint, dass das Endprodukt nach dem benannten Shrinks in irgend einer Weise einen Vorteil daraus hatte/hätte. Wie bspw. wenn du von xy nm auf abc nm shrinkst, die Leistung in etwa gleich bliebt, sich aber die Energieeffizienz angenommen verdoppelt. Oder sich die Leistung angenommen verdoppelt, ohne dass die Leistungsaufnahme steigt.

Ich halte allerdings den Vergleich mit den Prozessoren für nicht zielführend, denn die Ausrichtung ist doch eine ganz andere... Eine CPU, welche mit 4GHz und teils mehr taktet/takten soll, eine quasi fixe "Breite" in der Coreanzahl hat, sowie wo der GPU Part davon immer mehr wird, setzt ganz andere Anforderungen als eine GPU, wo es quasi ausschließlich reine Logik und durch erhöhen der Shadereinheiten auch idR mehr Leistung gibt.
Denn unabhängig der Intel Mainstream Modelle hat sich doch schon eine Menge getan. Ein 18 Core Prozessor wäre in den 32nm wohl nicht so möglich. Und da ist die absolute Größe des DIEs nur die eine Geschichte ;)
 
Gut erklärt. Ich finde das trifft es ganz gut auf den Punkt.

In 14nm (Intel) soll ein CPU-Kern auch nur noch eine Fläche von ca. 10mm² einnehmen. Bei einen Dual-Core wären das dann vielleicht 30% von der Gesamtfläche. Dagegen dürften die Shaderblöcke einer reinen GPU eher in die Richtung 80% gehen. Hier würde sich dann eine Strukturverkleinerung natürlich dann auch deutlicher bemerkbar machen.
 
Das stimmt sicher (sonst wäre das Shrinken ja vollends absurd), aber was genau bringt das, wenn keine positiven Auswirkungen davon im Endprodukt ankommen?
Bisher bedeutete ein Shrink auch immer eine deutliche Effizienzsteigerung, aber dies scheint halt auch abzuflachen.

Es Flacht garnichts ab. Schonmal geguckt wie viel Strom ein Skylake benötigt ?

Ein Skylake i7 @4,7 ghz auf allen Kernen mittels OC schluckt gerade mal 74W (ohne die igpu)
Weißt du wie viel ein 4,7ghz i7 Sandy Bridge gefressen hat ? Fast das Dreifache.

- - - Updated - - -

Hier verbraucht ein 2500k auf 4,5 Ghz bei 1,32v knapp 200 Watt:

http://www.computerbase.de/2011-01/test-intel-sandy-bridge/50/#abschnitt_overclocking

Beim 2600k und 200mhz mehr dürfte das also Definitiv über 220W liegen.

Man kann also sagen, zwischen 32nm und 14nm gabs eine Verdreifachung der Leistung pro Watt, selbst ohne den IPC Vorteil von Skylake mit einzubeziehen.

Wieso du daher von Abflachen sprichst, verstehe ich in keinster weise.
 
Ist es bei euch auch so das G-Sync nur mit aktivierten V-Sync IM Treiber funktioniert? Habs bei CSGO getestet, selbst mit Frame limitier 59,60 FPS gibts noch Tearing.
Wenn im Treiber nur G-Sync als Monitor Technologie eingestellt ist aber nicht V-Sync. Stellt man G-Sync aus und wieder an stellt der Treiber automatisch V-Sync an....
 
Bei den CPU´s spielt es sich eher im Serverbereich ab. Ein i7 Skylake auf 5 Ghz wird auch nicht mehr Leistung bringen als ein i7 Haswell-E mit 8 Kernen und 5 Ghz da die Anwendungen (Software) limitieren.
 
Zuletzt bearbeitet:
Keine Ahnung ob die Frage hier hingehört aber was geht denn auffm Graka Sektor ab ???

Meine Strix 970 die ich vor nem Jahr gekauft habe für 369 kostet jetzt 389 und als ich die vor nem Jahr gekauft hatte war die schon nen paar Monate draußen. Gibts heutzutage keinen Preisverfall mehr ?

Ich dachte die kostet auf keinen Fall mehr als 299,- und nun isse am Ende sogar teurer als damals.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh