News DirectX 10 und DirectX 11: DXVK 1.10.2 für noch besseres Spielen unter Linux erschienen

Tanzmusikus schrieb:
Klar, geht auch. :)

Mir persönlich ist Anzahl und Häufigkeit der Updates einer RR-Distro zu häufig gewesen (Garuda).
Deshalb hatte ich eine andere Distro gesucht ... und bin mittlerweile bei Pop!_OS gelandet.

Grüße
naja, die Häufigkeit hat eben den Vorteil, daß Du immer das aktuellste hast... und wenn Du viel selbst kompilierst, brauchst keine PPAs, weil alles im AUR zu finden ist.
 
Karan S'jet schrieb:
... weil die Technologien von nVidia in der Regel Hardware basiert sind und so auch etwas bessere Ergebnisse erzielen. Hat alles Vor- und Nachteile.
wie man aber bei FSR 2.0 sieht, bedarf es dazu keine Hardware basierte Lösungen. Details sind mal bei dem einem mal beim anderen besser, aber insgesamt sind sie gleichwertig. Der Nachteil der hardware basierten Lösung ist, die User zu beschränken und einschränken. Der Nachteil überwiegt. Dadurch, daß die Lösung OpenSource ist, kommt es eben dazu, daß die Leute FSR 2.0 in die Spiele reinmodden können, was mit nvidia niemals funktionieren würde, da DLSS vorarbeiten auf nvidias Servern bedarf, um für das Spiel ein Profil zu erstellen.
 
  • Gefällt mir
Reaktionen: Tanzmusikus und Kuristina
Eli0t schrieb:
wie man aber bei FSR 2.0 sieht, bedarf es dazu keine Hardware basierte Lösungen.

Fragt sich nur, ob FSR2 auch so viel an Leistungsplus bringt wie DLSS auf Performance. Hab ich noch nicht ausprobiert.
 
NoXPhasma schrieb:
Wird mit der nächsten DXVK Version überflüssig. Durch die neue Vulkan Extension VK_EXT_pipeline_creation_cache_control kann DXVK dann wie auch DX9-11 Shader im voraus kompilieren.
Habe das bereits mit dem Nvidia Vulkan Beta Treiber testen können und es ist mega gut. Im Grunde eliminiert es jedwedes stottern durch Shader kompilieren.
Wird diese Erweiterung jeder Vulkan Treiber aufnehmen oder ist die Methode aus dem Patch immer noch notwendig als Fallback? Sonst könnte man den Patch ja upstream einpflegen.
 
riloka schrieb:
Wird diese Erweiterung jeder Vulkan Treiber aufnehmen oder ist die Methode aus dem Patch immer noch notwendig als Fallback? Sonst könnte man den Patch ja upstream einpflegen.
Die Erweiterung wird auf jeden Fall im Nvidia Treiber (Ist schon im Vulkan beta) und in AMD RADV (arbeit das zu implementieren läuft bereits) landen. Im Intel Treiber vermutlich ebenfalls, aber da habe ich gerade keine Information zu. Bei Nvidia werden allerdings GPUs außen vor bleiben die nur noch mit dem 470 Treiber unterstützt werden (600 Series und älter).

Deswegen gibt es auch eine Warnung in den changelogs von DXVK. 1.10.2 könnte also die letzte DXVK Version sein die auf einigen älteren Nvidia GPUs funktioniert.
Ergänzung ()

Und einpflegen muss man in DXVK nichts, wenn du die master branch baust, denn da ist das bereits eingepflegt worden.
 
Zuletzt bearbeitet:
NoXPhasma schrieb:
Und einpflegen muss man in DXVK nichts, wenn du die master branch baust, denn da ist das bereits eingepflegt worden.
Warum ist der async patch dann ein eigenes Git Repository weiterhin?
 
Das da ein extra repo ist heißt erstmal nur genau das :D (hat noch keiner gelöscht? wer weiß). das bedeutet ja noch nicht, das kein Code übertragen/übernommen wurde.
Das könnte man dann herausfinden über die commits wenn man sich da auskennt oder einfach über die news.

Edit:
Wenn ich ganz kurz darüber nachdenke hat es zum Beispiel einen Vorteil das alte Repo noch beizubehalten:
dort ist dann noch der werdegang zum Patch enthalten und nicht nur der commit als gesamtes, der ggf übertragen wird in den main Zweig. (wenn das so funktioniert, ich bin kein Git Profi, habe da eingeschränkte Kenntnisse)
 
@riloka Ach du beziehst dich auf den Async patch. Das hatte ich nicht so heraus gelesen. Ob der noch funktionieren wird, weiß ich nicht, muss dann vermutlich angepasst werden. Da muss man dann mal abwarten.

Aber wie schon geschrieben wird DXVK in zukünftigen Versionen sowieso den Zopf von alten Treiberversionen abschneiden. Ob der Patch dann noch nötig ist, ist also fraglich.

Der Async patch ist übrigens code der ganz am Anfang mal in DXVK enthalten war. Aber aus verschiedenen Gründen entfernt wurde. Unter anderem weil er zu false positives in Anti-Cheat software führen kann.
 
NoXPhasma schrieb:
Unter anderem weil er zu false positives in Anti-Cheat software führen kann.
Ich dachte eher dass gepatchte Versionen von Dritten ein Problem sind, weil man nur das Original Projekt auf der Whitelist hat :)
 
Das ist tatsächlich kein Problem, also daran liegt das nicht. Das Spiel bekommt das auch gar nicht mit, welche Version von DXVK läuft. Aber wenn unerwartetes verhalten im Renderpath auftaucht schon.
 
W0dan schrieb:
Somit schränkt mich Linux bei der Wahl meiner GPU ein bzw. sollte ich mir wohl erstmal ne neue kaufen, bevor ich umsteigen sollte? Na das sind ja tolle Umstände.
So ein dummes Argument! Nein, nvidia schränkt Dich ein... deswegen gibts auch das Linus meme mit "fck u nvidia"... weil nvidia alles verdongelt, firmware für den Betrieb der Karten nicht freigbt etc. Es hat ein Jahr gedauert, bis nvidia die Firmware für die 30iger Serie freigegeben hat damit der freie Treiber damit endlich laufen kann... ohne Herstellerunterstützung kann der freie Treiber weder performant sein, noch alle Funktionen unterstützen. Du kannst natürlich den nvidia blob installieren, der allerdings einige Nachteile mit sich bringt, was sich nun bedingt bessern soll. Seit zwei Jahrzehnten hat niemand nvidia daran gehindert auch OpenSource Grafiktreiber zu unterstützen.
OpenSrouce gibts bei nvidia nur im Serversprace. Mellanox Treiber sind selbstverständlich im Kernel und werden auch von nvidia OpenSource entwickelt. CUDA Software ist unter Linux auch 0immer aktuell. nvidia scheisst eben auf Gamer, weil die keine Kohle bringen, so ne Server Grafikkarte bringt halt gleich mal 5000-20000$, die paar Hunderter bis 1,2k die Gamer abdrücken tangieren nvidia halt nicht im geringsten. Und für ARM braucht nvidia auch Linux oder glaubst Du, die könnten mit Windows irgendwas anfangen?

Es hat also nichts mit Linux zu tun, daß AMD unter Linux besser aufgestellt ist.
Ergänzung ()

Karan S'jet schrieb:
Fragt sich nur, ob FSR2 auch so viel an Leistungsplus bringt wie DLSS auf Performance. Hab ich noch nicht ausprobiert.
Kannst Du an den Tests nachvollziehen, daß das auch ziemlich gleichauf liegt. Je älter die Karte desto schlechter die Leistung. Aber immerhin läuft FSR2 auch auf GTX/RTX Karten.
 
  • Gefällt mir
Reaktionen: {Sardaukar} und Kaito Kariheddo
Alexander2 schrieb:
Ich kann (hier gerade auf dem Laptop auf Gnome-Wayland) nur zwischen 100% und 200% umschalten in den Standardeinstellungen (keine Mods)
Hmm das ist seit 2019 verfügbar daher bin ich mal von aus gegangen das es irgendwann Standardmäßig aktiviert ist, musst wohl diese gsettings Zeile immer noch in die Konsole pasten:
https://wiki.archlinux.org/title/HiDPI#Wayland

Nun mag sein das XWayland buffer bisschen verschwommen sind, aber wieso die option dann nicht angeboten wird, kann man ja wieder ausschalten wegen mir nen Warnschild hin machen, aber versteh nicht warum das noch deaktiviert ist, dafür laeufts viel zu gut.
 
Eli0t schrieb:
Kannst Du an den Tests nachvollziehen, daß das auch ziemlich gleichauf liegt. Je älter die Karte desto schlechter die Leistung. Aber immerhin läuft FSR2 auch auf GTX/RTX Karten.

Jo und wenn ich mir Teste anschaue, dann sehe ich auch, dass AMD Karten keine Alternative sind wenn man vernünftig mit Raytracing spielen will.

Und auch für Nvidia Broadcast hat amd keine Alternative.
 
blackiwid schrieb:
versteh nicht warum das noch deaktiviert ist
Bei Ubuntu und anderen Distributionen ist es ja auch meist aktiviert oder es gibt in den Einstellungen einen Regler zum Aktivieren. Aber bei Fedora, was ja auch mit unangepasstem Gnome läuft, muss man auch noch manuell die Variable setzen.
 
NoXPhasma schrieb:
Durch die neue Vulkan Extension VK_EXT_pipeline_creation_cache_control kann DXVK dann wie auch DX9-11 Shader im voraus kompilieren.

Neu?
https://registry.khronos.org/vulkan...l/VK_EXT_pipeline_creation_cache_control.html
Last Modified Date
2020-03-23

NoXPhasma schrieb:
Die Erweiterung wird auf jeden Fall im Nvidia Treiber (Ist schon im Vulkan beta) und in AMD RADV (arbeit das zu implementieren läuft bereits) landen.
RADV kann die erwähnte extension schon seit 2 jahren

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5072
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Zurück
Oben