GTC 2014: NVIDIA spricht über DirectX 12 und kommenden Wundertreiber

Ich weiß schon warum du gegen obige Argumente angehst. ;) In dem speziellen Fall dürfte das nur sehr ermüdend sein, du bist am Ende sowieso wieder der Nvidia-Anti-AMD-Moderator für ihn... :fresse2:

Da bei ist fdsonne einer der die Sache immer sehr nüchtern betrachtet.
Das Problem ist doch das einige gar nicht verstehen was fdsonne schreibt oder es gar verstehen wollen.

Alls ich AMD Grafikkarten gehabt habe und schrieb das ist sehr positiv von der CF Konstulation angetan bin und mit MR gut Umgehen kann habe ich so einige male Unterstützung bekommen von fd wo die eingefleischten NV user mir auf die Pelle rückten.

Er hat mich auch einige mal hier im Forum verbessert in meinen Ausagen und das darf man dann nur nicht persönlich nehmen ...(ganz ehrlich das waren manchmal posts von mir die nicht zu Ende gedacht waren)..den bei ihm geht es dann nicht gegen die Person sondern zum Thema so zu sagen bleibt er Sachlich.

Auch wenn Leute dann schon beleidigend werden bewart er meist bis zum Schluss seine Sachlichkeit .

Anders herum kann man seine Meinung auch ändern wenn man klar Argumentieren oder gar Fakten liefern kann.

Finde es super das wir so einen aktiven Mod hier haben mit dem es sich hervorragend diskutieren lässt... mach weiter so fdsonne.:wink:
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Da bei ist fdsonne einer der die Sache immer sehr nüchtern betrachtet.
Das Problem ist doch das einige gar nicht verstehen was fdsonne schreibt oder es gar verstehen wollen....Auch wenn Leute dann schon beleidigend werden bewart er meist bis zum Schluss seine Sachlichkeit .... mach weiter so fdsonne.
+1!
 
fdsonne schrieb:
Bei DX läuft das wie folgt -> Programmierer/Spiel -> DX Schnittstelle -> Treiber -> "xxx" -> Hardware.
Bei Mantle läuft es exakt gleich -> Programmierer/Spiel -> Mantle Schnittstelle -> Treiber -> "yyy" -> Hardware.
Die Aussage finde ich ein wenig merkwürdig. Wieso soll AMD nicht in der Lage sein in ihrer eigenen Schnittstelle Verbesserungen vornehmen zu können?
Vielleicht gar nicht mal so sehr in der Geschwindigkeit. Aber neue Features, die ihre Hardware unterstützt, können damit zeitnah umgesetzt werden, ohne dass sie auf Microsoft warten müssen, bis deren Schnittstelle diese auch unterstützt.
Was hilft es wenn der Treiber schneller draw Calls oder andere Befehle an die Grafikkarte verarbeiten kann, wenn es in der Schnittstelle hapert und nicht genügend angefordert werden?
Versteht mich nicht falsch, wenn da eine potente CPU verbaut ist, die dieses DirectX11 mit einem viel zu resourcenfressenden Hauptthread sogar verarbeiten kann, dann bringt das natürlich was. Aber da es hier um DirectX12 geht und da genau dieses nicht mehr zeitgemäße Problem angegangen werden soll, ist ja gerade interessant, wie sich DirectX11 mit einer nicht so potenten CPU verhält. Denn da werden die Unterschied zwischen DirectX11 und DirectX12 wahrscheinlich zu finden sein.
Das einzige was mir einfällt, was ein Grafikkartenhersteller machen kann, um die Schnittstelle indirekt zu beschleunigen, ist den Treiber resourcensparender zu implementieren, da dann mehr Resourcen für die Schnittstelle übrig bleiben. Allerdings fehlen dann wahrscheinlich Fehlerabfragen im Treiber, die ein Abschmieren der Grafikkarte verhindern würden, denn sowas kostet Resourcen.
Edit: Bäh fett wird beim Zitieren nicht übernommen. Manuel eingefügt.
 
Zuletzt bearbeitet:
Wo steht denn dass AMD seine eigene Schnittstelle nicht verbessern kann/könnte? Das bezieht sich doch nur aus Schaffes Blödsinn-Aussage, dass Nvidia die Möglichkeit fehle Mantle zu schlagen. Fdsonne hat nur den Bereich makiert, der für Nvidia optimierbar ist, das heißt nicht und das sagt er nicht dass AMD dies nicht auch könnte.
 
