DirectX 12 Grafik-API

[BlacKi]

gerade online gegangen http://www.pcgameshardware.de/DirectX-12-Software-255525/News/Maxwell-asynchronous-Shader-1169742/

edit: mich interessiert ebenfalls eine stellungnahme nvidia´s an dieser stelle.

[Isen]

ich weiche nicht aus, wir kennen nicht das setting auf das druck ausgeübt wurde zu deaktivieren.


;D ;D - machst gerade genau das, was nvidia macht. Argumentativ verwenden(Bewerben), und wenn man danach fragt(es verwendet), weiß man es nicht, wieso es nicht funktioniert(tut es, verschlechtert aber) Machst du das mit Absicht? Nein.... glaube ich nicht... nur ein " Kommunikationsproblem " :)

[dargo]

gerade online gegangen http://www.pcgameshardware.de/DirectX-12-Software-255525/News/Maxwell-asynchronous-Shader-1169742/

edit: mich interessiert ebenfalls eine stellungnahme nvidia´s an dieser stelle.
Die Überschrift ist mal geil. :tongue:
DirectX 12: Asynchronous Shader auf Geforces laut Oxide ein "absolutes Desaster"

[fondness]

Weil ja auch alle GW-Titel wie W3 so schlecht auf AMD laufen.
Dümmliche Verallgemeinerungen ftw.

Zumindest die Gameworks-Features selbst laufen entsprechend mies.
Hoffentlich ist AMD auch so schlau, und stellt entsprechend viele Effekte zur Verfügung, die über Async-Compute laufen.
Aber vermutlich werden es die Devs eh nutzen, da man aus den Konsolen alles raus quetschen will und womöglich wird Pascal dann auch ordentlich AsyncCompute unterstützen.

[BlacKi]

Welche Empfehlung denn. NV wirbt doch damit, dass es möglich ist. Macht man es, kackt die Leistung sogar ein. Lüge also. Sie können es nur auf dem Papier.
aus dem pcgh artikel geht hervor: " Nvidia soll deshalb dazu geraten haben, das Feature auf Maxwell, Kepler und Co. zu deaktivieren" soviel dazu zum ausweichen.

nur weil die leistung einbricht wenn man Asynchronous Shader nutzen möchte ist es doch keine lüge.

[aufkrawall]

Zumindest die Gameworks-Features selbst laufen entsprechend mies.
Schon wieder eine dümmliche Verallgemeinerung. Wo laufen PCSS oder HBAO+ auf Radeons mies?

[maguumo]

Mit solchen Artikeln gießt man doch nur Öl ins Fanboy War Feuer. Könnte man da nicht einen etwas fundierteren Artikel aufsetzen der die Problematik erklärt? PCGH dürfte dafür doch genug Kontakt zu kompetenten Leuten haben?

[BlacKi]

Die Überschrift ist mal geil. :tongue:
ich check das grade nicht.

die aktuellen DX12 benches zeigen nvidia karten mit Asynchronous Shader "On"? im desaster modus?

d.h. ohne Asynchronous Shader wären die nvidia karten unter DX12 schneller?

[Isen]

@BlacKi,

du weichst noch immer aus.
Ich sagte doch, " Kommunikationsproblem " ...

Wenn man etwas bewirbt und in den Spec enthalten ist, es entsprechend nutzt aber nicht funktioniert, dann wirbt man mit etwas, was man nicht halten kann. Ähnlich mit den 4G...
Und damit wirbt man ja nun nicht erst seit kurzem.

Genauer gesagt: Die Empfehlung, wovon du weiter hinten gesprochen hast, IST das, was in den Specs steht und Nvidia selbst so anbietet, werben schließlich damit. Aber es funktioniert eben nicht... wieso wirbt man dann damit?

[Tamagothi]

nochmals klartext:

die aktuellen DX12 benches zeigen nvidia karten mit Asynchronous Shader "On"? im desaster modus?

d.h. ohne Asynchronous Shader wären die nvidia karten unter DX12 schneller?

Nein ist für alle Nvidia Karten aus.

So hab ich das verstanden.

[BlacKi]

Nein ist für alle Nvidia Karten aus.

So hab ich das verstanden.
so wie ich das gelesen habe ist es doch genau das was nvidia wollte, das nvidia karten ohne Asynchronous Shader laufen zu lassen.

nochn zitat aus dem artikel: "Zum einen ist das Nvidias guter Optimierung unter DX11 geschuldet, auf der anderen Seite müssen Geforces aber ohne asynchrone Shader auskommen."

bezieht sich das schwarz markierte nun auf den dx11 modus oder dx12 modus?

[fondness]

Ach, lassen wir das. Bitte löschen.

[BlacKi]

@BlacKi,
Wenn man etwas bewirbt und in den Spec enthalten ist, es entsprechend nutzt aber nicht funktioniert, dann wirbt man mit etwas, was man nicht halten kann. Ähnlich mit den 4G...

aber es funktioniert! "Laut einem Oxide-Entwickler seien Nvidia-GPUs grundsätzlich nicht in der Lage, asynchrone Shader performant auszuführen." zitat aus dem pcgh artikel.

[Isen]

es verschlechtert die Leistung.
Wenn du das als " funktioniert " bezeichnest... oh oh....

@Blacki,

auf dx12 - Spec halt. Gehört zu DX12.

[deekey777]

Asynchrone Shader sind das, was Tessellation für Radeons war. Oder FP32 für GeforceFX: Man kann es, aber hat nicht schnell.

[dargo]

ich check das grade nicht.

die aktuellen DX12 benches zeigen nvidia karten mit Asynchronous Shader "On"? im desaster modus?

d.h. ohne Asynchronous Shader wären die nvidia karten unter DX12 schneller?
Meine Güte... jetzt warte doch erstmal paar DX12 Titel mit AS ab. Oxide selbst spricht davon, dass man das Performanceplus von denen mit AS nicht unbedingt auf die Goldwaage legen sollte. Da ist offenbar noch mehr drin. Man schnuppert quasi erst im AS-Bereich rum. Es braucht Zeit und Erfahrungen um das Maximum rauszuholen.

[BlacKi]

Meine Güte... jetzt warte doch erstmal paar DX12 Titel mit AS ab. Oxide selbst spricht davon, dass man das Performanceplus von denen mit AS nicht unbedingt auf die Goldwaage legen sollte. Da ist offenbar noch mehr drin. Man schnuppert quasi erst im AS-Bereich rum. Es braucht Zeit und Erfahrungen um das Maximum rauszuholen.
stimmt hast recht, aber bei solchen themen kann man leicht feuer und flamme sein.^^

[dargo]

so wie ich das gelesen habe ist es doch genau das was nvidia wollte, das nvidia karten ohne Asynchronous Shader laufen zu lassen.

nochn zitat aus dem artikel: "Zum einen ist das Nvidias guter Optimierung unter DX11 geschuldet, auf der anderen Seite müssen Geforces aber ohne asynchrone Shader auskommen."

bezieht sich das schwarz markierte nun auf den dx11 modus oder dx12 modus?
Wie soll sich das auf DX11 beziehen wenn AS erst mit DX12 möglich ist? :freak:

Edit:
Im Prinzip ist es ganz einfach. Unter DX12 sollten Entwickler auf Geforces bis hinauf zum Maxwell kein AS verwenden weil die GPUs dann langsamer werden. Auf Radeons (GCN) bringt AS bis zu 30% laut einigen Entwicklern. AMD selbst spricht afaik im Worst Case von bis zu 46%.
http://images.anandtech.com/doci/9124/Async_Perf.jpg

[Blediator16]

Asynchrone Shader sind das, was Tessellation für Radeons war. Oder FP32 für GeforceFX: Man kann es, aber hat nicht schnell.

Man kann verkrüppelnde Features nicht mit effizienterer Arbeitsweise vergleichen. Das selbe wurde bereits bei Mantle und physx/crapworks schon versucht.

Mal davon abgesehen.

Wurde nicht gesagt, dass MS und Nvidia schon vor Jaaaahren an DX12 gearbeitet haben? Wie kommts, dass sämtliche Nvidiakarten in dem Zusammenhang so verkrüppelt sind? Und damit werden auch die übertrieben hochfrequenten Treiberreleases von Nvidia ziemlich klar. Für jeden kleinen Furz müssen sie nämlich Hinz und Kunz optimieren, sonst läufts nicht so, wie es soll.

[Atma]

Wie kommts, dass sämtliche Nvidiakarten in dem Zusammenhang so verkrüppelt sind?
Wie kommt's, dass DX12 Demos von Final Fantasy 15, King of Wushu oder Forza 5 auf Nvidia Hardware gezeigt wurden?

[Isen]

Wie kommt es dann, trotz das nvidia mehrmals entsprechende Treiber bereitgestellt hat und entsprechend mit den Entwicklern zusammen arbeitete, dass die Leistung schlechter ausfällt?

Haben doch dann genügend Erfahrung durch die " Demos " ?

[Unicous]

Wie kommt's, dass DX12 Demos von Final Fantasy 15, King of Wushu oder Forza 5 auf Nvidia Hardware gezeigt wurden?

Ich werde mich jetzt mal gaaaanz weit aus dem Fenster lehnen und eine krasse Behauptung aufstellen, die dich erschüttern wird: Es sind allesamt GameWorks-Titel (bzw. nutzen GameWorks-Effekte).:eek:

Das ist also vollkommener Zufall. Und was das mit Async Compute zu tun hat, kannst du uns gerne verraten.;)

[dargo]

Wie kommt's, dass DX12 Demos von Final Fantasy 15, King of Wushu oder Forza 5 auf Nvidia Hardware gezeigt wurden?
Was hat das eine mit dem anderen jetzt zu tun?

[Tamagothi]

Man kann verkrüppelnde Features nicht mit effizienterer Arbeitsweise vergleichen. Das selbe wurde bereits bei Mantle und physx/crapworks schon versucht.

Mal davon abgesehen.

Wurde nicht gesagt, dass MS und Nvidia schon vor Jaaaahren an DX12 gearbeitet haben? Wie kommts, dass sämtliche Nvidiakarten in dem Zusammenhang so verkrüppelt sind? Und damit werden auch die übertrieben hochfrequenten Treiberreleases von Nvidia ziemlich klar. Für jeden kleinen Furz müssen sie nämlich Hinz und Kunz optimieren, sonst läufts nicht so, wie es soll.

Könnt an mantle liegen das DX12 so schnell erscheint. Vielleicht war DX12 erst zu Pascal Zeiten geplant?!

[Atma]

Ich werde mich jetzt mal gaaaanz weit aus dem Fenster lehnen und eine krasse Behauptung aufstellen, die dich erschüttern wird: Es sind allesamt GameWorks-Titel (bzw. nutzen GameWorks-Effekte).:eek:

Das ist also vollkommener Zufall. Und was das mit Async Compute zu tun hat, kannst du uns gerne verraten.;)
Forza 5 ist ein reiner Konsolentitel, der (eigentlich) auf GCN optimiert ist. Warum sollte man sich für eine DX12 Demo die Mühe machen und Gameworks einbauen?


Was hat das eine mit dem anderen jetzt zu tun?
Dass das Thema wieder (gewollt?) gepusht wird und ein gefundenes Fressen für Fanboys ist.

[deekey777]

Forza 5 ist ein reiner Konsolentitel, der (eigentlich) auf GCN optimiert ist. Warum sollte man sich für eine DX12 Demo die Mühe machen und Gameworks einbauen?
.
Damit man eine Geforce kauft?

[dargo]

Dass das Thema wieder (gewollt?) gepusht wird und ein gefundenes Fressen für Fanboys ist.
Hä? Noch vor nicht all zu langer Zeit hieß es von einigen hier im Forum Maxwell hätte keine Schwäche. Jetzt kennen wir die. Für mich persönlich ist das auch neu.

[Unicous]

@Atma

Bei Forza habe ich mich vertan, dachte da wird HBAO+ genutzt, aber es wurde seinerzeit nur auf einer Titan Black gezeigt. Lustiger dick move seitens Nvidia und Microsoft damals (als Publisher).

Nun frage ich dennoch, was hat das mit dem aktuellen Thema zu tun? Dass Nvidia in DX12 investiert hat, sowohl Ressourcen als auch Lobbyarbeit ist klar. Dass sie wohl zusammen mit Intel schon bevor DX12 final war schon ein erstes darüber hinaus gehendes Feature Level gepushed haben ist auch interessant. Nun sieht es so aus, als hätte AMD einen Ass im Ärmel was DX12 betrifft.

Ob AMD diese Ass ausspielen kann ist aber die Frage. Daher muss man sich von beiden Seiten nicht wie aufgescheuchte Hühner aufplustern.

Wir werden sehen, wie es in ein paar Jahren aussieht.

[Atma]

Damit man eine Geforce kauft?
Bei King of Wushu wurde erwähnt, dass GameWorks zum Einsatz kommt. Bei FF15 und Forza nicht. Wie gravierend das Problem ist, wird sich erst in Zukunft zeigen. Der Dev von Oxide Games schreibt doch, dass sie nur an der Oberfläche von Async Compute kratzen und experimentieren.

[Unicous]

HBAO+ ist bei Heavensward integriert, seines Zeichens Teil von ShadowWorks bzw. GameWorks.

Gibt sogar einen extra Blog-Eintrag von Nvidia.

http://www.geforce.com/whats-new/articles/final-fantasy-xiv-heavensward-benchmark

[aufkrawall]

Es wurde schon zigmal gebencht, dass nur HW wirklich Radeons benachteiligt.
Wer will, kann HBAO+ ja einfach ausschalten und sich an der schlechteren Grafik erfreuen...

[Unicous]

Darum geht es doch gar nicht. Atma musste unbedingt die Diskussion mit einem irrelevanten Einwurf in andere Bahnen lenken, dabei steht überhaupt nicht zur Diskussion, das Nvidia DX12 unterstützt, oder auf was er hinaus will.

HBAO+ ist laut Nvidia Teil von GameWorks, und das war sicherlich Teil der Motivation diese Spiele zu zeigen: was sich Microsoft bei Forza 5 gedacht hat, würde ich gerne mal wissen, denn sie haben sich mit dem Blödsinn nur ins eigene Bein geschossen. Ein Xbox One exklusives Franchise auf einem PC mit Titan Black vorzustellen ist schon selten dämlich.

[Blediator16]

Hä? Noch vor nicht all zu langer Zeit hieß es von einigen hier im Forum Maxwell hätte keine Schwäche. Jetzt kennen wir die. Für mich persönlich ist das auch neu.

Nicht nur das. Auch, dass es AMD absolut garnichts bringen wird, dass nur AMD inkl. GCN in allen Konsolen drinne ist.

Darum geht es doch gar nicht. Atma musste unbedingt die Diskussion mit einem irrelevanten Einwurf in andere Bahnen lenken, dabei steht überhaupt nicht zur Diskussion, das Nvidia DX12 unterstützt, oder auf was er hinaus will.

HBAO+ ist laut Nvidia Teil von GameWorks, und das war sicherlich Teil der Motivation diese Spiele zu zeigen: was sich Microsoft bei Forza 5 gedacht hat, würde ich gerne mal wissen, denn sie haben sich mit dem Blödsinn nur ins eigene Bein geschossen. Ein Xbox One exklusives Franchise auf einem PC mit Titan Black vorzustellen ist schon selten dämlich.


Ganz einfach. Eine Panikreaktion. Schau mal wann diese Präsentation stattgefunden hat :D

[Kartenlehrling]

Weiß auch gar nicht was die Aufregung bringt, Nvidia hat doch gezeigt das es mit DX11 SEHR-Gut läuft und mit DX12 + Async Compute nur leicht schlechter, dann sollen sie es wie empfohlen deaktivierbar machen.
Was halt nicht geht wenn jetzt Nvidia vorschreibt das generell auf Async Compute verzichte werden soll nur weil sie es nicht beherrschen, Optional in der Game-ini und gut.

[fondness]

Ich bin gespannt ob irgend ein Unreal-Engine-Spiel überhaupt Async-Compute verwenden wird.

[dargo]

Weiß auch gar nicht was die Aufregung bringt, Nvidia hat doch gezeigt das es mit DX11 SEHR-Gut läuft und mit DX12 + Async Compute nur leicht schlechter, dann sollen sie es wie empfohlen deaktivierbar machen.

Ich kann die Aufregung mancher aus dem grünen Lager schon verstehen. Dank AS auf Radeons kann es dann später in dem einen oder anderen Titel nicht mehr 980TI/Titan X vor Fury X heißen sondern andersrum. Eventuell ist die Fury non X auch minimal vor beiden Geforces. Und ne 390X ist dann auch nicht mehr weit.

[Novum]

Ich bin gespannt ob irgend ein Unreal-Engine-Spiel überhaupt Async-Compute verwenden wird.
Ich bin gespannt, ob Wasser nass ist.

[Troyan]

Ich bin gespannt ob irgend ein Unreal-Engine-Spiel überhaupt Async-Compute verwenden wird.

Dir ist schon klar, dass dies eine API Funktion ist, die von jeder DX12 Karte unterstützt wird? :rolleyes:

Hier mal was zum Lesen: https://msdn.microsoft.com/de-de/library/windows/desktop/dn899217%28v=vs.85%29.aspx

[sulak]

Vermute mal ein Treiber Problem für AS unter DX12.

nVidia hat ja immer betont, dass die die Auslastung ihrer Einheiten aufdrehen und aktuell sind die Scheduler wohl sehr gut durch optimiert. AS soll die Auslastung der GPUs erhöhen, aber wenn eine GPU schon zu 95% ausgelastet ist, geht da nix mehr (bei den Radeons heist es doch immer, die fahren nicht voll ausgelastet, blablublö ist zu klein/überlastet/schwach!).

Jetzt darf ein Entwickler erklären was AS von "Wald und Wiesen" Shadern unterscheidet.

Wenn nVidia die Ausführung von Shader Code soweit optimiert hat, das nun etwas "asynchrones" das ganze durcheinander würfelt und damit die Auslastung um 20% einbricht... das was falsch verdrahtet ist kann man sich ja schlecht vorstellen. Also Fix-It per Treiber ggf?

[aufkrawall]

Ich bin gespannt, ob Wasser nass ist.
Warum der Zweitaccount?

[Gipsel]

Weiß auch gar nicht was die Aufregung bringt, Nvidia hat doch gezeigt das es mit DX11 SEHR-Gut läuft und mit DX12 + Async Compute nur leicht schlechter, dann sollen sie es wie empfohlen deaktivierbar machen.Wo läuft es mit DX12 + AS "nur leicht schlechter"? Bei der Ashes-Demo sind die asynchronen Shader auf nV komplett deaktiviert, weil es sonst langsamer wäre. Dies hat Oxide übrigens auf Vorschlag von nV so gemacht. Wie es auf nV mit den asynchronen Shadern laufen würde, weiß man im Moment nicht so genau (außerhalb von ein paar Entwicklerstudios und bei nV und AMD natürlich, die das wohl getestet haben werden). AlphaTier hat vor zwei Wochen oder so hier im Thread ja schon mal etwas diplomatischer als Oxide ("Desaster") von "negative scaling" gesprochen. Sprich, daß es mit AS langsamer wird, ist ihm wohl auch schon mal aufgefallen bzw. zugetragen worden.
Nvidia hat negativ scaling mit Async Compute und ist deswegen beleidigt.Wie stark sich das jeweils auswirkt (da ist Alles drin von praktisch nicht meßbar bis massiv), hängt wohl wie immer davon ab, wie man es genau (und wie umfangreich) nutzt.

[tm0975]

kann man dann überhaupt von einer dx12-kompatibilität sprechen, wenn dx12-features (ohne wissen des gemeinen spielers) für das dx12-spiel nicht verwendet werden (können)?

[sulak]

Klar, und verwenden kannst es, is halt nur langsam...
Vergleich mal den Speed mit einer Intel IGP ;D

Was es früher an Features mit einer neuen Gen gab und was nicht genutzt werden konnte mangels Geschwindigkeit... (nV40 vs. R420)

[aufkrawall]

Wo sehen die Specs vor, dass durch das Nutzen eines Features etwas schneller werden muss?
Ist natürlich hirnrissig, wenn nicht, aber das war ja nicht deine Frage.

Aber erstmal abwarten, wie es sich mit weiteren Spielen und Treibern verhält.
Wobei die Indizien wohl nicht gut aussehen.

[Troyan]

Ach Leute, wie wäre es, wenn ihr euch erstmal in das Thema "Multi-Engine" einlest. Es gibt kein "Asynchronous Shaders" in DX12. Es gibt "Asynchronous Compute" und das wird von jeder kompartiblen GPU unterstützt.

Es liegt einzig und allein in den Händen der Entwickler, wie sie "Asynchronous Compute" verwenden. Und sollte die Leistung mit der Implementierung auf bestimmter Hardware langsamer sein, dann muss der Entwickler dies eben deaktivieren. Macht ja kein Sinn etwas anzulassen, dass auf anderem Weg gelöst werden kann.

[aufkrawall]

Man muss sich mit Maxwell eh nicht einpinkeln. AMD dürfte mit den bisherigen GPUs mit AC eher Boden gut machen, anstatt vorbeizuziehen.
Und das kann man schlecht schlecht finden.

[woodsdog]

Man muss sich mit Maxwell eh nicht einpinkeln. AMD dürfte mit den bisherigen GPUs mit AC eher Boden gut machen, anstatt vorbeizuziehen.
Und das kann man schlecht schlecht finden.

Genau das.
Letztlich sollte jeder NVler an einem gleichwertigen AMD Interesse haben.

[BlacKi]

Genau das.
Letztlich sollte jeder NVler an einem gleichwertigen AMD Interesse haben.
ja, aber nicht daran das nv karten schlechter gemacht wird als sie sein könnten.

wie schon oft erwähnt, liegt es nun in der hand der entwickler wie gut etwas laufen könnte.

eine passende antwort nvidia´s darauf könnte so aussehen, dass man Asynchronous Computing auf nvidia karten vorführt.

[fondness]

Ich bin gespannt, ob Hawaii nicht nur GK110, sondern auch GM204 überlebt. :D

BTW, sind solche Steigerungen VR spezifisch oder nicht?

http://s8.postimg.org/ksittqa6t/Kd_TJt_VK.png (http://postimage.org/)

[woodsdog]

ja, aber nicht daran das nv karten schlechter gemacht wird als sie sein könnten.

wie schon oft erwähnt, liegt es nun in der hand der entwickler wie gut etwas laufen könnte.

eine passende antwort nvidia´s darauf könnte so aussehen, dass man Asynchronous Computing auf nvidia karten vorführt.

Wo werden denn NV karten schlechter gemacht "als sie sein könnten" wenn sie Funktion X nun mal nur im Schlaftablettenmodus können...?!

Tessellation. Schon vergessen? Zieht da das Argument bei AMD dann auch?

Der Entwickler nutzt einfach nur eine Funktion DER SPEC. Wo ihm da jetzt ein Vorwurf zu machen ist bleibt dein Geheimnis.

Wenn hier einer die Eselskappe bekommen sollte ist es NV :freak:

[fondness]

Sehr gute Zusammenfassung im übrigen hier:
http://hardforum.com/showthread.php?t=1873640

Maxwell 2 is a less parallel compute architecture than Hawaii. How? HyperQ works "in order" and in several additional hierarchical stages which are not present in GCN's Asynchronous compute solution. HyperQ can thus be described as working "in order" in several segments of its pipeline and is prone to pipeline stalls due to dependencies, whereas Asynchronous Compute can be described as working "out of order" (capable of working in order as well, by syncing several ACEs, if the need arises).

SUMMARY
Hardware, software and API support are all now available to deliver on the promise of asynchronous
computing for GPUs. The GCN architecture is perfectly suited to asynchronous computing, having
been designed from the beginning with this operating model in mind. This will allow developers to
unlock the full performance potential of today’s PC GPUs, enabling higher frame rates and better
image quality.

[Grestorn]

Genau das.
Letztlich sollte jeder NVler an einem gleichwertigen AMD Interesse haben.

Zustimmung. Sowas in der Art wollte ich auch schon schreiben.

[][immy]

Wo werden denn NV karten schlechter gemacht "als sie sein könnten" wenn sie Funktion X nun mal nur im Schlaftablettenmodus können...?!

Tessellation. Schon vergessen? Zieht da das Argument bei AMD dann auch?

Der Entwickler nutzt einfach nur eine Funktion DER SPEC. Wo ihm da jetzt ein Vorwurf zu machen ist bleibt dein Geheimnis.

Wenn hier einer die Eselskappe bekommen sollte ist es NV :freak:
War auch vorher schon klar das es ne nvidia mit asyc compute nicht so rosig aussehen wird. Die lasten die vorhandene Hardware schon länger gut aus, während bei amd noch sehr viel Leistung brach liegt. Dann müsste man als Entwickler halt einfach zusehen einen nvidia chip nicht mit der hauptaufgabe komplett auszulasten sondern einfach ein wenig Leistung für async Berechnungen frei lassen.
Ist nur eine Sache der Auslastung. AMD kann nur endlich mal die vielen vielen flops, die bisher auf der Strecke blieben nutzen.

[Menace]

Ironiemodus: Vielleicht verkauft deshalb Huang einige nvidia Aktien. (http://finance.yahoo.com/news/weekly-ceo-sells-highlight-envision-214825661.html)
;)
Link von Desti aus dem planet3dNow-Forum geklaut.

Wenn nvidia mit DX11 schneller ist als mit DX12, können die doch problemlos diesen nehmen. Oder gibt es neue Eigenschaften für eine Grafikkarte?

[Nightspider]

Mensch es ging um das GPU Limit.

Im CPU Limit dreht DX12 Kreise um DX11.

[Troyan]

Ich habe mir mal den Spaß gemacht und das Asynchronous Compute Sample von Microsoft kompiliert:
http://workupload.com/file/sx5bMFJF

https://github.com/Microsoft/DirectX-Graphics-Samples/tree/master/Samples/D3D12nBodyGravity
https://msdn.microsoft.com/en-us/library/windows/desktop/mt186620%28v=vs.85%29.aspx

Musste die Partikelanzahl von 10k auf 80k erhöhen, da das Sample nur vernünftig im Fenstermodus läuft. So kommt meine GTX980TI@1500Mhz auf 60FPS (ausgelesen mit eVGA Precision im Log Menü).

Sehr gute Zusammenfassung im übrigen hier:
http://hardforum.com/showthread.php?t=1873640

Ab hier lesen: https://forum.beyond3d.com/posts/1868993/
Widerspricht den Aussagen aus dem Blog-Post.

[aufkrawall]

Dafür brauchts das Runtime-Environment:
https://www.microsoft.com/en-us/download/details.aspx?id=48145

[Blediator16]

Man muss sich mit Maxwell eh nicht einpinkeln. AMD dürfte mit den bisherigen GPUs mit AC eher Boden gut machen, anstatt vorbeizuziehen.
Und das kann man schlecht schlecht finden.

Hier wird ja gerade so getan, alsob AMD Karten ständig so langsam sind wie unter unoptimierten DX11 Pfaden.

[Nightspider]

Ist ja auch oft so.

[aufkrawall]

Sie sind es manchmal, das ist schon schlimm genug.

Edit: Nightspider siehts etwas schwärzer. :D

[Fusion_Power]

Ich kenn mich da nicht so aus aber ich bin sicher, DX12 kann noch mehr als nur dieses asynchrone Gedöns. Da hat dann bei anderen Sachen (hoffentlich) NVidia wieder die Nase vorn. Die können es sich gar nicht leisten, gegenüber AMD so ins Hintertreffen zu geraten wie es diese ersten benchmarks suggerieren. Hoffen wir mal die bekommen das noch in den Griff bei den aktuellen Grafikkarten, man kann mit guten Treibern ja Wunder bewirken. Wäre nur schade wenn NVidia das wirklich nur mit neuen Grafikkarten hinbekäme und die aktuelle 900er Generation schon wieder veraltet ist.

[Gipsel]

Ab hier lesen: https://forum.beyond3d.com/posts/1868993/
Widerspricht den Aussagen aus dem Blog-Post.Inwiefern?
Also ich sehe da, daß in dem Test für Compute + Graphic jeweils soviel Zeit benötigt wird, als wenn das sequentiell läuft, bei AMD aber parallel.
Also bei nV: time_total = time_compute + time_graphic
und bei AMD: time_total = max(time_compute, time_graphic)

Das bestätigt den Blog-Post von Oxide, daß bei Maxwell keine asynchronen Compute-Shader funktionieren (bzw. halt nur synchron, sequentiell nacheinander) doch perfekt!?!

[Troyan]

Das Compute-Ergebnis widerspricht den Aussagen aus dem Posting.

[Novum]

Wieso?

[Gipsel]

Wieso?Vielleicht meint er, weil das insgesamt etwas realitätsfern geschrieben ist (single lane shader? also nur ein thread pro threadgroup genutzt, irgendwo gibt es zumindest bei AMD noch einen fetten Zeitoverhead usw.). Dürfte aber trotzdem nichts an der parallelen (AMD) vs. sequentiellen (nv) Ausführung auf dem Shaderarray der GPU ändern. Also an den bisherigen Daten da kann ich keine Invalidierung der Oxide-Wortmeldung festmachen (wie von Troyan behauptet).

[Tamagothi]

Stimmt das so in etwa ?

https://www.reddit.com/r/pcgaming/comments/3j1916/get_your_popcorn_ready_nv_gpus_do_not_support/

übersetztung: (PCGH Forum)

Denke an einen Verkehrsfluss, der sich von A nach B bewegt.

NV GPUs: Hat eine Straße mit einer Spur für Autos(Grafik) und 32 Spuren für LKWs(Compute).

Aber es ist nicht möglich, dass Autos und LKWs die Straße zur selben Zeit benutzen. Wenn die Straße von Autos befahren wird, müssen alle LKWs warten bis keine Autos mehr kommen und dann können sie erst fahren. Das ist der sogenannte „context switch“ von dem die Programmierer reden. Das ist eine große Leistungseinbuße.

AMD GPUs auf Basis von GCN: Hat eine Straße(CP, Command Processor) mit einer Spur für Autos und LKWs. Hat jedoch weitere 8 Straßen (ACEs; Asynchronous Compute Engines) mit jeweils 8 Spuren pro Straße(64 insgesammt) nur für LKWs.

So können LKWs und Autos zur gleichen Zeit fahren, völlig parallel und asynchron.
Die LKWs durch die ACEs(je nach dem wie viele vorhanden sind) und die Autos durch den CP. Es ist kein „context switch“ erforderlich.

Nvidias Design ist für DX11 gut, weil DX11 nur eine Straße nutzen kann. Die ACE Einheiten in AMDs GCN Design tun nichts unter DX11, sie sind nicht erreichbar/geschlossen. DX12 öffnet all diese Straßen der ACEs.

[StefanV]

Oh, nVidia kann irgendein Feature nicht?
ÜBERRASCHUNG. Das ist doch schon seit Dekaden so!

Erinnert sich hier noch jemand an Geforce FX vs 9k Serie und folgend??
Und wie die aufgebaut waren?!

Bei nVidia war ja die Pipeline von TMU und Shader seriell, bei ATi aber unabhängig -> in Shader Lastigen Dingen ging die Performance von nV3x-G7x total baden...

Tja und jetzt haben wir eine Widerholung der ganzen Geschichte...
Und das gebrabbel von 'GCN ist ineffizient' erweist sich, wieder einmal, als Bullshit...

Denn dabei wird (mal wieder) außer acht gelassen, dass nVidia gerade so das nötigste tut und AMD etwas mehr rein packt...

[Novum]

Stimmt das so in etwa ?

https://www.reddit.com/r/pcgaming/comments/3j1916/get_your_popcorn_ready_nv_gpus_do_not_support/

übersetztung: (PCGH Forum)

Denke an einen Verkehrsfluss, der sich von A nach B bewegt.

NV GPUs: Hat eine Straße mit einer Spur für Autos(Grafik) und 32 Spuren für LKWs(Compute).

Aber es ist nicht möglich, dass Autos und LKWs die Straße zur selben Zeit benutzen. Wenn die Straße von Autos befahren wird, müssen alle LKWs warten bis keine Autos mehr kommen und dann können sie erst fahren. Das ist der sogenannte „context switch“ von dem die Programmierer reden. Das ist eine große Leistungseinbuße.

AMD GPUs auf Basis von GCN: Hat eine Straße(CP, Command Processor) mit einer Spur für Autos und LKWs. Hat jedoch weitere 8 Straßen (ACEs; Asynchronous Compute Engines) mit jeweils 8 Spuren pro Straße(64 insgesammt) nur für LKWs.

So können LKWs und Autos zur gleichen Zeit fahren, völlig parallel und asynchron.
Die LKWs durch die ACEs(je nach dem wie viele vorhanden sind) und die Autos durch den CP. Es ist kein „context switch“ erforderlich.

Nvidias Design ist für DX11 gut, weil DX11 nur eine Straße nutzen kann. Die ACE Einheiten in AMDs GCN Design tun nichts unter DX11, sie sind nicht erreichbar/geschlossen. DX12 öffnet all diese Straßen der ACEs.
Deine Autovergleich ist eine falsche Analogie.

Es gibt nicht mehr Einheiten, nur die Auslastung wird besser, aber auch nur wenn sie sonst nicht eh schon perfekt ist. Was zugegenbermaßen fast nie der Fall ist.

Oh, nVidia kann irgendein Feature nicht?
ÜBERRASCHUNG. Das ist doch schon seit Dekaden so!

Erinnert sich hier noch jemand an Geforce FX vs 9k Serie und folgend??
Und wie die aufgebaut waren?!

Bei nVidia war ja die Pipeline von TMU und Shader seriell, bei ATi aber unabhängig -> in Shader Lastigen Dingen ging die Performance von nV3x-G7x total baden...

Tja und jetzt haben wir eine Widerholung der ganzen Geschichte...
Und das gebrabbel von 'GCN ist ineffizient' erweist sich, wieder einmal, als Bullshit...

Denn dabei wird (mal wieder) außer acht gelassen, dass nVidia gerade so das nötigste tut und AMD etwas mehr rein packt...
Ach so wie alle Radeons vor der 7000 Series kein DX12 unterstützen, weil sie kein bindless können?

Oder so wie die Geometrie-Leistung der neusten Radeons immer noch nicht mal Fermi-Niveau erreicht hat?

Selektive Wahrnehmung, much?

[deekey777]

Oh, nVidia kann irgendein Feature nicht?
ÜBERRASCHUNG. Das ist doch schon seit Dekaden so!

Erinnert sich hier noch jemand an Geforce FX vs 9k Serie und folgend??
Und wie die aufgebaut waren?!

Bei nVidia war ja die Pipeline von TMU und Shader seriell, bei ATi aber unabhängig -> in Shader Lastigen Dingen ging die Performance von nV3x-G7x total baden...

Tja und jetzt haben wir eine Widerholung der ganzen Geschichte...
Und das gebrabbel von 'GCN ist ineffizient' erweist sich, wieder einmal, als Bullshit...

Denn dabei wird (mal wieder) außer acht gelassen, dass nVidia gerade so das nötigste tut und AMD etwas mehr rein packt...
Dafür renderten Radeons in Quake 3 nur 16 bit!

Schon die Leistungseinbrüche mit Tessellation vergessen?
Wir können eine schöne Liste machen, welcher IHV mit welchem Feature so manches Problem hatte, was der Wettbewerber als Killer-Feature hochschauckelte, und trotzdem dreht sich Erde weiter.

[tm0975]

ihr möchtet jetzt aber nicht dx12 performance-vorteil von 20 bis 40 % mit tessalation etc. gleichsetzen?!? wenn sich das hier bewahrheitet, werden viele geforce-user enttäuscht sein. nvidia wirds freuen, dann kaufen die jünger schneller ne neue karte. wäre doch ein unding, wenn die performance der eigenen karten mit der zeit steigen würde und wie bei amd eine 3 jahre alte 290 in 2 jahren immer noch genug leistung bringen würde unter dx12. ist natürlich etwas schade, dass es noch nicht allzu viele benchmarks unter dx12 gibt. daher erstmal abwarten...

[Blediator16]

Dafür renderten Radeons in Quake 3 nur 16 bit!

Schon die Leistungseinbrüche mit Tessellation vergessen?
Wir können eine schöne Liste machen, welcher IHV mit welchem Feature so manches Problem hatte, was der Wettbewerber als Killer-Feature hochschauckelte, und trotzdem dreht sich Erde weiter.

Ach komm Tesslation mit einem Boost vergleichen ist der letzte Scheiss. Das selbe wurde bereits mit Mantle und Physx/Crapworks gemacht. Das sind einfach keine Vergleiche.

[samm]

Vielleicht meint er, weil das insgesamt etwas realitätsfern geschrieben ist (single lane shader? also nur ein thread pro threadgroup genutzt, irgendwo gibt es zumindest bei AMD noch einen fetten Zeitoverhead usw.). Dürfte aber trotzdem nichts an der parallelen (AMD) vs. sequentiellen (nv) Ausführung auf dem Shaderarray der GPU ändern. Also an den bisherigen Daten da kann ich keine Invalidierung der Oxide-Wortmeldung festmachen (wie von Troyan behauptet).Er meint wohl gar nichts so Technisches wie ein single-lane-shader merkwürdiger Zeitoverhead, was ein gewisses Verständnis des Benchmarks voraussetzen würde, würde ich mal meinen, weil seine Argumentation ziemlich jener eines gewissen "sontin" auf dem AT-Forum entspricht, der als Antwort zu der eigentlichen Thematik "Graphics + Compute = Graphics + Comute vs. ... = max(Graphics, Compute)" nur aufzeigt, dass nVidia bis zum Punkt x schneller sind als die AMDs mit ihrem konstanten Verhalten. Bislang sprechen noch alle genaueren Untersuchungen zum Thema für Oxide's Aussage.

