Adrenalin 2020 Edition 20.5.1 bringt das GPU-Scheduling

Thread Starter
Mitglied seit
06.03.2017
Beiträge
113.960
radeonsoftware2019.jpg
Nachdem NVIDIA mit dem GeForce 451.48 bereits einen Treiber mit der Unterstützung von GPU-Scheduling veröffentlicht hat, zieht AMD nun mit dem Radeon Software Adrenalin 2020 Edition 20.5.1 nach. Es handelt sich noch um einen Beta-Treiber, daher ist die Funktionserweiterung um das GPU-Scheduling auch die einzige Neuerung in dieser Version.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Bessere GPU Auslastung, schnellere Funktionen, etwas mehr Performance (durch weniger Overhead) und wenn RDNA2 endlich landet, werden die RT-Coder sich auch drüber freuen. (Zu mindest theoretisch - bisher haben einige Leute vom grünen Team von Regressionen in der Performance geschrieben, entsprechend kann es auch bei AMD erstmal zu Einbußen kommen - deshalb sollte etwas getestet werden)
 
Hört sich gut an, vielleicht macht es Sinn, mal wieder einen Artikel oder Test über die Performance Besserungen zu bringen. :)
 
Bessere GPU Auslastung, schnellere Funktionen, etwas mehr Performance (durch weniger Overhead) und wenn RDNA2 endlich landet, werden die RT-Coder sich auch drüber freuen. (Zu mindest theoretisch - bisher haben einige Leute vom grünen Team von Regressionen in der Performance geschrieben, entsprechend kann es auch bei AMD erstmal zu Einbußen kommen - deshalb sollte etwas getestet werden)
Als wenn RDN2 irgendetwas damit zu tun hat, der Betatreiber hier hat noch nicht mal WHQL und du palaberst von RT Coding :sleep:. Das Feature ist kein direkter Teil von DirectX sondern Windows und hat per se gar nichts mit RT am Hut.

Regression in Performance ist auch Non-Sens, eher reduzierte Latenz dadurch können die Durchschnitts FPS abnehmen so hat es Nvidia kommuniziert.
Daher sollte man nach Möglichkeit testen, um sich der Gaming-Community würdig zu erweisen. Aktuell auch viele Triple A Titel inklusive Vulkan im Angebot. Wobei ich auch kein Vulkan 1.2 Update erkennen kann, was sagt Holzmann dazu ?
 
Als Frau würde ich dazu sagen: Männer Sache. :d
 
"Radeon RX Vega series graphics products may experience a system crash or TDR when performing multiple task switches using Alt+Tab. "

Ist das jetzt ein bekanntes Problem des Treibers, oder ein behobenes dieses Treibers?
Seit dem letzten Treiber habe ich dieses Problem..., habe es fleissig gemeldet. Daher die Frage: Wurde der nun nur zur Kenntnis genommen, oder angepackt?

Sowohl der englishe als auch der deutsche Text sind in dieser Hinsicht nicht hilfreich.
 
Sind das deine Testgraphen Carnage, oder was soll das sein 🤪 ?

"Radeon RX Vega series graphics products may experience a system crash or TDR when performing multiple task switches using Alt+Tab. "

Ist das jetzt ein bekanntes Problem des Treibers, oder ein behobenes dieses Treibers?
Seit dem letzten Treiber habe ich dieses Problem..., habe es fleissig gemeldet. Daher die Frage: Wurde der nun nur zur Kenntnis genommen, oder angepackt?

Sowohl der englishe als auch der deutsche Text sind in dieser Hinsicht nicht hilfreich.
"Bekannte Probleme dieser Treiberversion sind;" ;). Klingt auch stark nach GPU Scheduling Nebenwirkung und Fullsizeoptimization. Wenn du Probleme damit hast kannst du das bei der exe datei der Anwendung deaktivieren bzw. deaktivieren, dadurch wechselst du etwas langsamer hast aber evlt. keinen Abkacker.
 
bisher haben einige Leute vom grünen Team von Regressionen in der Performance geschrieben, entsprechend kann es auch bei AMD erstmal zu Einbußen kommen

Hintergund wird dafür sein, daß der Treiber bei seinem Ressourcenmgt. sehr allgemeine Annahmen treffen muss, während die Applikation sehr wohl weiß, ob sich z.b. das Leeren des Speichers bereits lohnt oder ob Elemente später doch nochmal gebraucht werden.
Von daher wird der Treiber wohl nur Vorteile bringen, wenn
a) die Applikation die Ressourcen mehr schlecht als recht verwaltet
b) oder mehrere Applikationen sich um die Ressourcen streiten, die einzelne App also nicht alle Parameter kennt, der Treiber hingegen schon.

Eine BenchmarkApp wird sicherlich ein gescheites Ressourcenmgt. beherrschen. Wenn das Scheduling des Treibers dieses überschreibt, kann man eigentlich nur schlechtere Werte erzeugen.
Um z.B. mal b) zu testen, müsste man mehrere Benchmarks gleichzeitig laufen lassen. Deren Gesamtleistung sollte mit Scheduling besser ausfallen.
 
Zuletzt bearbeitet:
Diese Version ist schon neu, sie trägt das Datum vom 24.06.

@Don
Wär das ok. wenn ihr damit mal einen Test machen könnt, einen Performance Vergleich zu einer älteren Version? :)
 
Ich habe mir beim NVIDIA-Treiber schon das GPU-Scheduling angeschaut und konnte keine Veränderung in der Leistung feststellen, die außerhalb der Messtolleranz gelegen hätte. Es mag hier Extremfälle geben, in denen der Unterschied größer ist, so im Alltag aber merkt man nichts davon. Ob das bei AMD anders aussieht, kann ich aber noch nicht sagen.
 
Als wenn RDN2 irgendetwas damit zu tun hat, der Betatreiber hier hat noch nicht mal WHQL und du palaberst von RT Coding :sleep:. Das Feature ist kein direkter Teil von DirectX sondern Windows und hat per se gar nichts mit RT am Hut.
Aha - so wie Chipsatztreiber auch keinen Einfluss auf die CPU-Performance haben, ja?

Dann erklär mir doch mal bitte, warum nicht. Denn laut PCGH:

Hardware-accelerated GPU scheduling: It allows the video card to directly manage its video memory, which in turn significantly improves the performance of the minimum and average FPS, and thereby reducing latency. It works regardless of the API used for games and applications such as DirectX / Vulkan / OpenGL.
Quelle

RT funktioniert bei AMD über die Shader, was die Performance von RT nicht nur von der Shaderanzahl, sondern auch von der Speicherbandbreite und der Latenz abhängig macht:
Der BVH-Algorithmus benötigt einen guten Zugriff auf Cache und VRAM bei hoher Bandbreite.
Quelle

Regression in Performance ist auch Non-Sens, eher reduzierte Latenz dadurch können die Durchschnitts FPS abnehmen so hat es Nvidia kommuniziert.
Zu erst einmal bedeutet eine reduzierte Latenz eine Verbesserung und keine Verschlechterung und des Weiteren bezichnet der Begriff der Regression einen Rückschritt - was bei der Performancebetrachtung auch diesen Begriff erfüllt. Ob du nun min-FPS, Durchschnitt oder Maximum nimmst, spielt dabei keine Rolle.

Daher sollte man nach Möglichkeit testen, um sich der Gaming-Community würdig zu erweisen.
Wieso nur gaming? Auch Compute-Aufgaben könnten davon profitieren. Schließlich gibt es auch dort speicherintensive Anwendungen.

Ob das bei AMD anders aussieht, kann ich aber noch nicht sagen.
Vorschlag: Spiele nehmen, wo man so halbwegs sieht, dass die mit dem Speicher gut skalieren. Dort den A/B Vergleich machen und evtl. sieht man dort dann kleine Unterschiede, so dass dann zu mindest eine Tendenz abzulesen ist.

Eine BenchmarkApp wird sicherlich ein gescheites Ressourcenmgt. beherrschen. Wenn das Scheduling des Treibers dieses überschreibt, kann man eigentlich nur schlechtere Werte erzeugen.
Um z.B. mal b) zu testen, müsste man mehrere Benchmarks gleichzeitig laufen lassen. Deren Gesamtleistung sollte mit Scheduling besser ausfallen.
Klingt logisch. Oder Anwendungen, die mehrere Rendering-Instanzen haben?
 
Zuletzt bearbeitet:
du palaberst von RT Coding.
unsachlich und unangebracht

Regression in Performance ist auch Non-Sens, eher reduzierte Latenz dadurch können die Durchschnitts FPS abnehmen so hat es Nvidia kommuniziert.
Zu erst einmal bedeutet eine reduzierte Latenz eine Verbesserung und keine Verschlechterung und des Weiteren bezichnet der Begriff der Regression einen Rückschritt - was bei der Performancebetrachtung auch diesen Begriff erfüllt. Ob du nun min-FPS, Durchschnitt oder Maximum nimmst, spielt dabei keine Rolle.
jap :-)

Oder Anwendungen, die mehrere Rendering-Instanzen haben?
Vermutlich nicht, denn sobald der Instanzmanager alle Instanzen kennt, wird er wieder selbst am besten wissen, was seine Schäfchen wann brauchen.
 
Zuletzt bearbeitet:
Über Tests was dies bringt, mit genauen Messungen bei beiden Fraktionen, würde ich mir sehr freuen!
Ist schon wer bei HWL dran?
 
unsachlich und unangebracht
Das lass mal meine Sorge sein. In welchem Zusammenhang steht denn AMD's "RT-Coding" mit dem GPU-Scheduler aktuell, in gar keinem. Der hat auch leider kein WHQL Zertifikat von MS erhalten und meint "die Devs" würden sich vor Freude überschlagen bei der Treiberarbeit seitens AMD, ist doch cringe.

Aha - so wie Chipsatztreiber auch keinen Einfluss auf die CPU-Performance haben, ja?

Dann erklär mir doch mal bitte, warum nicht. Denn laut PCGH:
Treiber jeglicher Art können logischerweise Einfluss auf alles Mögliche haben, was soll das für eine Argumentation sein.
Hat aber mit dem GPU-Scheduling per nichts zu tun, wenn du den PCGH Artikel gelesen hättest wärst du aufgeklärt.
RT funktioniert bei AMD über die Shader, was die Performance von RT nicht nur von der Shaderanzahl, sondern auch von der Speicherbandbreite und der Latenz abhängig macht:
Quelle
"Ob AMDs Lösung tatsächlich so wie hier beschrieben aussieht und ob die Konsolen eine abweichende Lösung erhalten, wird sich im Laufe dieses Jahres zeigen".

Man weiß explizit gar nicht wie genau das aussehen wird, geschweige denn wie oder ob der GPU Scheduler darauf Einfluss nehmen wird. Er ist kein direkter Teil von DXR, DirectX12 Ultimate oder Vulkan. Der Dienst für die Druckerwarteschlange ist auch kein Teil von Raytracing.

Zu erst einmal bedeutet eine reduzierte Latenz eine Verbesserung und keine Verschlechterung und des Weiteren bezichnet der Begriff der Regression einen Rückschritt - was bei der Performancebetrachtung auch diesen Begriff erfüllt. Ob du nun min-FPS, Durchschnitt oder Maximum nimmst, spielt dabei keine Rolle.
Dein Zitat; "bisher haben einige Leute vom grünen Team von Regressionen in der Performance geschrieben "

Das ist per se falsch, entweder kannst du kein Englisch oder fehlinterpretierst mal wieder absichtlich Aussagen anderer. Team Grün hat es so kommuniziert wie es im Release steht; "This new feature can potentially improve performance and reduce latency by allowing the video card to directly manage its own memory. "

Wieso nur gaming? Auch Compute-Aufgaben könnten davon profitieren. Schließlich gibt es auch dort speicherintensive Anwendungen.
Wieder whataboutism, natürlich auch Open-CL, jedoch ist teils die Radeon VII ausgeschlossen usw. und man wird den Fokus auf Engine Flags gelegt haben bzw. auf Echtzeit-Anwendungen im Spieletreiber daher der Name Radeon Software.
 
Das lass mal meine Sorge sein. In welchem Zusammenhang steht denn AMD's "RT-Coding" mit dem GPU-Scheduler aktuell, in gar keinem.
Siehe beide Quellen. GPU Scheduling kann die Latenz reduzieren, welche AMDs RT-Performance beeinflusst. Wie stark, werden die Benchmarks zeigen.

Der hat auch leider kein WHQL Zertifikat von MS erhalten
DAS ist jetzt Whataboutism

und meint "die Devs" würden sich vor Freude überschlagen bei der Treiberarbeit seitens AMD, ist doch cringe.
Bist du Dev?

Treiber jeglicher Art können logischerweise Einfluss auf alles Mögliche haben, was soll das für eine Argumentation sein.
Zwei Sätze vorher hast du noch was anderes behauptet.

Hat aber mit dem GPU-Scheduling per nichts zu tun, wenn du den PCGH Artikel gelesen hättest wärst du aufgeklärt.
Dann empfehle ich dir, den Artikel nochmals zu lesen, vielleicht verstehst du ihn dann.


"Ob AMDs Lösung tatsächlich so wie hier beschrieben aussieht und ob die Konsolen eine abweichende Lösung erhalten, wird sich im Laufe dieses Jahres zeigen".

Man weiß explizit gar nicht wie genau das aussehen wird, geschweige denn wie oder ob der GPU Scheduler darauf Einfluss nehmen wird. Er ist kein direkter Teil von DXR, DirectX12 Ultimate oder Vulkan. Der Dienst für die Druckerwarteschlange ist auch kein Teil von Raytracing.
Es ist zwar schade, dass du es nicht verstehst, aber nicht mein Problem. Nochmal für dich: GPU-Scheduling kann die Speicherbandbreite erhöhen und die Latenz reduzieren. Die RT-Performance ist bei AMD von beiden abhängig.


Dein Zitat; "bisher haben einige Leute vom grünen Team von Regressionen in der Performance geschrieben "

Das ist per se falsch, entweder kannst du kein Englisch oder fehlinterpretierst mal wieder absichtlich Aussagen anderer. Team Grün hat es so kommuniziert wie es im Release steht; "This new feature can potentially improve performance and reduce latency by allowing the video card to directly manage its own memory. "

Ich zitiere mal, was du selbst geschrieben hast:
Regression in Performance ist auch Non-Sens, eher reduzierte Latenz dadurch können die Durchschnitts FPS abnehmen so hat es Nvidia kommuniziert.
Bei einer Reduktion der Latenz steigen die FPS. Des Weiteren wurde bereits von Regressionen berichtet - sogar hier im Forum:
Quelle
Entsprechend haben sich Leute über die Ursache dieser gewundert und auch fleißig diskutiert - wie es in einem Forum nun einmal so ist.

Wieder whataboutism, natürlich auch Open-CL, jedoch ist teils die Radeon VII ausgeschlossen usw. und man wird den Fokus auf Engine Flags gelegt haben bzw. auf Echtzeit-Anwendungen im Spieletreiber daher der Name Radeon Software.
Ich geb dir mal die Definition von Whataboutism, damit du sie wenigstens einmal gelesen hast:
Code:
Whataboutism bezeichnet heute allgemein eine Technik der Manipulation, durch die von unliebsamer Kritik abgelenkt wird, indem auf ähnliche oder andere wirkliche oder vermeintliche Missstände auf der Seite des Kritikers hingewiesen wird.

Zu erst einmal gab es am Anfang keine Kritik, sondern es wurde eine Frage gestellt. Die hier:
Wieso nur gaming?
Und in einem Diskussionsforum dürfen alle Leute miteinander diskutieren, auch wenn du die Leute nicht ausstehen kannst.

:)
 
Siehe beide Quellen. GPU Scheduling kann die Latenz reduzieren, welche AMDs RT-Performance beeinflusst. Wie stark, werden die Benchmarks zeigen.
Whataboutism. Was in Zukunft ist kann noch keiner sagen, Benchmarks bezüglich RT und AMD gibt es schon.

DAS ist jetzt Whataboutism
Ja. Im Prinzip jeder 2. Post inklusive Polemik.


Nein, die fahren ganz andere Builds. Ein Build ohne WHQL hat die Prüfung seitens MS allerdings nicht bestanden was halt nicht dafür spricht das AMD besonders weit sei bezüglich Treiberarbeit, theoretisch.


Es ist zwar schade, dass du es nicht verstehst, aber nicht mein Problem. Nochmal für dich: GPU-Scheduling kann die Speicherbandbreite erhöhen und die Latenz reduzieren. Die RT-Performance ist bei AMD von beiden abhängig.
Hab ich schon verstanden, hat aber aktuell nichts mit RT zu tun Konsolen oder Nvidia, um ehrlich sein macht gar nichts was du geschrieben hast Sinn.

Den Speicherdurchsatz weiter zu steigern wird auch für die Raytracing nützlich sein welches AMD bringt.
Dein RT Gesülze suggeriert aber noch das es nicht für alle etwas bringen könnte, es hat per se wie dreimal schon geschrieben nichts mit RT zu tun, du erzählst einfach Schwachsinn der intelligent klingen soll.

Bei einer Reduktion der Latenz steigen die FPS. Des Weiteren wurde bereits von Regressionen berichtet - sogar hier im Forum:
Quelle
Entsprechend haben sich Leute über die Ursache dieser gewundert und auch fleißig diskutiert - wie es in einem Forum nun einmal so ist.

Sogar hier im Forum ;D, das wäre aber nicht Team Green. Wobei du bei beidem nichts dazu gelernt hast.

Das sind avg.FPS bzw. hochgerechnete Frametimes die meist auch in MS angegeben oder mit Graphen dargestellt werden, du weißt gar nicht was mit Latenz gemeint ist.
Im Lowlatency Mode wird die RenderQ verändert, Anti Lag bei AMD genannt. Dadurch nimmt die Signal bzw. Eingabeverzögerung ab, das geht immer auf Kosten der FPS, das ist bei Nvidias Statement mit Latenz gemeint, nicht Frametimes.

Selbiges wird beim GPU-Scheduling auftreten können, besserer Auslastung und Geschwindkeit in dem man der GPU weitere Aufgaben überträgt inklusive Speichermanagment, viele gute Lowlevel API Spiele die keine starke Treiber Limitierung haben inklusive Forza machen das aber wahrscheinlich schon so gut das dies zumindest aktuell keinen Effekt hat.

Ich geb dir mal die Definition von Whataboutism, damit du sie wenigstens einmal gelesen hast:

Whataboutism bezeichnet heute allgemein eine Technik der Manipulation, durch die von unliebsamer Kritik abgelenkt wird, indem auf ähnliche oder andere wirkliche oder vermeintliche Missstände auf der Seite des Kritikers hingewiesen wird.

Zu erst einmal gab es am Anfang keine Kritik, sondern es wurde eine Frage gestellt. Die hier:
Und in einem Diskussionsforum dürfen alle Leute miteinander diskutieren, auch wenn du die Leute nicht ausstehen kannst.

Du kannst gar nicht diskutieren leider :rolleyes: und hast mit 2 Seiten Whaboutism und Polemik eben auf meine Kritik reagiert, da du völlig Off Topic von RDNA2 Landungen, "RT Coding" bezüglich Developer usw. philosophiert hast, die weder mit dem Feature bzw. dem Treiberpacket in irgendeiner Form etwas zu tun haben.
 
Zuletzt bearbeitet:
:coffee: Leistungssteigerungen im Messtoleranzbereich und dafür wieder Bugs wo man wieder Lichtjahre auf Behebung warten kann .... lassen wir den Käse mal in Ruhe reifen und beachten wir ihn nicht bis er Windows Standardeinstellung wird.
 
Nein, die fahren ganz andere Builds. Ein Build ohne WHQL hat die Prüfung seitens MS allerdings nicht bestanden was halt nicht dafür spricht das AMD besonders weit sei bezüglich Treiberarbeit, theoretisch.

Das der Treiber kein WHQL-Zertifikat hat, bedeutet erst mal nicht, dass er den Test nicht bestanden hat und damit auch nicht, dass der Treiber nicht i.O. ist. Es kann genau so bedeuten, dass AMD den Treiber einfach nicht zur Prüfung vorgelegt hat. Das AMD nicht jeden Treiber zertifizieren läßt, sollte hinlänglich bekannt sein. Wenn sie nicht mit WHQL gekennzeichnet sind, werden dies mit Optional oder z.T. als Beta statt mit Recommended (WHQL) bezeichnet. Das der 20.5.1 sowohl als Optional als auch Beta vorliegt ist allerdings etwas suboptimal.
Einfach aus der fehlenden WHQL-Zertifizierung zu schliessen, dass AMD bei dem Treiber nicht besonders weit sei, ohne den Grund für das Fehlen des Zertifikats zu kennen, ist blödsinn. Oder hast Du eine seriöse Quelle, die belegt, dass der Treiber vorgelegt und durchgefallen ist?

Cunhell
 
Gibt es irgendwo eine Liste von unterstützter Hardware? Denn bei mir ist der Button "Hardwarebeschleunigte GPU-Planung" nicht vorhanden. System: Win 10 2004, letzter besagter Radeon-Treiber, Radeon Fury X.
 
Gibt es irgendwo eine Liste von unterstützter Hardware? Denn bei mir ist der Button "Hardwarebeschleunigte GPU-Planung" nicht vorhanden. System: Win 10 2004, letzter besagter Radeon-Treiber, Radeon Fury X.
AMD beschränkt die Unterstützung des GPU-Scheduling auf die Grafikkarten mit Navi-10-GPU – also die Modelle der Radeon-RX-5700- und Radeon-RX-5600-Serie.

LG
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh