Diskussion zu: Hardware- und Nachrichten-Links des 7. April 2017

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-7-april-2017

[Rabiata]

Na klasse. Wieder ein Hersteller mit dem Prädikat "nicht vertrauenswürdig" :mad:. Keine weiteren Worte...

[Iscaran]

Hier ist ebenfalls noch ein Aufschlußreiches video.

Grund für die massiven Performanceverluste von nVidia@DX12 ist vermutlich der Command-list "server" (bzw. "Software Scheduler") der bei nVidia eben auch für die gute Performance unter DXC11 verantwortlich ist.
https://www.youtube.com/watch?v=nIoZB-cnjc0

Das deckt sich auch sehr gut mit schon uralten Beobachtungen zu Kepler vs GCN von ext3h:
Vor allem, aber in Kombination mit den alten Boebachtungen ext3h (Oktober 2015): http://ext3h.makegames.de/DX12_Compute.html

The differences between GCN and Maxwell/Kepler are quite significant, and so is the effect of using the compute engines, respectively multiple queues in general. I will address possible approaches to utilize the platform to full extent or to avoid common misconceptions.

AMD

Compute engines can be used for multiple different purposes on GCN hardware:
Long running compute jobs can be offloaded to a compute queue.
If a job is known to be possibly wasting a lot of time in stalls, it can be outsourced from busy queues. This comes at the benefit of achieving better shader utilization as 3D and compute workload can be interleaved on every level in hardware, from the scheduler down to actual execution on the compute units.
High priority jobs can be scheduled to a dedicated compute queue.
They will go into the next free execution slot on the corresponding ACE. They can not preempt running shaders, but they will skip any queued ones. Make proper use of the priority setting on the compute queue to achieve this behaviour.
Create more back pressure.
By providing additional jobs on a compute engine, the impact of blocking barriers in other queues can be avoided. Barriers or fences placed on other queues are not causing any interference.
GCN is still perfectly happy to accept compute commands in the 3D queue.
There is no penalty for mixing draw calls and compute commands in the 3D queue. In fact, compute commands have approximately the same performance as draw calls with proxy geometry.
Compute commands should still be preferred for any non-geometry related operation for practical reasons, such as utilizing the local shared memory and increasing possible concurrency.
Offloading compute commands to the compute queue is a good chance to increase GPU utilization.


Nvidia

Due to the possible performance penalties from using compute commands concurrently with draw calls, compute queues should mostly be used to offload and execute compute commands in batch.

There are multiple points to consider when doing this:
The workload on a single queue should always be sufficient to fully utilize the GPU.
There is no parallelism between the 3D and the compute engine so you should not try to split workload between regular compute and 3D queues arbitrarily.
Pay close attention not to stall the GPU with solitary compute jobs limited by texture sample rate, memory latency or anything alike. Other queues can't become active as long as such a command is running.
Compute commands should not be scheduled together with draw calls in a single batch.
Doing so will hurt the performance measurably. The reconfiguration of the SMM units will impair performance significantly.
In the worst case, the GPU will even be partitioned inefficiently. This can result e.g. in the SMM units dedicated to graphics to run idle, while the compute shader running in parallel starves due to a lower number of SMM units available.
Make sure to always properly batch both draw calls and compute commands. Avoiding a mixture ensures that all resources are allocated to either type.
Consider the use of a draw call with a proxy geometry instead when batching and offloading is not an option for you. This will still save you a few microseconds as opposed to interleaving a compute command.
Make 3D and compute sections long enough.
Switching SMM units between compute and 3D mode results in a full flush of all pipelines. The GPU should have spent enough time in one mode to justify the penalty for switching.
Beware that there is no active preemption, a long running shader in either engine will stall the transition.


Also wird AMD wie es aussieht in Zukunft unter DX12 mit Ryzen selbst an einem 7700K vorbeiziehen wenn denn alles drauf angepasst ist.

[Gast]

Was soll eigentlich die ewige Angst vor den Telemetriedaten? Eine der wichtigsten Informationen um Fehler zu beheben ist nun mal dass man die genaue Konfiguration des Systems kennt, an welchem diese Fehler auftreten. Fehler die man nicht Reproduzieren kann, kann man nämlich auch nicht beheben. Wenn Fehler nur bei bestimmten Systemkonfigurationen auftreten muss man diese eben kennen um sie intern Reproduzieren und beheben zu können. Im Grunde profitieren also alle von der Übertragung der Telemetriedaten, der Hersteller weil er Fehler mit geringerem Aufwand beheben kann, der Kunde weil Fehler schneller behoben werden können.
Im B2B-Bereich ist es üblich, dass ein direkter Kontakt zwischen Hersteller und Kunden besteht, so dass man auch die Möglichkeit hat sich direkt die Kundenkonfiguration anzusehen. Im B2C-bereich ist das allerdings nicht üblich, also ist es nur logisch dass man hier auf andere technische Möglichkeiten zurückgreift um Fehlerbehebungen möglichst effizient zu gestalten.

Aber anstatt Nvidia zu loben dass man die Telemetrieübertragung nun auf offiziellem Weg auch deaktivieren kann (was zuvor nur durch Deaktivieren der entsprechenden Dienste konnte), bekommen sie eines auf den Deckel. Was für eine verkehrte Welt.

Wenn ihr solche Angst vor einem Unternehmen habt, dass dieses irgendwas böses mit euren Daten anstellt solltet ihr von diesem Unternehmen keinerlei Hard- und Software verwenden. Insbesondere wenn es sich um einen Grafiktreiber mit Kernel-Level-Komponenten handelt kann dieser im Grunde auf all eure Daten zurückgreifen und machen was er will, ohne dass man wirklich eine Chance hat das mitzubekommen.

Wenn Nvidia an eure Daten will um irgendwas damit zu machen kommen sie auch daran, wenn ihr kein Vertrauen habt dass Nvidia das nicht macht, verwendet keine Produkte von ihnen.
Genauso mit Microsoft, Google, Apple oder wer auch immer.

[Gast]

Grund für die massiven Performanceverluste von nVidia@DX12 ist vermutlich der Command-list "server" (bzw. "Software Scheduler") der bei nVidia eben auch für die gute Performance unter DXC11 verantwortlich ist.
https://www.youtube.com/watch?v=nIoZB-cnjc0


Sehr interessant, danke.
Das erklärt allerdings nicht wirklich das Verhalten von Ryzen.
Wenn ich es richtig verstehe schafft es Nvidia un DX11 über die CMD-Lists den Hauptthread eines Spiels zu entlasten und mehr vom gesamten Workload auf weitere Threads zu verlagern, was auch gut funktioniert, so lange die weiteren Threads noch genug Leerlauf haben, aber weniger gut wenn die Gamelogic schon selbst alle Kernde der CPU auslastet.

Dann sollte Ryzen aber noch viel mehr davon profitieren, schließlich hat er mehr Kerne und Threads, also sollte es unwahrscheinlicher sein, dass die Gamelogic selbst schon alle Kerne ausreichend auslastet.

[Eldoran]

Die Performance/Leistungsaufnahme entspricht bis jetzt dem angekündigten - eine Architektur die von Low Power bis High Performance skaliert. Die bisher erhältlichen (Desktop/Workstation) CPUs sind wie zu erwarten am oberen Ende der Kurve angelegt, kurz bevor der Verbrauch rapide zunimmt. Jetzt muss nur noch bewiesen werden, dass das untere Ende auch sinnvoll abgedeckt werden kann.
Einzig das Low Cost Segment ist etwas vakant, schließlich ist das Die nicht gerade klein und auch Raven Ridge wird da kaum besser dastehen. Sofern dort überhaupt noch x86 CPUs einen relevanten Marktanteil haben.

[Botcruscher]

Na klasse. Wieder ein Hersteller mit dem Prädikat "nicht vertrauenswürdig" :mad:. Keine weiteren Worte...

;D
Erlebnisverbesserungsprogramm
;D

Hat doch inzwischen jeder W10 Nutzer. Mit dem nächsten Update wird dann der hier nachgerüstet: Klick (https://www.youtube.com/watch?v=xgy3tIlu5gw&feature=youtu.be&t=45m12s)

Was soll eigentlich die ewige Angst vor den Telemetriedaten?

Weil die gleichen Defizite wie bei allen "Transparenzoffensiven" der Hersteller vorliegen:
1. Opt-In
2. Bericht vor der Übertragung für den Nutzer im Klartext
3. Genaue Definition wann, wie, wo welche Daten erhoben und versendet werden. Telemetrie ist im Moment ein Blanko bei dem sich der Hersteller nach belieben bedienen kann. Im Zweifel bedeutet Telemetrie alles zu jeder Zeit vom gesamten Rechner.

[Gast]

Unter DX12 und 720p ist der NV-Treiber derzeit eine ~30%-Bremse für Ryzen. Das konnte man schon an den ersten Reviews von CB und c't sehen.
https://techreport.com/forums/viewtopic.php?t=119280
https://www.reddit.com/r/Amd/comments/62s11m/german_tech_magazine_ct_did_a_test_with_a_fury_x/
https://www.youtube.com/watch?v=fTJi_gLyXQQ
https://www.youtube.com/watch?v=kmLtww8SMpE

[F4USt]

Wobei ich vermute, dass Techspot sich das Ganze vom Youtuber AdoredTV abgeschaut hat. Ihm gebührt wohl der Dank. Es wird schon seinen Grund haben, warum man beim Techspot ausgerechnet mit Rise of the Tomb Raider anfängt.

Hier zum Video von AdoredTV:
https://www.youtube.com/watch?v=0tfTZjugDeg

Er zeigt zudem sehr eindrucksvoll, dass Benchmarks und das (gewünschte) Ergebnis im selben Spiel sehr szenenabhängig sind. Oder wie er das Verhalten der Redaktionen nennt: "entertaining". Weiterhin, dass es nicht nur ein GPU- oder CPU-bottleneck, sondern auch ein API-bottleneck gibt.

Außerdem mag ich seine Testphilosophie. Nicht einfach nur 20 Sekunden bei nur 1 Szene "mitstoppen", sondern einfach ne Weile mit Mehrfachdurchläufen und verschiedenen Szenen spielen und dann auswerten.

Wer möchte, kann sich auch gerne dort die weiteren Videos zu Ryzen anschauen und stellt vielleicht fest, dass CPU-Benchmarks nur das Jetzt abbilden und nicht die Zukunft. Wie bei Grafikkarten Benchmarks auch.

[DanMan]

Na klasse. Wieder ein Hersteller mit dem Prädikat "nicht vertrauenswürdig" :mad:. Keine weiteren Worte...
Angeblich wurde es schon vor Monaten in den Treiber eingebaut, nur haben sie jetzt wohl auch einen Ausschalter eingebaut....

Ich hatte schon aufgehört Razer Zeug zu kaufen wegen ihrer bescheuerten Synapse Software, die eine Internetverbindung erfordert. Jetzt auch noch Nvidia... Wenn sie es wenigstens vorher bekannt gäben, inkl. der Info was genau alles übertragen wird. Aber so? Nee.... Dick move.

[Mangel76]

Aufgrund dessen, das jener Effekt unter DirectX 11 jedoch nachweislich nicht vorhanden ist, kann man kaum von einer "Bevorzugung" von AMD-Grafiklösungen reden – eher denn ist es eine generelle Optimierung auf DirectX-12-Spiele, welche hier bei beider AMD-Hardware greift.

Echt jetzt? Diese Formulierung suggeriert ja,dass dies AMD-Schuld ist, die bewusst ihre Produkte auf DX12 optimieren. Diese Schweine!;D

Mal im Ernst, dass ist eine vollkommene Verdrehung der Tatsachen und auch der hier geführten Diskussionen. Es ging nie um eine "Bevorzugung von AMD" sondern um ein Problem von Nvidia.

Die RX480 ist jeweils in DX11 und DX12 mit beiden CPUs in etwa gleich auf, es gibt hier keine besonders tolle Optimierung auf den AMD-Prozessor. Sie schneidet im Vergleich zur 1060 in DX12 nur besser ab, was aber auch schon lange bekannt ist. Die 1060 dagegen verliert auf Ryzen mit DX12 sowohl gegenüber DX11 mit Ryzen als auch gegenüber DX12 mit Intel. Der logische Schluss daraus ist also ein Problem von Nvidia bzw. des Treibers mit Ryzen unter DX12 und nicht eine Optimierung von AMD unter DX12!