Copy&Paste war noch nie schöner:
KurosSmurai117: " Andererseits würde es aber ja bedeuten dass man Programme ja an diese Arbeitsweise anpassen kann wodurch die Grünen gewinnen. Ist irgendwo geregelt wie man AC genau zu nutzen hat? Wenn nicht bleicht es doch den Entwicklern überlassen auf welche Architektur sie sich einschießen. Wer scheibt denn vor dass man AC dann nur exakt auf GCN zuschneiden darf? Wie gesagt falls es da keine Reglung gibt."
Nein, der Vorwurf ist haltlos und das ist nicht das erste mal das Mahigans falsche Ausführungen eine Hysterie auslösen.
Das hier ist der öffentlich dokumentierte Abschnitt zu Multiengine:
Synchronization and Multi-Engine (Windows)
Man definiert hier welchen Queue-Typen man haben möchte, GFX, Compute oder Copy und fühlt diese dann mit den entsprechenden Befehlslisten auf.
Ein Synchronisationsmechanismus wird verwendet um im Programmverlauf anzugeben, ab wann die zusätzlichen Queues zum Einsatz kommen und ab wann sie beendet werden.
Es gibt noch die Möglichkeit die Priorität anzugeben, falls bestimmte Berechnungen und ihre Ergebnisse früher gewünscht sind.
Das ist auch schon praktisch das ganze Software-Konstrukt, dass einem allerdings keine Garantie darüber gibt, ob die Hardware die Anweisung genau so konsumiert wie man sich das vorstellt, da die Spezifikation in der Hinsicht der Hardware nichts vorschreibt.
Die Hardware könnte die Queues parallel bearbeiten, sie könnte allerdings auch das ganze nacheinander forcieren, die Hardware kann auf die angegebene Priorität achten, sie kann das aber auch ignorieren.
Der Knackpunkt ist einfach das dies eine Software-Abstraktion ist, die unter jeder Hardware funktionieren muss, aber keine Vorschriften darüber macht wie genau.
Als Entwickler muss man sich deswegen bezüglich der Hardware erkundigen und Testläufe unternehmen, ob der Programmcode auch in der Praxis effizient ausgeführt wird.
Der 3D Mark verwendet hier den absolut gleichen Mechanismus wie alle anderen Entwickler bei ihren DX12 Anwendungen auch.
Der Vorwurf hier würde gar nicht Async Compute verwendet werden, ist einfach falsch.
Was man sowieso bei der ganzen Async Compute Geschichte haben möchte, ist eine Überlagerung von Aufgabenbereichen die unterschiedliche Hardwareblöcke auslasten.
Z.B. bei Shadow-Maps drehen die ALUs häufig Däumchen, hier könnte die Hardware dank einer zusätzlichen Compute-Queue parallel noch Compute-Shader durch die ALUs berechnen lassen.
Daraus folgt dann ein effektiver Gewinn der Performance, man möchte natürlich nicht Aufgaben mixen welche die selben Flaschenhälse haben.
Und die Time Spy Demo hat das erfolgreich umgesetzt, für AMD und sogar Nvidia:
3DMark Time Spy mit DirectX 12 im Benchmark (Seite 2) - ComputerBase
9-17% Gewinn für die Radeons, bei Ashes of the Singularity sind es ein paar % weniger, bei Hitman gibt der Entwickler 5-10% an.
Da muss es erst einmal ein Spiel geben was auch bei den Radeons bessere Resultate hervorbringt.
bonesai: "Theoretisch wäre es vorstellbar das man das ganze in einem Benchmark so hindreht das man den Compute Pipes von Pascal genügend Möglichkeit gibt um die Grafik und Computing Aufgaben seperat voneinander "besser" zu erledigen und zu profitieren. Das wäre dann natürlich eine Verfälschung da man so etwas nur in einem fix definierten Szenario umsetzen koennte und in einem Game wohl eher so nicht machbar ist... Also in der Praxis dann wohl wertlos.[...]"
Ohne den Programmcode zu kennen ist es natürlich nur eine Spekulation, ob Spiele ihre Pipelines genau so designen könnten oder nicht.
Ganz klar muss man sagen, dass jeder Entwickler das anders umsetzen könnte, die Time Spy Demo kann vom Code niemals eine allgemeine Referenz für alle Anwendungen sein.
Diese Erkenntnis ist aber nichts neues, man sollte die Ergebnisse immer als das betrachten was sie sind, Ergebnisse für eine einzige Anwendung.
Man kann keine App schreiben die 100% Herstellerneutral ist und die optimale Vergleichsbasis bietet, sowohl für die Hardware, als auch die Software.
Forenlink:
http://extreme.pcgameshardware.de/news-kommentare-zu-tools-anwendungen-sicherheit/446034-3d-mark-time-spy-d3d12-benchmark-veroeffentlicht-gtx-1070-1080-mit-zuwaechsen-durch-async-compute-15.html#post8343774
------------------------------------------------------------
Freiheraus: "Da bestätig ein 3DMark-Entwickler in der ersten Stellungnahme, dass Nvidia im Treiber Async Compute für Maxwell explizit deaktiviert hat und dann wird das im Update nicht mal in einem Nebensatz erwähnt. Halte das für ein wichtiges Detail, weil das die Spekulationen beendet, weshalb Maxwell in Time Spy weder Leistung verliert noch zugewinnt."
Nvidia hat es sehr wahrscheinlich für jede Applikation deaktiviert.
Wirklich interessant wäre es zu wissen wie der Treiber es genau handhabt?
Multiengine gibt Synchronisationspunkte vor, ich weiß nicht ob es sicher ist immer alle zu ignorieren.
Abhängig davon wie viele Sync-Punkte es gibt und welche Aufgaben in der Compute-Queue ausgeführt werden sollten, könnten sich messbare bis gar keine Verluste bei Nvidia einstellen.
Ashes of the Singularity ist leider das einzige Spiel, wo man explizit Async on/off testen kann und die Messschwankungen scheinen etwas höher als normal zu sein.
Jedenfalls hat CB teilweise bis zu 10% Verlust gemessen, im Schnitt lag der Unterschied aber bei unter 3%, egal ob Kepler oder Maxwell.
Ashes of the Singularity DirectX-12-Leistungsexplosion (Seite 3) - ComputerBase
KuroSamurai117: " Also ist es letzten Endes eine Entwicklersache wie er es umsetzt und auf die jeweilige Hardware anpasst."
Wie halt immer, egal ob Tessellation, Pixel-Shader, Geometry-Shader oder Compute-Shader.
Die Hardware unterscheidet sich bezüglich der Fixed-Function-Pipelines, der Effizienz, der Cache- und Register-Größen, der Thread-Group-Size.
Alles hat Auswirkungen darauf wie effizient die Hardware etwas konsumiert, der Software-Mechanismus ist immer der gleiche, aber wie es unter der Haube abläuft ist unterschiedlich und da das starke Auswirkungen haben kann, muss man immer schauen wieso Hardware X schlechter oder besser performt als Hardware Y.
Async Compute stellt dabei keinen Unterschied dar.
Forenlink:
http://extreme.pcgameshardware.de/news-kommentare-zu-tools-anwendungen-sicherheit/446034-3d-mark-time-spy-d3d12-benchmark-veroeffentlicht-gtx-1070-1080-mit-zuwaechsen-durch-async-compute-16.html#post8343897
------------------------------------------------------------
Man lernt schließlich nie aus:
http://s3.amazonaws.com/download-aws.futuremark.com/3DMark_Technical_Guide.pdf
Futuremark hat eine nette Dokumentation bezüglicher ihrer Benchmarks, viele Details wie Compute-Shader Aufrufe, Tessellation-Patches, verwendete Ressourcen und ihre Formate sind dokumentiert.
Auch wie und wo der Time Spy Benchmark Async Compute verwendet:
Seite 28 schrieb:
Asynchronous compute is utilized heavily to overlap multiple rendering passes for maximum utilization of the GPU. Async compute workload per frame varies between 10-20%.
Seite 30 schrieb:
Lighting is evaluated using a tiled method in multiple separate passes.
Before the main illumination passes, asynchronous compute shaders are used to cull lights, evaluate illumination from prebaked environment reflections, computescreen-space ambient occlusion, and calculate unshadowed surface illumination.
These tasks are started right after G-buffer rendering has finished and are executed alongside shadow rendering. All frustum lights, omni-lights and reflection capture probes are culled to small tiles (16x16 pixels) and written to an intermediate buffer.
Seite 31 schrieb:
Particles are simulated on the GPU using asynchronous compute queue.
Simulation work is submitted to the asynchronous queue while G-buffer and shadow map rendering commands are submitted to the main command queue.
Futuremark verwendet Async Compute für keinen unorthodoxen Fall, sie überlappen Aufgaben die genau so als Beispiel für Async-Compute genannt werden, Shadow-Map-Rendering + Compute-Shader Berechnungen wie Lightning, Post-Processing, Physics etc.
http://image.slidesharecdn.com/hode...directx12-and-vulkan-23-638.jpg?cb=1440081531
Ein BF4-Beispiel von DICE:
http://image.slidesharecdn.com/rend...efield-4-with-mantle-42-638.jpg?cb=1395313870
Mich macht das "DX11-Feature-Level" auch etwas stutzig, aber ich hoffe dass zumindest echtes Multithreading genutzt wird, vergleichbar zu Mantle-, DX12- und Vulkan-Games wo eindeutig der CPU-Overhead reduziert wird.
Weiß jemand wie stark der Tessellation-Faktor im Time Spy eigentlich ist? Ab 32x hat denke ich selbst eine RX 480 das deutliche Nachsehen gegenüber Nvidia-Modellen. Was wäre `hier also ein guter Kompromiss um keine Hersteller in die Karten zu spielen, Faktor 16x?
Es gibt kein DX11 Feature-Level, es gibt ein Feature-Level 11 unter DX11 und auch unter DX12.
DX12 bietet vier Feature-Levels an, 11.0, 11.1, 12.0 und 12.1
Das Feature-Level 11 ist zwischen DX11 und DX12 fast identisch, aber das Feature-Level schließt nicht die gesamte API mit ein.
Feature-Level unabhängig ist unter DX12 immer die explizite Speicherverwaltung vom Entwickler, die Möglichkeit Command-Buffer vom jeden CPU-Thread zu befüllen ( Multithreading) und Multiengine was in den Foren meistens als Async Compute bezeichnet wird, daneben noch paar andere Dinge wie ExecuteIndirect, womit die GPU sich teilweise selber füttern kann und nicht immer auf einen CPU-Aufruf angewiesen ist.
Time Spy verwendet Tess x32 als Standard.
Die Performance für Radeons ist aber weiterhin völlig in Ordnung, wenn man sich ein paar Resultate von Computerbase anschaut, da säuft niemand im zweiten Testablauf ab, wo wesentlich mehr Tess-Patches verwendet werden:
https://www.computerbase.de/2016-07/3dmark-time-spy-dx12-benchmark/3/
Radeons haben einen relativ schlechten Tess-Durchsatz bei höheren Faktoren, aber das ist nicht das einzige was die Performance manchmal abstürzen lässt.
Wenn man dank Tessellation hunderte Dreiecke hat, wo es pro Dreieck nur wenige Pixel gibt (1-5), dann sinkt der Durchsatz für die Szene dramatisch, da anstatt 16 Pixel pro Zyklus der Rasterizer sich mit 1-5 aufhalten muss.
Ein hoher Tessellation-Faktor ist nicht automatisch "böse", es kommt auch darauf an auf welche Fläche man ihn anwendet und wie viele Pixel dann pro Dreieck noch effektiv verfügbar sind.
Futuremark dokumentiert ebenso ihren Tessellation-Einsatz und das liest sich wie eine gute Implementierung und ist dank der Benchmarks auch wirklich ersichtlich:
Tessellation
The engine supports Phong tessellation and displacement-map-based detail tessellation.
Tessellation factors are adjusted to achieve the desired edge length for the output geometry on the render target (G-buffer, shadow map or other).
Additionally, patches that are back-facing and patches that are outside of the view frustum are culled by setting the tessellation factor to zero.
Tessellation is turned entirely off by disabling hull and domain shaders when the size of an object’s bounding box on the render target drops below a given threshold.
If an object has several geometry LODs, tessellation is used on the most detailed LOD.
es bleibt spannend....