[Timbaloo]

Was ich mich die ganze Zeit frage: Ob Sync oder Async, das Ergebnis wird sich ja nicht nur in der Performance unterscheiden. Welche Auswirkungen hat es denn noch? Die Frage geht in der gesamten Diskussion irgendwie unter, ist sie (die Frage) doof?

[aufkrawall]

Ist die Frage, obs wirklich mehr Performance gibt, wenn die im Vergleich zu Maxwell eh schon gut ist (wie etwa bei Ryse).
Es scheint nämlich auch so zu sein, dass GCN mitunter Async Compute braucht, um konkurrenzfähig zu sein.
Warum sonst verbraten die ALUs in Anno oder Risen Strom wie sonst was für ein mittelmäßiges Ergebnis?

[Novum]

Was ich mich die ganze Zeit frage: Ob Sync oder Async, das Ergebnis wird sich ja nicht nur in der Performance unterscheiden. Welche Auswirkungen hat es denn noch? Die Frage geht in der gesamten Diskussion irgendwie unter, ist sie (die Frage) doof?
Welches Ergebnis? Das Rechenergebnis? Natürlich ist das gleich.

Ist die Frage, obs wirklich mehr Performance gibt, wenn die im Vergleich zu Maxwell eh schon gut ist (wie etwa bei Ryse).
Es scheint nämlich auch so zu sein, dass GCN mitunter Async Compute braucht, um konkurrenzfähig zu sein.
Warum sonst verbraten die ALUs in Anno oder Risen Strom wie sonst was für ein mittelmäßiges Ergebnis?
Das Problem ist, dass die CUs fast das selbe verbrauchen, selbst wenn die Auslastung gering ist. Die parisitären Ströme sind heutzutage sehr hoch, allein wenn eine Schaltung an sein muss.

[samm]

Was ich mich die ganze Zeit frage: Ob Sync oder Async, das Ergebnis wird sich ja nicht nur in der Performance unterscheiden. Welche Auswirkungen hat es denn noch? Die Frage geht in der gesamten Diskussion irgendwie unter, ist sie (die Frage) doof?Die Frage ist nicht doof. Latenz ist so ein Stichwort. Ich denke, AMD könnte, wenn sie es schlau anstellen, gerade bei lantenzsensitiven Anwendungen wie VR einen fühlbaren Vorteil herausholen, wenn sie den Devs beibringen, wie sie asynchron zur Grafikberechnung weitere Tasks ausführen können, sei es Compute für's Spiel an sich oder für VR im Speziellen.

[Novum]

Performance und Latenz ist das selbe.

[del_4901]

Performance und Latenz ist das selbe.
disagree

[samm]

Nein. Performance ist ein Überbegriff, Latenz kann ein Teil der Performance sein. Allzuoft sind "höhere fps" mit "höherer Performance" gemeint.

[Novum]

Inwiefern? Wenn die Performance besser ist, ist auch das Ergebnis früher da, ergo die Latenz besser. Höhere FPS = Kürzere Frames = niedrigere Latenz.

Natürlich kann man längere Pipelines bauen um mehr Overlap zu haben um eventuell höhere Performance zu haben, aber die Latenz damit erhöhen. Da wüsste ich aber nicht, wie Async Compute dabei helfen soll, das nicht zu tun. Im Gegenteil, es ist eventuell sogar besser.

[del_4901]

Natürlich kann man längere Pipelines bauen um mehr Overlap zu haben um eventuell höhere Performance zu haben, aber die Latenz damit erhöhen.
Indeed, not the same after all.

[Timbaloo]

Welches Ergebnis? Das Rechenergebnis? Natürlich ist das gleich.
Also so natürlich ist das für mich irgendwie nicht. Ganz allgemein wenn ich zwei Tasks habe und sie einmal synchron und einmal asynchron ausführe und die Tasks tatsächlich auch miteinander kommunizieren, dann kommt eben nicht so ohne weiteres das gleiche Ergebnis heraus.

Die Frage: Inwiefern ist das relevant

[samm]

Mal ein Diagrämmchen. E ist ein Event, R ist das Resultat davon, F ist ein Frame, - ist eine Zeiteinheit ohne Frame / Event.

Fall 1
Spiel:
--E------
Grafikoutput:
FFFFFFFFR

Fall 2
Spiel:
--E------
F-F-R-F-F
Was hat nun die bessere Performance? Wie gesagt, Performance ist ein Überbegriff für etwas, was man quantitativ messen will. Latenz kann man als Teil der Performance sehen.

[Novum]

Edit: A ist nicht mehr da, aber ich verstehe trotzdem nicht was du mir mitteilen willst.

Also so natürlich ist das für mich irgendwie nicht. Ganz allgemein wenn ich zwei Tasks habe und sie einmal synchron und einmal asynchron ausführe und die Tasks tatsächlich auch miteinander kommunizieren, dann kommt eben nicht so ohne weiteres das gleiche Ergebnis heraus.

Die Frage: Inwiefern ist das relevant
Wenn das Ergebnis nicht gleich ist, dann ist es ein Bug, den der Programmierer verbrochen hat. Natürlich muss man für entsprechende Synchronisierung sorgen. Ich kann nicht alles einfach parallel laufen lassen, ist ja logisch.

Indeed, not the same after all.
Im Allgemeinen nicht, in der Regel schon.

[del_4901]

Im Allgemeinen nicht, in der Regel schon.
Disagree again. Gerade das Beispiel mit der längeren Pipeline, wo z.B. Post processing parallel mit dem nächsten frame läuft um den Durchsatz(throughput) zu erhöhen. Latenz ist dann etwa 3 frames wohingegen 2 frames in der Zeit fertig werden(e.g 1.5 frames durchschnittlicher durchsatz)

[Timbaloo]

Vielleicht habe ich in diesem Kontext einfach ein falsches Verständnis von "synchron" und "asynchron". Was ich meine an einem Beispiel:

Task 1 ist der synchrone Task ("zeichne ein Frame"). Dieser Task wird so schnell wie möglich ausgeführt (ist also nicht zeitsynchron).

Task 2 ist der asynchrone Task ("berechne physik"). Dieser Task wird alle 50ms ausgeführt (ist also zeitsynchron).

Ist mein Verständnis hier falsch?

[Kartenlehrling]

Deus Ex: Mankind Divided
Am 23. Februar 2016 wird Adam Jensen auf der PlayStation 4, Xbox One und dem PC zurückkehren.

Das es mit DX12 kommt ist schon bekannt,
aber anscheinen kommt es auch mit OS X El Capitan 10.11 (Metal) und Linux (Vulkan).

Jedenfalls arbeite Feral Interactive an der Linux und MacOSX Version,
seltsamerweise wird im Steam nur Windows angezeigt.
Wie gut war die Mittelerde: Mordors Schatten umsetzung für Mac, im Mac App Store sind nur 2 Kundenrezensionen?

[Novum]

Disagree again. Gerade das Beispiel mit der längeren Pipeline, wo z.B. Post processing parallel mit dem nächsten frame läuft um den Durchsatz(throughput) zu erhöhen. Latenz ist dann etwa 3 frames wohingegen 2 frames in der Zeit fertig werden(e.g 1.5 frames durchschnittlicher durchsatz)
Das kannst du aber eben auch nur sinnvoll mit Async Compute und seine These war ja gerade, dass die Latenz geringer werden soll.

Was ist denn jetzt dein Punkt gerade? Trägt doch nichts zur Diskussion bei. Ich würde davon absehen sowas zu tun, ein Frame weniger Latenz ist bei den meisten Spielen für den Spieler besser als eine 0,5ms geringere Frame-Zeit.

Vielleicht habe ich in diesem Kontext einfach ein falsches Verständnis von "synchron" und "asynchron". Was ich meine an einem Beispiel:

Task 1 ist der synchrone Task ("zeichne ein Frame"). Dieser Task wird so schnell wie möglich ausgeführt (ist also nicht zeitsynchron).

Task 2 ist der asynchrone Task ("berechne physik"). Dieser Task wird alle 50ms ausgeführt (ist also zeitsynchron).

Ist mein Verständnis hier falsch?
Ich verstehe es immer noch nicht, welche Latenz meinst du jetzt? Eingabe zu Ausgabe eines Frames? Was hat das mit alle 50ms Physik berechnen und Async zu tun?

Die Physik kann ich auch so alle 50ms in den Frame einbauen, mit Async wird die Latenz des überlappenden Frames und der Physikberechnung absolut größer werden, weil eben beides gleichzeitig läuft.

[del_4901]

Das kannst du aber eben auch nur sinnvoll mit Async Compute und seine These war ja gerade, dass die Latenz geringer werden soll.
geringere latenz geht auch, wenn man z.B screen re-projection in async compute macht kurz vor dem vBlank wie in vielen VR Applikationen ueblich. Es gibt noch mehr UseCases wo man mit Async Compute mehr Durchsatz bei geringerer Latenz haben kann einfach weil man algorithmisch effizienter arbeitet.

[Novum]

Da wäre es aber noch besser einen Context-Switch zu machen und es so schnell wie möglich synchron laufen zu lassen :tongue:

Das man was an einer beliebigen Zeit starten kann ist eigentlich orthogonal zu async, aber eben ein nötiger Nebeneffekt.

[del_4901]

Da wäre es aber noch besser einen Context-Switch zu machen und es so schnell wie möglich synchron laufen zu lassen :tongue:
Grafik Arbeit laesst sich nicht so einfach mal auslagern/preempten oder context switchen. Das waehre so als ob man die Titanic ma schnell beiseite schiebt nur um ein Schnellboot vorbei zu lassen.

[Timbaloo]

Ich verstehe es immer noch nicht, welche Latenz meinst du jetzt? Eingabe zu Ausgabe eines Frames?
Latenz ist ein Wort das ich bisher nicht verwendet habe?

Was hat das mit alle 50ms Physik berechnen und Async zu tun?
Wahrscheinlich nichts, weswegen ich nachgefragt habe ob mein Verständnis bez. synch und asynch diesbezüglich falsch ist. Ist es wohl.

Keine Sorge, ich habe was gelernt.

[Novum]

Hab dich verwechselt. Meine Antwort bleibt gleich. Wie bei jeder Parallelprogrammierung muss der Programmierer entsprechende Abhängigkeiten manuell synchronisieren, sonst kommt natürlich Käse raus.

[Timbaloo]

Ja, ich habe verstanden was du meinst. Aber du hast glaube ich nicht verstanden was ich meine (was für dieses Thema aber dann wohl auch irrelevant ist). Sorry für die Verwirrung.

[Troyan]

Der Entwickler muss dafür sorgen, dass z.B. die Physik-Berechnungen vor dem Render fertig sind. Ansonsten renderst du ein Frame, dass mit falschen Daten erstellt wird.
Siehe auch hier: https://msdn.microsoft.com/de-de/library/windows/desktop/dn899217%28v=vs.85%29.aspx

[Malabolge]

Ach Leute, wie wäre es, wenn ihr euch erstmal in das Thema "Multi-Engine" einlest. Es gibt kein "Asynchronous Shaders" in DX12. Es gibt "Asynchronous Compute" und das wird von jeder kompartiblen GPU unterstützt.

2 x 3 macht 4 - widdewiddewitt und 3 macht 9e !
Ich mach' mir die Welt - widdewidde wie sie mir gefällt ..




Es liegt einzig und allein in den Händen der Entwickler, wie sie "Asynchronous Compute" verwenden. Und sollte die Leistung mit der Implementierung auf bestimmter Hardware langsamer sein, dann muss der Entwickler dies eben deaktivieren. Macht ja kein Sinn etwas anzulassen, dass auf anderem Weg gelöst werden kann.

So wie "GameHairworks" bei W3 und der "zurückhaltenden" Tesselation ?:biggrin:

Ich hab' ein Haus, ein Äffchen und ein Pferd,
und Jeder, der uns mag, kriegt unser 1x1 gelehrt.

[bop]

ihr möchtet jetzt aber nicht dx12 performance-vorteil von 20 bis 40 % mit tessalation etc. gleichsetzen?!? wenn sich das hier bewahrheitet, werden viele geforce-user enttäuscht sein. nvidia wirds freuen, dann kaufen die jünger schneller ne neue karte. wäre doch ein unding, wenn die performance der eigenen karten mit der zeit steigen würde und wie bei amd eine 3 jahre alte 290 in 2 jahren immer noch genug leistung bringen würde unter dx12. ist natürlich etwas schade, dass es noch nicht allzu viele benchmarks unter dx12 gibt. daher erstmal abwarten...

Es gibt keinen Performancevorteil von AMD gegenüber NV in DX12. Sie holen einfach nur ihren Rückstand auf. Was viele hier immer vergessen ist, dass AMD auch unter DX12 im besagten Benchmark sich gerade so auf die NV-Niveau befindet. Der Leistungssprung von 40-60% ist da irreführend, da die DX11-Performance von AMD dort unterirdisch ist. NV braucht dieses Feature nicht, sie können ihren Chip auch ohne Auslasten. AMD nicht, da hat es nach 3-4 Jahre GCN erst die passende Api gebraucht.

[fondness]

Es gibt keinen Performancevorteil von AMD gegenüber NV in DX12. Sie holen einfach nur ihren Rückstand auf. Was viele hier immer vergessen ist, dass AMD auch unter DX12 im besagten Benchmark sich gerade so auf die NV-Niveau befindet. Der Leistungssprung von 40-60% ist da irreführend, da die DX11-Performance von AMD dort unterirdisch ist. NV braucht dieses Feature nicht, sie können ihren Chip auch ohne Auslasten. AMD nicht, da hat es nach 3-4 Jahre GCN erst die passende Api gebraucht.

Naja, im Schnitt über alle Benchs von Ashes of Singularity liegt AMD schon sehr gut. Eine 390 kann es zB locker mit einer GTX980 aufnehmen, bei den min-fps schlägt eine 290X je nach Szene schon mal eine GTX980 Ti. Und das wo Nvidia nicht weniger als drei Treiber heraus geboxt hat und gerade den integrierten Bench mit Sicherheit sehr gut optimiert hat. Also so ganz weg wischen kann man das sicher nicht.

Faktum ist, dass es mit DX12/Vulkan endlich zwei APIs gibt, welche alle Fähigkeiten von GCN nutzen können, in bisherigen DX11-Anwendungen lagen die ACE-Einheiten eben brach. Und Stichwort Rückstand aufholen, eine 390 bsw. liegt schon unter DX11 im Schnitt eher vor als hinter der GTX970 zum selben Preis.

[bop]

Je nach Szene und min. FPS ist Cherrypicking. Das findet sich bei jedem Chips, genau wie man bei jedem Chip Funktionen und Konstellationen findet, bei denen dieser schlechter performt.

Siehe dazu auch hier:

https://www.reddit.com/r/nvidia/comments/3j5e9b/analysis_async_compute_is_it_true_nvidia_cant_do/

Es kommt offenbar darauf in wie man dieses Feature nutzt. Und weiterhin wird klar, dass AMD offenbar genau diese ACEs nutzen MUSS, um überhaupt ihre theretische Leistung auf die Strasse zu bringen (wäre ja mal interessant zu wissen, was der Stromverbrauch dann dazu sagt ;), sinken wird er ja wohl eher nicht). Umgekehrt gibt es diese Features, die bei einem Hersteller viel Leistung kosten auch, siehe zB Tesselation und Hairworks. Auch da ist es aber so, dass der exzessive Einsatz eher sinnfrei ist (viele GTX980 USer schalten es ab). Und wenn man sich mal anschaut wie unterirdisch die DX11 Performance von AMD bei Ashes ist, fragt man sich, ob da nicht einfach mist gebaut wurde oder ob nicht vielleicht einfach der Einsatz eines Features übertrieben wurde, weil irgendein Entwickler mal der Meinung war was ganz tolles herausgefunden zu haben. Ist ja auch nicht so, als ob der Titel jetzt DIE grafische Offenbarung ist.

[BlacKi]

Naja, im Schnitt über alle Benchs von Ashes of Singularity liegt AMD schon sehr gut. Eine 390 kann es zB locker mit einer GTX980 aufnehmen, bei den min-fps schlägt eine 290X je nach Szene schon mal eine GTX980 Ti. Und das wo Nvidia nicht weniger als drei Treiber heraus geboxt hat und gerade den integrierten Bench mit Sicherheit sehr gut optimiert hat. Also so ganz weg wischen kann man das sicher nicht.

Faktum ist, dass es mit DX12/Vulkan endlich zwei APIs gibt, welche alle Fähigkeiten von GCN nutzen können, in bisherigen DX11-Anwendungen lagen die ACE-Einheiten eben brach. Und Stichwort Rückstand aufholen, eine 390 bsw. liegt schon unter DX11 im Schnitt eher vor als hinter der GTX970 zum selben Preis.
welche tests ließt du so? hier liegen die nvidia karten immernoch ein stück vorne. http://www.pcgameshardware.de/Ashes-of-the-Singularity-Spiel-55338/Specials/Benchmark-DirectX-12-DirectX-11-1167997/

Und wenn man sich mal anschaut wie unterirdisch die DX11 Performance von AMD bei Ashes ist, fragt man sich, ob da nicht einfach mist gebaut wurde oder ob nicht vielleicht einfach der Einsatz eines Features übertrieben wurde, weil irgendein Entwickler mal der Meinung war was ganz tolles herausgefunden zu haben. Ist ja auch nicht so, als ob der Titel jetzt DIE grafische Offenbarung ist.

das ist normal. wenn sie ihre dx11 treiber optimieren würden, dann verlieren sie nicht nur manpower für dx12 sondern der fortschritt wäre dann nur noch 10-15% statt 20-30%.

das war schon bei battlefield 4 der fall. mantle lief ab einem gewissen zeit punkt gut, die dx11 performance hat man dafür wegschmeißen können.

[Troyan]

Umgekehrt gibt es diese Features, die bei einem Hersteller viel Leistung kosten auch, siehe zB Tesselation und Hairworks. Auch da ist es aber so, dass der exzessive Einsatz eher sinnfrei ist (viele GTX980 USer schalten es ab). Und wenn man sich mal anschaut wie unterirdisch die DX11 Performance von AMD bei Ashes ist, fragt man sich, ob da nicht einfach mist gebaut wurde oder ob nicht vielleicht einfach der Einsatz eines Features übertrieben wurde, weil irgendein Entwickler mal der Meinung war was ganz tolles herausgefunden zu haben. Ist ja auch nicht so, als ob der Titel jetzt DIE grafische Offenbarung ist.

Tessellation und Async Compute haben doch gar nichts miteinander zu tun.

Tessellation ist eine Funktion innerhalb der Grafikpipeline, Async Compute ist eine Funktion der API zum Ausführen von individuellen Threads auf der GPU.

Das eine Feature wird von der Hardware (Grafik = 1 GPU = seriell) kontrolliert, dass andere ist eine Low-Level API, die vom Programmierer vernünftig implementiert werden muss (Async Compute = x Engines).

Von Microsoft:


The support for multiple parallel command queues in Direct3D 12 gives you more flexibility and control over the prioritization of asynchronous work on the GPU. This design also means that apps need to explicitly manage the synchronization of work, especially when the command lists in one queue depend on resources that are being operated on by another command queue. Some examples of this include waiting for an operation on a compute queue to complete so that the result can be used for a rendering operation on the 3D queue, and waiting for a 3D operation to complete so that an operation on the compute queue can access a resource for writing. To enable the synchronization of work between queues, Direct3D 12 uses the concept of fences, which are represented in the API by the ID3D12Fence interface.
https://msdn.microsoft.com/en-us/library/windows/desktop/dn899124%28v=vs.85%29.aspx

Es liegt einzig und allein in der Verantwortung des Entwicklers.

[Tamagothi]

Tessellation und Async Compute haben doch gar nichts miteinander zu tun.

Tessellation ist eine Funktion innerhalb der Grafikpipeline, Async Compute ist eine Funktion der API zum Ausführen von individuellen Threads auf der GPU.

Das eine Feature wird von der Hardware (Grafik = 1 GPU = seriell) kontrolliert, dass andere ist eine Low-Level API, die vom Programmierer vernünftig implementiert werden muss (Async Compute = x Engines).

Async Compute muss Hardware seitig vorhanden sein. Ist also nicht nur reine API/sofware sache.


welche tests ließt du so? hier liegen die nvidia karten immernoch ein stück vorne. http://www.pcgameshardware.de/Ashes-of-the-Singularity-Spiel-55338/Specials/Benchmark-DirectX-12-DirectX-11-1167997/

Der Test ist ungültig da Manuelle Einstellungen.
Die manuell von uns gesetzten Einstellungen

[Troyan]

Jede DX12 Hardware unterstützt Async Compute. Es gibt kein Flag, um das Vorhandensein überprüfen zu können. Es ist eine Basisfunktionalität.

Wie weit die Hardware verschiedene Threads zulässt, liegt am Treiber bzw. der unterliegenden Hardware.

Die Implementierung liegt jedoch einzig im Bereich des Programmierers, da es sich hier um eine Low-Level Funktion handelt.

[deekey777]

Ach komm Tesslation mit einem Boost vergleichen ist der letzte Scheiss. Das selbe wurde bereits mit Mantle und Physx/Crapworks gemacht. Das sind einfach keine Vergleiche.

Wir haben zwei Hersteller: A und N. A kann Funktion 1 viel besser als N. N kann Funktion 2 viel besser als A. A wird die Funktion 1 immer in den Vordergrund rücken und Entwickler dazu animieren, diese immer einzusetzen, auch für N. N wird das gleiche mit Funktion 2 machen.

[fondness]

welche tests ließt du so? hier liegen die nvidia karten immernoch ein stück vorne. http://www.pcgameshardware.de/Ashes-of-the-Singularity-Spiel-55338/Specials/Benchmark-DirectX-12-DirectX-11-1167997/


Die Ergebnisse sehen allerdings nirgends so gut für NV aus wie bei PCGH.

zB.
http://arstechnica.com/gaming/2015/08/directx-12-tested-an-early-win-for-amd-and-disappointment-for-nvidia/
http://www.pcper.com/reviews/Graphics-Cards/DX12-GPU-and-CPU-Performance-Tested-Ashes-Singularity-Benchmark
http://www.computerbase.de/2015-08/directx-12-benchmarks-ashes-of-the-singularity-unterschiede-amd-nvidia/

[Kartenlehrling]

Ich frage mich gerade ob die 4Ace der nano reichen, hat die voll ausgebaute furyX nicht 8 ace?
Und wenn das abspecken der 4Ace so viel Strom einspart, wieso haben sie es nicht gleich bei der Fury auch gemacht?

[Schnoesel]

Die Frage ist: Kann ein Entwickler die "Lösung" Nvidias bezüglich der AS auch performant nutzen oder ist das gar nicht möglich, sprich negatives scaling.

1. Option: Nvidias Lösung kann performant genutzt werden --> Ball liegt beim Entwickler
2. Nvidias Lösung kann grundsätzlich nicht performant genutzt werden (negatives scaling) --> Ball liegt bei Nvidia, bzw sie werben mit etwas was in der Praxis nicht genutzt werden kann oder sollte.

[fondness]

Ich frage mich gerade ob die 4Ace der nano reichen, hat die voll ausgebaute furyX nicht 8 ace?
Und wenn das abspecken der 4Ace so viel Strom einspart, wieso haben sie es nicht gleich bei der Fury auch gemacht?

Die Nano und die X haben die gleichen Anzahl an ACEs, das ist nur eine Frage der zählweise.

sie werben mit etwas was in der Praxis nicht genutzt werden kann oder sollte.

Naja, sie müssen es zumindest am Papier supporten, sonst gibt es kein DX12 Siegel.

[Malabolge]

Naja, sie müssen es zumindest am Papier supporten, sonst gibt es kein DX12 Siegel.

Naja , ich bin mir sicher das Nvidia das schon "richtig Kommunizieren" wird !;):rolleyes:


Die "Laubsägen"-Presentation
DX11.2
3,5 GB
ACEs (in Unknown State)
Alles eine Frage der "Kommunikation":rolleyes:

[deekey777]

Als der gute NV40 kam (für die kleinen hier: Das war 2004), war es der erste Grafikchip mit SM 3. Er beherrschte statisches und dynamisches Branching, wobei dynamisches Branching&PS sich nicht so gut vertrugen. Und trotzdem ist die Welt nicht untergegangen.

Jetzt mache ich auf obercool:
Da die aktuellen Konsolenchips auf GCN basieren (außer :cop:), sind sie der gemeinsame Nenner für die PC-Ports. Wird bereits dort AS/AC einegsetzt, so werden diese auch in PC-Ports eingesetzt. Nachteil für Nvidia.

Und jetzt der Einwand:
"Hast du ein Rad ab? Die in den Konsolen eingesetzten Custom-SoCs haben mit der PC-Welt nichts gemeinsam. Man kann das nicht so pauschalisieren."

[Birdman]

ihr möchtet jetzt aber nicht dx12 performance-vorteil von 20 bis 40 % mit tessalation etc. gleichsetzen?!?
20-40%? Woher hast Du den Quark?
Bis vor 2 Wochen war hier drin jeder Experte davon überzeugt dass DX12 quasi überhaupt keinen Performancevorteil im GPU Limit bringen wird!

Nun hat Oxide wohl als eine der ersten etwas ernsthafter mit DX12 Features umgespielt und bemerkt dass AsyncCompute bei AMD GPUs zu einer deutlich besseren Auslastung der Shadereinheiten führt und damit in entsprechenden Situationen bis zu 70% mehr Speed bringt.

Wie viel davon dann schlussendlich in einem Spiel (am GPU Limit) hängenbleibt, kann aktuell wohl noch keiner sagen. Denn zum einen gibts in einem echten Spiel noch viel andere zu berechnen wo AsyncCompute nix bringt und zum andern geht eine erhöhte Auslastung zumeist auch mit einem erhöhten Stromverbauch einher, was wiederum zu einer Drosselung des Chips und damit niedrigeren Taktfrequenzen führen kann.

[d2kx]

Einige User in diesem Thread verwechseln einen effizienten DX11-Treiber mit einem effizienten App-Profil.

[Kartenlehrling]

Laut AMD-Folie wurde schon bei Thief unter Mantle AsyncCompute eingesetzt, bei so einen Schlauchlevel Spiel mit 15 NPC hat es wohl wenig gebracht um es genau zusagen garnichts.

[Novum]

Was haben NPCs und Schlauchlevel mit Async Compute zu tun? Wenn ich das Postprocessing Async mache, dann hilft das selbstverständlich auch bei solchen Spielen und es gibt zig andere Sachen die mir einfallen würden.

[Kartenlehrling]

So wie was, Blur-effekt schalte ich immer aus? :)

Using asynchronous shaders for the blureffect improves performance by 45%

[Novum]

:facepalm:

Genau, Postprocessing besteht nur aus Blur-Effekten und die schält jeder aus. Dann haben wir das ja geklärt.

[dargo]

:facepalm:

Genau, Postprocessing besteht nur aus Blur-Effekten und die schält jeder aus. Dann haben wir das ja geklärt.
Köstlich. :D

[Hübie]

Ist mir irgendetwas entgangen? Wo seh ich denn jetzt eine deutliche Schwäche. Ich seh mal 1-3 fps weniger als eine vergleichbare Radeon, aber nichts was mich jetzt beunruhigen und dazu veranlassen würde, Seitenlange Quälereien von Stumpfsinn zu schreiben.
Was manche hier von sich geben klingt fast nach Apokalypse.

aufkrawall hats gut formuliert: AMD macht Boden gut und steht mit seinen Karten nun - zumindest in diesem Benchmark - auf Augenhöhe da. Wenn das durch die Bank aller D3D12-Spiele so bleibt hat man eine ausgewogene Marktsituation für Emfpehlungen.

btw: Arstechnica ist dabei der letzte Mist. Bei Ryan von PCPer hätte ich gern noch 980Ti vs. Fury gesehen, was an absoluten Zahlen heraus käme. CB hats richtig gemacht. Vor allem übersichtlich. Leider steht nirgends etwas vom Speicherverbrauch. Das würde mich interessieren.

[BlacKi]

toller satz:

So it is simple, currently no graphics card with full 100% DirectX 12 support, that means that some games are to favor AMD and others Nvidia.
http://www.guru3d.com/news-story/amd-there-is-no-such-thing-as-full-support-for-dx12-today.html

und

“We do not believe it is a good indicator of overall DirectX 12 performance.”
http://www.extremetech.com/gaming/212314-directx-12-arrives-at-last-with-ashes-of-the-singularity-amd-and-nvidia-go-head-to-head

wenn msaa gefixt ist sehen benches aus wie bei pcgh, ich denke das dass der grund ist warum die pcgh tests so anders ausfallen als der rest.

wenn der msaa bug gefixt ist, dann sieht die sache ausgeglichener aus. hat es amd und seine anhänger wirklich nötig, mit einem vorübergehenden bug der konkurenz, in einem alpha status game zu profilieren?

[fondness]

“We do not believe it is a good indicator of overall DirectX 12 performance.”
http://www.extremetech.com/gaming/212314-directx-12-arrives-at-last-with-ashes-of-the-singularity-amd-and-nvidia-go-head-to-head


Das verwundert natürlich extrem, das Nvidia so so sieht. :rolleyes:

wenn msaa gefixt ist sehen benches aus wie bei pcgh, ich denke das dass der grund ist warum die pcgh tests so anders ausfallen als der rest.

wenn der msaa bug gefixt ist, dann sieht die sache ausgeglichener aus. hat es amd und seine anhänger wirklich nötig, mit einem vorübergehenden bug der konkurenz, in einem alpha status game zu profilieren?

Wäre nett, wenn du dich wenigstens informierst, bevor die anderen solche Vorwürfe machst. Auch bei CB wurde defintiv auf das MSAA-Problem - das im übrigen am NV-Treiber liegen soll - Rücksicht genommen und ich traue auch den anderen Reviewern zu, das sie das geschafft haben.

Auch CB testet keine Presets. Oxide und Nvidia haben genügend auf das MSAA-Problem hingewiesen.

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10744350&postcount=9

[BlacKi]

Das verwundert natürlich extrem, das Nvidia so so sieht. :rolleyes:

ich nehme an, das jeder dieser meinung ist oder nimmst du jetzt ernsthaft AotS als benchmark für alle kommenden dx12 spiele her?


Der Test ist ungültig da Manuelle Einstellungen.
da musste ich doch annehmen das cb oxide presets verwendet werden wenn der pcgh test ungültig ist und der cb test gelten soll?

wenn das nicht so ist, warum unterscheiden sich die tests so abartig? und wie wollt ihr unterscheiden welches testscenario gelten darf und welches nicht?

wenn ich jetzt ein resüme für mich ziehe, siehts so aus: Alle tests sind für die Tonne, denn die test verwirren mehr als das sie aufklären.

[Blediator16]

Wir haben zwei Hersteller: A und N. A kann Funktion 1 viel besser als N. N kann Funktion 2 viel besser als A. A wird die Funktion 1 immer in den Vordergrund rücken und Entwickler dazu animieren, diese immer einzusetzen, auch für N. N wird das gleiche mit Funktion 2 machen.

Zu blöd nur, dass alle, die keine 700€ GPU haben, wie ich eben, überlst dumm in die Röhre schauen und die, die eine AMD GPU mit ACEs haben, eben nicht blöd in die Röhre schauen, weil es die Leistung am Ende des Tages nicht ins negative sondern ins positive verändert. Hätte ich jetzt eine Hawaii gekauft anstatt einer Kepler Karte, dann bin ich mir sicher hätte ich meine Karte länger behalten können. Meine Kepler Karte ist bereits jetzt oft langsamer als das ehemalige Konkurenzprodukt aus dem Hause AMD. Ich habe noch nie einen so schlechten Kauf gemacht, wie mit dieser Kepler Karte. Nichtmal meine NV GX2 Karte von darmals war so scheisse und kurzlebig.

[Scarred]

Die Ergebnisse sehen allerdings nirgends so gut für NV aus wie bei PCGH.
Eine mögliche Begründung dafür findest du hier:
http://hardforum.com/showpost.php?p=1041821993&postcount=84
"I figured out what pcgameshardware.de did. They disregarded Oxide's reviewer's guide.

1. They disabled one Post Processing effect (Glare). In other words they disabled a lot of Async shading.
2. They set the TAA to 12x (who uses 12x TAA??? that would blur the image like crazy and puts un-necessary strain on your GPU).
3. They increased terrain shading samples from 8 to 16 Million (putting extra strain on the rasterizers (small triangle issue), no extra image quality)
4. They only posted the result for the heavy batches (averaged them but all cards end up with a low FPS).

When Post Processing effects are utilized (such as Glare and Lighting) you tap into the Compute Performance of the GPUs. In doing so, AMDs GCN has an advantage when using Asynchronous shading (DirectX12).

[fondness]

Okay, wenn sie das Post Processing deaktiviert haben, und damit genau den Effekt, der AsyncCompute nutzt, dann verwundern die Ergebnisse wenig. Auch die anderen Einstellungen finde ich relativ seltsam, keine Ahnung was sich PCGH dabei gedacht hat.

[Schnoesel]

@ Hübie

ich denke nicht dass es hier um die Performance geht, was den Leuten sauer aufstößt, sondern dass eines der Kernfeatures von DX12 offenbar (nach jetzigem Stand) nicht genutzt werden kann, da negative Auswirkungen.

Und das obwohl Nvidia vollmundig mit vollem DX 12 Support wirbt und dies von den grünen Männchen auch überall weitergetragen wurde. Aber ist wieder ein Kommunikationsproblem wie mir scheint :eek:

[Loeschzwerg]

Und jetzt die Frage an die Experten: Was für Möglichkeiten hat NV hier mit dem Treiber gegenzusteuern?

[ilibilly]

Ich kann die ganze Aufregung nicht wirklich nachvollziehen,Falls fury x zB in dx 12 deutlich (20-30)% an meiner ti vorbeizieht dann wird halt Geswitcht zu amd,das ist halt das tolle wenn man kein Fanboy ist,wechseln ist da easier :)
Die grakapreise sinds ja recht stabil auch der gebrauchtmarkt.

[deekey777]

Und jetzt die Frage an die Experten: Was für Möglichkeiten hat NV hier mit dem Treiber gegenzusteuern?
Warum muss das über den Treiber gelöst werden? Man bleibt in solchen Fällen bei DX11 oder die Entwickler werden auf AC auf GeForces verzichten, wenn es keine Vorteile bringt.

[Loeschzwerg]

Muss nicht, aber wäre denn generell was möglich?

[Novum]

Warum muss das über den Treiber gelöst werden? Man bleibt in solchen Fällen bei DX11 oder die Entwickler werden auf AC auf GeForces verzichten, wenn es keine Vorteile bringt.
Warum sollte man bei DX11 bleiben? Ist ja nicht so, als hätte DX12 nur async compute als Vorteil.

[Troyan]

Warum muss das über den Treiber gelöst werden? Man bleibt in solchen Fällen bei DX11 oder die Entwickler werden auf AC auf GeForces verzichten, wenn es keine Vorteile bringt.

Hä? Man nimmt in einem solchen Fall eine Implementierung, die der anderen Hardware besser liegt.

Des Weiteren ist "Asynchronous Shaders" nicht "Asynchronous Compute" sondern nur eine bestimmte Technik. Die Fähigkeit mehrere Computetask auf der GPU laufen zu lassen, ist davon überhaupt nicht betroffen.

[Novum]

Des Weiteren ist "Asynchronous Shaders" nicht "Asynchronous Compute" sondern nur eine bestimmte Technik
Doch, das ist das selbe.

Eine mögliche Begründung dafür findest du hier:
http://hardforum.com/showpost.php?p=1041821993&postcount=84
"I figured out what pcgameshardware.de did. They disregarded Oxide's reviewer's guide.

1. They disabled one Post Processing effect (Glare). In other words they disabled a lot of Async shading.
2. They set the TAA to 12x (who uses 12x TAA??? that would blur the image like crazy and puts un-necessary strain on your GPU).
3. They increased terrain shading samples from 8 to 16 Million (putting extra strain on the rasterizers (small triangle issue), no extra image quality)
4. They only posted the result for the heavy batches (averaged them but all cards end up with a low FPS).

When Post Processing effects are utilized (such as Glare and Lighting) you tap into the Compute Performance of the GPUs. In doing so, AMDs GCN has an advantage when using Asynchronous shading (DirectX12).
Wahrscheinlich hat er recht mit den Einstellungen aber die Erläuterungen was TAA angeht in dem Post sind echt gruselig.

[StefanV]

Und jetzt die Frage an die Experten: Was für Möglichkeiten hat NV hier mit dem Treiber gegenzusteuern?
Gar keine, da 'Bauartbedingte Einschränkung'...

Und somit wäre wieder eine weitere Kerbe auf nVidias 'Blacklist' zu setzen, bei der sie wohl doch nicht sooo ganz ehrlich waren...

Oh und wie schauts eigentlich mit DX12 und Fermi aus?!
Ist da schon was gekommen? Kommt da noch was?
Oder war auch das nur heiße Luft?!

[Novum]

WDDM-2.0-Treiber für Fermi sind schon immer für Dezember angekündigt.

[aufkrawall]

Ursprünglich war von Windows 10 Release die Rede.
Wenn es zum Fable Release keinen Treiber gibt, können die Fermi-User schon stinkig sein.
Klar gibts bei AMD eh nichts für Pre-GCN, aber man hats halt für Fermi versprochen.

[Novum]

Wann war das? Juli war die Aussage
"With the Game Ready driver, Maxwell and Kepler GPUs offer complete support for DirectX 12. Fermi-based GPUs will gain support for DirectX 12 titles later this year, around the arrival of the first wave of DirectX 12 content."

Ich wüsste auch nicht, was es da zu motzen gibt, sie müssten nämlich eigentlich rein gar nichts machen. Die GPUs sind bald 5 Jahre alt.

[aufkrawall]

Nochmal: Sie hatten es für Fermi zum Windows 10 Release angekündigt (Monate vorher), was sie nicht eingehalten haben.
Es gab Statements in Foren von ManuelG (NV "Kundendienst" in Foren), die das eindeutig ausgesagt haben.
Man hat davon bis zum Win X Release nichts zurückgenommen und dann einfach verlautbart, dass der Treiber irgendwann später kommt.

[sulak]

Gar keine, da 'Bauartbedingte Einschränkung'...

Und somit wäre wieder eine weitere Kerbe auf nVidias 'Blacklist' zu setzen, bei der sie wohl doch nicht sooo ganz ehrlich waren...



Bleib doch mal auf dem Teppich, gehst ja ab wie eine Rakete nur weil EIN Entwickler viel Wind um sein Spiel macht, was ER verkaufen möchte und die Publicity gebrauchen kann. Wobei das noch nach hinten losgehen wird...

Wenn andere Entwickler zum gleichen Ergebnis kommen und nV per Treiber nichts daran ändern kann. DANN erst ist es eine Tatsache, bis dahin, kann auch der Entwickler einfach mist gebaut haben oder verfolgt vielleicht eine falsche Herangehensweise an die Materie.
Ich vergleiche es mal neckigerweise mit der PS4 und "die kann ja kein AF"... Am Ende waren es einfach Fehler/haben wir nicht gewusst = heiße Luft.

Games will tell, not Geeks/Boys.

[-/\-CruNcher-/\-]

Hmm so lange das ganze vorerst nur das PP in der relevanz betrifft kann man entspannt sein ;)
AMDs eigene tests zeigten auch nur eine relevanz von 10% beim improven des deffered Rendering, was schon wichtiger als das PP ist ;)

Die meisten Engines werden die volle effizienz ehh nie erreichen so lange sie nicht volkommen von unten neu geschrieben werden das werden die wenigsten aus kostengründen überhaupt nur in betracht ziehen ;)

Das ganze geht momentan vollkommen an der Realität vorbei zudem ist der impact von PP so minimal im overall nee das kann man nicht für ernst nehmen zudem die tendenz auch eher dahin geht das die meisten zu viel PP eh abschalten da sie es einfach nicht ertragen können ;)

[aufkrawall]

Was heißt hier "nur"?
PP macht mittlerweile häufig einen dicken Batzen an der Gesamtrenderzeit aus.

Wir werdens bei TR ja sehen...

[fondness]

Bleib doch mal auf dem Teppich, gehst ja ab wie eine Rakete nur weil EIN Entwickler viel Wind um sein Spiel macht, was ER verkaufen möchte und die Publicity gebrauchen kann. Wobei das noch nach hinten losgehen wird...

Wenn andere Entwickler zum gleichen Ergebnis kommen und nV per Treiber nichts daran ändern kann. DANN erst ist es eine Tatsache, bis dahin, kann auch der Entwickler einfach mist gebaut haben oder verfolgt vielleicht eine falsche Herangehensweise an die Materie.
Ich vergleiche es mal neckigerweise mit der PS4 und "die kann ja kein AF"... Am Ende waren es einfach Fehler/haben wir nicht gewusst = heiße Luft.

Games will tell, not Geeks/Boys.

Naja, zumindest das NV nicht von AsyncCompute profitiert scheint bestätigt, das zeigt auch das DX-SDK und NV hat Oxide wohl nicht ohne Grund geraten es zu deaktivieren. Auch AMD hat sicher gute Gründe für solche Äußerungen die ja auch Nvidia nicht leugnet.

[Gipsel]

Ich vergleiche es mal neckigerweise mit der PS4 und "die kann ja kein AF"... Am Ende waren es einfach Fehler/haben wir nicht gewusst = heiße Luft.Schlechtes Beispiel, das war von Anfang an nur heiße Luft, da absolut klar war, daß die PS4 (mit ihren GCN-TMUs) natürlich AF beherrscht. Da liegt der Fall hier minimal anders.

[-/\-CruNcher-/\-]

Die Frage muss sich ja jeder selber stellen "Ist es sinvoll investierte Renderzeit" bei VR wird man dort auf jedenfall als erstes ansetzen den Ballast los zu werden und sinvoller die resourcen die dadurch frei werden zu verteilen.

[fondness]

Neben den viel zitierten Satz von wegen DX12-Features, hat Robert Hallock auch noch eine vielsagende Bemerkung hinterhergeworfen, die kaum beachtet wurde:

Yes, we’re extremely pleased that people are finally beginning to see the game of chess we’ve been playing with the interrelationship of GCN, Mantle, DX12, Vulkan and LiquidVR.”

http://www.dsogaming.com/news/amd-theres-no-such-thing-as-full-support-for-dx12-today-lists-missing-dx12-features-for-furyx/

Es hat eben doch einen Vorteil, wenn sämtliche Next-Gen-APIs eine mehr oder weniger deutliche Kopie der hauseigenen Mantle-API sind und man praktischerweise auch noch die Konsolen hat.

[-/\-CruNcher-/\-]

Naja bedingt durch den Markt kann ich deine euphorie hier nicht teilen es ist toll für AMD nicht mehr hinten an zu stehen keine Frage nun seite an Seite von Nvidia zu stehen wieder auf gleicher Augenhöhe nach dem change auf GCN aber die bisherigen umgesetzten praktischen Vorteile überzeugen einfach nicht, leider tun das die Tesselation vorteile seitens Nvidias bei GameWorks auch noch nicht Richtig aber dort sieht man zumindestens die interessanteren Einsatzmöglichkeiten für die Zukunft :)
Und wenn Nvidia genau so fix ist wie bei Kepler dann wird sich dieses Problem mit Pascal dann wohl auch in Luft auflösen ;)
Deswegen sind auch eher die Vergleiche zwischen Kepler und Maxwell in diesem Benchmark von Relevanz weil dort ja das improvement stattgefunden hat (aufschliesen zu AMD) ;)

Übrigens

1. They disabled one Post Processing effect (Glare). In other words they disabled a lot of Async shading.

Hier sollte man sich ehrlich mal die Frage stellen wenn das so ist ob man das wirklich ernst meint ;)

Glare PP kenn ich zudem nichtmal das heist immernoch Bloom oder nicht ? ;)

Interessanter wird es da schon zwischen HBAO+ (Maxwell) DX12 Performance und HDAO (GCN) DX12 Performance ;)

Oder die Improvements die man schon auf den Konsolen mit AMDs ACEs beim Voxel GI erreichen konnte :)

Ich bin da mit sebbbi

Async compute is a little bit like hyperthreading. It helps some workloads a lot, while it (slightly) hurts some workloads. Because every GPU has a bit different bottlenecks, it is very hard to write async compute code that benefits them all. Console engines will be off course optimized first for GCN hardware. This might result in gains on PC side as well, but it is too early to say really, since even AMD PC GPUs have different bottlenecks (config is not identical to consoles). Nobody has shipped a DX12 PC console port yet and the DX12 drivers are still quite immature.


Zudem wird Nvidia alles einsetzen an ihrer Manpower das dies nicht passiert ;)

Nvidia musste jetzt schon ganz schön oft eingreifen das die Konsolen optimierungen ausgeglichen werden konnten aber bis jetzt schlagen sie sich da noch recht gut das hinzubekommen ;)

[StefanV]

Klar gibts bei AMD eh nichts für Pre-GCN, aber man hats halt für Fermi versprochen.
Eben und genau DAS ist das Problem.
Hätte man die Klappe gehalten und nix zu Fermi gesagt, wär alles im Lot.

Aber hier hat man den Mund voll genommen und da erwartet man natürlich auch - vergeblich??

[-/\-CruNcher-/\-]

Async Compute ist ja keine vorausetzung für den rest es ist ja nur ein zusätzlicher part mit dem man load effizienter für manche workloads handeln kann es ist so gesehen Multithreading für die GPU.

Das hier ist wohl sehr offensichtlich (Overall Latency Kepler vs Maxwell vs GCN)

Linear Kernel Increase

http://s2.postimg.org/e7mes6ut5/kepler_vs_maxwell.png
http://s3.postimg.org/rwqwzfx37/fury_x_vs_390x_vs_tahiti.png

Allerdings brauch man da nicht diesen Benchmark da kann man Optix/Octane anschmeisen und die resultate gleich in Echtzeit sehen für Nvidia ;)

[Novum]

Eben und genau DAS ist das Problem.
Hätte man die Klappe gehalten und nix zu Fermi gesagt, wär alles im Lot.

Aber hier hat man den Mund voll genommen und da erwartet man natürlich auch - vergeblich??
Hör auf rumzutrollen. Es gibt keine Anzeichen warum die Treiber nicht kommen sollten.

[Kriton]

Einige User in diesem Thread verwechseln einen effizienten DX11-Treiber mit einem effizienten App-Profil.

:up:

wenn msaa gefixt ist sehen benches aus wie bei pcgh, ich denke das dass der grund ist warum die pcgh tests so anders ausfallen als der rest.

wenn der msaa bug gefixt ist, dann sieht die sache ausgeglichener aus. hat es amd und seine anhänger wirklich nötig, mit einem vorübergehenden bug der konkurenz, in einem alpha status game zu profilieren?

Oxid hat IIRC doch bereits gesagt, dass es keine Performanceprobleme durch MSAA bei Nvidia gab/gibt.

ich nehme an, das jeder dieser meinung ist oder nimmst du jetzt ernsthaft AotS als benchmark für alle kommenden dx12 spiele her?

Natürlich nicht, aber er ist der 1. Spielebenchmark mit DX 12, der zudem von sich auch sagt, dass er die tatsächliche Spielperformance messen soll (weil er primär ein interner Benchmark für das Studio sein soll).

Eine mögliche Begründung dafür findest du hier:
http://hardforum.com/showpost.php?p=1041821993&postcount=84
"I figured out what pcgameshardware.de did. They disregarded Oxide's reviewer's guide.

Das fände ich irritierend.

[-/\-CruNcher-/\-]

Oxid hat IIRC doch bereits gesagt, dass es keine Performanceprobleme durch MSAA bei Nvidia gab/gibt.

War da nicht ein Bug im Treiber ;) ?

[del_4901]

@Cruncher sabbel nicht soviel Mist ansonsten muss ich dir das bischen Respekt was du dir bei mir erarbeitet hast wieder aberkennen.

[Nakai]

Gar keine, da 'Bauartbedingte Einschränkung'...

Und somit wäre wieder eine weitere Kerbe auf nVidias 'Blacklist' zu setzen, bei der sie wohl doch nicht sooo ganz ehrlich waren...

Oh und wie schauts eigentlich mit DX12 und Fermi aus?!
Ist da schon was gekommen? Kommt da noch was?
Oder war auch das nur heiße Luft?!

Es ist verdammt nochmal keine Einschränkung. NV braucht es nicht. AMD BRAUCHT ES!

Und ja, eine über 3 Jahre alte Architektur wird erst mit DX12 richtig ausgelastet.


Grundsätzlich ist es schonmal interessant, dass die ganzen Konsolen auf GCN setzen. Ergo können wir AsyncCompute auch auf dem PC erwarten. Und natürlich wird es wohl einen Renderpfad für AMD und für NV geben. Also ich sehe nicht soviele Probleme. GCN könnte bei DX12, je nach Fall, einfach besser dastehen.

[Armaq]

Respekt für AMD einen so langen Weg zu gehen und am Ende war man auf Microsoft angewiesen, die sich nur durch eine eigene API a la Mantle umstimmen ließen. Ich vermute ganz arg, dass AMD offiziell früher schon anfragte und einfach abgewiesen wurde. Dann kam Mantle als Druckmittel und MS bombte DX12 raus. Wenn das ein Plan war - Respekt.

Passiert jetzt eigentlich innerhalb von DX12 noch etwas, oder sind wir "fertig"?

[fondness]

Es ist verdammt nochmal keine Einschränkung. NV braucht es nicht. AMD BRAUCHT ES!

Das ist Blödsinn. Unabhängig von der besseren Auslastung macht es einfach für viele Anwendungsfälle Sinn, etwas asynchron ohne teuren Context Switch berechnen zu können, weil man dadurch Latenzen verstecken kann. Natürlich ist es eine Einschränkung, wenn das nicht möglich ist. Gerade für VR, wo die Latenz sehr wichtig ist könnte das darüber hinaus auch noch bei der responsiveness einiges bringen.

[Hübie]

Oxide ist nicht der Weisheit letzter Schluß. nVidia kann ebenso asynchrone Tasks abarbeiten wie AMD. Nur ist der Weg halt anders. Bei AMD wirds granular gemacht. Liegt wohl an der queue depth des Threads, aber da kann AlphaTier sicher genaueres sagen.
Wie weit hast du dich eigentlich mit Maxwell auseinander gesetzt, AlphaTier? Hast du denn auch welche im Office? Bisher sah ich nur Radeon-Bilder von dir. Und nein das ist jetzt keine subtile Anspielung, sondern eine Frage (für alle anderen).
Wie ist denn der Informationsfluss seitens nVidia? Unter CUDA gibt's ja einige Samples zum Thema async Scheduling / Threading. Wobei ich gerade nicht weiß ob auch für graphics&compute.

[Lurtz]

Neben den viel zitierten Satz von wegen DX12-Features, hat Robert Hallock auch noch eine vielsagende Bemerkung hinterhergeworfen, die kaum beachtet wurde:

http://www.dsogaming.com/news/amd-theres-no-such-thing-as-full-support-for-dx12-today-lists-missing-dx12-features-for-furyx/

Es hat eben doch einen Vorteil, wenn sämtliche Next-Gen-APIs eine mehr oder weniger deutliche Kopie der hauseigenen Mantle-API sind und man praktischerweise auch noch die Konsolen hat.
Und wann werden diese Vorteile mal am Markt ankommen? Solche Effekte müsste man schon seit zwei Jahren sehen!

[Unicous]

Und wann werden diese Vorteile mal am Markt ankommen? Solche Effekte müsste man schon seit zwei Jahren sehen!

Nö. Bei der Xbox wurde es (Async Compute) gar nicht erst angeboten, das kam wohl erst mit einem SDK Ende letzten Jahres und Mark Cerny sagte Mitte 2013 Folgendes:

"Our belief is that by the middle of the PlayStation 4 console lifetime, asynchronous compute is a very large and important part of games technology."

http://www.gamasutra.com/view/feature/191007/inside_the_playstation_4_with_mark_.php?page=2

[Kartenlehrling]

Wiegesagt es gabt ja schon letztes Jahr einige Spiele die Asynchronous Shaders nutzen,
seltsamerweise wird BF4 nicht aufgezählt unter Mantle, aber Thief.
Das keine XBone erwähnt wird liegt wohl daran das sie langezeit mit einer DX11.x version arbeiteten.

These games include Battlefield 4, Infamous Second Son and The Tomorrow Children on the PS4 and
Thief when running under Mantle on the PC.

[deekey777]

Async Shaders: Fehlende DirectX-12-Funktion auf Nvidia-Grafikkarten "ein vollkommenes Desaster" (http://www.heise.de/newsticker/meldung/Async-Shaders-Fehlende-DirectX-12-Funktion-auf-Nvidia-Grafikkarten-ein-vollkommenes-Desaster-2801497.html)

Etwas Feuer ins Benzin:
Robert Hallock – AMDs Chef fürs weltweite technische Marketing – bestätigte während einer Telefonkonferenz gegenüber c't, dass Nvidia-GPUs der Serien Kepler, Maxwell und Maxwell v2 einen Context Switch zwischen Grafik- und Compute-Anwendungen ausführen müssen, während ein solcher bei AMD-GPUs mit GCN-Architektur nicht nötig ist.

Er muss es ja wissen, was die Konkurrenz kann.

[fondness]

Async Shaders: Fehlende DirectX-12-Funktion auf Nvidia-Grafikkarten "ein vollkommenes Desaster" (http://www.heise.de/newsticker/meldung/Async-Shaders-Fehlende-DirectX-12-Funktion-auf-Nvidia-Grafikkarten-ein-vollkommenes-Desaster-2801497.html)

Etwas Feuer ins Benzin:


Er muss es ja wissen, was die Konkurrenz kann.

Naja, nachdem Nvidia dazu - wohl aus guten Gründen - auf Tauchstation geht, gibt es eben nur die Aussagen von AMD, Oxide, etc.

[mboeller]

Async Shaders: Fehlende DirectX-12-Funktion auf Nvidia-Grafikkarten "ein vollkommenes Desaster" (http://www.heise.de/newsticker/meldung/Async-Shaders-Fehlende-DirectX-12-Funktion-auf-Nvidia-Grafikkarten-ein-vollkommenes-Desaster-2801497.html)

Etwas Feuer ins Benzin:


Er muss es ja wissen, was die Konkurrenz kann.

das andere Quote ist aber doch viel interessanter:


Nach Angaben von Oxide Games habe Nvidia einige falsche Aussagen getroffen. Die PR-Abteilung von Nvidia habe auf die Entwickler Druck ausgeübt, damit sie bestimmte Einstellungen im Ashes-of-Singularity-Benchmark deaktivieren. Oxide Games habe diese Forderungen abgelehnt, was Nvidia "ein bisschen zu persönlich genommen habe".


das "übliche" Verhalten von Nvidia? Schaut nach täuschen und tarnen aus...

[Blediator16]

Erinnert diese Sache nur mich an das 3,5gb "Märchen" ?

[aufkrawall]

Wahrscheinlich erinnert das jeden daran, der den Heise-Artikel gelesen hat, in welchem darauf hingewiesen wird...

[dargo]

Bin ich eigentlich der einzige dem langsam klar wird warum Nvidia nicht an Mantle interessiert war? :tongue: Man wollte es offenbar schön aussitzen bis Pascal. DX12 konnten sie dann nicht mehr verhindern.

[Blediator16]

Bin ich eigentlich der einzige dem langsam klar wird warum Nvidia nicht an Mantle interessiert war? :tongue: Man wollte es offenbar schön aussitzen bis Pascal. DX12 konnten sie dann nicht mehr verhindern.

Moooment. DX12 ist doch schon so uralt, vieeel älter als Mantle, da musste man das alles doch wissen? Man hat doch schon so lange daran gearbeitet.

[dargo]

Moooment. DX12 ist doch schon so uralt, vieeel älter als Mantle, da musste man das alles doch wissen? Man hat doch schon so lange daran gearbeitet.
:biggrin:

[BlacKi]

Bin ich eigentlich der einzige dem langsam klar wird warum Nvidia nicht an Mantle interessiert war? :tongue: Man wollte es offenbar schön aussitzen bis Pascal. DX12 konnten sie dann nicht mehr verhindern.
mantle ist für nvidia einfach nicht nötig. dx11 treiber sind so gut eigentlich brauchen sie nichtmal dx12 auch wenn nvidia ebenfalls etwas von dx12 profitiert.

bin mal gespannt wie sich das weiter entwickelt.

[Lurtz]

Nö. Bei der Xbox wurde es (Async Compute) gar nicht erst angeboten, das kam wohl erst mit einem SDK Ende letzten Jahres und Mark Cerny sagte Mitte 2013 Folgendes:


http://www.gamasutra.com/view/feature/191007/inside_the_playstation_4_with_mark_.php?page=2
Man hätte noch andere Vorteile als AS aus der Konsolenverwandschaft ziehen müssen. nVidia hat es mit Gameworks ganz ohne Konsolendeals geschafft ihre Hardware besser dastehen zu lassen.

Bin ich eigentlich der einzige dem langsam klar wird warum Nvidia nicht an Mantle interessiert war? :tongue: Man wollte es offenbar schön aussitzen bis Pascal. DX12 konnten sie dann nicht mehr verhindern.
Wird Pascal architektonisch überhaupt große Unterschiede zu Maxwell aufweisen?

Moooment. DX12 ist doch schon so uralt, vieeel älter als Mantle, da musste man das alles doch wissen? Man hat doch schon so lange daran gearbeitet.
:upara:

[Blediator16]

mantle ist für nvidia einfach nicht nötig. dx11 treiber sind so gut eigentlich brauchen sie nichtmal dx12 auch wenn nvidia ebenfalls etwas von dx12 profitiert.

bin mal gespannt wie sich das weiter entwickelt.

Ich verstehe es einfach nicht. Wieso sollte etwas nicht nötig sein? Sie könnten ihre alten Geräte einfachmal länger melken, um die Zeit auf 16nm zu überbrücken. Aber nein garnicht nötig. Auch sind die besseren Frametimes absolut nicht nötig hat ja sonst niemanden jemals gejuckt :freak:

[dargo]

mantle ist für nvidia einfach nicht nötig. dx11 treiber sind so gut eigentlich brauchen sie nichtmal dx12 auch wenn nvidia ebenfalls etwas von dx12 profitiert.

Witz des Tages... danke. :up:

Ich schlage vor... jeder Entwickler sollte bei Nvidia keinen DX12 Renderpfad implementieren, schließlich braucht Nvidia diesen laut einigen Fan(boys)s nicht. ;D

[fondness]

Erinnert diese Sache nur mich an das 3,5gb "Märchen" ?

Genauso wie man ewig lange alle Karten als FL 11_1 kompatibel deklariert hat, etc. Nvidia ist sich für keine Lüge zu schade, wenn man glaubt davon zu profitieren.

[Unicous]

Man hätte noch andere Vorteile als AS aus der Konsolenverwandschaft ziehen müssen. nVidia hat es mit Gameworks ganz ohne Konsolendeals geschafft ihre Hardware besser dastehen zu lassen.

GameWorks sind Effektbibliotheken für faule Entwickler mit zu viel Cash in de Täsch (bzw. einem Marketing Co-Deal in der Arschtasche). Sehe da nicht, wie man das mit einer Hardware-Architektur gleichsetzen kann, die mehrere Jahre in der Entwicklung ist und man das für die Konsolen ab einem bestimmten Zeitpunkt einfrieren muss, damit man auch mal anfangen kann die Chips zu produzieren. Mit 20/20 hindsight kann man immer sagen, sie hätten mehr Vorteile daraus ziehen müssen, aber 2011 oder womöglich früher, als die Verhandlungen anfingen hatte man eben nur das zu bieten bzw. hat dann 2012 dann noch mal GCN 1.1 nachgelegt. Zudem hat AMD sicherlich den Audio DSP im Desktop nur eingebaut, weil sie es für die Konsolen eh eingebaut haben. Dass am Ende fast niemand den Chip nutzt ist eben auch ein Problem. Und die Implementationen haben ja auch nicht wirklich überzeugt. Aber soweit ich das mitbekommen habe, wird der DSP auch bei den Konsolen noch nicht wirklich genutzt.

[Hübie]

Es steht jedem frei diese Ergebnisse hier mal nachzusehen:

http://nubleh.github.io/async/#18

Es ist offenbar nur ein Desaster wenn es nicht exakt so geht wie die Devs von Oxide sich das vorstellen.

[Schnoesel]

Was soll das sein? Sorry für meine Unwissenheit aber wer hat da was genau getestet und was genau sagt das aus?

[Lord_X]

Das Desaster ist, dass Nvidia sich nicht dazu äussert!

Starke Worte von AMD:

...I think gamers are learning an important lesson: there's no such thing as "full support" for DX12 on the market today...

... Yes, we're extremely pleased that people are finally beginning to see the game of chess we've been playing with the interrelationship of GCN, Mantle, DX12, Vulkan and LiquidVR...

https://www.reddit.com/r/pcmasterrace/comments/3j2wpj/x_post_rpcgaming_nvidia_gpus_do_not_support_dx12/cum3xow

[BlacKi]

Ich verstehe es einfach nicht. Wieso sollte etwas nicht nötig sein? Sie könnten ihre alten Geräte einfachmal länger melken, um die Zeit auf 16nm zu überbrücken. Aber nein garnicht nötig. Auch sind die besseren Frametimes absolut nicht nötig hat ja sonst niemanden jemals gejuckt :freak:
mal abgesehen von asc, was bringt denn mantle? hauptsächlich nur die optimierung von den drawcalls und reduzierung von cpu overhead. die ist bei nvidia unter dx11 einfach so gut wie mantle mit amd karten. bei nvidia karten bringt das logischer weiße nicht soviel, da der ausgangspunkt also dx11, schon ziemlich gut läuft, somit kann der effekt bei nvidia karten garnicht so viel besser ausfallen.

eigentlich profitieren amd karten nur so stark, weil sie unter dx11 so kacke laufen.

warum dx12 so spät kam? weil es für nvidia kartenbesitzer also 2/3 des marktes kein bedarf besteht irgendwas zu ändern.

[Unicous]

Es steht jedem frei diese Ergebnisse hier mal nachzusehen:

http://nubleh.github.io/async/#18

Es ist offenbar nur ein Desaster wenn es nicht exakt so geht wie die Devs von Oxide sich das vorstellen.

So wie ich das mitbekommen habe, hat ein CUDA-Entwickler ein test case auf Basis des Microsoft Beispielschnipsels gebastelt, der die Vorteile der Async Shader gar nicht ausnutzt, aber auf Nvidia normal performed.


Ich finde es im Übrigen immer wieder interessant, wie Dan Baker und Co. die Expertise abgesprochen wird und Oxide Games als Dilletanten hingestellt werden. Der Typ war über Jahre leitend an der DX Entwicklung beteiligt und hat das erste Spiel bzw. Engine mit DX11 MultiThreading entwickelt. Außerdem waren sie aktiv an Mantle DX12 und Vulkan beteiligt. Ich verstehe nicht warum man das zu diskreditieren versucht.

[StefanV]

mantle ist für nvidia einfach nicht nötig. dx11 treiber sind so gut eigentlich brauchen sie nichtmal dx12 auch wenn nvidia ebenfalls etwas von dx12 profitiert.

bin mal gespannt wie sich das weiter entwickelt.
WTF!?

Was zur Hölle redest du hier?!
WARUM soll etwas unnötig sein, was die CPU Leistung besser nutzt...

Klar mit 'nem i7-5960 oder so mag deine Aussage korrekt sein.
Aber stimmt das auch mit 'nem i7-2600(K) oder AMD Phenom II 9xx?!

[y33H@]

Ein 2600K dreht Kreise um einen Phenom II X4 ^^

[BlacKi]

WTF!?

Was zur Hölle redest du hier?!
WARUM soll etwas unnötig sein, was die CPU Leistung besser nutzt...
weil die cpu leistung nicht besser werden würde wenn man mit nvidia karten mantle unterstützen würde. vl etwas besser, aber nicht so deutlich wie bei amd karten mit mantle. im prinzip hat die entwicklung von mantle dafür gesorgt das die drawcalls bei amd karten unter dx11 nicht besser werden, wie zb. bei nvidia aka wundertreiber.

[Tamagothi]

Es steht jedem frei diese Ergebnisse hier mal nachzusehen:

http://nubleh.github.io/async/#18

Es ist offenbar nur ein Desaster wenn es nicht exakt so geht wie die Devs von Oxide sich das vorstellen.

Ich kenne diese Seite und weiß was es aussagt und auch was nicht aber Erzähl mal was du von der Sache hälst.

Einfach eine Seite Posten wo Grafikkarten und Balken sind :down:

[StefanV]

Ein 2600K dreht Kreise um einen Phenom II X4 ^^
Yap, aber dennoch dürftens einige Leute geben, die solche Hardware rumstehen haben...

Und da ist die Aussage einfach mal Bullshit, dass DX12 nix bringen würde.
Es bringt sehr wohl etwas -> geringere CPU Last, daher kann man mit weniger starken CPUs durchaus sehr stark davon profitieren...

Dass dieser Zustand hier runtergespielt werden muss, ist mir nicht verständlich...

[BlacKi]

Yap, aber dennoch dürftens einige Leute geben, die solche Hardware rumstehen haben...

Und da ist die Aussage einfach mal Bullshit, dass DX12 nix bringen würde.
Es bringt sehr wohl etwas -> geringere CPU Last, daher kann man mit weniger starken CPUs durchaus sehr stark davon profitieren...

Dass dieser Zustand hier runtergespielt werden muss, ist mir nicht verständlich...
also mit nvidia karten unter dx11 kackt ein phenom x4 nicht so ab wie mit amd unter dx11. natürlich bringt dx12 etwas bei amd karten, aber der vorteil bei einem phenom x4 und einer nvidia karte zwischen dx11 und 12 hält sich in grenzen, es sind bestimmt keine 10%.

[Tamagothi]

also mit nvidia karten unter dx11 kackt ein phenom x4 nicht so ab wie mit amd unter dx11. natürlich bringt dx12 etwas bei amd karten, aber der vorteil bei einem phenom x4 und einer nvidia karte zwischen dx11 und 12 hält sich in grenzen, es sind bestimmt keine 10%.

http://www.computerbase.de/2015-08/directx-12-benchmarks-ashes-of-the-singularity-unterschiede-amd-nvidia/2/#diagramm-ashes-of-the-singularity-2560-x-1440

schau dir den 1440p test an und sag nochmal bitte es sind nur 10% ;D

Wohl gemerkt bei CB ist ein I7 4770k im einsatz

[dargo]

im prinzip hat die entwicklung von mantle dafür gesorgt das die drawcalls bei amd karten unter dx11 nicht besser werden, wie zb. bei nvidia aka wundertreiber.
Zu dumm nur, dass die Draw Calls bei Nvidia immer noch schnarch langsam unter DX11 sind wenn man sich die DX12 Ergebnisse anschaut.

[BlacKi]

http://www.computerbase.de/2015-08/directx-12-benchmarks-ashes-of-the-singularity-unterschiede-amd-nvidia/2/#diagramm-ashes-of-the-singularity-2560-x-1440

schau dir den 1440p test an und sag nochmal bitte es sind nur 10% ;D

Wohl gemerkt bei CB ist ein I7 4770k im einsatz
edit: ca. 10%

ihr zieht jetzt eben einen test herbei indem ihr alles mögliche reindeutet. um zu zeigen das der test mieß ist zeigt der 4k test da ist sogar dx11 schneller. ob es nun 10 oder 20% sind, bei amd sinds 80-100%.
Zu dumm nur, dass die Draw Calls bei Nvidia immer noch schnarch langsam unter DX11 sind wenn man sich die DX12 Ergebnisse anschaut.
beziehst du dich jetzt auf den 3dmark dx12 test?

worauf ich eigentlich hinauswollte, ist das nvidia treiber erzeugen kleinere cpu flaschenhälse, mit denen man noch arbeiten kann. amd dx11 treiber dagegen sind hoffnungslos und müssen dringend durch dx12 abgelöst werden.

[Nakai]

Das hat jedenfalls sehr viel Potential für einen Shitstorm, wenn die ersten DX12 Spiele kommen und dann manche NVidianer AsyncCompute im Spiel einschalten und nichts passiert. Aber bei AMD funktioniert das...

Naja es kommt mit Pascal und gut is.

[dargo]

Das hat jedenfalls sehr viel Potential für einen Shitstorm, wenn die ersten DX12 Spiele kommen und dann manche NVidianer AsyncCompute im Spiel einschalten und nichts passiert.
Ich glaube kaum, dass du so eine Option Ingame zu Gesicht bekommst. ;) Ist AS auf NV langsamer wird es einen entsprechenden NV-Pfad ohne AS geben.

[fondness]

Ich glaube kaum, dass du so eine Option Ingame zu Gesicht bekommst. ;) Ist AS auf NV langsamer wird es einen entsprechenden NV-Pfad ohne AS geben.

Bingo, und bei AMD macht es null Sinn es auszuschalten.

[Nakai]

Bingo, und bei AMD macht es null Sinn es auszuschalten.

Hups ich erweitere:
Einen AsyncSchalter mit NV-Informationslogo nebendran.

Und ja das ist schon etwas bissig.

[Schnoesel]

Also ich finde es ja langsam mal an der Zeit dass sich Nvidia dazu äußert. Sie selbst könnten die Vorwürfe beiseite fegen und jedem beweisen, dass Maxwell AS performant beherrscht aber irgendwie ... kommt da nix. Dabei steht das so schön auf deren Folien:

http://www.geforce.com/sites/default/files-world/attachments/windows-10-launch-directx-12-advanced-api-support.png

[fondness]

Was sollen sie denn groß sagen? Die beste Methode um einem Thema nicht zu viel Aufmerksamkeit zukommen zu lassen ist noch immer es tot zu schweigen.

[Schnoesel]

Was sollen sie denn groß sagen?

Na zumindest ein "Awesome" könnte schon mal sein finde ich ;-)

[dargo]

Ich liebe euren Sarkasmus. :biggrin:

[Menace]

Hat nvidia nicht erst DX11 verbessert, als mantle kam. Oder täuschte der Eindruck? :confused:

[BlacKi]

Also ich finde es ja langsam mal an der Zeit dass sich Nvidia dazu äußert. Sie selbst könnten die Vorwürfe beiseite fegen und jedem beweisen, dass Maxwell AS performant beherrscht aber irgendwie ... kommt da nix. Dabei steht das so schön auf deren Folien:

http://www.geforce.com/sites/default/files-world/attachments/windows-10-launch-directx-12-advanced-api-support.png

oder wenigstens ein "wir arbeiten drann!" oder besser, beispiele wo es funktioniert.

aber sich async auf die flagge zu schreiben und dann so ne leistung im raum stehen zu lassen ist schon ein halbes verbrechen...
Hat nvidia nicht erst DX11 verbessert, als mantle kam. Oder täuschte der Eindruck? :confused:
es gab den wundertreiber. mich wundert der treiber tatsächlich, wie man auf einen schlag (nicht über 1-2 jahre) einfach mal 10-20% mehr fps im cpu limit draufzaubern konnte, als hätte man einen knopf gedrückt.

[Hübie]

Ich kenne diese Seite und weiß was es aussagt und auch was nicht aber Erzähl mal was du von der Sache hälst.

Einfach eine Seite Posten wo Grafikkarten und Balken sind :down:

Ich habe einfach nicht die Zeit. Tut mir leid, aber es ist mir zu müßig zwischen all den unqualifizierten Aussagen etwas sinnvolles zu finden und einen langen Text dazu zu schreiben. Lesen bildet - hab ich mal irgendwo gelesen :biggrin:

Zugegebenermaßen hab ich aber nicht mal die Zeit, die Berichte und Analysen zu lesen. nVidia wird schon noch reagieren, keine Bange. Dafür spuck ich in die Hand und schlag ein. :P
Für Oxide dagegen schlag ich nirgends ein - auch wenn viele dort eine beeindruckende, fachliche Kompetenz besitzen, bedeutet dies nicht dass die nVidias Hardware kennen.

ps: Ich hielt es einfach nur für fair, diesen link auch hier zu publizieren.

[Birdman]

nV muss es nur schaffen dass Async Compute die Chose nicht langsamer werden lässt und schon ist das grundsätzliche Problem behoben.
Dies müsste sich imho im Treiber lösen lassen, da der eigentliche Rechenaufwand ja schlussendlich der selbe ist.

[Hübie]

Eigentlich muss es eher der Entwickler machen.

[fondness]

Eigentlich muss es eher der Entwickler machen.

Was redest du da bitte?

[Hübie]

Der Treiber biegt immer das gerade was der Entwickler nicht macht. Wobei es wohl mit D3D12 nicht mehr soweit geht wie zuvor, wenn ich richtig liege.

[Kartenlehrling]

Wär es nicht Microsoft und Square Enix’s aufgefallen wenn Nvidia Asynchronous Compute nicht optimal funktioniert,
schliesslich haben sie ja mit Forza5 + WITCH CHAPTER 0 zwei DX12 Demos gezeigt,
zwar haben sie mit Kanonen auf Spatzen geschossen mit ihrem 4xSLI Titan System aber trotzdem hätte es wohl auffallen müssen?

[fondness]

Der Treiber biegt immer das gerade was der Entwickler nicht macht. Wobei es wohl mit D3D12 nicht mehr soweit geht wie zuvor, wenn ich richtig liege.

Nvidia hat Oxide nicht ohne Grund gebeten die async Shader zu deaktivieren. Wenn die Hardware von Nvidia jedes mal einen Context Switch machen muss bei async compute kann auch der Treiber nicht zaubern. Der Spieleentwickler wird es also bei NV sinnvollerweise nicht verwenden.

[dargo]

Wär es nicht Microsoft und Square Enix’s aufgefallen wenn Nvidia Asynchronous Compute nicht optimal funktioniert,
schliesslich haben sie ja mit Forza5 + WITCH CHAPTER 0 zwei DX12 Demos gezeigt,
zwar haben sie mit Kanonen auf Spatzen geschossen mit ihrem 4xSLI Titan System aber trotzdem hätte es wohl auffallen müssen?
Wie kommst du jetzt auf die Idee der schnelle Forza 5 Demo-Port würde AS verwenden?

[Gerhard]

Es steht jedem frei diese Ergebnisse hier mal nachzusehen:

http://nubleh.github.io/async/#18

Es ist offenbar nur ein Desaster wenn es nicht exakt so geht wie die Devs von Oxide sich das vorstellen.

Danke, das scheint denn Heise Artikel ja wirklich voll zu bestätigen.

Kurz die Grafiken erklärt so wie ich sie sehe da diese ja doch verwirrend sein kann:

ASync Shaders soll verschiedene Teile der GPU besser auslasten in dem diverse Rechenaufgaben und Grafikdarstellung parallel voneinander arbeiten können. So sollen die aufwendigen z.B. Physikberechnungen gleichzeitig mit einfachen Shaderaufgaben laufen lassen welche kaum Floatingpointberechnungen brauchen.

Die Grafik vergleicht nun den Unterschied mit ASync IO (Compute-Hellrosa und Grafikshadern blau).

Wenn es nun einen Dunkelrosa Bereich gibt wurde es mit ASync IO schneller, die GPU also besser dadurch ausgelastet.
Wenn sie einfach übereinander liegen deutet es darauf hin das keine Parallelisierung erfolgt ist, also die Berechnungen nacheinander ausgeführt wurden. Ist weiß dazwischen dauerte es sogar länger.

Die AMD GPUs konnten fast alle die Aufgaben schön parallelisieren, also unterstützen ASync Shader in Hardware und parallelisiert schön die Aufgaben.

Die NVidia GPUs dagegen brauchen mit und ohne ASync Shader annähernd gleich lange, machten die Aufgaben also hintereinander und haben sie nicht parallelisiert. Der Treiber scheint somit zu melden das er was unterstützt was die Hardware so nicht kann.

Nun ist dies ein einfaches Beispiel, der Artikel legt nahe das bei komplexen Rechenanforderungen bei NVidia noch zusätzlicher Aufwand entsteht, es also beim wild durcheinander "reinkippen" der unterschiedlichen Shadern langsamer statt wie bei AMD schneller wird. Dies deswegen da die Hardware diese nicht parallelisieren kann sondern immer eine Aufgabe fertigstellen muss um sich um die nächste Shaderaufgabe zu kümmern. Die effizientere GPU Auslastung der "ASync Shader" also nicht da ist.

[ilibilly]

Also nachdem ich mir die benchmarks angesehen hab ,muss ich schon sagen das hier ein zu großes faß aufgemacht wird,ok fury ist dann teilweise 10-20% vor einer 980ti,Referenz wohlgemerkt.
Mit einer normaler custom die mit 1300 boostet ist man ca gleichauf mit fury x.
Nvidia hat imho unter dx11 viel bessere treiberabteilung abgeliefert sodass die Steigerung minimal ist ,bei amd muss man sagen das dx11 mit fury x Grotten ist,teilweise 30-40% langsamer als 980ti.
Klar das da mehr Potenzial vorhanden ist,in Sachen tflops ist die fury ja nvidia haushoch überlegen,vielleicht bringen Sie es ja mit dx12 endlich auf die Straße ,gönnen würd ichs amd,dann wird die nächste graka halt eine rote.

[Troyan]

Nvidia hat Oxide nicht ohne Grund gebeten die async Shader zu deaktivieren. Wenn die Hardware von Nvidia jedes mal einen Context Switch machen muss bei async compute kann auch der Treiber nicht zaubern. Der Spieleentwickler wird es also bei NV sinnvollerweise nicht verwenden.

Das Programm aus dem Beyond3d.com Forum zeigt, dass es keinen Nachteil beim Wechseln von der Graphics zur Compute Queue gibt. Die Abarbeitung erfolgt ausnahmelos ohne Zeitverlust.

Es zeigt auch, dass Asynchronous Compute auf nVidia-Hardware keine Nachteile hat, wenn man es nicht absichtlich so programmiert.

[Tamagothi]

Irgendein Benchmark ( ist das überhaupt einer? ) mit einem Spiel vergleichen und dann sagen es gibt keine Nachteile :freak:

[Menace]

Es zeigt auch, dass Asynchronous Compute auf nVidia-Hardware keine Nachteile hat, wenn man es nicht absichtlich so programmiert.

Oxide hat es also absichtlich so programmiert. Yeah, Gameworks reloaded. :biggrin:

[Hübie]

Nvidia hat Oxide nicht ohne Grund gebeten die async Shader zu deaktivieren. Wenn die Hardware von Nvidia jedes mal einen Context Switch machen muss bei async compute kann auch der Treiber nicht zaubern. Der Spieleentwickler wird es also bei NV sinnvollerweise nicht verwenden.

Deine einseitige Argumentation ist bezeichnend. Vielleicht ist deren Code Müll auf nVidia-Hardware. Vielleicht hat nVidia noch keinen Weg gefunden das effizient zu lösen. Vielleicht weigerte Oxide sich den Code so anzupassen dass es effizient läuft. Vielleicht haben nVidias Leute auch einfach kein Bock gehabt sich damit zu befassen. Vielleicht ist aber auch einfach nur Nachts kalt und über den Berg ists kürzer. :rolleyes:

Von dem was ich jetzt in der kurzen Zeit lesen konnte: Maxwell & Co sammeln erst 32 Threads und schicken diese dann synchron los. Das ist statisch im Treiber-code hinterlegt. Auf Kepler dürfte es anders aussehen, da hier mehr vom Frontend in Hardware verbaut ist. Also könnte man mit Maxwell durchaus mehr per Treiber machen als bei den Vorgängern.
Hab jetzt aber keine Lust mehr zu lesen und geh noch etwas zocken :P

@Troyan: Das ist aber auch ein best case und nur eine Auswahl von vielen so etwas anzugehen. Also nicht voreilig mit ungelegten Eiern handeln. Das viele gleich drauf losstürmen zeugt ja von einer gewissen "Qualität". :rolleyes:

@Gerhard: Afaik macht der Treiber das compiling für Maxwell-Threads.

[del_4901]

Die Fury hat nur nicht soviel ueberlappung weil der Grafikteil einfach getuned wurde und mehr sachen durchpumpen kann. Da ist dann auf den CUs einfach kein platz mehr fuer Async Compute. Es kann aber auch sein das der HBM das Memory Access pattern einfach nicht mag, evtl. sollte man das UAV dann ein bissel padden. Allerdings hat die Fury auch so extrem viele CUs, dass es generell schwierig ist die alle ohne Async Compute auszunutzen. Tonga waehre interessant, da gleiche Architektur aber weniger CUs.

[Unicous]

Money quote von Sebastian Aaltonen (RedLynx, Trials-Reihe) zu dem test case:




Jawed said:

Apart from that I can't help wondering if the [numthreads(1, 1, 1)] attribute of the kernel is making AMD do something additionally strange.

If the compiler is good, it could either skip the vector units completely by emitting pure scalar unit code (saving power) or emitting both scalar + vector in an interleaved "dual issue" way (the CU can issue both at the same cycle, doubling the throughput).

Benchmarking thread groups that are under 256 threads on GCN is not going to lead into any meaningful results, as you would (almost) never use smaller thread groups in real (optimized) applications. I would suspect a performance bug if a kernel thread count doesn't belong to {256, 384, 512}. Single lane thread groups result in less than 1% of meaningful work on GCN. Not a good test case at all.

[Nightspider]

Weil hier die Begriffe Async Comput und Mantle fielen....

Bisher wurde Async Compute doch gar nicht bei Mantle-Spielen genutzt oder?

Bei BF4 und Co wurde doch nur die CPU massiv entlastet aber das GPU Limit nicht verschoben. Schon gar nicht um 20-30%.

[Atma]

Weil hier die Begriffe Async Comput und Mantle fielen....

Bisher wurde Async Compute doch gar nicht bei Mantle-Spielen genutzt oder?

Bei BF4 und Co wurde doch nur die CPU massiv entlastet aber das GPU Limit nicht verschoben. Schon gar nicht um 20-30%.
Laut einer AMD Folie wurde Async Compute schon bei Mantle für Thief eingesetzt.

[tm0975]

Wär es nicht Microsoft und Square Enix’s aufgefallen wenn Nvidia Asynchronous Compute nicht optimal funktioniert,
schliesslich haben sie ja mit Forza5 + WITCH CHAPTER 0 zwei DX12 Demos gezeigt,
zwar haben sie mit Kanonen auf Spatzen geschossen mit ihrem 4xSLI Titan System aber trotzdem hätte es wohl auffallen müssen?

vielleicht hätte uns aber etwas auffallen sollen, wenn die techdemo 4 titan benötigt statt einer 980. nvidia wird kein problem damit haben, wenn sich jeder der eine 960 aufwärts hat für dx12 ne sli-kombi zulegen muss...

[Godmode]

vielleicht hätte uns aber etwas auffallen sollen, wenn die techdemo 4 titan benötigt statt einer 980. nvidia wird kein problem damit haben, wenn sich jeder der eine 960 aufwärts hat für dx12 ne sli-kombi zulegen muss...

Ich denke die wollten nur zweigen, dass mit DX12 jetzt Multi-GPU auch mit mehr Karten als zwei funktioniert. Multi-GPU-Systeme sind absolute Nische (300k weltweit, IIRC), dienen aber der Vermarktung. Jeder der so ein Multi-GPU-System sieht, denkt erstmal: "Wow geil, das muss FPS bringen...."

[Gipsel]

Money quote von Sebastian Aaltonen (RedLynx, Trials-Reihe) zu dem test case:
Ist ja nicht so, als wäre das hier im Thread nicht schon erwähnt worden:Vielleicht meint er, weil das insgesamt etwas realitätsfern geschrieben ist (single lane shader? also nur ein thread pro threadgroup genutzt, irgendwo gibt es zumindest bei AMD noch einen fetten Zeitoverhead usw.).;)
Und der genannte Overhead existiert wohl gar nicht (hatte mir den Code nicht angesehen), sondern ist nur ein Effekt davon, daß der Code bei jedem Aufruf einfach ewig (recht sinnlos) durch eine Schleife läuft (eine einzelner Kernel läuft also bereits so lange). Es ist also tatsächlich ein sehr praxisferner Test.

=======================

Das Programm aus dem Beyond3d.com Forum zeigt, dass es keinen Nachteil beim Wechseln von der Graphics zur Compute Queue gibt. Die Abarbeitung erfolgt ausnahmelos ohne Zeitverlust.

Es zeigt auch, dass Asynchronous Compute auf nVidia-Hardware keine Nachteile hat, wenn man es nicht absichtlich so programmiert.
Das Programm zeigt erstmal recht wenig. Aber was es zeigt ist, daß offenbar nV keine Vorteile aus der gleichzeitigen Nutzung von Compute Shadern ziehen kann. Also kein Überlapp bzw. gleichzeitige Ausführung auf den SMx'. Die Ausführungszeiten addieren sich einfach. Bei GCN geht dieser Überlapp ganz offensichtlich.
Und falls man (aus welchem Grund auch immer) noch Grafik- und Compute-Shader in einer Queue (der Direct) mischt, dann passiert offensichtlich das, wovon der eine Oxide-Mann geredet hat: Hell breaks loose. Dann muß offenbar tatsächlich der command processor (habe gerade den PR-Begriff von nV dafür vergessen) ständig zeitaufwändige Kontext-Switches durchführen, was zu absolut horrender Performance führt (Faktor 10-20 langsamer oder so in den Testcase, je mehr Kontext-Switches, desto langsamer wird es, das ist also noch nicht das Ende der Fahnenstange). Hier sind die GCN-GPUs wie es aussieht deutlich flexibler, weil die Compute-Shader OoO mit den Grafik-Shadern in der gleichen Queue ausgeführt werden können (wenn keine manuelle Synchronisierung erfolgt). Tatsächlich ist dies auf GCN anscheinend sogar die schnellste Möglichkeit (eventuell, da die Kommunikation mit anderen ACEs entfällt, aber vielleicht im Moment auch eher, weil bei AMD der Treiber den über ACEs abgesetzten asynchronen Shader nur etwa die Hälfte der Gesamt-GPU-Resourcen zur Nutzung erlaubt, die Priorität der Shader sehr niedrig gesetzt wird oder so etwas in der Art; das kann man gegebenenfalls ändern).
Bei der Benutzung separater Queues kann nV die Shader zwar nicht überlappen (wie auf GCN), aber immerhin entfallen dann die Kontextswitches in einer Queue, so daß die Verluste minimiert werden. Performance-Vorteile entstehen hier aber (anders als bei GCN) auch nicht.

Interessant wären natürlich realitätsnähere Tests, also welche, in denen wirklich was berechnet wird, größere Threadgroups zum Einsatz kommen (und nicht sinnlos für ein Einzelelement gelooped wird und dafür eine komplette Wavefront/Warp verbraten wird) und bei denen auch sporadische Synchronisation (also nicht stur immer, sondern nur ab und zu) sowohl zwischen einigen Compute-Shadern als auch zwischen ein paar Compute- und Grafik-Shadern zum Einsatz kommt. Dann würde sich eher zeigen, wie Async Compute Shader in etwa in der Praxis performen können.

[Unicous]

Da Troyan und Co. es ja immer besser wissen, hilft es doch wenn man mehrere Perspektiven abbildet, oder nicht.;)

[fondness]

Deine einseitige Argumentation ist bezeichnend.

Ist deine Argumentation etwa nicht einseitig? :rolleyes:
Die Tests zeigen alle das gleiche, nämlich das die NV-Karten völlig in die Knie gehen bei Compute + Grafik. Alles was du machst ist Oxide und was weiß ich wem noch alles die Schuld zu geben. Klar kann man hoffen, dass noch irgendwie ein Wunder passiert und NV das noch irgendwie in Software gerade bügeln kann. Aber da es nach wie vor weder ein Statement von NV gibt und noch dazu alles für eine Hardwarelimitierung spricht ist das wohl nicht sonderlich wahrscheinlich.

[StefanV]

Deine einseitige Argumentation ist bezeichnend.
Als ob du groß anders wärst...

Oder warum versuchst du gerade die Schuld auf irgendwen, nur nicht nVidia zu schieben?!

Und wo sind die Postings von dir, in dem du die Async Shader Leistung von AMD lobst?!
Oder wo sind generell die Postings von dir, in denen du AMD lobst?!

Vielleicht ist deren Code Müll auf nVidia-Hardware. Vielleicht hat nVidia noch keinen Weg gefunden das effizient zu lösen.
Und wie wäre es mit dem offensichtlichen?!

Vielleicht kann nVidia gar kein 'Async Compute'?!
WARUM ist dieses so unwahrscheinlich?!

Es ist ja eben gerade nicht so, als ob nVidia in der Vergangenheit bei Features nicht gelogen hätte...
Oder wie würdest du sonst die Kepler mit DX11.1/2 Dinge bezeichnen wollen?!


Vielleicht weigerte Oxide sich den Code so anzupassen dass es effizient läuft. Vielleicht haben nVidias Leute auch einfach kein Bock gehabt sich damit zu befassen. Vielleicht ist aber auch einfach nur Nachts kalt und über den Berg ists kürzer. :rolleyes:
Vielleicht bist du auch nur einer von denen, die nVidia schön reden müssen?!
Vielleicht magst du auch nicht einsehen wollen, dass die aktuelle nVidia Hardware dazu schlicht nicht in der Lage ist.
Vielleicht ist das ganze viel einfacher als du denkst.
Vielleicht ist nVidia einfach nur nVidia und hat mal wieder bei den Specs gelogen und bietet nur DX12 Treiber an, obwohl die Hardware nur DX12 FL11.x beherrscht?!

Vielleicht wäre das ja auch nicht so abwegig, meinst du nicht auch?!

Von dem was ich jetzt in der kurzen Zeit lesen konnte: Maxwell & Co sammeln erst 32 Threads und schicken diese dann synchron los.
BINGO, da ist nichts mit Asynchron!!11

Und Alphatier hats ja auch schon angemerkt, dass nVidia bei Async Compute nicht besonders gut dasteht. Ja, warum denn, wo DX12 doch schon soo lange geplant ist und man ja sooo eng mit M$ zusammengearbeitet hat?!
WARUM funktioniert denn eines der essentiellen Featues von DX12 nicht auf nVidia Hardware?!


Das ist statisch im Treiber-code hinterlegt. Auf Kepler dürfte es anders aussehen, da hier mehr vom Frontend in Hardware verbaut ist. Also könnte man mit Maxwell durchaus mehr per Treiber machen als bei den Vorgängern.
Hab jetzt aber keine Lust mehr zu lesen und geh noch etwas zocken
Vielleicht, vielleicht auch nicht...

Aber warum versuchst du hier das ganze wieder Positiv für nVidia zu sehen?!
Vielleicht ist das der 'grünen Karte' geschuldet, die bei dir momentan im Rechner steckt?!
Vielleicht versuchst du gerade, dein Hab und Gut besser zu sehen als es ist?

Vielleicht willst du auch einfach nicht sehen, dass AMD hier noch einfach besser dasteht?!

Oder warum ist von dir so wenig positives in AMDs Richtung und so viel in nVs Richtung zu sehen?!
Und das obwohl gerade nVidia das NICHT verdient hat.
Siehe DX11.1/2 bei Kepler. Siehe die Specs zur GTX970...

Und bei solch einem Laden, der die eigenen Kunden nach Strich und Faden verarscht, ja sie sogar mit Füßen tritt, denkst du auch noch positiv?! WTF?!
Wäre es nicht logischer, anhand der ganzen Fakten, die wir über nVidia haben, anzunehmen, dass Kepler und Maxwell schlicht nicht dazu in der Lage sind?! Und dass Oxides Statements völlig korrekt sind?!

Oh und war da nicht auch noch eine ähnlich arrogant-überhebliche Aussage bezüglich der separaten Chips zur TV Ansteuerung bei älteren nVidia Karten?! Hat jemand von nVidia damals nicht auch gesagt, dass das nicht deren Bier wäre und das 'die anderen' gefälligst zu lösen hätten?!

Sorry, aber dass man solch einen Laden auch noch in irgendeiner Weise positiv sehen kann, ist echt 'interessant'...

Und erinnerst du dich an die CineFX Architektur?!
Also nV3x, 4x und G70...
Erinnerst du dich daran, wie damals die Shader realisiert wurden?!
Erinnerst du dich daran, wie damals die Shader die TMUs gestallt haben (und/oder umgekehrt?)??
Irgendwie schaut das momentan exakt so aus, wie damals bei der CineFX V2 Architektur...

[DinosaurusRex]

Ich hab mal eine Frage, und zwar wird eine Szene nach meinem Verständnis mit einem CPU Thread gezeichnet, also die ganzen Pixel Shader von der CPU an die Arbeit geschickt und die Constants übermittelt und so weiter.

Kann man sowas auch mit Async Compute lösen, also das die GPU die Szene zeichnet? Falls das möglich wäre, würde es ja logischerweise die CPU entlasten. Was ich aber viel interessanter finde: Falls es möglich wäre, inwiefern könnte eine GPU mithilfe von Async Compute denn eine komplexere Szene zeichnen als die CPU? Wäre es einfach nur eine Entlastung oder tatsächlich sogar ein Boost?

[Gipsel]

@all:
Bitte behaltet im Kopf, daß das hier der DX12-Technologie-Thread ist. Irgendwelche von Fanboys beider Seiten befeuerten nV vs. AMD Diskussionen sind hier also fehl am Platz.

Danke.

[Hübie]

Ist deine Argumentation etwa nicht einseitig? :rolleyes:
Die Tests zeigen alle das gleiche, nämlich das die NV-Karten völlig in die Knie gehen bei Compute + Grafik. Alles was du machst ist Oxide und was weiß ich wem noch alles die Schuld zu geben. Klar kann man hoffen, dass noch irgendwie ein Wunder passiert und NV das noch irgendwie in Software gerade bügeln kann. Aber da es nach wie vor weder ein Statement von NV gibt und noch dazu alles für eine Hardwarelimitierung spricht ist das wohl nicht sonderlich wahrscheinlich.

