• Mitspieler gesucht? Du willst dich locker mit der Community austauschen? Schau gerne auf unserem ComputerBase Discord vorbei!

News Project Cars: Gameworks nicht verantwortlich für AMD-Performance

berkeley schrieb:
Für kein Geld der Welt würde ich wegen einem Spiel den Grafikkartenhersteller wechseln. Wo soll das Enden. Da hat sich SMS mit Nvidia wahrscheinlich verkalkuliert. Bei dir könnte es aber klappen :)

Tja am Ende des Tages ist es aber nun mal so, dass Kunden sich Grafikkarten kaufen um zu spielen. Sie kaufen sich keine Spiele um eine erstandene Grafikkarte auszulasten. Wenn AMD also nicht in die Pushen kommt und sich solche Themen häufen, und das haben sie ja in der Vergangenheit bereits, dann werden einfach noch weniger Kunden AMD Grafikkarten kaufen. So sieht nun mal die knallharte Realität aus. Man kann AMD daher nur raten endlich aufzuwachen und mehr Geld für die Softwareabteilung in die Hand zu nehmen. Irgendwelche Jammerposts oder Anschuldigungen auf Twitter & Co. bringen keine zusätzlichen Käufer. Von daher Klappe halten, hinsetzen und gescheit arbeiten. Am Ende des Tages ist es in AMDs eigenen Interesse dass Ihre Produkte gut laufen und das tun sich von irgendwelche PR Posts sicher keinen Millimeter.
 
Daedal schrieb:
Warum sollte ich mich verschlechtern wollen^^?

Und schon im ersten Satz zeigst du dein mangelndes Verständnis:
Ich schrieb nicht, dass die PhsyX Implementierung in Zusammenhang steht mit den Drawcalls. Ich schrieb, dass diese beiden um CPU Ressourcen konkurrieren. Das ist ein himmelweiter Unterschied bei Software!!!

Daher so eine Unsinnige Frage:
Entschuldige, verlieren wir uns nun in semantischer Haarspalterei? Worin der Inhalt bestand, ist dir doch bewusst. Deine Argumentation trifft nur leider nicht unter Bezugnahme der von mir gelieferten Informationen und solange du keinen Gegenbeweis liefern kannst, ist deine Darstellung hinfällig.

Zur unsinnigen Frage...also für dich ganz sauber formuliert: Du behauptest, natürlich ohne es zu wissen, dass PhysX die CPU so stark auslastet, dass nicht mehr genug CPU-Ressourcen zur Abarbeitung der Menge an Drawcalls vorhanden sind. Im Gegenzug gibt der Entwickler offiziell an, dass nicht mehr als 10% CPU-Last für PhysX benötigt werden. Demzufolge genug CPU-Ressourcen, für ausreichende Abarbeitung von Drawcalls. Weichst du erneut aus und spielst den Polemiker?
 
Zuletzt bearbeitet:
Daedal schrieb:
Da Der Code Nvidias PhysX bei Nvidias GPUs mit GPU-offload Funktionen ausgestattet hat, werden diese bei AMD GPUs auf der CPU berechnet.
Du glaubst auch alles was dir erzählt wird, oder? Bloß weil der Typ hier sowas erzählt hat?
https://www.computerbase.de/forum/t...tungssteigerung.1474016/page-12#post-17400561

Wie kommst du auf die Idee, dass der Entwickler ist? Der hat nichts mit der Entwicklung von PC zu tun und ich wüsste nicht, warum ich seinen Aussagen mehr trauen sollte als denen der tatsächlichen Entwickler.

Das sind schon merkwürdige Ergebnisse in Anbetracht der Tatsache, dass GPU PhysX so einflussreich auf die Performance sein soll.
http://forums.anandtech.com/showpost.php?p=37388559&postcount=79
 
DocWindows schrieb:
Dann frage ich mich auch (und ich frage mich das wirklich weil ich es echt nicht weiß): Wie können nVidia Particles als Physx-Effekt auf einem AMD-Rechner laufen der das Physx Framework überhaupt nicht installiert hat?

Dir ist noch nie aufgefallen, dass auch Systeme mit AMD-Grafik (oder Intel) die Physx-Software installiert bekommen, sobald man einen Titel damit installiert? Die Effekte können dann nur nicht auf die GPU ausgelagert werden. Das ist alles. Und wenn die Effekte nicht vollständig deaktivierbar sind, wird mit einer AMD-Karte immer etwas CPU-Leistung fehlen, es sei denn der Entwickler sorgt dafür, dass PhysX ordentlich auf die kerne verteilt wird (siehe Tomshardware Artikel vom 18.11.2010):

Then why is the performance picture so dreary right now?

- With CPU-based PhysX, the game developers are largely responsible for fixing thread allocation and management, while GPU-based PhysX handles this automatically.
- This is a time and money issue for the game developers.
- The current situation is also architected to help promote GPU-based PhysX over CPU-based PhysX.
- With SSE2 optimizations and good threading management for the CPU, modern quad-core processors would be highly competitive compared to GPU PhysX. Predictably, Nvidia’s interest in this is lackluster.

Ich bezweifle, dass CPU PhysX heute die SSE2 Einheiten nutzt, denn dann wäre das Feature GPU-seitig ja für den Allerwertesten.
An einem FX-8350 beispielsweise würde sich sicher ein freier Kern finden, der ein SSE2 PhysX gemütlich nebenbei abwickelt. Aber das wäre ja so nicht-nVidia.

noxon schrieb:
Das sind schon merkwürdige Ergebnisse in Anbetracht der Tatsache, dass GPU PhysX so einflussreich auf die Performance sein soll.
http://forums.anandtech.com/showpost.php?p=37388559&postcount=79

Der hat ja auch nur nen 5960X bei 4GHz... und es war weiterhin ne nVidia karte im Rechner, so dass sich nicht sagen lässt, was von CPU-Part, der immer läuft, doch von der GPU übernommen wird.
 
Zuletzt bearbeitet:
@hrafnagaldr: Nö, ist mir in der Tat noch nicht aufgefallen. Kann mich jetzt auch aktiv an kein Spiel erinnern, welches die PhysX-Software im Redistributable-Pfad mitgebracht hätte. Ich weiß nur dass diese Software immer mit den Treiberupdates von nVidia auf die Rechner kommt oder aktualisiert wird.

Was passiert denn wenn man diese Software nach der Installation des Spiels wieder runterschmeißt? Startet das Spiel dann nicht mehr? Hat das schonmal wer ausprobiert?
 
ONH schrieb:
Nun, da scheinen viele sich doof zu stellen SMS scheint unfähig zu sein dx 11 konformen code zu schreiben und verlangt von beiden gfx Karten Hersteller fixes in den Treiber dafür, oder Kan mir einer hier beweisen, dass amd dx nicht standardkonform implementiert, gibt es da auch eine Testsuit wie pilgit für OpenGl? Wenn nicht ist es dumm darüber zu diskutieren, nur darauf muss ein Spielhersteller achten. Ansonnsten wäre es eh besser für jeden der 3 Hersteller, ne eigene api zu nutzen.

Es könnte sich um DX11 konformen Code handeln. NVIDIA hat dann natürlich aus reiner Nächstenliebe geholfen den DX11 Code für ihre Karten zu optimieren. Am Ende lauft auf AMD-Karten der Standard-DX11-Code und auf NVIDIA-Karten der für NVIDA-Karten optimierte.
Mit anderen Worten Standard-Code läuft auf beiden Karten gleich übel, der eine Hardware-Hersteller hatte jedoch die Ressorucen um unter die Arme zu greifen.

Hinzu kommt vermutlich noch ein eher schlechter Standardcode, der halt statt den üblichen 10-20% plötzlich um einiges schlechter läuft auf der nicht optimierten Hardware. Das lese ich auch aus dem Pressestatement raus.

Der Schuldige? Alle oder keiner... Wobei Schuld das falsche Wort ist. Das Spiel läuft, auf mancher Hardware eben nicht mit maximalen Einstellungen und maximalen Frames, weil eben die Hardware die das Spiel mit Standard-Code vernünftig darstellen könnte noch nicht erfunden wurde.
 
noxon schrieb:
Das sind schon merkwürdige Ergebnisse in Anbetracht der Tatsache, dass GPU PhysX so einflussreich auf die Performance sein soll.
http://forums.anandtech.com/showpost.php?p=37388559&postcount=79
Oh danke dafür. Ich sollte nur noch Beiträge von nvidia Fanboys hin und her zittieren. In diesem Thread wurde gerade noch behauptet es gäbe gar keine GPU PhysX in dem Spiel:
Locuza schrieb:
Im Reddit-Beitrag steht nur Unsinn.

PhysX wird bei Project Cars bei allen GPUs auf der CPU berechnet.
Und er hat mit genau dem Gegenteil den selben Beitrag dort schlecht machen wollen - lustig so ein Forum manchmal :)
 
@TrueAzrael
Dass da ein DX11-Nvidia-Pfad und ein Pfad für alle anderen läuft, ist doch eher unwahrscheinlich. :o
 
DocWindows schrieb:
Was passiert denn wenn man diese Software nach der Installation des Spiels wieder runterschmeißt? Startet das Spiel dann nicht mehr? Hat das schonmal wer ausprobiert?

Du bekommst eine je nach Spiel mehr oder weniger aussagekräftige Fehlermeldung beim starten des Spiels. Bei Borderlands kommt z.B. einfach nur dass er eine (zu PhysX gehörige) DLL nicht findet.
 
DocWindows schrieb:
Was passiert denn wenn man diese Software nach der Installation des Spiels wieder runterschmeißt? Startet das Spiel dann nicht mehr? Hat das schonmal wer ausprobiert?

Spiel startet nicht mehr und beschwert sich das keine PhysX-Software gefunden wurde
 
DocWindows schrieb:
@hrafnagaldr: Nö, ist mir in der Tat noch nicht aufgefallen. Kann mich jetzt auch aktiv an kein Spiel erinnern, welches die PhysX-Software im Redistributable-Pfad mitgebracht hätte. Ich weiß nur dass diese Software immer mit den Treiberupdates von nVidia auf die Rechner kommt oder aktualisiert wird.

Was passiert denn wenn man diese Software nach der Installation des Spiels wieder runterschmeißt? Startet das Spiel dann nicht mehr? Hat das schonmal wer ausprobiert?


Jupp. Läuft dennoch. Allerdings sind die für das Spiel notwendigen PhysX-Dateien (.dll) weiterhin vorhanden, sind also unabhängig vom installierten PhysX weiterhin ein Bestandteil des Spiels ( dort sind sie drin )
Ich musste es nämlich gegen das Urgestein Ageia ersetzen, damit nen altes Spiel ( Legend ) läuft.
ph.JPG

+ die bereits vorhandenen PhysX .dll vom Spiel selbst, scheint sich kein modernes Spiel daran zu stören bzw. werden wohl auch vom alten Ageia(engine) unterstützt.
 
Zuletzt bearbeitet:
Fried_Knight schrieb:
Falls du deine Karte übertaktet hast, kommen deine Probleme mit erhöhter Wahrscheinlichkeit daher. Das war schon öfter der Fall. Wenn der neue Treiber die GPU anders anspricht oder besser Auslastet, verliert man manchmal etwas Übertaktungsspielraum. Typisch ist dann vor allem der "Treiber wurde zurückgesetzt"-Text.
Auch manch neues Spiel deckt eine zu hohe Übertaktung auf, die noch in den üblichen Tests durchging. Bei mir war das z.B. bei Lords of the Fallen der Fall. Etwas Takt zurücknehmen und nochmal testen.
Einfach mal versuchen. Bei mir verursacht der 350.12 überhaupt kein einziges Problem und eine größere Schwemme an Meldungen gibt es im Internet auch nicht. Es gibt zwar eine schemenhafte Meldung, die umhergeistert, die aber auch auf das eben Beschriebene hindeuten kann.
Auch wenn es Offtopic kurz ist:
Nicht übertaktet, daher verwirren mich die Probleme ja auch so massiv. Die Probleme traten in der Form auch erst auf, seit dem ich GTA Online gespielt habe. ;) Gut, es könnte die von MSI vorgenommene werkseitige ÜBertaktung sein bei der MSI Gaming 4G. ;) Es gibt halt so viele Faktoren. Selbst unter den neuen Treibern gingen Furmark-Tests teilweise bis zu 24 Stunden ohne Probleme. ;)

Manchmal steckt man in solchen Problemen nicht direkt mit drin. Ich werde wegen sowas auch nVidia jetzt nicht verteufeln, ich bin ja prinzipiell zufrieden mit der Grafikkarte.

Und das selbe ist es ja auch hier mit dem einen Spiel. Wenn man ansonsten zufrieden ist, sollte man halt auch etwas Geduld mit bringen, statt sich tierisch darüber aufzuregen. Es wird immer wieder mal etwas passieren, was einen verärgert und vor solchen Situationen ist man weder bei AMD noch eben nVidia gefeit.
 
hrafnagaldr schrieb:
Ich bezweifle, dass CPU PhysX heute die SSE2 Einheiten nutzt, denn dann wäre das Feature GPU-seitig ja für den Allerwertesten.
30 Sekunden googlen und deine Zweifel wären ausgeräumt gewesen. Da du aber sicherlich schon befürchtet hast, dass die Ergebnisse nicht in dein verzerrtes Weltbild passen hast du dir die Suche vorsichtshalber erspart.

PhysX: an easy target ?

Ergo:
Zum Einen bringt es gerade mal 3-4% höhere Frameraten und zum anderen ist eine SSE2 Compileroption enthalten.
Also Füße still halten.


Der hat ja auch nur nen 5960X bei 4GHz... und es war weiterhin ne nVidia karte im Rechner, so dass sich nicht sagen lässt, was von CPU-Part, der immer läuft, doch von der GPU übernommen wird.
Im Treiber kann man aber festlegen, dass die GPU nicht zur Berechnung verwendet werden soll. Dann wird auch mit nVidia Karte die Physik auf der CPU berechnet. Ganz genau wie bei den AMD Karten und siehe da. Bei der nVidia Karte bricht die Leistung nicht ein.
Der Prozessor ist zwar leistungsstark, aber selbst bei AMD Karten führt ein leistungsstarker Prozessor ja nicht dazu, dass das Spiel schnell läuft und AMD User schieben die Schuld dafür auf die PhysX Engine. da kann also was nicht stimmen. PhysX auf der CPU führt ja anscheinend nicht zu einem Leistungsverlust wie der Benchmark zeigt und das wäre auch logisch, wenn das stimmt, was die Entwickler sagen und ohnehin nur Kollisionen mit dynamischen Objekten auf der GPU berechnet werden.
 
DocWindows schrieb:
Was passiert denn wenn man diese Software nach der Installation des Spiels wieder runterschmeißt? Startet das Spiel dann nicht mehr? Hat das schonmal wer ausprobiert?

Kanns nur von Borderlands berichten, da kommt ein DLL Fehler beim Start. Diese gehört zum PhysX-Paket. Für ein PhysX-Spiel braucht man die Software, unabhängig, ob das von CPU oder GPU berechnet wird. Nur bei Borderlands ist es komplett deaktivierbares Eyecandy, bei Project Cars zusätzlich zur AMD-Karübernimmt Phys grundlegende Physik-Berechnungen, die ein Rennspiel natürlich braucht. Da nVidia seit einiger ja sogar sogar gesonderte PhysX-Karten in Form schwächerer oder älterer nVidia GPUs aper Treiber aussperrt, wenn die Haupt-GPU nicht von nVidia ist, hat man mit AMD also eigentlich überhaupt keine Chance, eine ähnliche Leistung mbei dem Spiel zu bekommen.

Dazu müssten nVidia-Karten als Addon wieder erlaubt sein oder CPU-PhysX zumindest SSE2-Instructions nutzen können. Aber beides widerspricht nVidias Marktstrategie.
Von daher gebe ich SMS die Schuld an dem Debakel, da einige PhysX-Effekte schlichtweg ein nicht deaktivierbarer Part ihrer Engine sind, und man mit AMD-Karte immer der Depp ist.

noxon schrieb:
Ergo:
Zum Einen bringt es gerade mal 3-4% höhere Frameraten und zum anderen ist eine SSE2 Compileroption enthalten.
Also Füße still halten.

Da hättest auch mal den ganzen Anandtech-Thread verlinkt und nicht nur einen ausgewählten Benchmark. Gleich der nächste Screen zeigt einen massiven FPS-verlust mit CPU-PhysX.

ndzlPXK.jpg


Conditions:
24 AI cars
Weather set to Clear
Map: Nordschleife
Pagani Zonda R
3:00PM

Bei Regen solls noch schlimmer sein. Eine SSE2 Compileroption heißt nicht, dass diese auch genutzt wird.

edit: lol sontin schreibt auch bei Anandtech seinen Trollmist, ich glaubs nicht...

edit2: im Anandtech Forum kommt auch die Vermutung auf, dass die Engine trotz der guten Multithreadingfähigkeit durch die CPU-PhysX beschränkt wird, was AMD-Karten wie bekannt schon immer mehr einschränkte.

Project Cars is multithreaded to hell and back. The SMS team has one of the best multithreaded titles on the market! So what is the issue? CPU based PhysX is hogging the CPU cycles as evident with the i7-5960X test and not leaving enough room for AMD drivers to operate. What's the solution? DX12 or hope that AMD changes the way they make drivers. It will be interesting to see if AMD can make a "lite" driver for this game. The GCN architecture is supposed to be infinitely programmable according to the slide from Microsoft I linked above. So this should be a worthy challenge for them.

Basically we have to hope that AMD can lessen the load that their drivers present to the CPU for this one game. It hasn't happened in the 3 years that I backed, and alpha tested the game. For about a month after I personally requested a driver from AMD, there was new driver and a partial fix to the problem. Then Nvidia requested that a ton of more PhysX effects be added, GameWorks was updated, and that was that... But maybe AMD can pull a rabbit out of the hat on this one too. I certainly hope so.

Naja, wie auch immer, ich werd das Spiel nicht kaufen.
Auf jeden Fall vermute ich, dass auch bei deaktiviertem GPU-PhysX ein offload stattfindet, sobald eine nVidia GPU erkannt wird.

AMD hat ja für diese / nächste Woche nen Treiber angekündigt, schaun wir mal wie es dann ausschaut.
 
Zuletzt bearbeitet:
BernardSheyan schrieb:
dem würde ich ja Glauben schenken, wenns nicht aus dem pCars-Forum stammt.

Gibt es dafür eine Bestätigung aus unabhängiger Quelle?
Wer könnte das denn bitte unabhängigerweise bestätigen? Wer hat das technische KnowHow um eine proprietäre Engine bis ins Detail zu analysieren und vor allem Zugriff auf den Sourcecode?
Ab und an muss man eventuell der Quelle auch vertrauen, gerade, wenn es sich um die Entwickler selbst handelt.
Nebenbei steigt die Performance bei der Nutzung des 15.5 Treibers auf Win7/8 bereits deutlich an, ebensowie unter Win10 mit einem für das OS ausgelegten AMD-Treiber, wie ich gerade lese.
 
-Schon sehr lustig wie man auf Biegen und Brechen SMS und Nvidia in Watte versucht zu packen hier.

-Mal anders rum gefragt....Wer war zuerst da, das Huhn oder das Ei?

-Seit wann muß die Hardware und Software, die schon sehr lange in dieser Form auf dem Markt ist, sich einen Spiel Anpassen? -Das läuft anders rum, schon immmer und immer so gewesen. Klar, "Feintuning" im Treiber, wurde immer nachträglich verbessert, aber das ist kein Feintuning mehr. -Aber klar, hier möchte man es völlig Ausblenden, Nvidia hätte sich auf SMS umgestellt, AMD würde kein Interesse haben. :lol:

-Klar, Geld Bezahlen, damit die Konkurrenz ganz schlecht dar steht, heisst hier Nvidia hätte Ihre Hausaufgaben besser gemacht. Und SMS hat das Geld mehr als nötig, wie viele große Spieleschmieden sind schon in der Vergangenheit Baden gegangen? -Warum wurde das Spiel quasi Vorfinanziert, von AMD und Nvidia Usern? -Etwas weil SMS es so dicke hat?

-Evtl. zahlt SMS jetzt das Geld zurück an Nvidia, denn bis zum offzielen Verkauf hat das Spiel ja immerhin geschaft.

-Und für Nvidia ist der Betrag ein "Klacks" gewesen, dafür dass so "gut" jetzt über die wieder gesprochen wird. -Sehr "guter" Schachzug, bei einen Spiel, was schon lange von vielen PC Gamern erwartet wurde, ausgerechnet da hat sich AMD mal wieder auf die faule Haut gelegt, klar. :lol:
 
lynx007 schrieb:
@Ph@ntom
Das würde Sinn ergeben... wobei Stop, warum läuft dann Witcher so gut auf AMD.... Der Grund der UNfähigkeit liegt vermutlich doch nicht bei AMD, als viel mehr beim Studio.
Das kannst du doch gar nicht beurteilen.
Vielleicht verwenden sie in ihrem Spiel einen bestimmten Shader, eine bestimmte Funktion, eine bestimmte Rendering-Technik, whatever, die bislang von AMD nicht die selbe Aufmerksamkeit erhalten hat wie von NVidia.

Noch mal:
Ohne wirklich Ahnung davon zu haben, sollte keiner hier irgendwelche Schuldzuweisungen machen.
 
@hrafnagaldr: Irgdendwie macht das alles grad gar keinen Sinn mehr. Entweder ich nutze PhysX, dann brauche ich die Runtime/Systemsoftware/Treiber (whatever), oder man nutzt es nicht und braucht diese Zusatzsoftware nicht.

Frage ist deshalb: Installiert Project Cars überhaupt die PhysX Runtime während des Setups mit und startet es auch wenn man die Runtime wieder deinstalliert. Ich hab das Spiel leider nicht, sonst würde ich das in 2 Stunden mal testen.

Wenn es die Runtime nicht braucht und einige PhysX-Funktionen damit direkt in die Spiele-DLLs kompiliert sind, ist für mich klar, dass sämtliche Physik ausschließlich auf der CPU berechnet werden kann, egal ob da ne nVidia oder AMD Karte im System steckt. MAn wird ja wohl kaum die gesamte Physx-Runtime ins Spiel kompilieren :D. Und dann müssten die FPS-Einbrüche auf nVidia und AMD Systemen vorkommen, denn die CPU bleibt ja unverändert.

Die Abhängigkeit des gesamten Spiels von der PhysX Runtime im Fall von Borderlands spricht dagegen für echte GPU-Physikfunktionen. Da wäre es dann sogar logisch wenn PhysX auch auf Systemen installiert wird die nicht über ne nVidia-Karte verfügen, denn sonst würde das Spiel ja nicht starten.

Somit ist wieder die Frage: Warum sind AMD-Karten langsamer wenn in jedem Fall Physik von der CPU berechnet wird, und warum nur in Ultra-Einstellungen? Das würde ja heißen dass auf High-Einstellungen die Physikberechnung nicht mehr stattfindet. Grafiktechnisch ändert sich ja relativ wenig zwischen den beiden Optionen. Sagt zumindest CB. Aber dier Performance steigt eben bei AMD enorm wenn man auf High spielt.

Das mit dem Offload der Physik auf die GPU wäre ne Erklärung, aber dazu müsste die PhysX-Runtime wiederum zwingend vorausgesetzt werden.
 
Zuletzt bearbeitet:
SSE2 wird schlampig bis kaum genutzt... viel zu viel Aufwand.
Dann isoline Tess factor 64 - völlig sinnlos hoch... macht Technisch null Sinn.
 
Zurück
Oben