TEST

AMD Radeon RX 480 im Test - TrueAudio Next und AFR Frame Pacing

Portrait des Authors


Werbung

TrueAudio Next:

AMD führte mit der Hawaii-GPU dedizierte DSPs in der GPU selbst ein, die sich um eine realistischere Berechnung von Audio-Inhalten kümmern sollte. TrueAudio aber konnte sich nicht richtig durchsetzen und wurde trotz Middleware-Unterstützung nur in Thief umgesetzt. War dort aber auch nicht das wichtigsten Argument für und wieder das Spiel. Mit Polaris versucht sich AMD an einem erneuten Anlauf, dieses Mal aber mit etwas anderen Zielvorgaben.

Polaris-Architektur - TrueAudio Next

Polaris-Architektur - TrueAudio Next

Der Ansatz des neuen TrueAudio Next ist dabei dem von NVIDIA mit VRWORKS Audio nicht ganz unähnlich. Die beiden Technologien haben sich aber unabhängig voneinander entwickelt. TrueAudio Next soll dabei auch eine Art Raytracing für Audio darstellen, bei dem mehreren Audioquellen realistisch und mit möglichst vielen Reflektionen dargestellt werden können. Dabei sollen die Berechnung auch von Asyncronous Compute profitieren, denn die dazugehörigen Berechnungen müssen gleichzeitig zu den Grafikberechnungen erfolgen.

Polaris-Architektur - TrueAudio Next

Polaris-Architektur - TrueAudio Next

Um die Aufteilung der Rechenlast nicht allein dem Hardware Scheduler zu überlassen, ermöglicht AMD via Compute Unit Reservation die Zuteilung einer dedizierten Anzahl von CUs zu einem bestimmten Prozess. So können von 36 CUs 28 der Grafikberechnung zugeteilt werden, während acht weitere der Audioberechnung zugeschrieben werden. Dabei sollen vier CUs in etwa die Rechenleistung eines Quad-Core-Prozessors bieten, wenn es um die Auslagerung von Rechenaufgaben geht.

Bereits eine Handvoll Middleware-Hersteller für Audioschnittstellen in Spielen haben ihre Unterstützung für TrueAudio Next angekündigt. Nun wird es aber darauf ankommen, wie viele Spiele letztendlich eine Umsetzung bieten werden und wie groß der Nutzen sein wird. Diese Frage werden wir aber erst in einigen Monaten beantworten können.

Polaris-Architektur - Variable Rate Shading

Polaris-Architektur - Variable Rate Shading

Ähnlich wie NVIDIA sieht auch AMD in der Architektur die Möglichkeit vor, mehrere Viewports gleichzeitig zu berechnen. Bei NVIDIA heißt diese Technik Simultaneous Multi Projection, bei AMD eben Variable Rate Shading. Das Hintergrund der Technik ist identisch, denn in einer VR-Brille muss die gleiche Szene aus dem Blickwinkel zweier Augen berechnet werden.

Während NVIDIA in der Pascal-Architektur bis zu 16 Viewports ermöglicht, sind es bei AMD ebenfalls bis zu 16 und auch hier bleibt der Geometry Shader außen vor und benötigt für 2 bis 16 Viewports nur einen Durchlauf. Variable Rate Shading ist aber nicht neu in der Polaris-Architektur, sondern schon etwas länger im GCN-Design enthalten, wurde bisher nur noch nicht verwendet.

AFR Frame Pacing:

Mit dem Frame Pacing nahm sich AMD einer Problematik an, die gerade im Multi-GPU-Betrieb auftrit und unterschiedliche Frametimes zur Ursache hat. Das Frame Pacing sorgt per Algorithmus dafür, dass Abstände angeglichen werden. Dies funktionierte zunächst aber nur in DirectX-11-Spielen und wurde erst nach und nach in mehreren Phasen ausgerollt. Mit der Polaris-Generation bzw. der neuen Radeon Software ermöglicht AMD auch ein Frame Pacing für DirectX 12 und hier vor allem für den CrossFire-Betrieb.

Polaris-Architektur - CrossFire und AFR Frame PacingPolaris-Architektur - CrossFire und AFR Frame Pacing

Polaris-Architektur - CrossFire und AFR Frame Pacing

Allerdings ist der aktuelle Treiber, mit dem wir die Radeon RX 480 getestet haben, dazu noch nicht in der Lage. In der Renderpipeline wird zur Angleichung der Frametimes eine Verzögerung eingeführt, ähnlich wie dies im Single-GPU-Betrieb auch schon der Fall ist.

Quellen und weitere Links KOMMENTARE (1666) VGWort