Mit wine-wow64 32-bit-Windowsanwendungen ohne 32-bit-Linux-Bibliotheken ausführen können

[Caramon2]

Bei diesem besch…en Wetter habe ich heute gerade mal wine10-wow64 eingerichtet: Komplett neu, damit nichts verfälscht.

dxvk hat übrigens immer noch diesen (bekannten!) Bug, den ich wie in #1 beschrieben korrigiert habe:

Wenn ich wine-wow64 installiert und eingerichtet habe und dann dxvk installiere, kopiert es die DLLs doppelt in "system32"

Meine Testumgebung hat sich inzwischen geändert:

Vorher hatte ich das Windows 11 genutzt, das ich zusammen mit Windows 10 testweise parallel zu ComodoreOS installiert hatte. Da ich Win10 und CommodoreOS nicht mehr brauche, habe ich neulich die SSD gelöscht und Win11 neu installiert. (wie gehabt offline: es wird von mir nie wieder eine Internetverbindung bekommen)

Der Einfachheit halber zusammen mit meiner Artix+Wine-Installation, damit beide die Benches von der "NTFS"-Partition nutzen können:

(das LMDE brauche ich für Virtualbox 6.1.50: die letzte Version, die noch macOS 10.14 (und Win7) unterstützt, das ein Bekannter aus Kompatibilitätsgründen noch nutzt)​

Ja, das ist eine USB-SSD und auch Windows lässt sich davon booten: Wenn es im BIOS-Modus installiert wurde.

---

Nachtrag:

Ich werde übrigens bei Wine-wow64 Version 10.0 bleiben und erst zur 11.0 aktualisieren, da das eine Stable ist:

Alle Nachkommastellen sind Developer-Versionen, so dass Wine 10.1 praktisch die erste öffentliche Beta von Wine 11 sein wird.

Falls die Stable aktualisiert wird, wird es 10.0.1 - Wine 9.0 wurde z. B. nicht aktualisiert, vorletztes Jahr ging es dagegen bis Wine 8.0.2: https://www.winehq.org/news/25

 

[Caramon2]

Hi!

Das hat leider etwas gedauert, da Windows mal wieder Ärger gemacht hat und nicht booten wollte. (s. Anhang) - Also ich es wieder hinbekommen habe, hatte ich keine Lust mehr. - Bin ich froh, schon lange nicht mehr auf dieses Meisterstück des Marktführers angewiesen zu sein.

Hardware:

• AMD FX-8350 (4 GHz X8), mit deaktiviertem TurboCore, dafür spannungsoptimiert (-0,08 V Offset)
• 4x8 GiB DDR3L @ 1,21 V
• Radeon RX 560D mit 2 GiB RAM

Software:

• Artix-Linux mit Kernel 6.12.9, Mesa 24.3.4 und Wine 10-wow64 (ohne Mono und Gecko)
• Windows 11 22H2 offline frisch installiert, keine Swap, "powercfg -h off" und GraKa-Treiber 24.9.1

Cinebench 11.5 32-bit (Wine / Windows):

Wow64 bleibt bei 32-bit-3D weiter sehr lahm, Windows hatte dabei wie gehabt Probleme:

Cinebench 11.5 64-bit (Wine / Windows):

Cinebench 15 64-bit (Wine / Windows):

Superposition konnte ich aufgrund meiner Hardware nur in FullHD Medium benchen:

OpenGL (Wine / Windows):

DirectX (Wine / Windows):

Linux native (nur OpenGL):

 

[Caramon2]

Mit meiner alten GCN4-GraKa (2 GB RX 560D) bringt Mesa 25 nicht viel.

Bei den Cinebenches gar nichts (weder OpenGL noch Rendering) und beim Superposition nur was bei OpenGL, wobei die Windows-Version mir Wine und die Linux-Version mit ca. 3,3% gleich profitieren:

mesa 24.3.4, linux 6.13.4:

Superposition-Windows:
OpenGL: 2913 Pt, fps: 17,97 min, 21,79 avg, 27,96 max
DirctX: 3118 Pt, fps: 19,59 min, 23,32 avg, 30,26 max

Superposition-Linux:
OpenGL: 2950 Pt, fps: 18,17 min, 22,07 avg, 28,39 max

---
mesa 25.0.1, linux 6.13.4:

Superposition-Windows:
OpenGL: 3012 Pt, fps: 18,49 min, 22,53 avg, 29,12 max
DirctX: 3111 Pt, fps: 19,55 min, 23,28 avg, 30,23 max

Superposition-Linux:
OpenGL: 3051 Pt, fps: 18,65 min, 22,83 avg, 29,63 max

 

[Deinorius]

Unter Linux laufen Radeon Grafikkarten teilweise (oder meistens) eh schon besser als unter Windows. Ein paar Prozentpunkte sind mehr, als man sich gerade für alte Modelle noch erhofft.

 

[Caramon2]

Da ich mit alter Hardware und nur dem offenen Treiber teste, hier ein ein Vergleich zum proprietäre Treiber auf aktueller Hardware:

Mesa RADV vs. AMDVLK Vulkan Driver Performance For The AMD Radeon RX 9070 Series

Mal ist der eine etwas schneller, mal der andere, der proprietäre streikt sogar bei einem Spiel, aber da noch sehr neu, haben beide Treiber sicherlich noch einiges an Potential:

But a rather nice showing with Mesa RADV at launch day already running 96.7% the speed of the AMDVLK driver for the Radeon RX 9070 XT... Keeping in mind RADV+ACO is developed by engineers from Valve, Red Hat, Google, and the open-source community while AMD focuses much of their effort on AMDVLK.

 

[Deinorius]

Die wichtigste Aussage dieses Reviews, wenn auch nicht neu, ist jedoch, dass man für Raytracing nur AMDVLK verwenden sollte. Das Gute ist, dass man relativ einfach zwischen den Treibern wechseln kann, indem man eine environment variable einstellt. Gut wäre, wenn das in Steam/Lutris/HGL einfach mittels Hakerl ausgewählt werden kann (in Lutris irgendwie möglich, glaub ich).
Mehr Benchmarks mit RT wären gut.

https://wiki.archlinux.org/title/Vulkan#Switching_between_AMD_drivers
https://www.reddit.com/r/linux_gaming/comments/h8b7zv/amd_gpu_vulkan_driver_how_to_easily_switch/
https://www.gamingonlinux.com/2021/...etween-vulkan-drivers-amdvlk-and-radv-easier/

 

[Caramon2]

Mehr Benchmarks mit RT wären gut.

Unten in "Related Articles" gibt es u. a. RADV vs. AMDVLK Radeon Vulkan Ray-Tracing Performance For Mid-2024 und dort gleich einen Verweis auf AMD vs. NVIDIA Vulkan ray-tracing benchmarks.

Für meine Hardware ist Strahlenverfolgung noch utopisch.

 

[Deinorius]

Mir geht es um mehr.

• Andere Webseiten mit Linux Benchmarks (nicht nur irgendwelche YouTuber)
• Aktuelle Benchmarks, auch mit den neuen Grafikkarten
• Eine Testsuite mit richtigen Spielen und synthetischen Benchmarks als Zusatz
• Separate Fokussierung auf Raytracing Leistung

Nichts gegen Phoronix, dort bekommt man seine Linux Benchmarks und ich lese diese gerne. Aber gerade bei Gaming Benchmarks testet er Spiele/Anwendungen, die aus Gamer-Sicht kaum interessant sind und weil das auch nicht sein primärer Zugang ist, gibt es auch kaum spezielle Reviews, die bestimmte Fragestellungen haben. Dafür hat er genug anderes zu testen.

 

[Caramon2]

@Deinorius: Da kann ich dir nicht helfen, da ich mit sowas nichts mehr am Hut habe.

Ganz früher (vor über 20 Jahren) habe ich gerne 3DCenter.org (Wow! Sieht immer noch genauso aus wie damals…) gelesen: Sowas für Linux wäre wahrscheinlich das richtige, oder?

Nachtrag:

Ich habe deine Frage an die Opera-KI durchgereicht. Neben viel am Thema vorbei wurde das vorgeschlag: OpenBenchmarking.org

Ob das was taugt kann ich nicht sagen, da mir die Seite auf dem Handy viel zu unübersichtlich ist.

 

[Deinorius]

Das war keine spezifische Frage an dich gerichtet, sondern eine allgemeine Aussage.

Ich habe deine Frage an die Opera-KI durchgereicht. Neben viel am Thema vorbei wurde das vorgeschlag: OpenBenchmarking.org

Das ist die Benchmark-Result Seite (Phoronix Test-Suite) von phoronix.com.

 

[Caramon2]

Das war keine spezifische Frage an dich gerichtet, sondern eine allgemeine Aussage.

Ein Link zu einer Seite mit vernünftigen Benchmarks würde gut zum Thread passen, also habe ich geguckt, ob ich auf die schnelle was finde.

Eigentlich ist der Thread dazu gedacht, dass auch andere was dazu beitragen können, weil ich Wine ja kaum nutze und insbesondere nichts zu Spielen sagen kann, aber diesbezüglich bin ich etwas enttäuscht: Eine "Community" hatte ich mir anders vorgestellt.

 

[Deinorius]

Ein Link zu einer Seite mit vernünftigen Benchmarks würde gut zum Thread passen, also habe ich geguckt, ob ich auf die schnelle was finde.

Alles gut, es war nur eine Reaktion auf den ersten Satz in deinem Kommentar.

Eine "Community" hatte ich mir anders vorgestellt.

Ich weiß jetzt nicht, wo das jetzt herkommt. Falls eine Aussage von mir irgendwie falsch rübergekommen ist, dann war es definitiv nicht so gemeint.
Wenn es darum geht, dass nur noch du diesen Thread aufrechterhältst ... Ähm, ja, kommt vor. ¯\(ツ)/¯

 

[Caramon2]

Ich weiß jetzt nicht, wo das jetzt herkommt.

Ne, dich hatte ich damit überhaupt nichts gemeint.

wow64 (keine 32-bit-Abhangigkeiten) ist eine tolle Entwicklung und ich wollte das eigentlich nur vorstellen, weil viele das vielleicht noch nicht kennen und sich dann Leute, die sich besser mit Wine auskennen, darüber austauschen können, damit alle was davon haben.

 

[Utensil1538]

WineHQ reicht mir für fast alle Spiele. Da braucht es kein Lutris oder Winetricks.

 

[Pummeluff]

Ich verwende Lutris sehr gerne. Gerade die Auswahl der Proton-Versionen find ich klasse. Dazu kann man noch per Schalter einfach Gamescope für HDR aktivieren. Lutris nimmt einem schon viel Arbeit ab.

 

[Caramon2]

Linux Kernel 6.14

Ein neuer NT-Synchronisationstreiber reduziert den Overhead bei der Emulation von Windows Programmen unter Linux. Dadurch laufen Windows-Spiele flüssiger und mit weniger Verzögerung.

Ob das wohl wirklich spürbares bringt?

 

[Utensil1538]

Habe ich gerade inkl. Mesa 25.0.2 und AMVLK v-2025.Q1.3 auf mein Mint 22.1 installiert

 

[Deinorius]

Linux Kernel 6.14

Ob das wohl wirklich spürbares bringt?

Hängt sehr stark vom Spiel ab. Cyberpunk 2077 wird immer wieder gerne als ein Beispiel genannt, wo der Unterschied größer ist. Die oft zitierten Leistungsverbesserungen mit teilweise einigen hunderten an Prozent hingegen sollten ignoriert werden, da diese mit winesync verglichen wurden. Es ist zumindest relevant, wenn man nur upstream wine für Spiele verwendet ... wieso man das auch immer tun wollen würde.
Wer jedoch ernsthaft spielt (proton, GE-proton, usw.), verwendet immer esync/fsync, was man als eine Hack-Variante bezeichnen kann, die gut genug war. NTSync jedoch ist jetzt die wahre Variante, die gleich auf Kernel-Level agiert. Ich bin schon auf Benchmarks gespannt. Es braucht halt aber auch wine/proton mit aktivem NTSync.

Ergänzung (Gestern um 13:22)

Zitat von Pierre-Loup Griffais zu NTSync auf Bluesky:

We already include fsync, which should be as fast or faster as ntsync. We developed ntsync as a general solution that'd be acceptable in upstream Wine, but there's no urgency in including it in the Deck / SteamOS kernel.

Quelle

 

[Caramon2]

Die oft zitierten Leistungsverbesserungen mit teilweise einigen hunderten an Prozent hingegen sollten ignoriert werden, da diese mit winesync verglichen wurden.

Als Rechenbeispiel: Die eigentliche Funktion wird zwar doppelt so schnell, aber da sie an der Gesamtleistung nur mit 1% beteiligt ist, beträgt der effektive Vorteil gerade mal 0,5%.

 

[Deinorius]

Der Vergleich ist nicht falsch, beschreibt es aber nicht ausreichend, man bräuchte eine große Formel, um das formidabel zu beschreiben. Besser wäre es, das Ganze mit dem Verkehr zu vergleichen. Hat ein Auto einen Unfall, oder fährt es nicht schnell genug im Vergleich zu den anderen, entsteht ein Stau. Aber der Verkehr gefällt mir als Vergleich auch nicht so recht.
Wirklich vergleichbar ist das mit dem Bau. Jedes Gebäude stellt einen Frame dar. Einzelne Bereiche bauen der Reihe nach oder synchron einen Frame auf. NTSync/esync/fsync/winesync vergleiche ich am ehesten mit der Logistik. Hapert es an einer Stelle, verzögert sich der gesamte Bau, weil ein Bereich auf den anderen aufbaut und dieser wiederum für einen weiteren vorbereiten muss.
Man darf mich gerne korrigieren, aber so erkläre ich mir das.