da:
fdsonne schrieb:
Der Hersteller der Hardware und Wissenträger über die Funktionsweise des Treibers kann jeweils im Fett markierten ansetzen zu optimieren.
Mantle Schnittstelle ist nicht fett markiert. Oder anders gesagt AMD kann mit Mantle in 4 Parts optimieren und Nvidia wie auch AMD mit DirectX nur in 3 Parts. So und nun kommt das aber. Da Microsoft sowohl DirectX als auch Windows programmiert, kann Microsoft an dieser Stelle optimieren. AMD kann das mit Mantle aber nicht.
Meiner Meinung nach sieht das irgendwie so aus.
DirectX:
Programm -> OS -> DirectX Schnittstelle -> Treiber -> xxx -> Hardware
sowohl AMD als auch NVIDIA können im fett markierten Bereich optimieren. Nagut vielleicht noch im Programm, wenn sie Programmierer zur Verfügung stellen. Microsoft im blau markierten Bereich oder eben auch im Programm selber.
Mantle:
Programm -> OS -> Mantle Schnittstelle -> Treiber -> yyy -> Hardware
AMD kann hier im fett markierten Bereich optimieren. Allerdings können sie nicht im Bereich OS -> Mantle optimieren. Ok das ist auch falsch, da wenn Mantle jemals unter Linux oder einem anderen freien OS laufen sollte, auch dies möglich sein kann.
OpenGL:
Programm -> OS -> OpenGL Schnittstelle -> Treiber -> zzz -> Hardware
Sowohl AMD als auch NVIDIA können in 4 Parts optimieren und das tolle ist, dass OpenGL auch noch auf vielen Betriebssystemen läuft.

Edit: Diese verfluchten Kommata
 
Zuletzt bearbeitet:
Hmmm aber, dass er das deswegen verneint interpretierst du da irgendwie rein. Aber das ist eh eine Foren-Krankheit frei nach dem Motto:

Nerd 1: "Nvidia hat gute Grafikkarten"

Nerd 2: "Wie kannst du behaupten AMD hat schlechte Grafikkarten?!"
 
fdsonne schrieb:
Kleine Gedankenstütze als simple Skizze:
Bei DX läuft das wie folgt -> Programmierer/Spiel -> DX Schnittstelle -> Treiber -> "xxx" -> Hardware.
Bei Mantle läuft es exakt gleich -> Programmierer/Spiel -> Mantle Schnittstelle -> Treiber -> "yyy" -> Hardware.
Bei Mantle läuft es meiner Meinung nach eben nicht exakt gleich. AMD kann auch Mantle anpassen. Ich weiß ehrlich gesagt gar nicht, was es da überhaupt zu diskutieren gibt.
Aber anscheinend hat fdsonne recht und hier haben eben manche:
fdsonne schrieb:
mit Programmierung NULL am Hut
ebenfalls
fdsonne schrieb:
Nix für ungut...
Denn Prgrammierer verstehen Logik und exakt gleich ist es eben nicht.
Edit: Und ja diesen Post werde ich wieder bereuen. Aber ich hasse es mit Leuten zu diskutieren, die ich überhaupt nicht ansprach und meinen zu wissen was andere gedacht haben und vielleicht nur was falsches schrieben. Das ändert aber nichts daran, dass es meiner Meinung derzeit so falsch dasteht.
 
Zuletzt bearbeitet:
Ich meine nicht zu wissen was er gedacht hat, ich meine nur mich nur um das zu kümmern was da steht und er hat nirgendwo verneint, dass AMD Mantle weiter entwickeln könnte. Selbst wenn das vielleicht etwas differenzierter hätte ausgedrückt werden können, ist es wohl um Welten realistischer als Schaffes Hinrfurz, dass Nvidia gar keine Möglichkeiten hat. Aber nun gut, ich nehme mal du wirst dich darüber auch noch direkt mit fdsonne unterhalten dürfen... ;)
 
Bei Mantle läuft es meiner Meinung nach eben nicht exakt gleich. AMD kann auch Mantle anpassen. Ich weiß ehrlich gesagt gar nicht, was es da überhaupt zu diskutieren gibt.
Aber anscheinend hat fdsonne recht und hier haben eben manche:

