AMD und die bescheidene Performance im DX11 CPU Limit

Ich stimme dir im grundsätzlichen zu und bin da bei dir.

Jedoch finde ich es, allgemein gesprochen, einfach ein Hammer das man aber solche highend Kisten quasi voraussetzt wenn man, nicht mal alles ultra, aber gut aussehend - über Konsolen Niveau - mit anständigen 60 fps haben möchte.

Klar. Ne 970 reicht dafür heute noch in den meisten Fällen, zumindest in fhd, selbst mit etwas größeren Einschränkungen hier und da auch noch in QHD, und auch mein Sandy kommt jetzt langsam mit seinen Takt in manchen Spielen, die auch recht gut optimiert sind (Projekt Cars 2 z. B.) langsam aber sicher an seine Grenzen.

Aber : gerade die großen bling bling Produktionen sind es zu meist die Probleme machen obwohl sie auf den mainstream mit schwacher hw ausgelegt sein sollten.

AC unity als worst case Beispiel mal benannt. Und dann gibt es eben auch Rosinen wie BF1 die auf n Toaster noch gut aussehen und recht gut laufen.

Das ganze Verhältnis passt hier und da einfach nicht zusammen zwischen dem wo es für ausgerichtet ist und dem was man aber tatsächlich braucht... Wovon die difinition von brauchen natürlich eine subjektive Frage ist...

Finde halt das oftmals die Verhältnisse nicht so richtig stimmen.

Dabei rede ich nicht mal von gehobene Ansprüchen wie 4k / 120 fps was auch immer. Sondern einfach gut aussehendes Gaming über Konsolen Niveau.

Gesendet mit Tapatalk
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wo habe ich geschrieben, dass sich der Content automatisch verbessert wenn die Entwickler LL nutzen?

LL ermöglich jedoch erst Content zu schaffen der anders nicht umsetzbar wäre. ZB AotS. Oder massiver Einsatz von Physik.

MT ist auch ganz offensichtlich alles andere als einfach unter DX11. Bestes Beispiel PUB und BF1.

Und solange man das ganze nicht nativ von vorne herein einsetzt bleibt es eine Spielerei. Sehr ähnlich zu Tesselation. Man erinnere sich an die "tollen" Effeke in Metro.

Um eine Engine und Spiel sinnvoll multithreaded umzusetzen Bedarf es vor allem eines großen Rundumschlags und Befreien von Altlasten. In der Regel wird Software immer weiter mitgeschleppt und somit ineffizient.

Der Witz ist, dass man ohnehin nicht drum rumkommt, so gerne Shappy dies auch möchte. Mit weiter steigenden Anspruch an den Content steigt auch die Belastung des Mainthreads. Während Einige das in Dx11 noch sehr gut umgesetzt bekommen, sind andere, gerade kleinere Studios bereits an die Dx11 Wand gefahren. Hier geht der Weg nur noch über Engine-Lizenzierung womit alle Titel ein ähnliches Verhalten an den Tag legen und von Vorteilen profitieren.
 
@ LDNV

Aus meiner Sicht ist eins der Probleme, warum das so ist, einfach der Punkt, wir sind auf einem Qualitätsniveau, wo man mit einfachen Mitteln nicht mehr so eben die Qualität sichtbar steigern kann.
Vieles kommt aus Details. Da macht es eben einen riesigen Unterschied bei der Atmosphäre, ob du mehr realistisches HBAO+ oder gar noch aufwendigere Verfahren nutzt anstatt gar keiner Umgebungsverdeckung oder nur statisches Zeug.
Schatten müssten fein sein und voll dynamisch. Reflektionen müssen vorhanden sein und den aktuellen Gegebenheiten entsprechen (dynamisch) usw. usf.
Das sind alles so Themen, bringt im Details viel und macht in Summe das Ergebnis stimmiger... Aber im einzelnen Betrachtet ist es meist sehr wenig, was man da an Qualität bekommt.

Ausreißer gibts natürlich immer. Muss man aus meiner Sicht aber eigentlich auch ein Stück weit differenzieren. Weil es idR völlig unklar ist, warum der Ausreißer eben so ist, wie er ist. Viele (vor allem in der Community) urteilen schnell. GPU/CPU Optimierung scheiße, Entwickler scheiße, Partnerschaften scheiße, Engines scheiße usw. -> aber hinter die Kulissen hat da "keiner" gesehen bzw. mal geschaut, warum das so ist.
Keine Frage, das mindert die Mit/Teilschuld der Entwickler generell nicht. Aber um es zu verstehen und zu urteilen wäre es eigentlich notwendig zu wissen... Wer sich in KI/Physikberechnungen "verrennt", bekommt bspw. 1A MT-Skalierung frei Haus... Dummerweise macht eine intelligente KI keine hübsche Optik, um mal ein Beispiel zu nennen. Was wird die Community draus machen? -> ein unoptimiertes Spiel und unfähige Entwickler. Vllt ist aber die KI das fortschrittlichste, was ein Spiel aktuell je gesehen hat??

LL ermöglich jedoch erst Content zu schaffen der anders nicht umsetzbar wäre. ZB AotS. Oder massiver Einsatz von Physik.

MT ist auch ganz offensichtlich alles andere als einfach unter DX11. Bestes Beispiel PUB und BF1.

Nur ist eben genau das Unsinn... Wenn ich MT will, dann nutze ich MT, das geht in jeder API und mit jeder Engine.
Beispiel: Der horn alte Fluidmark Benchmark basiert auf ner rudimentären mini Engine und es ist einzig und allein der Software-PhysX Anteil, der für extreme MT-Workloads sorgt/sorgen kann. Schau dir das Ding selbst an... Damit fährst du auch nen SKL-X 18C in die Ecke... Also bitte keine Märchen erzählen ;)

Nochmal für dich erklärt, es gibt nicht DAS CPU Limit. Es gibt viele viele kleine einzelne Baustellen. Und alle in Summe am Ende bilden den Workload. WENN nur eine von diesen Baustellen in ein Limit läuft, dann ist es vorbei mit Skalierung. Das ist in ALLEN APIs und mit JEDER Engine im Grundprinzip gleich.

Um eine Engine und Spiel sinnvoll multithreaded umzusetzen Bedarf es vor allem eines großen Rundumschlags und Befreien von Altlasten. In der Regel wird Software immer weiter mitgeschleppt und somit ineffizient.
Richtig, aber was hat das nun mit DX11 oder einer Lizenzengine zu tun!?
Warum sollte dieses Befreien von Altlasten nicht auch in DX11 oder OpenGL gehen? Oder mit der Engine in Eigenentwicklung?
Genau hier krankt deine Aussage ;)

Hier geht der Weg nur noch über Engine-Lizenzierung womit alle Titel ein ähnliches Verhalten an den Tag legen und von Vorteilen profitieren.
Auch das ist genau genommen Käse. Aus Entwicklersicht ist eine Eigenentwicklung nicht zwangsweise weniger, teils sogar mehr wert als ne Lizensierung. Vor allem mit steigender Komplexität.
Wenn du nämlich mehr Zeit zum Customizen der Kaufversion brauchst als um es selbst zu machen, hast du was falsch gemacht!

Aber auch das "lernt" man, siehe oben, erst, wenn man einmal selbst auf die Nase gefallen ist ;)
Kann andersrum aber halt auch so sein, also der versuch, es selbst zu machen MUSS nicht perse der bessere sein...
Mal davon ab, wie lange erzählst du das nun schon? Und wo sind die ganzen Titel? Ich sehe keinen flächendeckenden Einzug von Lizenzengines... Das ist alles im Rahmen der üblichen Nutzung. Es gibt bspw. hunderte PhysX based Games. Einfach weil es sich über die Jahre angesammelt hat. Das macht PhysX nicht automatisch zur Besten PhysX-Basis, nur weil es die meisten Lizenznehmer hat!

Wieder so ein Punkt, an dem die Aussage insich nicht schlüssig ist.
 
Sagmal du hast die Kernaussage bezüglich der Entwicklungszeit von primär auf DX12 entwickelter Software aber (eher nicht) verstanden oder?

Auch wenn ich bei dem Punkt Vulkan vs. DX12 mich nicht ganz so sicher aus dem Fenster lehnen würde, hinsichtlich der Plattformübergreifenden Kompatibilität, stimme ich seinem Beitrag im gesamten jedoch überein. Die ganze "wo bleibt denn jetzt das flächendeckende DX12/Vulkan" Diskussion ist müßig aufgrund der durchschnittlichen Entwicklungszeit von entsprechend Umfangreichen Games und der Engine die zugrunde liegt. Natürlich kann man DX12 oben drauf setzen, nachträglich, aber das wird niemals so optimirbar sein wie Nativ von Grund auf DX12 basierender Grundlage. Das ist nunmal die Realität.
Der Post war "sarkastisch" gestaltet, wenn du dir die Minimum FPS anschaust und die % Steigerung anschaust weist du was ich meine.
Das nehme ich natürlich auch beim nur gepimmten DX11 mit, dafür braucht es jetzt kein natives DX12.
 
