DX12: AMD erweitert Asynchronous Compute um Quick Response Queues

35
News Mark Mantel Als bevorzugte Quelle auf Google hinzufügen
AMD erweitert Asynchronous Compute und Quick Response Queues
Quelle: PC Games Hardware

Mit der Radeon Software Crimson 16.3.2 hat AMD mit seine Asynchronous-Compute-Fähigkeiten ausgebaut. Statt Grafik- und Compute-Aufgaben nur parallel laufen zu lassen, können Entwickler die beiden Teile dank Quick Response Queues nun priorisieren. Hilfreich sei es unter anderem für die Asynchronous Time Warps der Oculus Rift.

Für AMD ist Asynchronous Compute eine wichtige Funktion, um seine Shader-Einheiten besser auslasten zu können. Dabei konnten GCN-basierte GPUs bisher Grafik- und Compute-Aufgaben parallel abarbeiten, ohne sie nacheinander berechnen zu müssen. Mit DirectX 12 und Vulkan wird das Ganze nach einigen Jahren auch von den gängigen Spiele-APIs unterstützt, wohingegen DX11 und OpenGL noch stark seriell aufgebaut sind.

Vor wenigen Tagen hat AMD schließlich die Radeon Software Crimson 16.3.2 veröffentlicht, welche die Asynchronous-Compute-Funktionalität weiter ausbaut. Neu sind die Quick Response Queues, dank denen Entwickler wahlweise den Grafik- oder Compute-Berechnungen mehr Hardware-Ressourcen zuteilen können. Hat man sich beispielsweise die Mühe gemacht, die Beleuchtung über Asynchronous Compute zu realisieren, kann man der mehre Compute Units zuweisen, wenn die Szene gerade aufwendiger wird. Anders als bei den Pre-Emptions muss kein Context-Switch durchgeführt und die Grafik-Aufgabe nicht komplett unterbrochen werden. Quick Response Queues funktionieren ab GCN 1.1 (Gen 2). Tahiti, Pitcairn, Cape Verde und Oland werden ausgeschlossen, da AMD erst bei den darauffolgenden GPUs die sogenannten ACEs (Asynchronous Compute Engines) entsprechend ausgebaut hat.

AMD gibt an, dass die Quick Response Queues unter anderem für die Asynchronous Time Warps der Oculus Rift leistungsfördernd seien. Dabei werden zuvor gerenderte Frames mit den aktuellen Positionsdaten des Head-Trackings verrechnet, um Ruckler bei gesunkenen Fps-Raten zu minimieren. Auch Sonys vom Prinzip gleiche Reprojection der Playstation VR dürfte auf diese Funktion setzen. Daniel Baker, als Principal Graphics Architect bei Oxide Games für die Nitrous Engine verantwortlich, geht davon aus, dass man bei GCN-GPUs weitere drei bis fünf Prozent Leistung (im Grafiklimit) dazu gewinnen könnte.

Quelle: AMD (Blog)

Vergleich zwischen Pre-Emption, Asynchronous Compute und Asynchronous Compute mit Quick Response Queues Quelle: AMD Vergleich zwischen Pre-Emption, Asynchronous Compute und Asynchronous Compute mit Quick Response Queues

35

    • Kommentare (35)

      Zur Diskussion im Forum
      • Von IluBabe Volt-Modder(in)
        Zitat von Soulsnap
        Was ich persönlich für gegeben halte, da Pascal bis auf wenige änderungen ein Maxwell Shrink ist (mMn) und AS erst Rummel gemacht hat als Pascal schon längst zu weit war um AS in Hardware noch zu implementieren.
        Die Grafikkartenentwicklung beginnt Jahre bevor Rummel kommt das stimmt, nichts desto trotz ist AS in Entwicklerkreisen sicher nicht erst seit gestern bekannt. Und die Entwicklung von Pascal kann ganz andere Anforderungslisten gehabt haben als nur ein Shrink von Maxwell. Deswegen gucken wenn es soweit ist. Und selbst wenn es nicht dabei wäre. Kurzfristig hats eh nicht so viel Auswirkung. AS wird ja erst durch die Software die es nutzt ausgelastet. Und wie Ashes dem Beispiel nach zeigt, ist das Potenzial von AS zwar von Anfang an da, aber erst mit weiterer Verbesserung des Codes wurde immer mehr rausgeholt. Insofern sind die Benchmarks die wir dann bei Neuerscheinungen sehen, und dem Fall Pascal beherrscht kein Hardware AS, vielleicht nicht mehr aussagekräftig. Erst mit weiteren Patches werden dann ggf. die Leistungsunterschiede offensichtlich werden, den die Zeit zum optimieren hat meist gefehlt, wegen der Einhaltung des Releastermins.
        Zitieren
      • Von IluBabe Volt-Modder(in)
        Zitat von Soulsnap
        Was ich persönlich für gegeben halte, da Pascal bis auf wenige änderungen ein Maxwell Shrink ist (mMn) und AS erst Rummel gemacht hat als Pascal schon längst zu weit war um AS in Hardware noch zu implementieren.
        Die Grafikkartenentwicklung beginnt Jahre bevor Rummel kommt das stimmt, nichts desto trotz ist AS in Entwicklerkreisen sicher nicht erst seit gestern bekannt. Und die Entwicklung von Pascal kann ganz andere Anforderungslisten gehabt haben als nur ein Shrink von Maxwell. Deswegen gucken wenn es soweit ist. Und selbst wenn es nicht dabei wäre. Kurzfristig hats eh nicht so viel Auswirkung. AS wird ja erst durch die Software die es nutzt ausgelastet. Und wie Ashes dem Beispiel nach zeigt, ist das Potenzial von AS zwar von Anfang an da, aber erst mit weiterer Verbesserung des Codes wurde immer mehr rausgeholt. Insofern sind die Benchmarks die wir dann bei Neuerscheinungen sehen, und dem Fall Pascal beherrscht kein Hardware AS, vielleicht nicht mehr aussagekräftig. Erst mit weiteren Patches werden dann ggf. die Leistungsunterschiede offensichtlich werden, den die Zeit zum optimieren hat meist gefehlt, wegen der Einhaltung des Releastermins.
        Zitieren
      • Von Soulsnap Volt-Modder(in)
        Zitat von Atent123
        Nein mit Maxwell.
        Es ging doch um den Fall fallsPascal noch keine ACE ähnlichen Einheiten hatt und deshalb wie Maxwell auf NVIDIAs Software Lösung zurück greifen muss.
        Was ich persönlich für gegeben halte, da Pascal bis auf wenige änderungen ein Maxwell Shrink ist (mMn) und AS erst Rummel gemacht hat als Pascal schon längst zu weit war um AS in Hardware noch zu implementieren.
        Zitieren
      • Von Atent123 Volt-Modder(in)
        Zitat von FunTast1c
        Gleiches Beispiel. Ich würde ja vorher mich nicht zu weit aus dem Fenster lehnen, könnte sonst weh tun.

        Für/mit Pascal? Wann und wo?
        Nein mit Maxwell.
        Es ging doch um den Fall fallsPascal noch keine ACE ähnlichen Einheiten hatt und deshalb wie Maxwell auf NVIDIAs Software Lösung zurück greifen muss.
        Zitieren
      • Von FunTast1c
        Zitat von Soulsnap
        Wer redet hier von Fermi und Tesselation ?
        Gleiches Beispiel. Ich würde ja vorher mich nicht zu weit aus dem Fenster lehnen, könnte sonst weh tun.

        Zitat von Atent123
        NVIDIA hat doch schon die Performance ihrer Software Lösung gezeigt.
        Für/mit Pascal? Wann und wo?
        Zitieren
      • Von Atent123 Volt-Modder(in)
        Zitat von FunTast1c
        So wie Fermi ja auch Tessellation nur in Software könnte und da AMD Kreise um sie drehen würden?
        NVIDIA hat doch schon die Performance ihrer Software Lösung gezeigt.
        Sie haben sie später wieder deaktiviert weil sie die Leistung verschlechtert hat.
        Zitieren
      Direkt zum Diskussionsende
Hoch
  • Print / Abo
    Apps
    PCGH Magazin 08/2026 PC Games 08/2026 play5 08/2026 N-Zone 08/2026 Linux Magazin 08/2026 LinuxUser 08/2026 Raspberry Pi Geek 09/2026
    PC Games Hardware PC Games Linux Magazin Raspberry Pi Geek Computec Kiosk