So ganz unrecht hat der Mick da nicht...
Zum einen, steht nirgends geschrieben, das AMD nicht Mantle anpassen kann. Nur weil es nicht erwähnt ist, ist es nicht so auszulegen!
Zum zweiten mit der "Forenkrankheit", dass alles, was nicht explizit erwähnt wird dann im Interpretationsspielraum der Diskusionsteilnehmer als quasi Fakt hingebogen wird.
Und zum dritten, ich habe explizit keine Hersteller in der Skizze erwähnt. Warum? Eben genau aus dem Grund. Die Skizze sollte allgemein zu verstehen sein, weswegen auch kein Herstellerbezug auftaucht.

Das Mantle hier von AMD kommt, und in der jetzigen Umsetzung nur explizit für AMD Karten geht, steht auf nem anderen Blatt Papier... Ein Hintergrund für mich war die Aussage von AMD, Mantle auch für andere Hardware potentiell anzubieten. Und dann schließt sich nämlich der Kreis, das ich von DXischer Umsetzung sprach und den Vergleich mit einer möglichen Mantle Umsetzung zog, aber nicht von AMD mit Mantle vs. NV mit DX oder AMD mit DX. Der der Skizze anschließende Erklärungstext zeigt weiterhin Beispiele und ist ebenso nicht 100% vollständig.

Was das OS in deiner Skizze angeht. Ich habe das OS explizit rausgelassen. Zum ersten, weil es nicht nur das Programm selbst beeinflussen kann, sondern auch den Treiber und die Schnittstelle selbst. Zum zweiten, weil der Hersteller der Hardware idR keinen Einfluss direkt auf das OS hat. Und zum dritten, weil Vergleiche im Optimalfall unter gleichen Bedinungen getätigt werden. Derart ins Detail zu gehen war nicht die Ambition des ganzen, sondern sollte auf die Aussagen von oben gehen, wo man einem Hersteller von Grafikhardware die Möglichkeit absprechen wollte, das Overheadverhalten von DX zu beeinflussen. Nimmt man das sogar genau, spielt es nichtmal eine Rolle, ob Mantle da durch AMD optimierbar ist oder nicht... Denn das ändert an der DX Umsetzung auch nix :fresse:

PS: Die Leute regen sich hier teilweise auf, das meine Beiträge viel zu lang wären. Nur was soll ich noch alles reinschreiben bevor das Interprätieren aufhört!? :wink:
 
Zuletzt bearbeitet:
die Leute regen sich hier teilweise über noch viel nichtigere Dinge auf. kennste doch.

also ich les Deine Beträge echt gern (weil so informativ u von der Logik gut dargestellt sind) und find auch nicht, dass die kürzer gehen.
 
Das machts glaube ich auch nicht besser. Gesetzestext lässt auch viel Spielraum für Interpretationen :fresse:
 
fdsonne schrieb:
Die Leute regen sich hier teilweise auf, das meine Beiträge viel zu lang wären.
Ich ganz sicher nicht.

fdsonne schrieb:
Was das OS in deiner Skizze angeht. Ich habe das OS explizit rausgelassen. Zum ersten, weil es nicht nur das Programm selbst beeinflussen kann, sondern auch den Treiber und die Schnittstelle selbst. Zum zweiten, weil der Hersteller der Hardware idR keinen Einfluss direkt auf das OS hat.
Viele Kernelpatches in Linux stammen genau von den Hardwareherstellern, die Bugs in ihrer Hardware ausbügleln müssen. Ähm ich mein natürlich ihre Hardware unterstützen wollen.
Aber auch Windows muss diverse Hardware Bugs umschiffen. Ich kann mir nicht vorstellen, dass das ohne die Hardwarhersteller geht. Ich hielt es wichtig das OS zu erwähnen, da es sicher einen Unterschied macht, ob der OS und Schnittstellenentwickler identisch ist. Interessant ist dann auch ob OpenGL mit DirectX12 unter Windows mithalten kann, da NVIDIA ja beide Overheads verbessern will.

fdsonne schrieb:
Zum einen, steht nirgends geschrieben, das AMD nicht Mantle anpassen kann.
Gut seh ich ein. Inzwischen hast du ja ergänzt, dass die Optimierungsmöglichkeiten nur exakt gleich sind, wenn ein anderer Hardwarehersteller als der Schnittstellenhersteller den CPU Overhead verringern will.
Dieses Detail halte ich in einer Diskussion zwischen Treiberoverhead und Schnittstellenoverhead durchaus für erwähnenswert. :wink:

