Test Dirt Rally Benchmarks: AMD liegt vorne, bleibt aber nicht unfallfrei

[Drummermatze]

Bringt nichts, egal wievielen Usern das auffällt und wie viele sich dazu äußern, Hopfen und Malz und so. Ist eben schon etwas länger die NvidiaBase - warum nicht gleich das blaue Theme auf Grün ändern

Fakt: Im Nvidia Forum kann man sich besser über Grafikkarten unterhalten als hier. Hier gibts nur Fanatiker.

Seltsamerweise lese ich in letzter Zeit immer wieder solche Kommentare.
Dabei sehe ich in letzter Zeit aber 95% AMD Fanboys die über nVidia herziehen und ihre eigenen Karten in den Himmel loben.
Und genau diese Leute hauen dann so einen Satz raus.
Müsst ihr irgendwas kompensieren?

 

[Wolfgang]

Die Überschrift ist natürlich wieder typisch CB. Und ich frage mich weiterhin, warum CB Battlefront nicht gebencht hat...

? Haben wir doch, hier:
https://www.computerbase.de/artikel...lefront-erste-benchmarks-der-open-beta.51910/
Mag ja die Open Beta sein, die läuft aber nicht anders als die final.

Und was ist an der Überschrift problematisch? Das sie die Wahrheit sagt? Das AMD-Problem ist deutlich schwerwiegender als die zwei Objekte, die bei Nvidia bei CMAA nicht dargestellt werden.

Bringt nichts, egal wievielen Usern das auffällt und wie viele sich dazu äußern, Hopfen und Malz und so. Ist eben schon etwas länger die NvidiaBase - warum nicht gleich das blaue Theme auf Grün ändern

Am lustigsten finde ich bei solchen Bemerkungen, dass AMD noch NIE (nie!) soetwas auch nur angedeutet hat. Wir (AMD und CB) kommen gut miteinander aus. Wäre es anders, wären wir wohl nicht letzte Woche erst auf Kosten von AMD in den USA gewesen. Genauso kommen wir auch mit Nvidia gut aus. Ihr Leser seht da echt Zustände, die selbst die betroffnenen Unternehmen nicht sehen...

 

[Grundkurs]

Update 19:13 Uhr
Wie AMD ComputerBase soeben informiert hat, ist man sich der Grafikfehler bei der Darstellung der Vegetation bewusst. Der Radeon-Entwickler hat ein Treiber-Update in Aussicht gestellt, das sich dem Problem annehmen soll. Einen genaueren Zeitraum für die neue Crimson-Version konnte man aber noch nicht benennen.

Der Grafikbug war über 7 Monate bekannt und es braucht erst einer Erwähnung durch ein reichweitenstarkes Medium wie Computerbase damit sich AMD endlich mal rührt!
Ein großes Lob an Computerbase, das sie das Thema im Test deutlich angesprochen haben!
MSAA kostet bei meiner R9 270X zu viel Leistung, daher hab ich es ausgelassen zwecks guter Framerates und mich dafür dann über das deutlich sichtbare Textur-Raster in der Vegetation schwarzgeärgert.

Ein Armutszeugnis, dass AMD jetzt erst reagiert.

 

[domidragon]

Hat mal jemand versucht anstatt mehr Kantenglättung einzusetzen, weniger, sprich keine Kantenglättung einzusetzen und dafür einfach auf 2.160 zu zocken, anstatt auf 1080p, oder 1440p ?

Was man an Mehrleistung braucht für die höhere Auflösung, müsste doch durch die wegfallende Kantenglättung wieder frei werden, oder nicht ?
Sieht das in 2160p denn noch so aus, als bräuchte man da noch Kantenglättung ?

Edit: Gerade wegen der manchmal einsetzenden "Unschärfe" mag ich so manche Kantenglättungsoption nicht so.
Manchmal wird's richtig matschig. Da wäre doch einfach höhere Auflösung ohne Kantenglättung besser, weil "schärfer".

Downsampling kostet nun mal immer deutlich mehr Leistung als MSAA oder dergleichen. Dafür nimmt es per se natürlich alle Objekte mit. SSAA wäre da die alternative, was aber durch die Downsampling einbindung bei Nvidia überflüssig wurde.
MSAA ist eine kompromiss Lösung, welches gut arbeiten (kann) aber auch entsprechend Leistung kostet.
Da ist man aber stark von der Engine und der Entwickler abhängig, wie gut die MSAA implementieren (können)

TXAA ist eine weitere kompromiss Lösung von Nvidia, welche gute ergebnisse liefern (kann) und im besten fall weniger Perf. frisst als MSAA.

FXAA und all die Post möchte gern Kantenglättungen kann man alle in die Tonne werfen, da wird das bild einfach unscharf, kein Wunder, wenn man sich die Funktionsweise dieser anschaut.

Bei Downsampling ist man halt stark von der eigenen GPU Leistung abhängig.

 

[DocWindows]

Ihr Leser seht da echt Zustände, die selbst die betroffnenen Unternehmen nicht sehen...

Sind doch immer nur ein paar und auch immer die Selben. Kann man ignorieren.
Gibts die Möglichkeit die Fehler anhand von Screenshots zu zeigen? Sowohl die fehlenden Objekte wie auch die Texturfehler? Mich würde die Schwere interessieren und inwieweit sie jeweils das Spielerlebnis vermiest.

Der Grafikbug war über 7 Monate bekannt und es braucht erst einer Erwähnung durch ein reichweitenstarkes Medium wie Computerbase damit sich AMD endlich mal rührt!

Bei Project Cars ist man auch aus allen Wolken gefallen. Ich denke man hat manche Early Access Spiele einfach nicht im Blick, aus welchen Gründen auch immer.

 

[spreagadh]

MSAA kostet bei meiner R9 270X zu viel Leistung, daher hab ich es ausgelassen zwecks guter Framerates und mich dafür dann über das deutlich sichtbare Textur-Raster in der Vegetation schwarzgeärgert.
Anhang anzeigen 530347
Ein Armutszeugnis, dass AMD jetzt erst reagiert.

Der Fehler wird aber halt auch leider selbst bei 8xMSAA nicht behoben. Es ist zwar nicht mehr ganz so schlimm wie auf deinem Screenshot, vor allem das Gras sieht ein bisschen besser aus. Aber die Bäume haben immer noch haargenau die selbe Textur.

Wirklich ganz schwach von AMD...zumal es das selbe Bild schon bei DIRT3 gab und dort nie behoben wurde...

 

[PTS]

Ich halte die Kantenglättung-Vergleichsvideos für unfassbar sinnlos. Warum macht ihr euch die Arbeit? Spart sie euch lieber. Man sieht auf den Video NIEMALS einen Unterschied. Alles sieht 100% gleich aus. Die Kantenglättungsthematik wird eh total überbewertet meiner Meinung nach.

bitte was? überbewertet? Ich spiele kein einziges spiel ohne Kantenglättung, alles andere ist augenkrebs
Das man im Video keinen Unterschied sehen kann kann ich nicht beurteilen, hab die Videos nicht gesehen aber kann sein das die Qualität der Videos es nicht zulässt zu erkennen was besser ist aber Kantenglättung ist meiner Meinung ein sehr wichtiges Feature um Spiele schöner aussehen zu lassen!

 

[Zehkul]

Wenn AMD an der Problematik nicht schnellstens was ändert, könnte ihnen das entgültig das Genick brechen. Auf DX12 ist doch eh kein Verlass. Bis das mal flächendeckend genutzt wird vergehen noch mindestens 2 Jahre.

Glaube ich nicht. Nächstes Jahr kommen einige Gaming Evolved Titel, und die dürften großteils Vulkan oder DX12 Renderer haben.

Das alles wäre an und für sich auch gar nicht das Problem, denn DX12 steht ja quasi vor der Tür. Das Problem ist, dass nicht jemand kommt und über Nacht einen Schalter umlegt und am nächsten Morgen läuft dann plötzlich alles ohne diese Flaschenhälse unter DX12 was vorher unter DX11 lief.

Doch, eigentlich schon. Ein naiver DX12 Port ist recht schnell erledigt. Was schwierig ist, ist die API auch wirklich sinnvoll und zu ihrem vollen Potenzial zu nutzen

Es ist auch noch unklar ob Neuentwicklungen zwingend gleich auf DX12 setzen, denn dies wird ja nur von Windows 10 unterstützt.

Dafür gibts ja Vulkan. Hoffentlich. Bald™. So langsam wird es echt Zeit.

 

[DocWindows]

Doch, eigentlich schon. Ein naiver DX12 Port ist recht schnell erledigt. Was schwierig ist, ist die API auch wirklich sinnvoll und zu ihrem vollen Potenzial zu nutzen

Ein naiver vielleicht , ich glaube aber nicht dass ein nativer Port so einfach ist, weil eben das Grundkonzept ein anderes ist. Wenn man dem Entwickler mehr Verantwortung überträgt, dann muss er die auch wahrnehmen. Ich weiß nicht genau wie viel von dieser Verwantwortung die Gameengine übernehmen kann. 100% sicherlich nicht. Und dann fragt man sich eben was es für einen Nutzen hat DX12 zusätzlich anzubieten wenn man auch DX11 anbieten kann und damit dann gleich alles abdeckt. Diesbezüglich kann man sich eigentlich nur eine schnelle Verbreitung von Windows 10 wünschen.

Dafür gibts ja Vulkan. Hoffentlich. Bald™. So langsam wird es echt Zeit.

Wenn Vulkan wieder so eine halbgare Kompromisslösung wie OpenGL wird, kannste es als ernsthafte Konkurrenz gleich vergessen. Ein Entwickler von X-Plane, einem OpenGL-Spiel mit Multiplattformfähigkeit (Windows, Mac, Linux), sagt zu OpenGL immer gerne "code it once, debug it everywhere". Sowas kann vielleicht für Indietitel funktionieren, aber nicht für AAA-Schlüsselspiele. Von der Tatsache dass auch Vulkan nur 3D-Grafik abdeckt und für Sound, Input, etc. wieder andere Dinge eingesetzt werden müssen fang ich gar nicht erst an.

 

[paccoderpster]

TXAA ist eine weitere kompromiss Lösung von Nvidia, welche gute ergebnisse liefern (kann) und im besten fall weniger Perf. frisst als MSAA.

FXAA und all die Post möchte gern Kantenglättungen kann man alle in die Tonne werfen, da wird das bild einfach unscharf, kein Wunder, wenn man sich die Funktionsweise dieser anschaut.

TXAA ist vom "Weichzeichnungsfaktor" her auch nicht besser.

 

[Zehkul]

Ein naiver vielleicht , ich glaube aber nicht dass ein nativer Port so einfach ist, weil eben das Grundkonzept ein anderes ist.

Was soll hier nativ und nicht nativ heißen? Nativ ist alles. Die neuen APIs zwingen dich nicht dazu, irgendetwas auf eine bestimmte Art und Weise zu machen und geben auch nicht magisch Multithreading, sie behindern Anwendungen lediglich nicht dabei, es selbst zu implementieren, geben mehr Freiheit. Nativ ist aber alles, da ist nix mit Wrappern und Emulation.

Ich weiß nicht genau wie viel von dieser Verwantwortung die Gameengine übernehmen kann. 100% sicherlich nicht.

Das Rendering ist zu 100% Verantwortung der Game Engine, doch.

Und dann fragt man sich eben was es für einen Nutzen hat DX12 zusätzlich anzubieten wenn man auch DX11 anbieten kann und damit dann gleich alles abdeckt.

Denselben wie Mantle: Läuft gut mit AMD.

Wenn Vulkan wieder so eine halbgare Kompromisslösung wie OpenGL wird, kannste es als ernsthafte Konkurrenz gleich vergessen. Ein Entwickler von X-Plane, einem OpenGL-Spiel mit Multiplattformfähigkeit (Windows, Mac, Linux), sagt zu OpenGL immer gerne "code it once, debug it everywhere". Sowas kann vielleicht für Indietitel funktionieren, aber nicht für AAA-Schlüsselspiele.

Man merkt, wie wenig Ahnung du von Vulkan hast. (Protip: Nur weil es keine komplette Spec gibt, heißt das nicht, dass es nicht schon genug andere Information gibt)
Vulkan ist eine explizite API mit vendor neutralem Loader und Validation Layer, der GLSL Compiler ist ebenfalls aus dem Treiberstack in einen vendor neutralen Bytecode Compiler zu SPIR-V ausgelagert. Heißt auch, dass kein Quellcode mehr geshippt werden muss und es keine spontanen Shader Recompiles gibt.

OpenGL ist übrigens auch alles andere als halbgar. Das Problem von Khronos war nie Inkompetenz, im Gegenteil. OpenGL das Genick gebrochen hat, wie lange es zu 3.0 gedauert hat. Khronos ist langsam. Dennoch nicht so langsam wie Microsoft, denn OpenGL4+ kann schon extrem vieles von dem, was nun als Argument für DX12 genutzt wird, nur ging der Fokus nun von OpenGL weg, bevor das irgendwer wirklich nutzen konnte. Der ein oder andere Linuxport, aber da die Engines nun mal alle für DX11 geschrieben sind und modernes OpenGL eher in Richtung DX12 gehen möchte, wird das mit simplen Ports einfach nichts, performancetechnisch.

Von der Tatsache dass auch Vulkan nur 3D-Grafik abdeckt und für Sound, Input, etc. wieder andere Dinge eingesetzt werden müssen fang ich gar nicht erst an.

Gut so, denn der Teil ist wirklich irrelevant. ;-)

 

[BlubbsDE]

@DocWindows

OpenGL ist eine halbgare Kompromisslösung? Das ist interessant. Und nur für Indietitel brauchbar? Abwertend arroganter gehts wohl kaum. Sowohl OpenGL gegenüber als auch der Entwickler von Indietiteln gegenüber. Nur mal ein Tipp. Schau Dir mal den Entwickler ID-Software an.

 

[DocWindows]

@BlubbsDE: Ich weiß nicht was du da für eine Arroganz hineininterpretieren willst. Und mit Wortverdrehen brauchst du auch gar nicht erst anfangen. Wüsste auch nicht was es bringen sollte mir ID-Software anzuschauen. Viel zu sehen gibts da ja nicht.

Was soll hier nativ und nicht nativ heißen?

Musst ja ziemlich aufgeregt sein, wenn dir ein Späßchen zu deinem eigenen Schreibfehler nicht auffällt. Immer schön locker bleiben. Keiner will dir was tun

Vulkan ist eine explizite API mit vendor neutralem Loader und Validation Layer, der GLSL Compiler ist ebenfalls aus dem Treiberstack in einen vendor neutralen Bytecode Compiler zu SPIR-V ausgelagert. Heißt auch, dass kein Quellcode mehr geshippt werden muss und es keine spontanen Shader Recompiles gibt.

Ja, in der Theorie ist immer alles super usw. OpenGL ist in der Theorie auch super und die Extensions sind da auch ne Mörderidee. Nur eben in der Praxis nicht. Wir werden schon noch früh genug sehen was Vulkan kann und wie es wird.

Was OpenGL das Genick gebrochen hat, wie lange es zu 3.0 gedauert hat. Khronos ist langsam.

Da gibt es noch mehr Gründe, aber das ist hier ja nicht das Thema. Könnte man in einer OpenGL News mal erörten, falls es je eine solche geben sollte. Bin eh schon verblüfft ob der Diskussion um Hertz, Augen und FPS. Da klickt man auf eine Benchmark-News für ein Spiel und findet sich in einer Biologievorlesung wieder Amazing!

 

[BlubbsDE]

Was habe ich denn verdreht? Und warum gibt es da nichts zu sehen bei ID? Alle iD Tech 5 basierten Spiele rendern via OpenGL. Und das ist nur ein Beispiel eines Entwicklers.

 

[DocWindows]

Was habe ich denn verdreht?

Den Sinn meiner Aussagen

Und warum gibt es da nichts zu sehen bei ID?

Quake, Doom, Rage, Fertig

Alle iD Tech 5 basierten Spiele rendern via OpenGL.

Laut Wikipedia genau 5 Spiele

Und das ist nur ein Beispiel eines Entwicklers.

Viel mehr gibts auch nicht, oder?

 

[BlubbsDE]

Sicher gibts da mehr. Viel mehr. Wirst Du auch finden, wenn Du Deine Windows Brille abnimmst. Und ja, auch unter Windows. Aber nur eben ohne Deine Windows Brille.

 

[ChrisMK72]

Downsampling kostet nun mal immer deutlich mehr Leistung als MSAA oder dergleichen. Dafür nimmt es per se natürlich alle Objekte mit. SSAA wäre da die alternative, was aber durch die Downsampling einbindung bei Nvidia überflüssig wurde.

Ja, danke.

Hab's mir gestern spontan gegönnt(Dirt Rally) und konnte Abends nur noch kurz die Einstellungen so einrichten, dass es bei mir gut läuft und gut aussieht.
War am Ende bei UHD mit CMAA angekommen und einige Einstellungen runtergeschraubt, bzw. ausgeschaltet.
Auf meinen bei UHD 60Hz hab ich eh Frameratetarget auf 50, um auch ohne Vsync kaum/kein tearing zu haben und hab im Benchmark zwischen 42 und 50 fps. Glaub irgendwas um die 48 Durchschnitts-FPS am Schluss.

Sieht so klasse aus muss ich sagen.
Hätte nicht gedacht, dass es so gut läuft mit ner 670er.

Kam nur noch nicht zum Spielen.
Schätze mal, dass es sicher im Spiel einige Stellen gibt, wo die FPS mal einbrechen, im Gegensatz zum Benchmark !?
Jedenfalls läuft der Benchmark gut in UHD. Evtl. spiel ich aber später trotzdem in Full HD mit 8x MSAA, oder so.
Mal schauen.

Wollte eigentlich erst mit meiner nächsten GPU und neuem Monitor auf 21:9 Dirt Rally zocken, aber nach den guten Bewertungen und dem Angebot auf Steam konnte ich nicht widerstehen, jetzt schon zuzuschlagen

Bin aktuell noch auf der Arbeit und werd' nachher mal testen, wie's im Spiel läuft.
Sieht aber echt klasse aus, das game. Endlich mal wieder n Grund das Lenkrad rauszuholen.

 

[DocWindows]

@BlubbsDE: Ja, so viele dass du nur einen Entwickler auflistest, der darüber hinaus auch noch eins der schlechtesten Beispiele ist. Aber vielleicht seh ich die anderen auch nicht weil ich die Windows-Brille auf habe

Hättest wenigstens die Multiplattform-Spieleengineanbieter anführen können. Aber gut, lass ma stecken ;-)

 

[VikingGe]

Musst ja ziemlich aufgeregt sein, wenn dir ein Späßchen zu deinem eigenen Schreibfehler nicht auffällt.

Ich glaube, du hast einfach nur nicht begriffen, dass das kein Schreibfehler war, sondern genau so gemeint war wie es da steht.

Ein paar Dx12-Features an einen existierenden Dx11-Renderer anflanschen dürfte letztendendes nicht viel schwieriger sein als viel zu übertriebene Dx11-Tessellation auf die ineffizienteste Art und Weise in einen Dx9-Renderer einzubauen, und viel mehr waren die ersten so genannten Dx11-Spiele ja nicht.
Damit das Marketing dann sagen kann, man habe ein Dx12-Spiel. Und eine solche Umsetzung bezeichnet man eben als naiv.

Von der Tatsache dass auch Vulkan nur 3D-Grafik abdeckt und für Sound, Input, etc. wieder andere Dinge eingesetzt werden müssen

Soll Vulkan jetzt Polygone an die Soundkarte schicken? Hast du überhaupt irgendeine Idee, wie die verschiedenen Subsysteme miteinander interagieren?

Könnte man in einer OpenGL News mal erörten, falls es je eine solche geben sollte. Bin eh schon verblüfft ob der Diskussion um Hertz, Augen und FPS.

Du willst also sagen, OpenGL sei grundsätzlich langsam? Was ist mit Direct3D-Spielen, bei denen sich die Leute über die Performance aufregen, weil die Entwickler mit ihrem Werkzeug nicht umgehen können (Dying Light, DayZ, ...)? Warum laufen Id Tech 5-Spiele, bei aller berechtigter Kritik an der Engine, auf so ziemlich jedem Toaster mit konstanten 60 FPS?

Ein Entwickler von X-Plane, einem OpenGL-Spiel mit Multiplattformfähigkeit (Windows, Mac, Linux), sagt zu OpenGL immer gerne "code it once, debug it everywhere".

Weil AMD zu blöd ist, das ganze vernünftig zu implementieren, ja. Das ist in der Tat ein Problem bei GL - welches Vulkan aber gar nicht in dem Maße haben kann, weil die Spezifikation a) deutlich simpler ist (implizite globale Zustandswechsel sind der Feind eines jeden Programmierers) und b) vieles (Lifetime von Objekten, z.B.) der Anwendung überlässt.

Letztenendes sind die Low Level-APIs jedenfalls nicht viel mehr als Schnittstellen für VRAM-Verwaltung, Shader-Compiler und eine Abstraktionsschickt, um klar definierte Aktionen irgendwie vom Treiber in GPU-Befehle zu übersetzen.

Das Problem von Khronos war nie Inkompetenz, im Gegenteil. OpenGL das Genick gebrochen hat, wie lange es zu 3.0 gedauert hat.

Das Problem von OpenGL 3.0 war vor allem, dass die Khronos-Gruppe letztenendes auf die Leute gehört hat, die keine Lust hatten, ihre Renderer umzubauen. Der Schritt von GL 2.1 auf GL 3.x ging ja quasi einher mit dem Wechsel weg vom Fixed-Function-Modell, bei dem die Grafikkarte (immerhin schon mit Hilfe von Fragment- und Vertex-Shadern) nur Bilder malen durfte, hin zu einem deutlich abstrakteren General Purpose-Modell. Dafür braucht man aber für das einfachste Beispielprogramm zum Rendern eines Dreiecks schon den halben Funktionsumfang des gesamten Core-APIs.

Da hätte man besser gleich bei 0 anfangen können, um dann auch gleich mal die Programmiermodelle auf den Stand des aktuellen Jahrtausends zu bringen (DSA zum Beispiel, wollte man seit Ewigkeiten haben, kam erst letztes Jahr mit GL 4.5). Zumal man mit GL 3.2 und der Einführung des so genannten Core Profiles ohnehin den ganzen Fixed Function-Legacy-Mist mehr oder weniger rausgeworfen hat.

Dafür gibts ja Vulkan. Hoffentlich. Bald™. So langsam wird es echt Zeit.

Dito. Mir juckt es schon in den Fingern, das bisschen, was ich im Moment zum Rendern habe, wenigstens mit einem modernen und durchdachten API zu rendern.

 

[IngoKnito]

Wieso sind die Testergebnisse auf CB so niedrig? In dem Tabelle steht bei 2560x1440 für die 980Ti 83,6 FPS. Ich hier komm bei mit mit selbem "Ultra-Preset, 4×MSAA" auf 125 FPS im Schnitt. Da kann doch nur was am Testsystem nicht stimmen.