Nur ist eben genau das Unsinn... Wenn ich MT will, dann nutze ich MT, das geht in jeder API und mit jeder Engine.
Beispiel: Der horn alte Fluidmark Benchmark basiert auf ner rudimentären mini Engine und es ist einzig und allein der Software-PhysX Anteil, der für extreme MT-Workloads sorgt/sorgen kann. Schau dir das Ding selbst an... Damit fährst du auch nen SKL-X 18C in die Ecke... Also bitte keine Märchen erzählen ;)

Nochmal für dich erklärt, es gibt nicht DAS CPU Limit. Es gibt viele viele kleine einzelne Baustellen. Und alle in Summe am Ende bilden den Workload. WENN nur eine von diesen Baustellen in ein Limit läuft, dann ist es vorbei mit Skalierung. Das ist in ALLEN APIs und mit JEDER Engine im Grundprinzip gleich.

Steht der Smilie eigentlich für die Selbstirnoie? Du ziehst also eine PhysX Benchmark als Beispiel heran? Ernsthaft? Nvidia hatte ageia gekauft gerade weil man Physik perfekt auf den taudenden Cores einer Graka skalieren kann. Zumal es auch nur ein einzelner Bestandteil in einem Spiel ist. Das ist wie CPU-Rendering, das skaliert auch nahezu perfekt.

Natürlich limitiert irgendwann ein einzelner Thread und limitiert die weitere Skalierung. Es kommt jedoch drauf an das dies möglichst spät passiert. Und ja es gibt Engines die skalieren nahezu perfekt, wobei es hier klare Grenzen mit DX11 gibt. Das eine Studio schafft es diese besser auzunutzen, andere krebsen bei lediglich 2 genutzen Threads rum.

Wenn Entwickler sagen, dass man spätens bei 16 Cores nicht mehr um LL drum rumkommt, dann gebe ich da mehr drauf als auf eine Aussage deiner Wenigkeit. Ein AotS zeigte bereits wozu LL in der Lage ist... Da kommst du mit DX11 nicht sehr weit.

Zumal MT einer, aber nicht der wichtigeste Punkt ist. Primär geht es daraum Singlethreadlast des Mainworkers zu reduzieren um mehr Drawcalls zu ermöglichen. Keine Ahnung was einige gegen LL haben. Ich wäre froh wenn meine PC-Software annäherend so effizient laufen würde wie auf Konsolen.

Warum soll ich mir jetzt auf Teufel komm raus DX12 Hardware kaufen und habe praktisch keine Vorteile, das ganze kann ich doch dann machen wenn es soweit ist ....

Gegenfrage: Warum sollte ich bei gleichem Preispunkt auf eine veraltete Technologie oder geringere Ausstatung setzen, auf die Gefahr hin, dass ich dadurch eher gezwungen bin wieder aufzurüsten. Es gibt halt Leute die haben keine Lust jede Grafikkartengeneration aufrüsten zu müssen, so wie du.
 
Zuletzt bearbeitet:
Wenn Entwickler sagen, dass man spätens bei 16 Cores nicht mehr um LL drum rumkommt, dann gebe ich da mehr drauf als auf eine Aussage deiner Wenigkeit.

16 kerne.. bis es eine gewisse menge an studios gibt, die gewillt sind dafür zu sorgen, das ihre spiele mit so vielen threads skalieren, haben wir warscheinlich dx14.
 
Multithreading ist gar nicht mal so das Problem bei LL-APIs. Das ist ein netter Nebeneffekt, der Prozessoren mit mehr als 8 Kernen irgendwann sinnvoller macht als jetzt. Es ist die Art der Entwicklung. Und da ist AotS sind unbedingt ein gutes Beispiel, denn dieses Game ist genaso "beschränkt" entwickelt worden wie alle anderen, da es ja DX11 unterstützen muss. Da ist unheimlich viel PR drin, um die Verkäufe bei Technikbegeisterten anzukurbeln, hat ja auch ganz gut funktioniert, von daher sehe ich das als schlechtes Beispiel. Man darf das jetzt nicht missverstehen, die haben schon nen klasse Job gemacht bei der Technik von dem Game.
Aber was ich meine, ist, dass Entwickler anders arbeiten können, wenn sie nur noch LL nutzen, man kann sehr viel näher an den Konsolenversionen bleiben und dadurch massiv Kosten einsparen. Zudem kann man vieles effizienter machen als jetzt und muss auf Beschränkungen wie Drawcalls weder auf der einen noch auf der anderen Plattform Rücksicht nehmen.
Bislang ist es so, dass auf Multiplattformtiteln auch die Konsolenentwicklungen Rücksicht auf die wenigen Drawcalls nehmen müssen, die der PC mit DX11 nur darstellen kann. Immerhin war das Drawcalllimit auch der Motor, der die LL-Entwicklung überhaupt ins Rollen gebracht hat.
Alle großen Engines werden auf LL umsteigen, die Frage stellt sich einfach nicht. Wie gesagt ist sämtliche auch nur halbwegs aktuelle Hardware fähig für LL (die letzte Karte die dazu nicht in der Lage war ist die HD6970!!!) und der letzte Softwarebremsklotz ist Windows 7, welcher aber überschätzt ist. Das gab es in der Geschichte der APIs überigens noch nie, dass der komplette Markt im Prinzip technisch schon dazu fähig ist. Die Entwicklungszeiträume sind halt weiterhin primär das Problem. Software braucht Zeit. Das war schon immer so und wird auch so bleiben. Man muss sich da ja nur mal anschauen, wie lange es gedauert hat, dass sich Multithreading auf einem akzeptablen Niveau befand. Jetzt geht die ganze Geschichte ja weiter mit Mutlithreading von Computetasks auf Grafikchips, nennt man asynchronous Compute. Da ist unheimlich viel Entwicklungszeit nötig um das wirklich effizient zu bekommen. Und das ist auch erst der blutige Anfang. Es werden API-Erweiterungen kommen, die das noch stark aufweiten werden. Aber das ist Entwicklungszeit, die sich lohnt, da die Erfahrungen für alle späteren Projekte weitergenutzt werden.
 
Zuletzt bearbeitet:
das ne hohe Rohleistung von Vorteil für Langlebigkeit ist, bezweifel ich. die höhere Rohleistung AMDs hat bisher immer auch zu höheren Temps geführt und damit auch zu mehr Leckströmen. die ja bekanntlich nicht zur längeren Lebenserwartung beitragen.

dx11 Schwäche ok, aber das AMD Karten nun auch noch eine kurze Lebenserwartung haben gegenüber der Konkurenz, sollte mal belegt werden. :hmm:
 
Naja die Karten der Generation 2013 sind dafür aber auch heute noch gut dabei, mit einer Titan/780 Ti/290(X) kommt man schon noch gut in Spielen mit, die sind auch heute noch knapp unter der Mittelklasse ala GTX 1060/RX580 unterwegs, für 4 Jahre alte Karten finde ich das nicht übel, auch die 7970 ist heute noch gut spieletauglich und die ist von 2011. Und dort haben die AMD Karten gegenüber ihren Nvidia Konkurrenten teils schon einen gehörigen Schub erfahren, lag aber vermutlich eher am VRam :fresse2:
 
Zuletzt bearbeitet:
dx11 Schwäche ok, aber das AMD Karten nun auch noch eine kurze Lebenserwartung haben gegenüber der Konkurenz, sollte mal belegt werden. :hmm:
ich wollte das bei dem Langlebigkeitsdingens von G3cko nur zu bedenken geben. ich habe da keine pauschale Aussage draus gemacht, wie du es verstehst.
 
G3cko meinte Langlebigkeit zu Performance und du gibts zu bedenken, dass auf Grund von Rohleistung und hohen Wärme Entwicklung das Ding aber dann früher abrauchen könnte, vermutlich ist da sogar was dran. :fresse:
 
Es wäre schön wenn ihr BTT kommen könntet. Die Befindlichkeiten von Geckos 7970 haben recht wenig mit dem Thema zu tun ;)
 
Steht der Smilie eigentlich für die Selbstirnoie? Du ziehst also eine PhysX Benchmark als Beispiel heran? Ernsthaft? Nvidia hatte ageia gekauft gerade weil man Physik perfekt auf den taudenden Cores einer Graka skalieren kann. Zumal es auch nur ein einzelner Bestandteil in einem Spiel ist. Das ist wie CPU-Rendering, das skaliert auch nahezu perfekt.
Nein, ich habe dir schlicht und ergreifend ein Beispiel gebracht, welches deine Pauschalaussage widerlegt. Physik hast du höchst selbst ins Spiel gebracht. Und ich sehe nichts von Lower Level APIs oder deinen geliebten Lizenzengines im Fluidmark. Das kann jeder Depp zusammen coden, der nur im Ansatz was von Software Entwicklung versteht.
Ergo, Aussage widerlegt. Punkt.

Es kommt jedoch drauf an das dies möglichst spät passiert. Und ja es gibt Engines die skalieren nahezu perfekt, wobei es hier klare Grenzen mit DX11 gibt.
Und immernoch hast du es nicht verstanden... Weder das Fluidmark Beispiel noch die Zusammenhänge. Es hängt NICHT an der Engine. Sondern daran, WAS der Entwickler am Ende da macht... Viel Physik = viel/gute MT Skalierung, viel KI = viel/gute MT Skalierung usw. UND das völlig API/Engine Unabhängig.

Das eine Studio schafft es diese besser auzunutzen, andere krebsen bei lediglich 2 genutzen Threads rum.
Beleg doch bitte einfach deine Aussagen...
Es werden weit mehr wie 2 Threads genutzt. Schau in deinen Taskmanager, wenn du es nicht glaubst. Das machen Spiele schon seit 10+ Jahren...
Aber ich weis schon, worauf das hinaus läuft -> du begehst den Fehler und verwechselst einfach Multithreading mit Threadskalierung.

Wenn Entwickler sagen, dass man spätens bei 16 Cores nicht mehr um LL drum rumkommt, dann gebe ich da mehr drauf als auf eine Aussage deiner Wenigkeit.
Ach weist du G3cko, ICH habe deinen Pauschalen Quatsch hier kommentiert. Nicht mehr und nicht weniger. Und das möglichst mit Beispielen belegt oder zumindest mit nachvollziehbaren Aussagen, wenn man sich damit beschäftigen möchte. Mehr möchte die meinige Aussagen überhaupt nicht bezwecken. Auf was du etwas gibst oder nicht, ist mir persönlich völlig egal... Denn sinnvolle Aussagen bekommt man von dir nicht. Du willst dich überhaupt nicht damit auseinander setzen, sondern predigst hier nur dein Zeug runter.

Schade dass du selbst nicht mal merkst, wie sehr du dich damit selbst argumentativ abschießt. Irgendwelchen Mist zu erfinden nur damit man was zum Widersprechen hat, zieht halt einfach nicht. Zumal du dir permanent selbst widersprichst. Oben behauptest du noch, MT mit DX11 sei so schwer... Jetzt sollen irgendwelche Entwickler (wer eigentlich?) was von ab 16 Cores erst LL erzählt haben? Das wären 32 Threads... SMT ist ja heute üblich, vor allem für die AMD Ryzen Leute... Dummerweise sind 32 Threads 4x so viel, wie heute üblich. Ja wo ist sie denn die MT Skalierung!? Wenn man erst ab 16 Cores um LL nicht mehr drum rum kommen soll?

Herr lass Hirn vom Himmel fallen... :rolleyes:

Kleiner Hinweis: Benches mit einer R280 tun es auch, dürfe einfacher zu finden sein ...

Unterstütz doch nicht immer diesen Unsinn!?
Er kommt gern mit HD7970 Aussagen, meint aber eigentlich HD7970GHz oder gar 280X Custom OC Karten...
Da stehen teils 10-15% Unterschied auf der Uhr, allein weil er sich das kleinste Modell (für den Namen) und das größte Modell für den Balken rauspickt...

:btt:
 
Zuletzt bearbeitet:
Jetzt sind wir eh wieder abgedriftet...


Ich sehe kein Core im "idle" :cool:
 
Er kommt gern mit HD7970 Aussagen, meint aber eigentlich HD7970GHz oder gar 280X Custom OC Karten...
Da stehen teils 10-15% Unterschied auf der Uhr, allein weil er sich das kleinste Modell (für den Namen) und das größte Modell für den Balken rauspickt...

:btt:

Wie oft noch. Durch die 7970 GHz-Edition wurden die OC 7970 Modelle (also praktisch die GHz) als günstigste Modelle überhaupt angeboten. AMD hat sich so konkurenz im gleichen lager geschaffen. Etwas ähnliches passiert vermutlich auch bald mit den GTX1070 Modellen durch die GTX1070Ti.

Und noch etwas. Du tust immer so als Foren-Guru, aber außer langen Beiträgen kommt da nix. Man schreibt 3 Sätze und bekommt eine A4-Seite zurück. Schreibt man eine A4-Seite kann man ein Buch aus deinem Posting binden lassen... Wie wäre es mal mit Links? Die sieht man bei dir höchst selten.
Stardock-CEO: DirectX 12/Vulkan wird mit 16-Kernern unumgänglich

Ich erinnere mich noch an die hitzige Disskusion und die Meinung von dir, dass Intel nie den 8 Core Sandy im Consumer-Umfeld gebracht hätte, obwohl der verspätete 4-Core-Die ein eindeutiges Indiz dafür war. Nun konntert Intel mit 18 Kernen, weil Sie es müssen.

Nvidia liefet zum Release ab, da kann man nix sagen, aber ältere Karten werden doch schnell mal hängen gelassen.
Bestes Beispiel Resident-Evil 7. Oben haut die TitanX alles weg. Unten säuft man gnadenlos ab. Ich habe mal keine Prozentwerte angegeben, damit man einmal sieht, dass die alten Karten unter Ultra-Settings noch sehr gut spielbare fps raushauen! Und an der 6GB Titan1 sieht man auch schön, dass es nicht am VRAM liegt. Auch interessant 7870 vs GTX680 im dann klaren VRAM-Limit.
Resident Evil 7: Technik-Test mit Benchmarks von 22 Grafikkarten - gruselig mit weniger als 4 GiB VRAM
ResidentEvil.png


Und natürlich gehört VRAM zur Kaufentscheidung dazu. Ohne HBCC hätte ich definitiv keine Vega gekauft. Aktuelle Games kratzen hier und da an +6GB. Würde meine Karte gerne wieder +4 Jahre nutzen...
Lustig auch, dass es von GTX970/GTX980 keine Versionen mit doppeltem VRAM gab und was eine 280x da noch raushaut. Wie gesagt, dass sind Ultra-Settigns , FullHD. Noch nichtmal einbischen die Einstellungen reduziert.
Wolfenstein 2 im ersten Technik-Test: Shooterfest mit Vega-Stärke, Vulkan only! [Großes Update]

Wolfenstein.png
 
Zuletzt bearbeitet:
Dann hast du nicht verstanden worum es mir ging. Ich habe schon vor Jahren geraten lieber einen 1230v3 oder einen 5820k zu nehmen. Hauptsache mehr Leistung in der Breite. Und genau in diese Problem sind die Leute glaufen die entsprechend beraten wurden.

Nein, du verstehst einfach nicht, dass deine Begründungen einfach nicht die Mehrheit der Spiele darstellen. Das mag vielleicht auf eine handvoll AAA-Spiele zu treffen, dass hier 4+ Kerne Vorteile haben, aber nicht für die ganzen anderen Spiele, welche es nicht einmal schaffen merklich mit mehr als 4 Threads irgendwie zu skalieren. Die meisten Leute interessieren sich für E-Sports Titel wie CS:GO, LOL, Dota usw. und das reichen 4 Kerne vollkommen aus.
Und um wirklich von Problemen mit reinen 4 Kernern sprechen zu können, sind wir noch sehr weit entfernt.


Für mich hört sich spiele BF1 über ein paar Stunden, und bekomme FPS-Einbrüche eher nach voll laufenden Ram an, als eine überforderte CPU. Der TE hat auch nur 8GB Ram, was für BF1 viel zu wenig ist und daher kommt es zu Nachladerucklern. Aber ist nur meine bescheidene Meinung :hust:

Aber auch hier stellst du einmal mehr deine Cherrypicking-Künste unter Beweis. :wink:
Du versuchst deine Aussage jetzt einfach mit irgendwelchen Foren Beiträgen zu beweisen, bei dem die Person mit den Problemen nicht einmal die empfohlenen Systemvoraussetzungen erfüllt. Liegt natürlich nur an der CPU und andere Faktoren können es nicht sein. :rolleyes:

Und das wie gesagt nicht nach Jahren, sondern 7600k vs AMD1600x aus März bis heute! Man muss keine hellseherischen Fähigkeiten besitzen um abschätzen zu können wie der Markt sich weiter entwickelt und welche Käufer eher wieder aufrüsten müssen. Nächstes Jahr gibt es auch 8 Kerne von Intel für 350€. 2019 bis 2020 wird es ähnlich weitergehen. Ein 350€ 7700k ist nun ein i3 für 150€. Core i3-8350K

Zu dem verlinkten Test. Nächster Cherrypick.
Die Aussage basiert auf einen untertakteten R7 1700 und somit können keine Rückschlüsse auf eine Intel CPU geschlossen werden, da diese sich anders Verhalten. Gerade der hohe Takt ist doch ein Vorteil von Intel und dabei hat Intel auch die bessere Singlethreadleistung. Dadurch schafft es die CPU von Intel mehr Threads auf einem Kern abzuarbeiten als Ryzen und kommt somit erst später ins Limit bei gleicher Kern/Thread Anzahl!
Auch muss hier die CCX Spezifika von Ryzen beachtet werden, denn je nachdem wie die Kerne deaktiviert wurden, steigen die Latenzen des L3-Caches oder dieser wird in der Größe verringert.

Es gibt 6 Kerner nicht erst seit März und auch schon das Gelaber von wegen 4 Kerner sind tot, gibt es deutlich länger, auch wenn dieses sich seit März verstärkt hat. :d

Und bevor es wieder von irgendwem kommt. Nein ich bin kein 4 Kern Verfechter, nur neigen manche gerne dazu diesen More-Cores-Do-Matter-Hype etwas zu übertreiben. :wink:

Aber das ist hier eh alles total Off-Topic, daher werde ich nicht weiter darauf eingehen. :wink:
 
@ Topic
CB hat AC:Origins getestet:
Assassins Creed: Origins im Benchmark (Seite 2) - ComputerBase

Wieder ein Spiel auf der Liste der scheinbar höheren CPU Limitierung bei AMD -> die Roten sind in FHD sehr schlecht. Quasi durch die Bank weg.
Andere Tests scheinen das zu bestätigen:
Assassin's Creed Origins те�т GPU/CPU | Action / FPS / TPS | Те�т GPU
-> wie man bei der Vega64 schön sieht, die CPUs oben erzeugen unterschiedliche Performance -> im GPU Limit (bspw. auf Polaris) kommt hingegen die gleiche Leistung bei rum.


Und der Wolfenstein Test:
Wolfenstein 2: The New Colossus im Benchmark (Seite 2) - ComputerBase
-> mit Vulkan API -> Vega dreht in niedrigen Auflösungen auf und kommt annähernd an die TI ran. Um so höher die GPU Belastung, desto weniger schlägt offenbar die Abhängigkeit der API zu und Vega "verliert" ggü. der TI wieder.

Die zweite Szene bei CB ist allerdings mit Vorsicht zu genießen. Würde ich erstmal nicht überbewerten und auf irgend ein Problem/Fehler schiebe.
Schaut man aber bspw. mal den GameGPU Test:
Wolfenstein II: The New Colossus те�т GPU/CPU | Action / FPS / TPS | Те�т GPU
Kommt ein interessantes Details zum Vorschein...
Die Vega64 rennt ins GPU Limit in diesem Test -> die TI aber nicht vollends.


@G3cko
Du streitest also um 50MHz hin oder her ...

Irgendwie widerhole ich mich...
Ich kritisiere an deiner Aussage, dass du permanent vom kleinsten Modell sprichst und das größte (oder ein OC) Modell meinst...

925 zu 1050 sind bei mir übrigens 125MHz, nicht 50 :wall:
Und im konkreten Zusammenhang sind das ~10-15% Leistungsunterschied, aber auch das sagte ich bereits.

Es ist offenbar zu schwer für dich, anstatt HD7970 einfach "HD7970 GHz", "HD7970 OC" oder "280X" zu schreiben :rolleyes:
Nein, da muss es natürlich die bis zu 925MHz HD7970 sein um einfach besagte 10-15% Leistung unter den Tisch fallen zu lassen. Stattdessen zeigst du hier irgendwelche Preise und verlinkst einen Test, wo die 670 um 12-17% langsamer als eine HD7970GHz/280X ist. Finde den Fehler, andem das absichtliche unterschlagen von pro 10-15% Performance ein Problem wird!!!

Meinst du wirklich, wir sind hier zu blöd um deine Spielchen zu blicken!? Wenn man dich auf eine Sache hinweist, mehrfach und von verschiedenen Personen, solltest du vllt einfach mal drüber nachdenken, ob du nicht doch auf dem Holzweg bist. Falls du das nicht kannst, troll einfach woanders... Es ist OT und nervt. :btt:
 
Und der Wolfenstein Test:
Wolfenstein 2: The New Colossus im Benchmark (Seite 2) - ComputerBase
-> mit Vulkan API -> Vega dreht in niedrigen Auflösungen auf und kommt annähernd an die TI ran. Um so höher die GPU Belastung, desto weniger schlägt offenbar die Abhängigkeit der API zu und Vega "verliert" ggü. der TI wieder.

Die zweite Szene bei CB ist allerdings mit Vorsicht zu genießen. Würde ich erstmal nicht überbewerten und auf irgend ein Problem/Fehler schiebe.


Es gibt derzeit noch Probleme mit Wolfenstein bei AMD sowie Nvidia und läuft daher wohl nicht so ganz, wie es eigentlich sollte. Z.B. wurde Async Compute bei den Karten von AMD bis jetzt noch gar nicht genutzt und auch bei Nvidia scheint es auch noch nicht ganz so rund zu laufen, insbesondere bei der 1080ti.

10/28 - Beta Patch Live (Steam Overlay, Async Compute, JP Fixes) :: Wolfenstein II: The New Colossus General Discussions
Wolfenstein 2 Beta-Patch: Async Compute bringt 5 Prozent auf einer RX Vega 64 - ComputerBase

Und ob das Spiel Rapid das Feature Rapid Packet Math von Vega schon benutzt, geht auch noch nicht so ganz hervor. Obwohl es ja im voraus ganz groß angekündigt wurde, dass Wolfenstein neben Far Cry 5 dieses Feature nutzen soll.
 
Dennoch gibt es bisher von Treiber zu Treiber teils deutliche Verbesserungen für Vega und das ist kein schlechtes Zeichen und lässt hoffen, dass es sich ähnlich entwickelt wie seinerzeit bei 7970XX oder nicht? :)
 
OK, um noch mal auf das thread Thema zu kommen, ist die besagte AMD dx11 Schwächte den nun eine Hardware oder eine Softwareproblem eigendlich aus heutiger Sicht und auch als Ergebnis dieses threads?
 
Zuletzt bearbeitet:
ja. sowohl ein hard- als auch ein software-Problem. AMD kriegts nicht hin, die eigenen TFlops softwaremäßig so aufn Monitor zu bringen, wie die Konkurrenz.
wahrscheinlich sitzen auch bei AMD die Probleme vorm PC und nicht drin.
ein Ergebnis kann es so ja nicht geben. aber nen Stand der Dinge. da haben sich 3, 4 Spiele dazugesellt, aber im Großen und Ganzen ist es nach wie vor unverändert.
 
mmh das wäre krass, dann hätten sie das Problem seit GCN1 bis heute mitgeschliffen :shake:

Schöne neue Welt :fire:
 
mmh das wäre krass, dann hätten sie das Problem seit GCN1 bis heute mitgeschliffen :shake:

Wieso?
GCN hat bis auf Vega doch nur Detailänderungen erfahren...

Das Problem selbst ist schon viel älter... Frag mal die Leute, welche hier versucht haben mit HD6970 CF Gespannen im BF3 Multiplayer auf hohe FPS zu kommen :wink:
Oder schau dir Benches zur HD5970 an -> mit sehr sehr mauer CF Skalierung obwohl die Titel im Detail teils annähernd Faktor 2 zulegen mit CF.


Bei NV hat es das halt exakt genau so. Der MT-Aufsatz bei der API ist aber im Moment noch dafür gut, oben raus ein paar Prozent über dem AMD Level zu abzuliefern. Was vor allem im API-Limit eben die NV Modelle pusht. Setzt aber eben oftmals mehr CPU Leistung voraus. Ohne diese skaliert das halt auch nicht. Es kommt also auch bei NV nicht einfach aus der Luft!
 
mmh das wäre krass, dann hätten sie das Problem seit GCN1 bis heute mitgeschliffen :shake:

Schöne neue Welt :fire:
Naja, aber nur wenn man ein Spiel nicht Patcht, also immer noch mit der selben Version wie am Release Tag spielt.
Wobei das nicht so schlimm ist wie mit Beta Versionen zu Vergleichen. :fresse:

Thief 2014 mit DX11 CF Win1703:
 
Zuletzt bearbeitet:
@Phantom

So schaut's aus :bigok:
 
ja. sowohl ein hard- als auch ein software-Problem. AMD kriegts nicht hin, die eigenen TFlops softwaremäßig so aufn Monitor zu bringen, wie die Konkurrenz.
wahrscheinlich sitzen auch bei AMD die Probleme vorm PC und nicht drin.
ein Ergebnis kann es so ja nicht geben. aber nen Stand der Dinge. da haben sich 3, 4 Spiele dazugesellt, aber im Großen und Ganzen ist es nach wie vor unverändert.

Ich glaube eher das es ein konzeptionelles Problem im Aufbau der einzelnen CUs ist. Also das AMD das Augenmerk eben nicht auf perfekte "Spiele" CUs legt, sondern eher Richtung multipurpose geht. Das bedeutet dann im Umkehrschluss aber für Spieler auch, das Rohleistung auf der Strecke bleibt. Eben weil der Treiber die CUs nicht zu 100% auslasten kann.
Das resultiert dann darin, das eine AMD Gpu mit x tflops in Spielen langsamer ist als eine NV Gpu mit x tflops.

Deshalb bin ich mittlerweile der Meinung das AMD am grundsätzlichen Aufbau der CUs arbeiten müsste um dieses "Problem" (obs überhaupt eins ist wäre dann die nächste Frage...) aus der Welt zu schaffen.
 
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