Ich ziehe erst einmal alles in betracht (das mit nVidia war ja für euch schon klar), was du schon mal gar nicht tust. Auf StefanV sein Gequatsche gehe ich einfach mal Null Komma Null ein, da völlig unqualifiziert und hirnlos daher geplappert (ich erinnere da mal an die vielen lustigen Stunden die er uns wegen den 3,5 GB geschenkt hat). Ich frage mich eh woher manche hier die Zeit nehmen. Kein Job oder so? :confused:

Da ich schon viel mit Devs zu tun hatte, die unterschiedliche Probleme unter CUDA lösen mussten, weiß ich durchaus dass die Hardware dazu in der Lage ist asynchronen code auszuführen. Nur ist das halt eine andere Welt. Oft auch weniger grafiklastig.
Und solang wir nicht wissen wo es denn genau hängt bin ich nicht bereit einfach wie ein Hund zu bellen, das nVidia scheiße ist. Ende, Aus, Nikolaus. Nicht mehr und nicht weniger will ich hier mal klarstellen. Was ihr in euren Lasergehirnen in meine Texte interpretiert kann ich ja nicht beeinflußen.

Mich persönlich trifft es ja auch, wenn nVidia mich beschißen hat. Also versteh ich nicht wieso ihr mich so hinstellt, als würde ich nVidia verteidigen. Ich plapper einfach nicht alles blöde nach, was ihr vorgesetzt bekommt. Bin nicht so konditioniert. :P

[Locuza]

Kann man sowas auch mit Async Compute lösen, also das die GPU die Szene zeichnet? Falls das möglich wäre, würde es ja logischerweise die CPU entlasten. Was ich aber viel interessanter finde: Falls es möglich wäre, inwiefern könnte eine GPU mithilfe von Async Compute denn eine komplexere Szene zeichnen als die CPU? Wäre es einfach nur eine Entlastung oder tatsächlich sogar ein Boost?
So ein Feature zieht in DX12 mit dem Namen ExecuteIndirect ein.
Wenn ich mich recht erinnere, kommen die Zahlen von einer MS Präsentation mit Intels Asteroiden Demo:

http://i.imgur.com/vHf9DrH.png

[Gipsel]

Nur ist das halt eine andere Welt. Oft auch weniger grafiklastig.
Und solang wir nicht wissen wo es denn genau hängtDas könnte der Knackpunkt sein. Wie in meiner Antwort an Troyan geschrieben, hat nV Probleme mit dem Mix aus Grafik+Compute. Während sich bei verschiedenen Queues (eine für Grafik, eine andere für Compute) sich die Ausführungszeiten noch einfach addieren (kostet also keine Performance, bringt aber auch keine), heben die nV-GPUs in dem B3D-Test beim Mixen von Grafik+Compute in einer Queue praktisch die Hufe. Nur ist der Test dort wie ja schon beschrieben wenig realitätsnah. Hier muß man mal abwarten, was bessere Tests ergeben werden.

[Lord_X]

Die Tests zeigen alle das gleiche, nämlich das die NV-Karten völlig in die Knie gehen bei Compute + Grafik.
Genau und der Grund steht hier:

...Let me start with this: MAXWELL DOES SUPPORT ASYNC SHADERS/COMPUTE. There is a slight gain. But it software emulates it. The driver is sending the compute workload to the CPU for it to process while the GPU is processing graphics (link below). It's a clever trick to claim feature "support"....

https://www.reddit.com/r/pcgaming/comments/3jfgs9/maxwell_does_support_async_compute_but_with_a/

[Tamagothi]

oder hier

http://www.pcgameshardware.de/DirectX-12-Software-255525/News/Maxwell-Asynchronous-Compute-1170078/

[Hübie]

Ich bin mir ziemlich sicher, dass die CPU nicht die Berechnungen durchführt sondern kompiliert und dann zurück sendet.
PCGH sollte dies mal mit Titan oder Titan Black messen (keine 780 / 780 Ti!!). Das Ergebnis würde mich sehr interessieren.

Edit: Geht async threading nicht schon eine Weile auf OGL? Dann kann da mal jemand einen Test machen. Ich konnte in der testsuite von B3D gestern keine auffällige CPU-Leistung feststellen. Habe das Programm dabei auf einen Kern festgenagelt (rot umrandet).

http://abload.de/thumb/async_bench_182k4j.png (http://abload.de/image.php?img=async_bench_182k4j.png) http://abload.de/thumb/async_bench_2snjom.png (http://abload.de/image.php?img=async_bench_2snjom.png) http://abload.de/thumb/async_bench_3kzjkk.png (http://abload.de/image.php?img=async_bench_3kzjkk.png) http://abload.de/thumb/async_bench_4eek2v.png (http://abload.de/image.php?img=async_bench_4eek2v.png)

Takt war meistens um die 1,4 GHz. Peak waren 3,3 GHz auf dem Kern.

[DinosaurusRex]

So ein Feature zieht in DX12 mit dem Namen ExecuteIndirect ein.
Wenn ich mich recht erinnere, kommen die Zahlen von einer MS Präsentation mit Intels Asteroiden Demo:

http://i.imgur.com/vHf9DrH.png


Ist das dann mit Intel CPU und Intel iGP?

[Gipsel]

Ich konnte in der testsuite von B3D gestern keine auffällige CPU-Leistung feststellen. Habe das Programm dabei auf einen Kern festgenagelt (rot umrandet).Das könnte auch schlicht daran liegen, daß dort eigentlich gar nicht viel berechnet wird, sondern praktisch die CUs bzw. SMs für eine bestimmte Zeit geblockt werden (mit threadgroups der Größe 1, die einfach sinnlos loopen). Eine CPU ist extrem viel effizienter für sowas (und verschwendet z.B. auch nicht ~96,8% [nV] bzw. ~98,4% [AMD] der verfügbaren ALUs, die tun auf GPUs nämlich absolut nichts bei dem dort benutzten Code und bleiben schlicht ungenutzt). Das ist praktisch maximal ungünstiger GPU-Code (erheblich besser für CPUs geeignet).

[Hübie]

Dennoch habe ich jetzt etwas interessantes festgestellt. Ich bitte zunächst einmal um Reproduktion mit AMD-Fury / R9 390 und GTX Titan Classic/Black.


System mit allen Diensten starten. Bei nVidia sind das ja einige - bei AMD kein Plan.
Dreimal cmd.exe starten
cmd.exe jeweils CPU1, CPU2 und CPU3 zuweisen (nicht CPU0!)
cmd.exe einmal niedrige Priorität, Normal und Hoch
In allen drei cmd.exe die AsyncCompute.exe starten und schon mal die 1 eingeben - noch nicht Enter!
Checken ob jede AsyncCompute.exe anderen Kern zugewiesen ist und andere Priorität hat
Parallel den Taskmanager und ein GPU-Monitor laufen lassen
Anschließend schnell alle cmd.exe-Fenster nacheinander anklicken und Enter drücken um einen relativ gleichzeitigen Start hinzulegen
Kaffee kochen und abwarten. Zwischendrin screenshots (100er Bereich, 350er Bereich, 450er und 512).


Das ganze dann bitte noch einmal OHNE sämtliche Graka-Dienste.

Meine Ergebnisse kann ich noch nicht richtig deuten, aber der Treiber hat großen Einfluß auf das Ergebnis. Allein der Start ist stark unterschieldich:
http://abload.de/thumb/async_bench_comparisodcojd.png (http://abload.de/image.php?img=async_bench_comparisodcojd.png) http://abload.de/thumb/async_bench_comparisoo8ooo.png (http://abload.de/image.php?img=async_bench_comparisoo8ooo.png)

Dann ist es im Falle mit den Diensten so, dass nur zwei der drei wirklich rechnen. Nummer drei steht fast nur und läuft durch, nachdem zwei abgearbeitet sind. Weiterhin spiked es heftiger und der Takt ist im Schnitt höher. Ich hatte bisher auch noch nie gesehen, dass die GPU zu 100% ausgelastet wird. Waren immer nur 99%. Auf dem PCIE-Bus gibt es wenig bis keine Aktivität.

@Gipsel: Das der Code nur bedingt taugt sagte ich ja bereits, aber für Grundlagen ist der wohl erst mal tauglich. Ist irgendwie so, als ob ich durch klopfen auf eine Wand versuche herauszufinden was dahinter verborgen ist. Etwas frustrierend.

[Nakai]

Ich bin mir ziemlich sicher, dass die CPU nicht die Berechnungen durchführt sondern kompiliert und dann zurück sendet.
PCGH sollte dies mal mit Titan oder Titan Black messen (keine 780 / 780 Ti!!). Das Ergebnis würde mich sehr interessieren.


Also wer schon auf die Idee kommt, dass die CPU da mitarbeiten würde...*hust*.
Womöglich wird da ein Software-Scheduling eingebaut, was es so wirken lässt, dass es Async-Compute ist. Und klar können Nvidia-GPUs mehrere Sachen parallel ausführen. Und es sieht tatsächlich so aus, dass NV Probleme mit Compute+Graphics hat. Seite OpenCL1.1 gibt es Multihtreading bei und es gibt schon mehrere Queues pro Device. Damit kann man Sachen parallel ausführen.

Ich muss auch sagen, dass AsyncCompute jetzt nicht soetwas "neues" ist.:)

[Loeschzwerg]

Bin im B3D nicht registriert, bitte das Progrämmchen hier hochladen.

Was für Graka Dienste meinst du? Evtl. den Geforce Experience und Gaming Evolved Schrott?

[Hübie]

Nein, ich meine alle Dienste von nVidia oder AMD - ALLE!

http://abload.de/thumb/nvidia-dienstecrqm1.png (http://abload.de/image.php?img=nvidia-dienstecrqm1.png)

Datei häng ich dir an.

@Nakai: Was soll ich mit deinem Beitrag anfangen? :confused: Es ist ja offenbar nicht nur das scheduling vom Treiber, sondern auch von Diensten abhängig wie man sieht. Lies mal meinen Beitrag. Hab editiert :D

[Unicous]

@Hübie

Ich möchte jetzt keinen unnützen Streit anfangen möchte aber mal eine Sache kommentieren.


Ich ziehe erst einmal alles in betracht (das mit nVidia war ja für euch schon klar), was du schon mal gar nicht tust.

Dafür, dass du alles in Erwägung ziehst hast du erst kürzlich die Ausführungen von Oxide kompeltt in Zweifel gezogen und im gleichem Atemzug diesem dahingefriemelten test case sehr viel Beachtung beigemessen und als vollkommen legitim erachtet.

Ein jeder muss sich an seinen eigenen Aussagen messen lassen und diese gegebenenfalls reflektieren. Besonders wenn die Faktenlage eher dünn ist. Beide Lager bauschen das künstlich auf bzw. versuchen zu beschwichtigen und zu beschönigen.

Für mich zum Beispiel klingen die Ausführungen von Oxide plausibel, das heißt aber nicht, dass sie am Ende relevant sind. Ob Async Compute für AMD kurz- bis mittelfristig einen Vorteil verspricht und alle Studios sich darauf stürzen oder nicht ist jedenfalls nicht abschließend geklärt und Nvidia hat sich in solchen Situationen immer zu helfen gewusst.;)

[Hübie]

Worauf soll ich mich sonst stürzen? Ashes of singularity gibt es ja nicht zum download. Und wenn dann kann man keinen Code einsehen. Statements seitens nVidia stehen ebenfalls aus. Nur das Wort eines kleinen Entwicklerteams steht im Raum.
Und streiten tue ich nur mit meinem Weibchen :biggrin: Soweit bekommt mich hier niemand.

[Schnoesel]

Statements seitens nVidia stehen ebenfalls aus. Nur das Wort eines kleinen Entwicklerteams steht im Raum.

Amd hat das auch schon gesagt und ich bezweifle, dass die das Konkurrenzprodukt nicht kennen. Zudem ist es bezeichnend, dass Nvidia bei diesen Anschuldigen sich einfach mal gar nicht äußert, bzw. ist man wohl zum Schluss gekommen sich besser nicht öffentlich zu erklären.

Mir und jedem anderen konnte jedenfalls noch nicht bewiesen werden dass Nvidia AS performant beherrscht, sollte doch gehen bei den ganzen Experten hier oder?

[Loeschzwerg]

Also ich habe das mal nebenher laufen lassen... und einfach planlos ein paar Screenshots gemacht.

Mit den Diensten aktiv:
http://abload.de/thumb/14xsy7.png (http://abload.de/image.php?img=14xsy7.png) http://abload.de/thumb/226sqt.png (http://abload.de/image.php?img=226sqt.png) http://abload.de/thumb/3wssd4.png (http://abload.de/image.php?img=3wssd4.png) http://abload.de/thumb/4m4s5m.png (http://abload.de/image.php?img=4m4s5m.png) http://abload.de/thumb/5wks72.png (http://abload.de/image.php?img=5wks72.png) http://abload.de/thumb/6shsdw.png (http://abload.de/image.php?img=6shsdw.png)

Und was willst du jetzt daraus ablesen?

[Hübie]

Klar. AMD kennt die tiefen der Hardware von nVidia und nutzt nicht wieder mal die Gunst der Stunde um seine eigene Marktposition zu verteidigen. Also manchmal wundere ich mich noch über die Aussetzer einiger Forenmitglieder.

@Loeschzwerg: Okay du hast HT an. Das machts schwieriger den Überblick zu behalten. Hast du das mit Priorität und Zuweisung gemacht? Stand dein System zwischenzeitlich immer wieder? Deine GPU-Auslastung ist wieder völlig anders. Dieser Test scheint für AMD nicht so geeignet.

[aufkrawall]

Der Effekt kommt eh von allein, wenn die Spiele erscheinen. Da muss sich AMD gar nicht äußern, um zu profitieren.

[Kartenlehrling]

Alle Demos und Testsprograme kann man doch nicht ernst nehmen.
Wir mussen es wie Nvidia "aussitzen" bis die ersten Games da sind, und dann ist die frage ob Async shaders wirklich Vorteile von zweistelligen Prozente bringt.

JustCause3 (Nvidia) 01.12.2015 und Hitman (AMD) 08.12.2015 werden wohl die ersten DX12 Games sein.
RotTR wird ja leider erst XBone exklusiv sein.

[Schnoesel]

Klar. AMD kennt die tiefen der Hardware von nVidia und nutzt nicht wieder mal die Gunst der Stunde um seine eigene Marktposition zu verteidigen. Also manchmal wundere ich mich noch über die Aussetzer einiger Forenmitglieder.

Haben sie doch gemacht als die sich dahingehen geäußert haben, dass Async Compute auf Nvidia nicht ohne Context switch möglich ist und dem hat Nvidia bis heute nicht widersprochen. Einfach nur feste dran glauben, dann geht das auch bei Nvidia funktioniert halt nicht, aber wer will kann das natürlich gerne tun.

[BlacKi]

JustCause3 (Nvidia) 01.12.2015 und Hitman (AMD) 08.12.2015 werden wohl die ersten DX12 Games sein.
RotTR wird ja leider erst XBone exklusiv sein.

wow, solange muss man sich hier rumstreiten bis man klarheit hat? na gute nacht...

[Loeschzwerg]

@Loeschzwerg: Okay du hast HT an. Das machts schwieriger den Überblick zu behalten. Hast du das mit Priorität und Zuweisung gemacht? Stand dein System zwischenzeitlich immer wieder? Deine GPU-Auslastung ist wieder völlig anders. Dieser Test scheint für AMD nicht so geeignet.

Nix HT an, native 14 Cores ;)

Die Zuweisung auf 1, 2, 3 und niedrig bis hoch habe ich gemacht. Bei dem Task mit "niedrig" geht stellenweise einfach überhaupt nichts vorwärts. Es kann aber auch vorkommen dass der mittlere Task hängt.

Komplett hängen tut mein System nicht. Aktuell läuft der Test ohne AMD Dienste.

Edit:

Hier ohne die Dienste:
http://abload.de/thumb/11hoobt.png (http://abload.de/image.php?img=11hoobt.png) http://abload.de/thumb/22h9rma.png (http://abload.de/image.php?img=22h9rma.png) http://abload.de/thumb/33n7pe4.png (http://abload.de/image.php?img=33n7pe4.png) http://abload.de/thumb/44hyo1h.png (http://abload.de/image.php?img=44hyo1h.png) http://abload.de/thumb/5553o67.png (http://abload.de/image.php?img=5553o67.png) http://abload.de/thumb/667dogs.png (http://abload.de/image.php?img=667dogs.png) http://abload.de/thumb/77nyqn9.png (http://abload.de/image.php?img=77nyqn9.png)

[Pappenheimer]

ich kann mir vorstellen das es wie folgt ablaufen wird.

nv wird sich was einfallen lassen um dieses problem zu umgehen.

nv ist weiter verbreitet und daher werden die softwarehersteller großteils von sich aus diese funktion nicht nutzen.
nv bringt mit der nächsten oder übernächsten kartengeneration dieses feature raus bis dato werden nur wenige spiele das nutzen. amd wird bei einer handvoll spiele davon profitieren was dann kaum jemand interessiert.

nv neue karten kommen dann auf dem markt und werden wieder wie warme semmeln verkauft weil es das feature schlecht hin ist und alles so super toll und amd wird nichts dabei gewinnen.

[Hübie]

Fairerweise muss man ja auch sagen, dass soviel gewusel wie bei Ashes of Singularity ebenfalls die Ausnahme sind. Zuletzt gesehen bei Planetary Annihilation und Supreme Commander.
Deshalb wird es wohl in der Masse der Spiele untergehen. Ich bin nach wie vor gespannt wie nVidia dazu Stellung bezieht.

[aufkrawall]

Die Masse an Gewusel gibt keinen Aufschluss darüber, wie viel und für was Compute genutzt wird.
Sieht eher nach recht harmlosem PP aus, aber das kann natürlich auch täuschen.

[fondness]

Fairerweise muss man ja auch sagen, dass soviel gewusel wie bei Ashes of Singularity ebenfalls die Ausnahme sind. Zuletzt gesehen bei Planetary Annihilation und Supreme Commander.
Deshalb wird es wohl in der Masse der Spiele untergehen. Ich bin nach wie vor gespannt wie nVidia dazu Stellung bezieht.

Es geht doch gar nicht um Ashes of Singularity, es geht um ein elementares DX12-Feature. Aber sehr leicht durchschaubar, wie du Stück für Stück versuchst das ganze herunter zu spielen.

[BlacKi]

was hat gewusel mit asc zu tun? oxide hat doch geschrieben das asc nur mittelmäßig verwendung in ashes findet. draw call optimierung findet auf beiden herstellern optimal unter dx12 statt. bei nvidia klappt das sogar noch halbwegs in dx11.

in dx12 games wird man einen klaren boost feststellen wenn das spiel stark auf pp effekte setzt und dabei noch asc unterstützt.

[y33H@]

Aber sehr leicht durchschaubar, wie du Stück für Stück versuchst das ganze herunter zu spielen.Immer wieder geil, was hier an Unterstellungen hin und her geht :freak: