ACO - Das neue Compiler-Backend für RADV

[danarcho]

Hi,
da ich gefragt wurde, ob ich nicht ein bisschen über die Entwicklung des Compilers reden möchte, habe ich mir gedacht, ich mache mal einen neuen Thread dazu auf.
So habe ich den Kram einigermaßen gebündelt, und werde versuchen auf Fragen und Anmerkungen einzugehen.

Wer nicht ganz weiß, worum es gerade geht, links:
Ankündigung (https://steamcommunity.com/games/221410/announcements/detail/1602634609636894200)
Benchmarks (https://www.phoronix.com/scan.php?page=article&item=radv-aco-llvm)

Ich fang mal einfach beim Anfang an.
Seit letzten Februar arbeite ich freiberuflich für Valve mit dem Auftrag LLVM und den RADV Mesa Treiber zu verbessern. Im März kamen wir während einiger interner Diskussionen zu dem Schluss, dass LLVM bedeutende Schwierigkeiten mit ganz bestimmten Arten von Shadern hat. Ich darf vermutlich nicht allzusehr ins Detail gehen hier, aber die Hauptursache der Probleme lag in der praktisch nicht vorhandenen Divergence-Analysis, die ausrechnet, ob eine Variable uniform für alle Instanzen einer invocation group ist. In manchen Anwendungen war/ist LLVM dadurch 20-30% langsamer als der propritäre (Windows-)Compiler von AMD.
Um das zu beheben, haben wir beschlossen einfach selbst ein Backend zu schreiben, das in der kompletten instruction selection auf einer sehr aggressiven divergence analysis aufbaut. Mittlerweile benutzt LLVM selbst auch eine divergence analysis dafür, die aber noch ein gutes Stück konservativer vorgeht. Hätten wir das damals gewusst, vielleicht gäbe es ACO gar nicht :eek:
Das zweite große Thema war dann eigentlich register pressure. Anders als bei CPUs hängt bei GPUs die Anzahl der möglichen gleichzeitig aktiven (Hardware-)Threads hauptsächlich von der Anzahl der Register ab, die ein Thread belegt. Jede SIMD-Einheit hat bei GCN 256 VGPRs, die in Paketen von 4 von den Shadern alloziiert werden können. Um also 10 Waves gleichzeitig auf einer SIMD-Einheit laufen zu lassen, dürfen nicht mehr als 24 VGPRs benutzt werden. Richtig blöd wäre es dann zum Beispiel 65 VGPRs zu benutzen, da dann nur noch 3 Waves gehen, obwohl mit 64 VGPR noch 4 gepasst hätten. Das ist praktisch ein Unterschied von 33% Performance!
Das Thema Compiletime um stutter zu reduzieren kam eigentlich erst relativ spät und ist mehr ein Nebenprodukt vom schlanken Aufbau des Backends. Witzig, dass es jetzt zum Hauptfeature wurde. Aber das liegt wohl mehr an der starken Verbreitung von DXVK.

Was die Zukunft angeht, hat sich dadurch natürlich unser Augenmerk ein bisschen verschoben, und wir werden versuchen die anderen shader stages möglichst zügig einzubauen, um die stutter noch weiter zu reduzieren. Ansonsten steht natürlich Navi (und auch die alten GCN1/2) auf dem Plan.

Ihr könnt mich jetzt gern mit Fragen zuschmeißen =)
Was mich im Gegenzug von euch interessieren würde, wären Benchmarks Windows vs Linux. ;)

[Affinator]

Was mich interessieren würde:

Ich habe selbst im Studium nur einen "einfachen" MIPS-Compiler geschrieben. Wie unterschiedlich ist ein GPU-Compiler zu einem CPU-Compiler? Wie verhält es sich mit Komplexität, Abhängigkeiten, Quirks, Errata, etc.?

Auf den ersten Blick müssten GPUs ja eher einfacher sein, aber da würde mich eine realistische Einschätzung mal interessieren.

[danarcho]

Hey,
das Grundprinzip ist natürlich das Selbe, aber die theoretischen Probleme unterscheiden sich bisweilen sehr.
So ist bei GPUs zB der logische control flow graph in der Regel nicht der selbe wie der physische, wodurch gleiche eine ganze Reihe an schönen Problemen entstehen, mit denen man sich die Nächte um die Ohren schlagen kann. Die hauptsächliche Frage, die dabei aufkommt, ist wann welche Variable überhaupt live ist, also ein Register beansprucht, das nicht anderweitig verwendet werden darf. LLVM hat knapp zwei Jahre gebraucht um horizontal reductions fehlerfrei zu bekommen, weil dort nicht richtig zwischen dem logischen und physischen control flow graph unterschieden wird.
Die anderen zwei Punkte, die bei GPUs wichtig sind, habe ich oben schon genannt (divergence analysis & register pressure).
Bei CPUs sind dafür die Timings deutlich anspruchsvoller, und dadurch das Scheduling viel komplexer. Wir z.B. kümmern uns beim Scheduling um nichts außer memory instructions, weil alles andere sowieso in-order ausgeführt wird.
Bei CPUs wird meistens nicht so sehr auf den register pressure geachtet, aber bei GCN muss man immer gleich 64x4=256 Bytes spillen, oder verliert direkt eine Wave (beides Scheiße), weshalb wir z.B memory loads nicht früher schedulen, wenn dabei der register pressure zu groß wird.
Realistische Einschätzung ist schwierig... man kann halt beides bis zum Exzess treiben und beides wird irgendwann sehr komplex.

[gravitationsfeld]

Das ist praktisch ein Unterschied von 33% Performance!
Naja. Das ist so nicht gesagt. Du kannst auch mit nur einer Wave theoretisch vollen Durchsatz haben wenn du nie auf irgend was warten musst. Die Wahrheit ist irgendwo zwischen 0% und 33%.

[Badesalz]

Ihr könnt mich jetzt gern mit Fragen zuschmeißen =)
Was mich im Gegenzug von euch interessieren würde, wären Benchmarks Windows vs Linux. ;)Futter? :wink:

[mksn7]

Was ist der Unterschied zwischen physischem und logischem Control Flow?

[danarcho]

Naja. Das ist so nicht gesagt. Du kannst auch mit nur einer Wave theoretisch vollen Durchsatz haben wenn du nie auf irgend was warten musst. Die Wahrheit ist irgendwo zwischen 0% und 33%.
Ah, you got me :)
Auf der anderen Seite kann sich der Compiler nicht aussuchen, was für ein Müll Code er übersetzen darf. Aber ja, dieser Fall ist tatsächlich eher selten.


Was ist der Unterschied zwischen physischem und logischem Control Flow?
Grafikshader werden in der Regel in SPMD (single program - multiple data) style geschrieben, beschreiben also den Programmablauf aus Sicht eines einzelnen Elements (zB Pixels). Die GPU als Vector-Architektur muss aber dieses Programm auf ganz vielen Daten ausführen. Das heißt, während einige Pixel vielleicht bei if-then-else auf die then-Seite wollen, müssen andere auf die else-Seite. Die GPU führt daher einfach beide Seiten aus und deaktiviert die jeweils inaktiven Lanes. Der logische control flow sieht dann so aus:

if()
/ \
then else
\ /
merge

während der physische (oder lineare) control flow graph (vereinfacht) so aussieht:

if()
|
then
|
else
|
merge

Du kannst dir vorstellen, dass das bei Loops noch deutlich schlimmer wird ;)

[Ganon]

Hätten wir das damals gewusst, vielleicht gäbe es ACO gar nicht :eek:

Damit hast du den Kern meiner Frage schon erfasst. Aber jetzt nicht falsch verstehen, meinen Glückwunsch zur bisherigen Leistung.

Aber warum wurde die Arbeit nicht dafür investiert eben die genannten Probleme in LLVM anzugehen? Es ist natürlich wesentlich aufwändiger ein bestehendes Projekt anzupassen. Darum sind solche Clean-Room Implementierungen meist auch effizienter. Ich sehe nur gerade ein kleines Problem was Wartung und Pflege angeht. Es kann natürlich sein, aber ich rechne irgendwie nicht damit, dass Valve den Kram für alle Ewigkeiten finanzieren wird.

Es ist halt etwas ernüchternd, dass AMD ihren OpenSource Vulkan Treiber baut, RedHat/IBM bauen dann noch einen und jetzt kommt Valve (mit euch) und legt noch einen weiteren eigenen Shader Compiler oben drauf :ugly: Das wäre natürlich schön, wenn es da irgendwo einen Austausch geben würde, aber das sehe ich irgendwie gerade nicht. Der Endanwender steht dann quasi mit 2,5 Vulkan-Treibern da. Aber wäre natürlich schön, wenn alles gut läuft und euer Compiler dann in der fertigen Version er "offizielle radv" Compiler wird.

Bin aber weiter gespannt wie es sich alles so entwickelt.

[aufkrawall]

Ich nehme mal an, da die ISA mit Navi weiterhin GCN ist, sollte ACO auch hierfür ohne riesigen Aufwand nutzbar sein?
Der überwiegende Teil der Linux-User nutzt vermutlich wegen Mesa sowieso RADV und amdvlk bleibt weiterhin relativ uninteressant.

[gravitationsfeld]

Es ist nicht einfach nur GCN. Z.B. koennen VALU-Instructions jetzt zwei SGPR-Register lesen.

[iuno]

Es ist halt etwas ernüchternd, dass AMD ihren OpenSource Vulkan Treiber baut, RedHat/IBM bauen dann noch einen und jetzt kommt Valve (mit euch) und legt noch einen weiteren eigenen Shader Compiler oben drauf :ugly:
Du suggerierst das Gegenteil, aber radv war vor amdvlk da. AMD hat da einfach zu lange gebraucht und jetzt haben wir mit radv einen guten Treiber, der CPU-seitig auch noch effizienter ist. Passt doch.

Wieso eigentlich RedHat? Wegen Dave? Ich glaube Bas, ist relativ schnell eingestiegen und macht inzwischen mehr an radv. Ich kann mich natuerlich taeuschen, aber fuer mich hat das auch nicht den Anschein gemacht, dass das jetzt ein "offizielles" RedHat Projekt war, als Dave angefangen hat. Wobei es IMHO durchaus Sinn ergeben wuerde. GCN haette man mit guten freien Treibern schon lange als "die Standard-Linux-GPU" etablieren koennen, wenn man das mal so bloed sagen will.

---

Wie (gut) kann man eigentlich das Kompilat bewerten? Gibt es fuer euch eine Moeglichkeit, die Effizienz eures compilers z.B. mit dem von Sony zu vergleichen?
Habt ihr vor, aco irgendwann auch mal fuer radeonsi, der ja inzwischen auch NIR benutzt, zu nutzen?

[Ganon]

Du suggerierst das Gegenteil, aber radv war vor amdvlk da. AMD hat da einfach zu lange gebraucht und jetzt haben wir mit radv einen guten Treiber, der CPU-seitig auch noch effizienter ist. Passt doch

Sicherlich. Mir ging es jetzt auch weniger um die 2 Vulkan-Implementierung an sich, sondern dass wir da jetzt mit 3 Shader-Compilern dastehen.

[aufkrawall]

Genau genommen sind es vier, wenn man den für amdvlk-open gesondert zählt, da er kein mainline-llvm nutzt (bzw. mit Custom Patches darauf aufbaut, die offenbar kaum den Weg nach oben finden).

[danarcho]

Damit hast du den Kern meiner Frage schon erfasst. Aber jetzt nicht falsch verstehen, meinen Glückwunsch zur bisherigen Leistung.
Danke!
Aber warum wurde die Arbeit nicht dafür investiert eben die genannten Probleme in LLVM anzugehen? Es ist natürlich wesentlich aufwändiger ein bestehendes Projekt anzupassen. Darum sind solche Clean-Room Implementierungen meist auch effizienter. Ich sehe nur gerade ein kleines Problem was Wartung und Pflege angeht. Es kann natürlich sein, aber ich rechne irgendwie nicht damit, dass Valve den Kram für alle Ewigkeiten finanzieren wird.
Die Probleme sind alle seit Jahren bekannt, und seit Jahren wird an LLVM herumgedoktort, um es irgendwie brauchbar zu machen. Keiner sagt, dass es unmöglich ist LLVM genauso schnell zu bekommen. Der Schluss unsererseits war nur, dass es wohl aufwendiger ist (Was ein bisschen absurd klingt, wenn man sich den Aufwand anschaut um das Ding neu zu schreiben.) Das control flow handling und compiletime bräuchten einfach sehr starke Eingriffe in die Core-Infrastruktur von LLVM, und da haben dann plötzlich alle möglichen anderen Parteien auch noch ein Wort mitzureden.
(Clean-Room war das übrigens nicht, wir hatten ja LLVM zum abgucken, aber ich versteh was du meinst.)
Was Wartung und Pflege angeht: Ja, wir haben das Problem mit ACO, dass es recht schwierig ist Day1 Support für neue HW zu bieten, wenn wir nicht irgendwann AMD von ACO überzeugen können...
Es ist halt etwas ernüchternd, dass AMD ihren OpenSource Vulkan Treiber baut, RedHat/IBM bauen dann noch einen und jetzt kommt Valve (mit euch) und legt noch einen weiteren eigenen Shader Compiler oben drauf :ugly: Das wäre natürlich schön, wenn es da irgendwo einen Austausch geben würde, aber das sehe ich irgendwie gerade nicht. Der Endanwender steht dann quasi mit 2,5 Vulkan-Treibern da.
Nur 2,5? Sony und Microsoft haben doch auch noch ihre Compiler :)
Eigentlich sind wir uns alle einig, dass es am Besten wäre, wenn LLVM einfach sauber und schnell laufen würde. Austausch läuft halt eher hinter den Bühnen, aber ich kann dir versichern, dass es diesen fortwährend gab und gibt, und ACO für AMD auch nicht aus heiterem Himmel gefallen ist. Allgemein pflegen wir eigentlich ein gutes Verhältnis, aber ich kann mir auch vorstellen, dass die immer wieder herbeigeredete Konkurrenz den AMD-Entwicklern intern mehr zu schaffen macht, was überhaupt nicht unserer Intention entspricht.
Ich nehme mal an, da die ISA mit Navi weiterhin GCN ist, sollte ACO auch hierfür ohne riesigen Aufwand nutzbar sein?
Im Grunde ja. Es gibt ein paar kleine Optimierungen, die LLVM Navi-spezifisch macht, wo ich mal vom Kosten-Nutzen schauen muss, was wir da machen. Wenn du lange Weile hast, kannst du ja gern alle opcodes aus LLVM rausfischen ;)

[danarcho]

Es ist nicht einfach nur GCN. Z.B. koennen VALU-Instructions jetzt zwei SGPR-Register lesen.
Nice, hab ich noch gar nicht gesehen! Wird mal Zeit für eine neue ISA-Doc...

[gravitationsfeld]

Zugegebenerweise sind die Unterschiede wirklich nicht so riesig. Ich hatte erwartet, dass die Abhaengigkeiten jetzt im Instruction-Stream enkodiert werden wie bei NVIDIA, aber das ist scheinbar nicht der Fall. AMD hat das anscheinend in Hardware geloest.

[danarcho]

Futter? :wink:
Naja, unser Ziel ist es eben genau nicht AMDVLK zu schlagen, und deren Ziel wahrscheinlich auch nicht RADV zu schlagen, sondern wir alle wollen halt (mindestens) Windows-Performance unter Linux erreichen und (und compiletimes wie Nvidia).
In manchen Fällen klappt das von der Performance her schon sehr ordentlich, aber ich habe ja nur ein Bruchteil an möglichen Spielen zum Testen.

[Ganon]

Die Probleme sind alle seit Jahren bekannt, und seit Jahren wird an LLVM herumgedoktort, um es irgendwie brauchbar zu machen. [...]
Was Wartung und Pflege angeht: Ja, wir haben das Problem mit ACO, dass es recht schwierig ist Day1 Support für neue HW zu bieten, wenn wir nicht irgendwann AMD von ACO überzeugen können...

Gut, das klingt schon etwas hoffnungsvoller. Ich bin gespannt und wünsche euch weiterhin viel Erfolg, auf dass das alles gut läuft.

Nur 2,5? Sony und Microsoft haben doch auch noch ihre Compiler :)
Eigentlich sind wir uns alle einig, dass es am Besten wäre, wenn LLVM einfach sauber und schnell laufen würde. Austausch läuft halt eher hinter den Bühnen, aber ich kann dir versichern, dass es diesen fortwährend gab und gibt, und ACO für AMD auch nicht aus heiterem Himmel gefallen ist. Allgemein pflegen wir eigentlich ein gutes Verhältnis, aber ich kann mir auch vorstellen, dass die immer wieder herbeigeredete Konkurrenz den AMD-Entwicklern intern mehr zu schaffen macht, was überhaupt nicht unserer Intention entspricht.


Na mit den 2.5 Compilern meine ich, den der Endanwender bei sich installieren kann und je nach Fall bei dem einen bessere oder schlechtere Performance bekommt als bei einem anderem. Den Compiler von MS oder den von Sony kann ich ja nicht selbst benutzen. Da aber alle hier relevanten Open Source sind, ist es natürlich wünschenswert wenn es einen Open Source Treiber geben würde, der einfach nur gut funktioniert ;) Klar, ist sicherlich auch etwas utopisch das anzunehmen, aber ich denke du verstehst was ich "als Endanwender" damit meine. edit: Und ich drücke euch die Daumen, dass ihr die Leute von Mesa überzeugen könnt (und vielleicht sogar AMD).

Aber das geht jetzt natürlich in eine Richtung die hier etwas OT ist.

[aufkrawall]

Es zeichnet sich ja schon jetzt ab, dass ACO unterm Strich am besten performt und Probleme sehr schnell angegangen werden.
amdvlk hat allgemein immer noch mehr Rendering-Probleme mit Wrappern als radv, kaputtes Vsync, kein FreeSync, amdvlk-open durch den lahmen Compiler Monster-Ruckler und amdvlk-closed durch fehlenden on-disk Shadercache stetig wiederkehrende. Da ist die Wahl ziemlich einfach, sofern die Hardware anständig von radv/aco unterstützt wird...

[danarcho]

So, wir haben ja keinen Blog oder so, wo wir ein changelog führen. Wir hattens kurz überlegt, aber eigentlich ist ja das Ziel möglichst schnell upstream zu kommen und nicht einen Fork zu entwickeln.
Aber die Änderungen der letzten Woche sind in etwa:
- ein Haufen Bugfixes
- Rebase, so dass LLVM nicht mehr von der rtld regression geplagt wird
- shaderInt64, mehr ein Checklisten-Feature, nervt aber immer rum, wenn man mit ACO LLVM captures abspielen möchte
- ein Haufen Peephole optimizations, bringt glaube ~0.5% weniger code size

Als nächstes kommen wohl shader_demote und shaderFloat64.

[aufkrawall]

Elex Mini-Benchmark:
https://abload.de/thumb/screenshot_20190716_126ky2.jpg (https://abload.de/image.php?img=screenshot_20190716_126ky2.jpg) https://abload.de/thumb/screenshot_20190716_1u2kis.jpg (https://abload.de/image.php?img=screenshot_20190716_1u2kis.jpg) https://abload.de/thumb/screenshot_20190716_17rjzj.jpg (https://abload.de/image.php?img=screenshot_20190716_17rjzj.jpg)
Auf ~amdvlk-open Niveau gelandet, was ja schon mal nicht schlecht ist. :) Nur komisch, dass das "Radar" mit ACO größer ist. Ist dann wohl in LLVM mittlerweile gefixt:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11932569&postcount=69

[danarcho]

Sind die min- und max- Zahlen frametimes oder fps? Als FPS machen sie etwas weniger Sinn. Als frametimes hast du wahrscheinlich noch compile stutter während die anderen beiden Treiber die shader schon gecached hatten?
Das Radar sieht zwischen AMDVLK und RADV aber auch unterschiedlich aus... Hast du mal ein capture davon?

[aufkrawall]

Hast Recht, das Radar ist 3x verschieden. Bzw. 4x, wenn man Windows D3D11 mitzählt. :freak:
Die angezeigten fps schwanken nur leicht und sind damit quasi repräsentativ für Durchschnittswerte. Der Ausschlag mit ACO kam durchs Minimieren, ist zu ignorieren. Durch den DXVK State Cache und die treiberseitigen Binary-Caches gibt es mit keinem der drei getesteten Treiber Stuttering oder Einbrüche nach dem Laden.

Ich hatte für amdvlk "UseFlipHint,1" gesetzt, mit dem Legacy DC (amdgpu.dc=0) erhöht das kurioserweise die fps um ein paar Prozent. Baustelle...

Du meinst ein RenderDoc capture für Elex?

[danarcho]

Ja, wobei ich eigentlich stark bezweifle, dass das ein Treiber-Bug sein soll. Vielleicht rechnet das Spiel ja die Größe des Kompasses Anhand der strlen vom Treiber Name :P

[gravitationsfeld]

Ist es denn konsistent zwischen den Runs? Vielleicht ist es auch nur uninitialisierter Speicher?

[aufkrawall]

Habs 3x mit RADV/ACO gestartet, es blieb 3x gleich groß. Wobei mir dieses "Problem" halt auch ziemlich egal ist, anders als die Artefakte in HotS (für die ACO natürlich nichts kann). ;)
Hier trotzdem ein RenderDoc Capture:
https://drive.google.com/open?id=1sO51kHs7AIB0DC9DIexG-NlvM-Nk-f0s

Dummerweise bringt es mir RadeonSI oder amdgpu zum Crashen, wenn ich es in RD öffne.

[danarcho]

Wie eigentlich kaum anders zu erwarten, ist der Kompass anscheinend fixed in dem capture. Rendert exakt gleich mit ACO und LLVM.
Btw, es sollte auch nicht möglich sein Captures mit anderen Treibern, verschiedener HW oder sogar APIs zu öffnen. Das geht eigentlich nur zwischen RADV/LLVM und RADV/ACO, und auch nur, weil wir alle in- und outputs gleich setzen.

[aufkrawall]

Ach so, RenderDoc läuft immer mit der API des Captures? Dann stimmt meine Aussage bez. RadeonSI natürlich nicht.

Mir ist btw. aufgefallen, dass der AMD Windows Vulkan-Treiber genau wie das amdgpu-pro-Pendant keinen on Disk Shadercache hat.
amdgpu-pro 19.30 ist in Doom genau so schnell wie der Windows 19.7.2, also noch einen Hauch schneller als ACO (~91 vs. ~88fps).

[aufkrawall]

So, kleiner Rundum-Test in Doom auf RX 570 (nicht mehr 580):

Adrenalin 19.7.3 Windows 10 1903 (~90fps):
https://abload.de/thumb/windows_ergebnisunki1.jpg (https://abload.de/image.php?img=windows_ergebnisunki1.jpg)

Linux 5.2-rc1 Proton 4.2-9 amdgpu-pro 19.30 (~92fps):
https://abload.de/thumb/amdvlk-closed_ergebni6pkc9.jpg (https://abload.de/image.php?img=amdvlk-closed_ergebni6pkc9.jpg)

amdvlk-open v-2019.Q3.2 (~90fps):
https://abload.de/thumb/amdvlk-open_ergebnisppkjl.jpg (https://abload.de/image.php?img=amdvlk-open_ergebnisppkjl.jpg)

radv-aco-git (~88fps):
https://abload.de/thumb/radv-aco_ergebnismcjqu.jpg (https://abload.de/image.php?img=radv-aco_ergebnismcjqu.jpg)

Zeigt neben der beeindruckend guten radv-aco-Performance (man beachte auch die CPU-Werte) auch, wie gut der AMD Linux-Treiber auf Performance optimiert ist (und dass Wine im GPU-Limit wirklich gar nichts kostet). Mit Nvidia lag ich immer mindestens 1fps unter den Windows-Werten, mit AMD wird es hier hingegen trotz völligen GPU-Limits sogar leicht überholt.

[danarcho]

Wow, da hat AMDVLK ja einen ziemlichen Sprung hingelegt. Ich denke, wir stehen trotzdem ganz gut da aus folgendem Grund:


AMDVLK (und damit wohl auch Pro und der Windows Treiber):
wobei anscheinend bei Polaris nicht ganz so viel gecheatet wird.

xgl/icd/settings/settings.cpp:
if (appProfile == AppProfile::Doom)
{
pSettings->enableSpvPerfOptimal = true;

pSettings->optColorTargetUsageDoesNotContainResolveLayout = true;

// No gains were seen pre-GFX9
if (info.gfxLevel >= Pal::GfxIpLevel::GfxIp9)
{
pSettings->barrierFilterOptions = SkipStrayExecutionDependencies |
SkipImageLayoutUndefined |
SkipDuplicateResourceBarriers |
ForceImageSharingModeExclusive;
}

// Vega 20 has better performance on DOOM when DCC is disabled except for the 32 BPP surfaces
if (info.revision == Pal::AsicRevision::Vega20)
{
pSettings->dccBitsPerPixelThreshold = 32;
}

// id games are known to query instance-level functions with vkGetDeviceProcAddr illegally thus we
// can't do any better than returning a non-null function pointer for them.
pSettings->lenientInstanceFuncQuery = true;
}
...
if (((appProfile == AppProfile::WolfensteinII) ||
(appProfile == AppProfile::Doom)) &&
(info.gfxLevel > Pal::GfxIpLevel::GfxIp9))
{
pSettings->asyncComputeQueueMaxWavesPerCu = 40;
pSettings->nggSubgroupSizing = NggSubgroupExplicit;
pSettings->nggVertsPerSubgroup = 254;
pSettings->nggPrimsPerSubgroup = 128;
}


xgl/icd/api/app_shader_optimizer.cpp:
if (appProfile == AppProfile::Doom)
{
if (Pal::GfxIpLevel::GfxIp9 == gfxIpLevel)
{
// Apply late VS alloc to all (graphics) pipelines
i = m_appProfile.entryCount++;
m_appProfile.entries[i].pattern.match.always = 1;
m_appProfile.entries[i].action.createInfo.apply.lateAllocVsLimit = true;
m_appProfile.entries[i].action.createInfo.lateAllocVsLimit = 0;

///////////////////////////////////////////////////////////////////////////////////////////////////////////
// fa535f5e84c8b76eef8212debb55d37f,PS,False,PBB,1
i = m_appProfile.entryCount++;
m_appProfile.entries[i].pattern.shaders[ShaderStageFragment].match.stageActive = true;
m_appProfile.entries[i].pattern.shaders[ShaderStageFragment].match.codeHash = true;
m_appProfile.entries[i].pattern.shaders[ShaderStageFragment].codeHash.lower = 0xef8212debb55d37f;
m_appProfile.entries[i].pattern.shaders[ShaderStageFragment].codeHash.upper = 0xfa535f5e84c8b76e;
m_appProfile.entries[i].action.createInfo.apply.binningOverride = true;
m_appProfile.entries[i].action.createInfo.binningOverride = Pal::BinningOverride::Disable;
}
}



... und einen mini Boost von 2-3 FPS haben wir auch noch in Petto, wenn ich mich eben nicht verguckt habe ;)

[aufkrawall]

Habt ihr eigentlich schon d9vk auf dem Schirm? Kurioserweise verhält sich das hier bislang quasi gegensätzlich zu dxvk, bei dem radv spätestens mit aco häufig schneller als amdvlk-pro ist. Bei d9vk ist aber amdvlk-pro häufig am schnellsten im GPU-Limit (und amdvlk-open mit Abstand am langsamsten im CPU-Limit). In Risen 3 liegen zwischen amdvlk-pro und radv-aco ~10%.

[aufkrawall]

Hab mal die Shader Compile Time vs. amdvlk-pro verglichen (mit ACO inkls. VS):
amdvlk-pro: ~72ms
ACO: ~42ms :eek:
amdvlk-open: ~258ms :freak: :freak:
Edit: radv-llvm: ~185ms
Test ist simpel, aber zuverlässig: In SS: Fusion mit Raketenwerfer auf einen Baum schießen, der fps-Counter des Spiels zeigt die Frametime-Abweichung an.

Edit: Der Windows-Treiber ist mit ~53ms etwas schneller als amdvlk-pro (oder Zufall?), aber immer noch langsamer als ACO. Die fps sind zwischen Windows und amdvlk-pro allerdings identisch, in beiden Fällen ~82. Linux radv-aco: ~87fps. :D

[danarcho]

Hey, danke für den Bericht!
zu d9vk: bis jetzt haben wir da noch nicht wirklich reingeschaut, aber wenn das in Proton landen sollte, dann bekommt es sicher mehr aufmerksamkeit unsererseits ;)

zu den compiletimes: wir benutzen dafür ganz gerne pipeline-db, wobei fossilize auch gehen sollte. Dann kannst du ganze datenbanken an shadern durchjagen von haufenweise Spielen, und wir kommen dabei auf eine leicht höhere zeit als pro. Das wird aber auch stark von der Größe des shaders beeinflusst, so dass es durchaus sein kann, dass aco bei kurzen shadern schneller ist als pro und bei langen shadern etwas langsamer. Ich weiß nicht, ob es wirklich einen Unterschied zwischen dem Windows- und Linux- Pro Treiber gibt, würde ich eher nicht davon ausgehen.

[aufkrawall]

Schätze, es kann leichte Abweichungen geben, weil man keine Kontrolle darüber hat, welche Zeitpunkte der Counter genau heranzieht. Aber die langen Zeiten von llvm und insbesondere amdvlk-open sind eindeutig, was macht AMD da für komisches Zeugs? :redface:

[Ganon]

Hey, danke für den Bericht!
zu d9vk: bis jetzt haben wir da noch nicht wirklich reingeschaut, aber wenn das in Proton landen sollte, dann bekommt es sicher mehr aufmerksamkeit unsererseits ;)


https://www.phoronix.com/scan.php?page=news_item&px=Proton-4.11-Released

In addition, Proton 4.11 takes things further by now shipping D9VK (v0.13f) as the experimental Vulkan-based Direct3D 9 implementation that's been gaining steam recently for those using it for a faster D3D9 Linux gaming experience.

:D

[aufkrawall]

Mit ACO ist die Performance von RotTR-Linux näher an D3D12 als an 11:
radv-aco:
https://abload.de/thumb/acol1k14.jpg (https://abload.de/image.php?img=acol1k14.jpg)

amdvlk-open:
https://abload.de/thumb/amdvlk-openwmkc4.jpg (https://abload.de/image.php?img=amdvlk-openwmkc4.jpg)

amdvlk-pro:
https://abload.de/thumb/amdvlk-proppjx9.jpg (https://abload.de/image.php?img=amdvlk-proppjx9.jpg)

radv-llvm:
https://abload.de/thumb/llvm9yjwv.jpg (https://abload.de/image.php?img=llvm9yjwv.jpg)

d3d11:
https://abload.de/thumb/d3d11ljk0k.jpg (https://abload.de/image.php?img=d3d11ljk0k.jpg)

d3d12:
https://abload.de/thumb/d3d12d1ks0.jpg (https://abload.de/image.php?img=d3d12d1ks0.jpg)

[danarcho]

Mit ACO ist die Performance von RotTR-Linux näher an D3D12 als an 11:
cool! Aber hast du unter Linux den Feral-Port benutzt oder die Windows-Version mit Proton erzwungen? Falls Feral: Hast du unter Windows HBAO+ deaktiviert damit es vergleichbar bleibt?

[aufkrawall]

Ja, ist natürlich der Feral-Port und unter Windows mit der normalen SSAO (fügt sich häufig eh besser ins Lighting ein als die HBAO+). Ansonsten alles max. Details + FXAA.

[danarcho]

Willst du mal vergleichen mit forced-Proton? Wäre interessant zu wissen wie DXVK abschneiden im Vergleich zu Feral :P

[aufkrawall]

Ziemlich schnell, erreicht quasi native D3D11-Performance:
https://abload.de/thumb/screenshot_20190802_10zkbz.png (https://abload.de/image.php?img=screenshot_20190802_10zkbz.png)

Das Spiel müllt allerdings nicht nur mit D3D12 den VRAM wie sondergleichen zu, sondern auch mit 11. In den offenen Hubs alloziert er mit DXVK 8,6GB und knackt auch die 8GB Verbrauch, inkls. übler Pressure-Ruckler. Der Feral-Port ist sparsamer und kommt problemlos mit 8GB aus.

[Affinator]

Ich habe heute mal Zeit gefunden den fsync-kernel und mesa-aco zu installieren (Distribution = Manjaro; build direkt von http://repo.steampowered.com/arch/valveaur/).

Anno 1800 sieht leider nicht ganz so hübsch aus. Bild im Anhang (skaliert wegen Dateigröße). Gibt es erste Schritte, die ich unternehmen kann, oder soll ich ein Issue bei Github einstellen?

CPU: Ryzen 2700X
GPU: Radeon 480X

[danarcho]

Github issue :)
Da steht dann auch, was du tun kannst...

[aufkrawall]

In HotS hat ACO für VS nochmal ca. die gleiche Stutter-Linderung gebracht wie für FS. Mit DXVK State Cache ist kaum noch ein fühlbarer Unterschied zu Windows D3D11 bemerkbar.

[danarcho]

@Affinator
Hat sich das Problem von selbst behoben? Ansonsten würde ich mich über ein Renderdoc capture freuen.

[Affinator]

Sorry, bin heute erst wieder aus dem Urlaub zurück. Ich schaue mal, ob ich heute einen Renderdoc hinbekomme. (Sieht ja auf der CLI recht einfach aus - mal schauen, ob das direkt mit dem Ubisoft-Launcher funktioniert.)

Edit: OK, ich brauche wohl doch eine Anleitung. Muss ich ganz Steam "capturen"? Die Anno1800.exe bzw. die UPlay_BLA.exe geht ja - wie zu erwarten - nicht.

Edit2: Der Fehler tritt auch mit LLVM auf! Ich hatte das nicht getestet, da vorher alles funktioniert hat. Aber irgendein anderes Update muss den Fehler ausgelöst haben. Hätte ich früher testen müssen, sorry!

[aufkrawall]

Probier mal die neuste DXVK-Version.

[Affinator]

Tut mir leid, ich will mir jetzt nicht auf meiner Zock-Maschine eine Build-Umgebung einrichten. Mit sowas habe ich auf der Arbeit schon genug zu tun ;-)

[aufkrawall]

Einfach die Binaries von Github beziehen und in Proton schmeißen.

[aufkrawall]

... und einen mini Boost von 2-3 FPS haben wir auch noch in Petto, wenn ich mich eben nicht verguckt habe ;)
Da isser, den schnellsten Treiber von AMD selbst knapp geschlagen :) :
https://abload.de/thumb/screenshot_20190814_18jky5.png (https://abload.de/image.php?img=screenshot_20190814_18jky5.png)

[danarcho]

Da isser, den schnellsten Treiber von AMD selbst knapp geschlagen :)
:O

achievement earned! \o/

[gravitationsfeld]

Laufen da jetzt eigentlich die AMD-Intrinsics-Shader?

[danarcho]

Schon lange (wenn ich mich richtig erinnere macht das etwa 10-15% aus)
Bei LLVM sieht das mittlerweile auch korrekt aus (kann man testen mit RADV_PERFTEST=shader_ballot, für ACO ist das aber eh an), und immerhin wird es auch nicht mehr viel langsamer, wenn die benutzt werden :|
Was uns noch fehlt (vor allem auch, wenn ACO default werden soll), sind die 16bit extensions für Wf2 and neuer.

Edit: abgesehen davon, dass ACO auch ohne 16bit schon schneller ist als LLVM... ging es mir gerade darum, dass wir Extension-Support nicht regressen sollen

[danarcho]

@gravitationsfeld

LLVM -> ACO
PERCENTAGE DELTAS Shaders SGPRs VGPRs SpillSGPR SpillVGPR PrivVGPR Scratch CodeSize MaxWaves Waits
youngblood 843 9.85 % -36.54 % -100.00 % -100.00 % . -100.00 % -19.24 % 4.85 % .

Ich glaube, man braucht da nicht viel dazu zu sagen. Ein shader sticht besonders hervor mit 320 spilled vgprs / 256 vgprs -> 0 spilled / 64 vgprs und code size halbiert. Ich behaupte mal, die durchschnittlichen stall cycles sind trotzdem nicht höher, und das Ergebnis merkt man auch.

[gravitationsfeld]

LLVM als Shader-Compiler scheint wirklich nutzlos zu sein. Gute Arbeit. Ich hoffe immer noch, dass AMD sich da was abschaut.

[aufkrawall]

Davon würd ich nicht ausgehen, das Firmen-Mantra ist Kohärenz durch PAL und LLVM. Man schaue sich dann noch den verspäteten Linux-Support von Navi an, teilweise fragwürdigen Zustand der OCL-Treiber und amdvlk-open für Navi, dann drängt sich jedenfalls kein Optimismus auf...

[gravitationsfeld]

PAL ist schon okay, das wird auch auf Windows gebraucht um DX12 und Vulkan unter einen Hut zu bringen. Die Compiler sind nur nicht das Wahre. Egal ob LLVM oder priorietaer.

[danarcho]

Theoretisch wäre es möglich ACO mitsamt dem NIR-frontend aus mesa nach AMDVLK bzw PAL zu portieren. Es ist halt von der ABI ein bisschen Aufwand zu erledigen, aber möglich definitiv, wenn auch eher Zukunftsmusik.

[gravitationsfeld]

Der ACO-Code ist MIT/BSD style lizensiert, oder?

Wueder dich das aergern, wenn AMD einfach euren Code benutzen wuerde?

[danarcho]

Ich vermute mit "einfach" meinst du, dass sie Fixes und Optimizations nicht zurückgeben? Das würde mich schon ärgern. Auf der anderen Seite wollen wir ja, dass die verbesserte Performance so vielen Spielern wie möglich zugute kommt, aber bisher sieht es eher nicht danach aus, dass AMD einen Finger rühren wird. Die (also vermutlich Management) haben damals einfach für LLVM entschieden und halten daran fest, komme was wolle.
Wenn ich den Post von Bridgman richtig verstanden habe, soll ja der proprietäre Compiler auch irgendwann durch LLVM ersetzt werden (wahrscheinlich, wenn es keine Regressions mehr gibt, also nie).

[gravitationsfeld]

wahrscheinlich, wenn es keine Regressions mehr gibt, also nie.
;D

[aufkrawall]

Mir ist amdvlk-open wegen der (völligen?) Nicht-Unterstützung von RADV/ACO seitens AMD nicht gerade extrem sympathisch. Allerdings kann man schon so etwas wie soliden Fortschritt bei Performance und Kompatibilität bescheinigen. Mit den Abart-Compile-Times kann man den propr. Compiler aber wohl schwerlich ersetzen. Ob die das jemals in den Griff bekommen...

[gravitationsfeld]

AMD will halt keine Arbeit doppelt machen. Die Code-Base ist die selbe auf Windows und Linux. Ist bei NVidia ja auch nicht anders, ausset dass die nur Blobs liefern und Nouveau nicht mal mit dem Arsch anschauen.

[danarcho]

AMDVLK: Naja, zum einen sind sowas ja Management-Entscheidungen, für die die Entwickler wenig können. Und unter den gegebenen Umständen machen die schon solide Arbeit. Wegen der Compiletimes stellt sich gerade die Frage, wie viel global isel bringen wird.
Dass AMD überhaupt einen open stack unterhält, ist ja prinzipiell erst mal positiv.
So gesehen denke ich nicht, dass es sich um eine Entscheidung gegen RADV/ACO handelt, sondern dass das, was wir machen, einfach nicht in ihr Konzept passt. Das ist etwas unglücklich, da sich die Entwickler auf beiden Seiten sicher freuen würden, wenn man die Arbeit teilen könnte anstatt sie zu verdoppeln :)

[iuno]

ACO goes upstream:: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2009 (weitere MRs sind verlinkt) :up:

[aufkrawall]

Frühen Navi-Support gibt es nun auch:
https://github.com/daniel-schuermann/mesa/issues/136

Ich frag mich, ob man für RadeonSI auch teilweise bis zu 20-30% vs. LLVM erwarten darf?
Ich mein, Doom läuft so schon mit OGL pervers schnell auf einer RX 570 vs. viele D3D-Spiele nativ.. :freak:
Wär natürlich auch schön, wenn man bald gar kein LLVM für 3D mehr bräuchte.

[Achill]

Dann mal Glückwünsche an danarcho und natürlich auch die anderen Entwickler ... :)

[iuno]

Ist drin fuer 19.3, also voraussichtlich Ende des Jahres dann auch in einem stable release.

[aufkrawall]

Man sollte vorerst noch beim ACO-Fork bleiben, bis die Performance-MRs drin sind.

[danarcho]

Dann mal Glückwünsche an danarcho und natürlich auch die anderen Entwickler ... :)
Danke :)
Man sollte vorerst noch beim ACO-Fork bleiben, bis die Performance-MRs drin sind.
Für die, die ein bisschen mehr Stabilität bevorzugen, gibt es jetzt noch dieses Repo (https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa). Es enthält ebenfalls schon die Performance-MRs.

[aufkrawall]

Im SotTR Feral Port ist amdvlk-pro etwas schneller als radv-aco auf Polaris, 43fps vs. 46fps (ersterer Treiber erreicht damit Windows DX12-Performance (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12138903&postcount=158)).
Mit amdvlk-open crasht es im Menü... :facepalm:

[aufkrawall]

Mittlerweile sind es 45fps :) :
https://abload.de/thumb/screenshot_20191112_1lkjmh.png (https://abload.de/image.php?img=screenshot_20191112_1lkjmh.png)

[danarcho]

Danke für die Benches :)
Meiner Erfahrung nach schwankt der SotTR benchmark so extrem, dass man nur schwerlich vergleichen kann (vor allem ist der zum Ende stark CPU-limitiert, weshalb DX12 auch gnadenlos schneller ist). Aber angenommen die Zahlen sind bei dir einigermaßen verlässlich, sieht das doch schon ganz gut aus :)
Ist das upstream oder von Github?

[aufkrawall]

Das ist upstream + !1240. Der Benchmark spuckt hier verlässliche avg-fps aus, ist mit der 570 auch komplett im GPU-Limit.

[danarcho]

ein paar neue Phoronix benchmarks (https://www.phoronix.com/scan.php?page=article&item=radv-aco-navi)

Ansonsten habe ich derweil mal support für CI (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2751) eingebaut. SI dürfte dann auch recht easy sein.

[Gast]

Für die, die ein bisschen mehr Stabilität bevorzugen, gibt es jetzt noch dieses Repo (https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa). Es enthält ebenfalls schon die Performance-MRs.
Mit Ubuntu 18.04.3, diesem Repo und einer RX570 sürzt
RADV_PERFTEST=aco dolphin-emu
mit segfault ab, sobald man versucht ein spiel zu starten. Egal ob mit Ubershader oder ohne.

[danarcho]

Äh ja, nicht unbedingt der richtige Platz für einen Bugreport. Besser wäre es hier (https://github.com/daniel-schuermann/mesa/issues) oder hier (https://gitlab.freedesktop.org/mesa/mesa/issues) aufgehoben. Ich schau mal, ob ich es reproduzieren kann. Danke

[iuno]

cool: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3533

Vielleicht ueberlegt sich's AMD ja nochmal, GCN 1 aus amdgpu zu schmeissen.

[aufkrawall]

Und merged (Geometry Shader btw. auch).
Fehlt noch Tess, aber hier funktioniert LLVM offenbar eh gut (ist z.B. in WT3 oder SotTR quasi gratis, wie halt mit nativem D3D). Weitere Navi-Optimierungen wären imho wesentlich wichtiger.

Wenn Valve jetzt noch jemanden für AMD Kernel-Feinschliff einsetzen könnte, fällt von der Qualität vs. Mesa doch teilweise recht arg ab...

[iuno]

Ich kann mir nicht vorstellen, dass das passiert.

[aufkrawall]

Ist wohl eher ein Wunschtraum, ja...

[danarcho]

Und merged (Geometry Shader btw. auch).
Fehlt noch Tess, aber hier funktioniert LLVM offenbar eh gut (ist z.B. in WT3 oder SotTR quasi gratis, wie halt mit nativem D3D). Weitere Navi-Optimierungen wären imho wesentlich wichtiger.
NGG steht noch auf der Liste, aber mal sehen, was wir jetzt noch in 20.0 reinbekommen. Weitere Optimierungen eher erst wieder nach dem Branchpoint.

Wenn Valve jetzt noch jemanden für AMD Kernel-Feinschliff einsetzen könnte, fällt von der Qualität vs. Mesa doch teilweise recht arg ab...
Das würde ich eher ausschließen. Glaube auch nicht, dass man da als außenstehender so produktiv sein kann, vor allem was zukünftige HW angeht.

[iuno]

Und merged (Geometry Shader btw. auch).

https://www.phoronix.com/scan.php?page=article&item=radv-aco-gcn10

ACO haucht GCN1 tatsaechlich noch mal frisches Leben ein. Teils sind es >10%.
Waere schon ein Witz, wenn AMD GCN1 jetzt aus amdgpu schmeisst, auch wenn da jetzt natuerlich keine Vulkan/ACO vs. OGL (GCN1 haette ohne amdgpu ja kein radv/Vulkan) benchmarks dabei sind.

[Pirx]

jupp, sorgt auch auf meinem 3400G für ein wesentlich flüssigeres Spielgefühl mit DXVK (bei geringfügig höheres fps)

[danarcho]

Sorry, dass ich diesen Thread mal wieder ausgrabe, aber ich wollte einfach ein kleines Update geben:

Hier (https://www.phoronix.com/scan.php?page=article&item=amd-drivers-sep20&num=1) gibt es ein paar neuere Benchmarks (beachtet dabei, dass ACO zur Zeit nur Vulkan unterstützt, die OpenGL Benchmarks benutzen weiterhin LLVM.)

Timur erzählt in diesem Video (https://www.youtube.com/watch?v=FxFPFsT1wDw&t=1736s) ein bisschen über die Fortschritte des vergangenen Jahres und wie ACO zum default backend für RADV geworden ist. Desweiteren gibt es einen eher technischen Überblick über die Compiler-Pipeline und am Ende einen Ausblick auf das, was wir noch so geplant haben.

[Benutzername]

Sorry, dass ich diesen Thread mal wieder ausgrabe, aber ich wollte einfach ein kleines Update geben:

Hier (https://www.phoronix.com/scan.php?page=article&item=amd-drivers-sep20&num=1) gibt es ein paar neuere Benchmarks (beachtet dabei, dass ACO zur Zeit nur Vulkan unterstützt, die OpenGL Benchmarks benutzen weiterhin LLVM.)

Timur erzählt in diesem Video (https://www.youtube.com/watch?v=FxFPFsT1wDw&t=1736s) ein bisschen über die Fortschritte des vergangenen Jahres und wie ACO zum default backend für RADV geworden ist. Desweiteren gibt es einen eher technischen Überblick über die Compiler-Pipeline und am Ende einen Ausblick auf das, was wir noch so geplant haben.


Brauchst Dich nicht zu entschudligen. :smile:

Danke, daß Du das hergebracht hast. :up: Ich kann ja nicht bei allem die Augen offenhalten, obwohl Ich fleißig Proton benutze.

[Simon]

Sorry, dass ich diesen Thread mal wieder ausgrabe, aber ich wollte einfach ein kleines Update geben:

Hier (https://www.phoronix.com/scan.php?page=article&item=amd-drivers-sep20&num=1) gibt es ein paar neuere Benchmarks (beachtet dabei, dass ACO zur Zeit nur Vulkan unterstützt, die OpenGL Benchmarks benutzen weiterhin LLVM.)

Timur erzählt in diesem Video (https://www.youtube.com/watch?v=FxFPFsT1wDw&t=1736s) ein bisschen über die Fortschritte des vergangenen Jahres und wie ACO zum default backend für RADV geworden ist. Desweiteren gibt es einen eher technischen Überblick über die Compiler-Pipeline und am Ende einen Ausblick auf das, was wir noch so geplant haben.
Ich finde das Update hier gut und interessant =)

[aufkrawall]

Schlägt jetzt Windows in SotTR auf der RX 480.
Win 10 20H2 20.9.2 DX12: 46fps
Linux Vulkan RADV ACO mit aktuellem mesa-git: 47fps
Not bad. :cool:

[aufkrawall]

RADV + ACO zersägt auf RDNA2 mittlerweile den PRO-Treiber:
https://www.phoronix.com/scan.php?page=article&item=radeon-rx-6600&num=1
Inkls. weniger Grafikfehler und besseren Shader Compile Zeiten...

[aufkrawall]

und besseren Shader Compile Zeiten...
Jemand hats mal gemessen:
I have some more: replaying this fossilize archive (which basically compiles a bunch of recorded vulkan pipelines) https://drive.google.com/file/d/1c1H...ew?usp=sharing
With fossilize-replay from https://github.com/ValveSoftware/Fossilize
`time fossilize-replay --num-threads 1 rpcs3-fossilize.a342c755b5f2aa72.1.foz`:
amdvlk: 115,88 secs
amdgpu-pro: 32,51 secs
radv/aco: 10,81 secs
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1299177-mesa-s-radv-vulkan-driver-holds-a-narrowing-lead-over-amdvlk-with-ubuntu-21-10-on-wayland/page3#post1299241
:freak:

[Gast_samm]

Sehr schön wie's immer weiter vorangeht :)

Dev-seitig würd mich mal interessieren, ob regelmässig gegen RADV getestet wird, oder ob man da wegen AMD's toolchain doch AMDVLK vorzieht.