P.S. Dein Beitrag zu OpenGL im FirePro Thread war sehr gut. Nur finde ich es immer etwas albern einen Thread zu verfassen nur um einen anderen Thread zu loben.
 
Zuletzt bearbeitet:
bei nv gabs doch erst vor kurzem so einen wundertreiber,
wo danach manche gpu defekt war.
:rofl:

so kann man die wirtschaft auch ankurbeln
 
Zuletzt bearbeitet:
Viele Kernelpatches in Linux stammen genau von den Hardwareherstellern, die Bugs in ihrer Hardware ausbügleln müssen. Ähm ich mein natürlich ihre Hardware unterstützen wollen.
Aber auch Windows muss diverse Hardware Bugs umschiffen. Ich kann mir nicht vorstellen, dass das ohne die Hardwarhersteller geht. Ich hielt es wichtig das OS zu erwähnen, da es sicher einen Unterschied macht, ob der OS und Schnittstellenentwickler identisch ist.

Das kann durchaus ein Umstands sein, bricht man es aber auf Windows runter, macht es effektiv normal quasi keinen Performancenachteil ob du nun ein gepatchtes System nimmst oder eins ohne diese Patches, sofern der Funktionslevel identisch ist.

Was OpenGL angeht. Wie gesagt, aus meiner Sicht ist der Markt da so oder so nicht ganz konsequent. OpenGL ist heute schon lange weit weniger OS gebunden, also kein MS only. Aber der Markt will es scheinbar nicht haben... macht für mich den Eindruck, das das reine Funktionslevel und der potentielle Speed gar nicht sooo ausschlaggebend ist. Sprich ich hab OpenGL da schon innerlich ein wenig abgeschrieben ;) DX12 wird aber durchaus interessant. Auch was NV da noch aus DX11 rausquetschen kann. Nimmt man die Folie von oben, legt der heutige R334 Treiber schon gut zu... Sofern die Werte stimmen halte ich es für gut möglich das NV da Overheads potenziell so stark "drücken" kann, das man nicht ins Limit rennt. (immer stark Anwendungsabhängig)
Ich könnte mich irren, aber warb AMD nicht mit 9x mehr draw fall Speed mit Mantel als DX? Wenn NV der Folie nach mit dem neuen Treiber zu der CCC14.2 Umsetzung 8x mehr draw fall Speed quetschen will, bleibt effektiv da wenig Vorteil für Mantle. -> sind halt Marketing Folien, dass sollte man nicht vergessen :fresse:

Dieses Detail halte ich in einer Diskussion zwischen Treiberoverhead und Schnittstellenoverhead durchaus für erwähnenswert. :wink:
Ich versteh schon ;)
Vor allem wollte ich ursprünglich erst noch im Beitrag oben ergänzen, das die Ausführung keinen Anspruch auf Vollständigkeit hegt. Habe den Satz der lieben Postlänge dann aber rausgelassen. Hätte ich ihn mal doch gebracht :fresse:
 
Vor allem wollte ich ursprünglich erst noch im Beitrag oben ergänzen, das die Ausführung keinen Anspruch auf Vollständigkeit hegt. Habe den Satz der lieben Postlänge dann aber rausgelassen. Hätte ich ihn mal doch gebracht
Das kenn ich. Ich wollte in meinem Post, eigentlich noch intel, Matrox und andere Grafikkartenhersteller ergänzen. Nur fiel mir dann nicht ein ob SIS überhaupt noch Grafikkarten baut und hab es dann gelassen. Dafür gibt es ja dann die Editierfunktion nur doof wenn jemand schon auf den Beitrag geantwortet hat :fresse2:
Das kann durchaus ein Umstands sein, bricht man es aber auf Windows runter, macht es effektiv normal quasi keinen Performancenachteil ob du nun ein gepatchtes System nimmst oder eins ohne diese Patches, sofern der Funktionslevel identisch ist.
Ja mir fällt da eigentlich auch nur der TLB Bug vom Phenom ein und auch das war eigentlich in einem Desktop System nicht weiter dramatisch oder ein paar Energiesparfunktionen gingen halt erst nach einem Kernelpatch.
Sprich ich hab OpenGL da schon innerlich ein wenig abgeschrieben
Ja hatte ich eigentlich auch. Aber gerade geht es in der Richtung echt ab. Ich hab noch nie so viele Meldungen in dem Bereich gelesen wie im letzten Jahr. Häufig wird zwar nur gewrappt. Das klappt aber auch. Valve baut fleissig am Debugger: https://github.com/ValveSoftware/vogl/wiki/Change-Notes und deckt Bugs in den Treibern auf. Womit wir wieder bei der Befürchtung von mir wären, dass Overhead verringern gleichbedeutend mit Fehlerabfragen reduzieren ist.
Oder auch da: Epic: Unreal Engine 4.1 unterstützt SteamOS und andere Linux-Systeme | heise online
StreamOS scheint diesbezüglich da einiges ins Rollen zu bringen.
 
B) geht es nach wie vor um den Umstand, woher Mantle die Performance holt. Schau ein paar Posts weiter oben, DU SELBST! spracht doch da von 19% Vorsprung vor Mantle. Woher kommen die? Sag es uns doch einfach anstatt rumzueiern... Schlimmer noch, oben sprachst du sogar davon, das diese 19% auch daher kommen, das AMD nicht den DX Part optimiert hat. -> und sprichst damit direkt Mantle die Fähigkeit ab, wirklich schneller zu sein.

Ich spreche Mantle gerne die Fähigkeit ab im GPU Limit schneller zu sein, denn bisher hat man davon wenig gesehen, eigentlich gar nichts.
Und der Umstand dass Mantle auch im GPU Limit bei diesem einen Benchmark schneller war ( bei mir ist es nicht so ) kann vieles bedeuten, unter anderem dass AMD ihre Treiberarbeit mehr auf Mantle konzentiert hat.
Das ist alles andere als ungewöhnlich.

Wie wir an Nvidia sehen ist Mantle im GPU Limit nicht schneller als NV unter Directx.
Unterscheide mal zwischen GPU und CPU Limit, das ist scheinbar dein Problem oder das Problem warum wir aneinander Vorbeireden.

Welche Mysterien meinst du? Zur Info, ich habe die Werte nicht erstellt... Sondern sehe nur das Ergebnis.

Zum letzten, auch hier irrst du. Die Diskusion fing damit an, das man oben behauptet, Mantle wäre aufgrund des low(er) level Ansatzes per se schneller als DX. Das bezieht man auf die Werte aktuell zu findender Umsetzungen. Damit schließt sich der Kreis auf die Nachfrage, woher der Vorsprung überhaupt kommt.

Per se ist Mantle überhaupt nicht schneller als Directx, das betrifft nur den CPU Overhead, soviel sollte klar sein.
Mir kam es so rüber als ob du sagen willst, Nvidia reduziere den CPU Overhead und man erstmal abwarten solle, wie sich das entwickelt.

Bei DX läuft das wie folgt -> Programmierer/Spiel -> DX Schnittstelle -> Treiber -> "xxx"-> Hardware.
Bei Mantle läuft es exakt gleich -> Programmierer/Spiel -> Mantle Schnittstelle -> Treiber -> "yyy"-> Hardware.
Der Hersteller der Hardware und Wissenträger über die Funktionsweise des Treibers kann jeweils im Fett markierten ansetzen zu optimieren.
"xxx" und "yyy" meinen in obigen Fall zusätzliche "abstraction layer", die wir als Außenstehende nicht kennen, geschweige denn einschätzen können.
Fakt sollte nach aktuellen dünnen Infos zu Mantle sein, das "yyy" bei Mantle weniger "fett" als "xxx" bei AMD mit DX und NV mit DX zu sein scheint. Auch ist "xxx" bei AMD mit DX und bei NV mit DX völlig unterschiedlich. So und jetzt kommst du und willst uns hier allen ernstes erklären, das ein Hersteller, der mal ebenso drei Parts der fünf in der Kette selbst in der Hand hat, keinen Einfluss auf das Overheadverhalten unter DX11 haben soll?

Das "Overheadverhalten" habe ich gar nicht gemeint, sondern ausschließlich CPU Overhead, also die Leistungsbremse des Systems im CPU Limit die Mantle behebt.
Nvidia kann diese nicht beheben, das zeigen sie selbst in ihren Skalierungsbenchmarks. Ansonsten hätten die die Balken bei AMD lang gemacht und bei NV kurz.
Was sie beheben können ist der Treiberoverhead ihrer GPU oder die Zusammenarbeit der CPU mit der GPU wenn es kein CPU Limit gibt, siehe das Skalierungsproblem bei NV mit 2 Kernen oder weniger.
Mantle können sie damit nicht schlagen, Mantle entlastet die CPU, das kann Nvidia nicht, zumindest nicht, wenn die CPU limitiert.

PS: Ich hab mal die Abschnitte markiert die relevant sind und an denen Nvidia arbeiten kann.

So und jetzt kommst du und willst uns hier allen ernstes erklären, das ein Hersteller, der mal ebenso drei Parts der fünf in der Kette selbst in der Hand hat, keinen Einfluss auf das Overheadverhalten unter DX11 haben soll?

Also Nvidia und AMD haben gar keinen Einfluss auf Directx11, die können lediglich das Zeug nehmen was Microsoft programmiert hat und ihre Treiber und Hardware darauf einstellen, das ist auch der Grund warum Nvidia nur das tun kann. Und das heißt nicht, dass sie mehr FPS im CPU Limit bekommen werden, sieh das mal ein.
Das bekommt NV, wenn die Directx12 Schnittstelle kommt und vorher können sie ihren Treiberovead verringern, die Zusammenarbeit CPU mit GPU mthilfe ihres Treibers verbessern, aber nicht die Performance im CPU Limit, die bleibt immer gleich, da NV hier keinen Enfluss hat.

Nimm mal eine NV oder AMD Karte und versuche beide ins CPU Limit laufen zu lassen, die FPS sind immer bis auf Messungenauigkeit identisch und warum wohl... weil sie darauf keinen Einfluss haben, oder schreiben sie nen Treiber für die CPU?

neuli schrieb:
Das einzige was mir einfällt, was ein Grafikkartenhersteller machen kann, um die Schnittstelle indirekt zu beschleunigen, ist den Treiber resourcensparender zu implementieren, da dann mehr Resourcen für die Schnittstelle übrig bleiben. Allerdings fehlen dann wahrscheinlich Fehlerabfragen im Treiber, die ein Abschmieren der Grafikkarte verhindern würden, denn sowas kostet Resourcen.

Genau das können sie tun.
 
Zuletzt bearbeitet:
bei nv gabs doch erst vor kurzem so einen wundertreiber,
wo danach manche gpu defekt war.

Wenn NIVIDIA Wundertreiber in den Mund nimmt, muss man aufpassen.
Ich selber war damals auch von dem GPU Defekt betroffen, von dem ach so tollen Wundertreiber (320.18?).
 
Zuletzt bearbeitet:
Unterscheide mal zwischen GPU und CPU Limit, das ist scheinbar dein Problem oder das Problem warum wir aneinander Vorbeireden.
Nein, weil es in der Detailbetrachtung viel zu oberflächlich wäre, dies zu tun. Es geht nach wie vor um den Umstand, woher Mantle die Leistung holt. Auch wenn du mittlerweile schon wieder abgekehrt bist und auf einmal Sachen wie "unter anderem dass AMD ihre Treiberarbeit mehr auf Mantle konzentiert hat" als normal angesehen werden. Damit sprichst du direkt die Fähigkeit ab, das Mantle überhaupt schneller sein kann. Denn unter diesem Gesichstspunkt lassen sich Vergleiche von Umsetzungen aufbauend auf eine Schnittstelle nicht ziehen, da eben unter völlig verschiedenen Bedingungen. Du wirst dich sicher nicht mehr dran erinnern, aber das Thema "fehlende Optimierung" hatten wir vor einiger Zeit schonmal... Da galt sowas noch als äußerst problematisch, wenn man es vorsichtig zusammen fasst. Stichwort war seinerzeit NV Gameworks... Nur so nebenbei :wink:

Das "Overheadverhalten" habe ich gar nicht gemeint, sondern ausschließlich CPU Overhead, also die Leistungsbremse des Systems im CPU Limit die Mantle behebt.
Nvidia kann diese nicht beheben, das zeigen sie selbst in ihren Skalierungsbenchmarks. Ansonsten hätten die die Balken bei AMD lang gemacht und bei NV kurz.
Was sie beheben können ist der Treiberoverhead ihrer GPU oder die Zusammenarbeit der CPU mit der GPU wenn es kein CPU Limit gibt, siehe das Skalierungsproblem bei NV mit 2 Kernen oder weniger.
Mantle können sie damit nicht schlagen, Mantle entlastet die CPU, das kann Nvidia nicht, zumindest nicht, wenn die CPU limitiert.

Siehst du, hier ist wieder der Punkt, wo dir einfach mal das Wissen im Bereich Programmierung fehlt. Dennoch tätigst du Aussagen und stellst Fakten in den Raum.
Es gibt im Grunde kein generelles CPU Limit wie du es hier gern hättest. Das CPU Limit kann von XX verschiedenen Sachen kommen.
- Wenn ein Spiel beispielsweise durch die KI Berechnung ins "CPU Limit" läuft, nämlich weil die KI Berechnung derart komplex ist, das die CPU zu langsam ist und somit deckelt ist das ein CPU Limit.
- Wenn ein Spiel durch Physikberechnungen derart bedeckelt wird, weil die CPU zu langsam ist, ist es ein anderes CPU Limit.
- Wenn beispielsweise die von AMD mit Mantle genannten "draw calls" nicht schnell genug getätigt werden, ist es wieder was anderes, dennoch limitiert die CPU.
- genau so wie wenn die Treiberoptimierungen auf breite CPUs setzen, die CPU aber nicht breit genug ist und somit Leistung liegen gelassen wird, ist das ein CPU Limit.
Beispiele hierfür kann man noch und nöcher bringen... Es sind grundverschiedene Sachen, die eben nicht mit den gleichen Mitteln bekämpft werden können.
Beispielsweise kann Mantle weder KI noch Physikberechnungen beschleunigen, ebenso wird kein Treiber durch Mantle grundlegend schneller. Wärend die draw call Problematik durch Mantle angegangen wird.
Auch hat bspw. der Hersteller der GPU keinen direkten Einfluss auf die KI oder Physikberechnung (GPU PhysX außen vor), kann aber beim Treiber ansetzen und bei den draw calls ebenso...

Was die Balkenlänge angeht. NV kann nur mit Werten von DX unter AMD vergleichen. Es gibt Mantle nicht frei zugänglich. Lange Balken in Rot auf der NV Folie hätte man mit Mantle. Aber ohne frei zugängliches Mantle keine langen Balken.

Also Nvidia und AMD haben gar keinen Einfluss auf Directx11, die können lediglich das Zeug nehmen was Microsoft programmiert hat und ihre Treiber und Hardware darauf einstellen, das ist auch der Grund warum Nvidia nur das tun kann. Und das heißt nicht, dass sie mehr FPS im CPU Limit bekommen werden, sieh das mal ein.

Wie soll ich etwas einsehen, was nicht stimmt? Und vor allem, wo wir doch eigentlich über den Punkt hinaus sind, das NV und AMD eben doch Einluss auf die DX Leistung haben, es geht schließlich immernoch um Umsetzungen. Auch macht es den Eindruck, als denkst du, das DX selbst irgendwie eine Software ist, die Last erzeugt... Das ist nicht der Fall. DX und auch Mantle sind eher Schnittstellen, bzw. auch Bibliotheken, woraus man sich bedienen kann. Die Last wird aber quasi ausschließlich im Kontext der Anwendung und des Treibers erzeugt...
Du musst dir das Leistungsverhalten sinnbildlich in etwa wie beim Inputlag vorstellen. Dort summiert sich das vom Eingabegerät über die PC Hardware (CPU, GPU usw.) über die Kabelverbindungen bis zum Monitor nebst dessem Verarbeitungsspeed und der Ausgabegeschwindigkeit. Es gibt also eine Kette von Objekten, die maßgeblich an der Leistungsfähigkeit beteiligt sind. Du kannst vorn optimieren und es wird in Summe schneller, ebenso aber auch hinten, oder auch überall. In Summe wird es schneller. Und das ist der Punkt. Mit Mantle gibts nun eine zweite Kette (Mit OpenGL eine dritte), deren einzelne Glieder die Leistungsfähigkeiten anders wichten.
Dennoch ist der Weg, den die Berechnung nimmt im Prozess, wie oben skizziert, identisch. Was anders ist, ist die Zeit, die benötigt wird, bis man von ganz vorn nach ganz hinten gewandert ist.
Nimmt man jetzt als Beispiel mal wieder die draw calls, so kann eine Umsetzung mit Mantle sagen wir 50.000 Cubes zeichnen. Eine Umsetzung mit DX hingegen vielleicht 20.000 Cubes. Kommt nun NV und sagt, wir haben was gefunden, was die Abarbeitungsgeschwindigkeit der draw calls signifikant steigert, kommen womöglich dann 40.000 Cubes mit dem neuen Treiber bei rum.
Hast du jetzt ne Anwendung, die 30.000 Cubes zeichnet bei 60 FPS und definierter Auflösung, wäre die erste DX Umsetzung vor dem Treiberupdate klar CPU limitiert und würde nur um die 40 FPS schaffen, nach dem Treiberupdate hingegen fällt das Limit weg und es stehen ebenso 60 FPS auf der Uhr. Man hat also DX dahingehend stark im Speed gesteigert und diesen Part als CPU Limit beseitigt.

Wie oben schon erwähnt, die Werte von der NV Folie sollten für jederman nachvollziehbar sein, da es sowohl den R331 als auch den R334 schon gibt. Stimmt das in etwa, liegt die Vermutung nahe, das NV mit dem neuen Treiber dort nach eben der Folie zulegen wird.
 
@fdsonne: Müsste das im zweiten Absatz, zweiter Satz nicht "stellst sie als Fakten" heißen? Wenn es Fakten wären, müsstest du ja nicht mit der Wand diskutieren...^^
 
mhhh stimmt :fresse:
Neja ich lass das mal so drin... Sonst kommt wieder jemand und beschwert sich, weil man den Post nachträglich ändert :wall:
THX für den Hinweis
 
Naja der Quoteinator ist nicht anwesend, aber deine Entscheidung. ;) Man versteht ja auch so, was du sagen willst. :)
 
fdsonne schrieb:
Es geht nach wie vor um den Umstand, woher Mantle die Leistung holt.
und daran scheitert diese Diskussion. AMD Mantle
Natürlich kann ein Direktzugriff auf den Grafikkartenspeicher schneller bei korrekter Implementierung der Software sein. Und natürlich reduziert es den Overhead weniger Konvertierungen durchführen zu müssen. Und ja derzeit gibt es leider noch keine öffentliche Mantle API Dokumentation, weswegen man sich noch auf die Aussagen der Marketingabteilung von AMD oder auf die Entwickler, die darauf schon Zugriff haben, verlassen muss.
Und ja wenn DirectX statisch im Programm gelinkt wäre, könnte ein Komplier vielleicht den Konvertierungsaufwand negieren, ist es aber nicht.

Allerdings kann der Entwickler es eben in Mantle leichter versauen. Oder anders gesagt der Entwickler hat mit Mantle mehr Verantwortung für die Geschwindigkeit in der Kette, als der Entwickler mit DirectX.
 
Zuletzt bearbeitet:
Nimm mal eine NV oder AMD Karte und versuche beide ins CPU Limit laufen zu lassen, die FPS sind immer bis auf Messungenauigkeit identisch und warum wohl... weil sie darauf keinen Einfluss haben, oder schreiben sie nen Treiber für die CPU?

Soso, "identisch".
Du behauptest also, dass im folgenden Screenshot die "FPS bis auf die Messungenauigkeit" identisch wären?
bf4-fps.gif

First look: AMD Mantle CPU performance in Battlefield 4 - The Tech Report - Page 2

Die hellste Lampe im Leuchter bist'de nicht, wa?
 
Naja wenn er nicht die hellste ist ist deine lampe wohl entgültig durchgebrannt. Kannst du lesen ? Was steht bitte oben im Titel ?

Wenn du die bedeutung Average FPS nicht kennst dann google sie lieber mal. Btw. dazu auch noch singleplayer.
 
Zuletzt bearbeitet:
Naja wenn er nicht die hellste ist ist deine lampe wohl entgültig durchgebrannt. Kannst du lesen ? Was steht bitte oben im Titel ?

Wenn du die bedeutung Average FPS nicht kennst dann google sie lieber mal. Btw. dazu auch noch singleplayer.

Oh, lass mich raten:
Wenn eine Grafikkarte auf der selben Plattform 33% schneller ist, dann muss dies das GPU-Limit sein. Weil, wenn es ein CPU-Limit wäre, wären ja die FPS "identisch".
Und wenn dann die selbe Grafikkarte auf unterschiedlichen Plattformen unterschiedliche Ergebnisse liefert, muss dies ein Geschenk Gottes sein.

Warum äußern sich dauernd Leute zu Themen, die von diesen keine Ahnung haben?
 
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