Testbericht unter Linux

Hier kann alles Allgemeine rund um Zusi 3 gefragt und beantwortet werden. Neuigkeiten zum Programm werden hier erscheinen.
Nachricht
Autor
Flo Zille
Beiträge: 201
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#561 Beitrag von Flo Zille »

Der memory leak mit Proton 7 wird wohl mit dem nächsten Proton 7-Release abgestellt sein, dann steht einer stundenlangen Kassel-Hamburg-Fahrt hoffentlich auch mit "nur" 16 GB RAM oder weniger nichts mehr im Wege (wenn man dxvk in Proton abschaltet oder per dxvk.conf das neue 64-bit-dxvk-Grafikproblem beseitigt).

Fabian H.
Beiträge: 3
Registriert: 18.10.2021 15:23:07

Re: Testbericht unter Linux

#562 Beitrag von Fabian H. »

Johannes hat geschrieben: 06.03.2023 18:20:36 "libusb-1.0.so.0: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden"

Es muss libusb in der 32-Bit-Variante installiert sein. Weiß nicht, wie man das bei Manjaro macht.
libusb war eigentlich in der 32bit Version installiert. Nach einer Neuinstallation wird auch alles gefunden.
Aber jetzt kam ein neues Problem:
Der Web Installer gibt mir eine "Zugriffsverletzung bei Adresse 7CCB27FC. Lesen von Adresse FFFFFFFF." aus.
Die Konsole sieht jetzt so aus:

Code: Alles auswählen

007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
Bitte 'wine winecfg' aufrufen und unter 'Drives' eine neue virtuelle Festplatte mit folgenden Einstellungen anlegen:
 - Path: <Pfad, an dem der Zusi-USB-Stick eingehängt ist>
 - Type: Floppy disk  [zum Anzeigen dieses Feldes auf "Show Advanced" klicken].
Auch dann, wenn Wine schon eine virtuelle Festplatte mit demselben "Path" angelegt hat!
Nach Ende der Installation kann die virtuelle Festplatte wieder entfernt werden.

Bitte mit Enter-Taste bestätigen, dass die Einstellungen so sind wie beschrieben.

0110:fixme:thread:GetThreadUILanguage : stub, returning default language.
0110:fixme:nls:RtlGetThreadPreferredUILanguages 00000038, 00CAD9D4, 00000000 00CAD9FC
0110:fixme:nls:get_dummy_preferred_ui_language (0x38 0x407 00CAD9D4 00000000 00CAD9FC) returning a dummy value (current locale)
0110:fixme:nls:RtlGetThreadPreferredUILanguages 00000038, 00CAD9D4, 027BA680 00CAD9FC
0110:fixme:nls:get_dummy_preferred_ui_language (0x38 0x407 00CAD9D4 027BA680 00CAD9FC) returning a dummy value (current locale)
0110:fixme:system:NtUserSystemParametersInfo Unknown action: 8220
0110:fixme:wtsapi:WTSRegisterSessionNotification Stub 0001007E 0x00000000
0110:fixme:uxtheme:BufferedPaintInit Stub ()
0110:fixme:system:EnableNonClientDpiScaling (00010090): stub
0110:fixme:system:EnableNonClientDpiScaling (000100A6): stub
0120:fixme:imm:ImeSetActiveContext (000000000002002A, 0): stub
0120:fixme:imm:ImmReleaseContext (0000000000020036, 000000000002002A): stub
0110:fixme:imm:ImeSetActiveContext (00010076, 1): stub
0110:fixme:imm:ImmReleaseContext (000100A6, 00010076): stub
0110:fixme:richedit:editor_handle_message EM_SETMARGINS: stub
0110:fixme:richedit:editor_handle_message EM_SETEDITSTYLE: stub
0058:fixme:nsi:ipv6_forward_enumerate_all not implemented
0058:fixme:nsi:ipv6_forward_enumerate_all not implemented
0110:fixme:wincodecs:BitmapScaler_Initialize unsupported mode 4
device 0: class 9, manufacturer 3, product 2
 - bus 4, device 1
 - configuration 0
  - interface 0
   - altsetting 0
device 1: class 0, manufacturer 1, product 2
 - bus 3, device 3
 - configuration 0
  - interface 0
   - altsetting 0
  - interface 1
   - altsetting 0
device 2: class 0, manufacturer 1, product 2
 - bus 3, device 2
 - configuration 0
  - interface 0
   - altsetting 0
  - interface 1
   - altsetting 0
  - interface 2
   - altsetting 0
device 3: class 9, manufacturer 3, product 2
 - bus 3, device 1
 - configuration 0
  - interface 0
   - altsetting 0
device 4: class 9, manufacturer 3, product 2
 - bus 2, device 1
 - configuration 0
  - interface 0
   - altsetting 0
device 5: class 0, manufacturer 1, product 2
 - bus 1, device 3
 - configuration 0
  - interface 0
   - altsetting 0
 - reading from /sys/bus/usb/devices/1-5/serial

Grüße
Fabian

Flo Zille
Beiträge: 201
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#563 Beitrag von Flo Zille »

Damit es nicht so aussieht, als ob ich dich ignoriere: Leider kann ich dazu nichts sagen.


Aber ein anderes Thema, das mir aufgefallen ist: Einige wenige Befehle bzw. Funkgespräche werden unter Wine nicht angezeigt, das Fenster bleibt weiß. Das betrifft Befehle, die nicht als HTML-Datei erstellt werden, sondern direkt als PNG-Datei (laut Zusi-Doki ist das nicht vorgesehen, "Die angezeigte Datei muss im html-Format erstellt sein und wird in einem in Zusi integrierten Fenster des Internet-Explorers angezeigt", funktioniert aber unter Windows). Ein betroffener Zug ist 79706 im Fahrplan Luitpoldhuette-Klardorf_2022_06Uhr-10Uhr.fpn, direkt am Anfang wenn von der Abstellung zum Bahnsteig rangiert werden soll.

Ein Workaround ist, mittels regedit im Wine-Präfix unter "HKEY_CLASSES_ROOT\MIME\Database\Content Type\image/png" einen Schlüssel "CLSID" mit dem gleichen Inhalt wie z.B. in "image/gif" anzulegen. Ist aber nicht für das "Upstreaming" in wine geeignet, weil unter Windows dieser Schlüssel für image/png auch nicht existiert.

Meine Versuche, einen unter Windows funktionierenden und unter Wine fehlschlagenden Test für das PNG-Laden in einem "ieframe" zu erstellen, den wine für die Anzeige der Befehle nutzt, haben mich dann beinahe in den Wahnsinn getrieben. Es schien einfach keine Konfiguration des Tests unter Windows zu laufen. Bis ich dann gestern bemerkt habe, dass es unter Windows 10 eben manchmal tatsächlich auch nicht funktioniert: Während das Windows auf meinem eigenen Rechner, der meistens Ubuntu ausführt, PNG-Dateien in einem ieframe völlig problemlos anzeigt und auch das Erstellen eines funktionierenden Tests daher leicht ist, weigert sich der andere Windows 10-Rechner im Haushalt, den ich i.d.R. für die wine-Tests nutze, beharrlich. Statt die PNG-Datei anzuzeigen, erscheint nur eine weiße Seite und es öffnet sich stattdessen ein Download-Dialog für die PNG-Datei. Deshalb schlugen dort auch die ganzen Test-Bastelversuche bei nicht sichtbarem Fenster immer fehl. Hier hat jemand das gleiche Phänomen in einer anderen Software bemerkt.

Meine aktuelle Theorie für die Sache ist jetzt, dass Zusi normalerweise das Webview2 nutzt, welches auf Edge basiert und kein Problem mit PNGs hat (das hat Carsten ja für 3.5 bekanntgegeben, wenn ich mich richtig erinnere, und wir haben jetzt auch WebView2Loader.dll-Dateien). Nur wenn Edge nicht verfügbar ist, wie wohl eben bei Nutzung mit Wine, gibt es einen Fallback auf die alte Internet Explorer-basierte "IWebBrowser2"-Lösung. Und hier implementiert zumindest Wine derzeit die Variante, dass PNG-Dateien nicht funktionieren, so wie das wohl teilweise auch unter Windows der Fall zu sein scheint, aber irgend eine Konfiguration gibt es, mit der es dann doch funktioniert – so wie auf meiner Win10-Installation – und vielleicht löst Zusi diese Konfiguration ja auch irgendwie programmseitig aus.

Das doofe an der Situation ist jetzt, dass man die wine-Leute immer am besten von einer Änderung überzeugen kann, wenn man einen automatisierten Wine-Test hat, der demonstriert, dass etwas auf Windows funktioniert und unter Wine nicht. Das dürfte in dem Fall jetzt schwierig werden, denn tatsächlich würde der Test ja auch unter Windows nicht immer funktionieren, falls ich nicht noch herausfinde, wie man Windows zuverlässig davon abbringen kann, die Datei nur zum Download anzubieten. Vielleicht kann man auf recht umständliche Art einen abgespeckten Test basteln, der nur einen Teil der momentan für ieframe-Tests üblichen Dinge prüft (unter Wine gibt es beim PNG-Versuch derzeit einen expliziten Fehler, aber unter Windows nicht, denn es kommt ja immerhin zumindest erfolgreich der Datei-Download-Dialog).

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Testbericht unter Linux

#564 Beitrag von Carsten Hölscher »

Also ist in dem Fahrplan als Befehlsdatei direkt die png-Datei angegeben? Das wäre dann wirklich falsch, es soll immer eine html-Datei sein.

Carsten

Benutzeravatar
Leonard K.
Beiträge: 1049
Registriert: 12.06.2020 19:03:07
Aktuelle Projekte: NMH

Re: Testbericht unter Linux

#565 Beitrag von Leonard K. »

Das ist so in der Strecke konfiguriert (auch, um die Anzahl der Dateien zu reduzieren). Ich kann aber bei Gelegenheit mal die 14 HTML-Dateien für die Befehler erstellen und in der Strecke entsprechend anpassen.

schorlemischer
Beiträge: 6
Registriert: 27.04.2019 19:43:40

Re: Testbericht unter Linux

#566 Beitrag von schorlemischer »

Hallo zusammen,
Fabian H. hat geschrieben: 08.03.2023 14:46:19 Aber jetzt kam ein neues Problem:
Der Web Installer gibt mir eine "Zugriffsverletzung bei Adresse 7CCB27FC. Lesen von Adresse FFFFFFFF." aus.
Kann ich bestätigen. Da ich mein Tagesziel einer funktionierenden Zusi Installation auf meiner Linux Maschine aber unbedingt erreichen wollte, hab ich versucht den Fehler einzugrenzen und habe sogar etwas gefunden: In serial.cpp#L100 des Hilfsprogrammes ist ein DEBUG Aufruf. Ich kann mit meinen stark limitierten C++-Kenntnissen nicht erklären warum, aber als ich den Aufruf ausgebaut habe, lief der Installer weiter ;)

Viele Grüße
schorlemischer

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Testbericht unter Linux

#567 Beitrag von Johannes »

Danke, ich hab den Aufruf rausgenommen -> Version 0.14. Auf was für einer Linux-Distribution und mit welcher Wine-Version bist du unterwegs?

schorlemischer
Beiträge: 6
Registriert: 27.04.2019 19:43:40

Re: Testbericht unter Linux

#568 Beitrag von schorlemischer »

Hi Johannes,

bei mir läuft aktuell Arch Linux mit Kernel 6.2.6 und wine 8.4 staging.

Benutzeravatar
Paneologe
Beiträge: 96
Registriert: 25.03.2023 13:49:28

Re: Testbericht unter Linux

#569 Beitrag von Paneologe »

Moin,

ich möchte hier auch meinen Testbericht von der Steam-Version von Zusi 3 unter openSUSE 15.4 mit Proton 7.0 anhängen.

CPU:
AMD Ryzen 7 2700X Eight-Core Processor
Grafik:
VGA compatible controller: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] (rev a1)
nvidia-glG05-470.161.03-lp154.59.1.x86_64

A) Vulkan-Bugfix:
erstellung von dxvk.conf wie unter https://www.forum.zusi.de/viewtopic.php ... 11#p344411 beschrieben war notwendig.

B) Das Öffnen der Konfiguration verursacht folgenden Fehler:
Bild
Die Bilder unten rechts werden nicht geladen, sonst ohne weitere Auswirkungen

C) Das Beenden der Simulation verursacht meist Probleme, nach Auswertung der Fahrt bleibt es im Simulator-Bild hängen, das nochmalige "Beenden" verursacht diverse Fehlermeldungen (bei Bedarf kann ich Details nachreichen) - Das Beenden der Anwendung ist nur über "kill" oder über Steam-Button "STOP" möglich.

D) Die Zusidateiverwaltung bringt eine Fehlermeldung, der Zusi-Server werde nicht erreicht. Somit nicht nutzbar

sonst keinerlei Probleme mit Zusi 3 oder ZusiDisplay.
Zusimeter und Zusistart habe ich nicht zum laufen gebracht.

Viele Grüsse
Dell Precision T7600, 2 x Intel(R) Xeon(R) CPU E5-2665 (8 cores per CPU, 2 threads per core, 20MB L3 cache, 2.4/3.1GHz) (⁼32 logische CPUs), 512 GiB DDR3 ECC registered 1600 MT/s, NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] (11GB GDDR5X 352 bit), SAS Hardware RAID Level 1

Flo Zille
Beiträge: 201
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#570 Beitrag von Flo Zille »

Zu den Problemen mal der aktuelle Stand:

A) Falls die Leute von dxvk gnädig sind und die Erweiterung der "Handelt es sich hier um Zusi?"-Abfrage auf die "ZusiSim.64.exe" akzeptieren, sollte das dann auch wieder ohne dxvk.conf funktionieren. So ganz glücklich ist wohl keiner mit dieser Lösung, nur gibt es derzeit glaub ich keine bessere.
B) Ich nutze ein auf wine 8.3 basierendes Proton (proton_tkg_8.3.r0.g575f6f67), und dort ist das Problem wohl gelöst, jedenfalls bei mir nicht mehr reproduzierbar. Hoffentlich somit dann auch mit einem Proton 8.0 von Valve, das vielleicht ja irgendwann mal kommt.
C) Ist mir glaube ich schon länger nicht mehr begegnet, auch mit Proton 7 nicht, aber ich meine mich daran zu erinnern – weiß nicht genau, ob ich da nur Glück hatte.
D) Also die normalen Updates sollen wir Steam-Nutzer ja ohnehin nicht über die Dateiverwaltung installieren, habe da also noch nie etwas ausprobiert. Aber unter "Verwaltung" -> "Verwaltung Add-Ons" erscheint bei mir eine Liste von eingereichten Add-Ons (aktuell nur ein 422), die ich dann mit meinem 8.3-basierten Proton auch herunterladen kann.

Ich würde noch anmerken, dass die aktuelle Proton 7-Version von Valve einen üblen ZusiDisplay-Memory Leak verursacht. Der wird aber mit dem nächsten Proton-Release (egal ob 7 oder 8) behoben. Und eine Zugwende macht glaube ich in Proton 7 noch die integrierten Displays kaputt, in 8 sollte es klappen. Außerdem bringt Proton 8 Performance-Verbesserungen für die integrierten ZusiDisplays (neue zlib-Version und schwächere PNG-Komprimierung).

Benutzeravatar
Paneologe
Beiträge: 96
Registriert: 25.03.2023 13:49:28

Re: Testbericht unter Linux

#571 Beitrag von Paneologe »

Ich würde noch anmerken, dass die aktuelle Proton 7-Version von Valve einen üblen ZusiDisplay-Memory Leak verursacht. Der wird aber mit dem nächsten Proton-Release (egal ob 7 oder 8) behoben. Und eine Zugwende macht glaube ich in Proton 7 noch die integrierten Displays kaputt, in 8 sollte es klappen. Außerdem bringt Proton 8 Performance-Verbesserungen für die integrierten ZusiDisplays (neue zlib-Version und schwächere PNG-Komprimierung).
konnte ich mit Steam und Proton replizieren, "Kopf machen" geht so nicht.

Hab mir neben der Steam-Version nun auch die USB-Stick-Version zugelegt.
unter Verwendung von wine-staging-8.4-lp154.1562.3.x86_64:
A) funktioniert alles richtig auch ohne dxvk.conf
B) Fehler ist ebenfalls nicht vorhanden
C) Simulation->Beenden führt dazu, dass Zusi ordnungsgemäss beendet wird
D) Zusidateiverwaltung bringt aber immernoch den Fehler. Könnte aber möglicherweise auch z.B. an fehlender IPv6-Unterstützung in meinem Netzwerk liegt.
o.g. Problem mit der Zugwende existiert ebenfalls nicht.
:tup :tup :tup

Zusimeter funktioniert etwas mehr, aber nicht nutzbar (Text-Widget lässt sich anlegen, starten - jedoch Fehler beim Start der Simulation).
Zusistart keine Funktion.

Edit:
Folgendes Problem ist neu:
Bild nach dem Laden eines Fahrplans, Nach einem Klick auf "OK" passiert nichts. Welche Auswirkung der Fehler hat, konnte ich noch nicht feststellen.
NET 3.5 mit winetricks installieren funktioniert bei mir nicht:

Code: Alles auswählen

Executing w_do_call dotnet35
Executing load_dotnet35
------------------------------------------------------
dotnet35 does not yet fully work or install on wine.  Caveat emptor.
------------------------------------------------------
Executing w_do_call dotnet30sp1
Executing load_dotnet30sp1
------------------------------------------------------
dotnet30sp1 does not yet fully work or install on wine.  Caveat emptor.
------------------------------------------------------
Executing w_do_call dotnet30
Executing load_dotnet30
Executing w_do_call dotnet20
Executing load_dotnet20
Executing w_do_call remove_mono
Executing load_remove_mono
002c:fixme:winediag:LdrInitializeThunk wine-staging 8.4 is a testing version containing experimental patches.
002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org.
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:wineusb:query_id Unhandled ID query type 0x5.
007c:fixme:wineusb:query_id Unhandled ID query type 0x5.
------------------------------------------------------
Mono does not appear to be installed.
------------------------------------------------------
Executing w_do_call fontfix
Executing load_fontfix
Setting Windows version to win2k
Executing winetricks_early_wine regedit C:\windows\Temp\_dotnet20\set-winver.reg
/usr/local/bin/winetricks: line 1688: test: too many arguments
/usr/local/bin/winetricks: line 1692: test: too many arguments
------------------------------------------------------
Working around wine bug 10467 -- Install l_intl.nls
------------------------------------------------------
Executing unzip -o -q -d /home/pane/.zusiwine/dosdevices/c:/windows/syswow64 l_intl.zip
/usr/local/bin/winetricks: line 1688: test: too many arguments
/usr/local/bin/winetricks: line 1692: test: too many arguments
/usr/local/bin/winetricks: line 1688: test: too many arguments
/usr/local/bin/winetricks: line 1692: test: too many arguments
------------------------------------------------------
Working around wine bug 30845 -- Adding .NETFramework registry key.  Ignore fatal error dialog if it pops up.
------------------------------------------------------
reg: The operation completed successfully
/usr/local/bin/winetricks: line 1688: test: too many arguments
/usr/local/bin/winetricks: line 1692: test: too many arguments
------------------------------------------------------
Working around wine bug 30845 -- Using native fusion while installing...
------------------------------------------------------
Executing env WINEDLLOVERRIDES=mscoree,fusion=n wine dotnetfx.exe
0298:fixme:advapi:DecryptFileA ("C:\\users\\pane\\Temp\\IXP000.TMP\\", 00000000): stub
0284:fixme:imm:ImeSetActiveContext (0000000000040038, 0): stub
0284:fixme:imm:ImmReleaseContext (0000000000040046, 0000000000040038): stub
0298:fixme:imm:ImeSetActiveContext (00010064, 1): stub
0298:fixme:imm:ImmReleaseContext (0001005E, 00010064): stub
02a8:fixme:security:GetWindowsAccountDomainSid (006AF338 007DDF14 006AF334): semi-stub
02a8:fixme:secur32:GetComputerObjectNameW NameFormat 7 not implemented
02a8:fixme:file:NtLockFile I/O completion on lock not implemented yet
02a8:fixme:imm:ImeSetActiveContext (00020070, 1): stub
02a8:fixme:imm:ImmReleaseContext (0002006E, 00020070): stub
------------------------------------------------------
Note: command 'env WINEDLLOVERRIDES=mscoree,fusion=n wine dotnetfx.exe' returned status 26.  Aborting.
------------------------------------------------------
Hat Jemand eigentlich Erfahrung mit Fahrpulten (Raildriver? Stillertec?) unter Linux?
Dell Precision T7600, 2 x Intel(R) Xeon(R) CPU E5-2665 (8 cores per CPU, 2 threads per core, 20MB L3 cache, 2.4/3.1GHz) (⁼32 logische CPUs), 512 GiB DDR3 ECC registered 1600 MT/s, NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] (11GB GDDR5X 352 bit), SAS Hardware RAID Level 1

Flo Zille
Beiträge: 201
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#572 Beitrag von Flo Zille »

Paneologe hat geschrieben: 28.03.2023 21:57:47 unter Verwendung von wine-staging-8.4-lp154.1562.3.x86_64:
A) funktioniert alles richtig auch ohne dxvk.conf
Das liegt dann aber daran, dass ein "nacktes" Wine (auch -staging) gar kein dxvk nutzt. Das Rendering erfolgt dann per OpenGL statt Vulkan. Als ich vor ein paar Jahren mal geschaut habe, hatte das dann schlechtere Performance zur Folge. Du könntest also dxvk in deinem Wine-Präfix installieren, um vielleicht bessere Performance zu erhalten. Nur dann brauchst du auch die dxvk.conf wieder (bis jetzt gibt es noch keine Rückmeldung zu meinem Vorschlag der Aufnahme der ZusiSim.64.exe in die "offizielle Ausnahmeliste" von dxvk).

Benutzeravatar
Paneologe
Beiträge: 96
Registriert: 25.03.2023 13:49:28

Re: Testbericht unter Linux

#573 Beitrag von Paneologe »

Das liegt dann aber daran, dass ein "nacktes" Wine (auch -staging) gar kein dxvk nutzt. Das Rendering erfolgt dann per OpenGL statt Vulkan.
Ok. das hatte ich nicht geprüft. die FPS lagen aber wie auch mit dxvk zwischen 30 und 40.
Habe jetzt dxvk 2.1 installiert, nun erhalte ich einen Fehler beim Start der Simulation:
Bild (Bildausschnitt)

Ich versuche mal dxvk 1.10.2 (offizielles rpm-release von openSUSE) - ich hoffe ich bringe nicht die ganzen dll's komplett durcheinander [EDIT: komischerweise fehlen bei dem Paket dxvk-32bit die 32bit Bibliotheken? aber für zusi da 64bit nicht relevant...]
Edit:
damit läuft's und der dxvk-bug wäre wieder da, also dxvk.conf noch erneut anlegen, dann sollte alles gehen. der dxvk_hud bietet noch interessante informationen:
Bild
[Wieso 64bit Bibliothen unter %windows%\system32\ abgelegt werden muss man nicht verstehen oder?]
Damit die dxvk.conf wirksam wird muss sie im aktuellen Arbeitsverzeichnis liegen (hier kann man auch für verschiedene Anwendungen unterschiedliche Parameter angeben). Oder Durch die Umgebungsvariable "DXVK_CONFIG_FILE". Mein Aufruf von Zusi erfolgt dann in meinem Beispiel über folgendes Kommando:

Code: Alles auswählen

DXVK_CONFIG_FILE="/home/pane/.zusiwine/drive_c/Program Files (x86)/Zusi3/dxvk.conf" WINEPREFIX=/home/pane/.zusiwine wine64 "C:\\Program Files (x86)\Zusi3\ZusiSim.64.exe"
Dell Precision T7600, 2 x Intel(R) Xeon(R) CPU E5-2665 (8 cores per CPU, 2 threads per core, 20MB L3 cache, 2.4/3.1GHz) (⁼32 logische CPUs), 512 GiB DDR3 ECC registered 1600 MT/s, NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] (11GB GDDR5X 352 bit), SAS Hardware RAID Level 1

Benutzeravatar
Paneologe
Beiträge: 96
Registriert: 25.03.2023 13:49:28

Re: Testbericht unter Linux

#574 Beitrag von Paneologe »

Noch folgendes Problem habe ich hier, Zugdateneingabe nicht möglich (sowohl via ZusiDisplay oder QDmi): viewtopic.php?f=75&t=18618
Kennt das ein anderer Linux-Nutzer?
Dell Precision T7600, 2 x Intel(R) Xeon(R) CPU E5-2665 (8 cores per CPU, 2 threads per core, 20MB L3 cache, 2.4/3.1GHz) (⁼32 logische CPUs), 512 GiB DDR3 ECC registered 1600 MT/s, NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] (11GB GDDR5X 352 bit), SAS Hardware RAID Level 1

Benutzeravatar
Paneologe
Beiträge: 96
Registriert: 25.03.2023 13:49:28

Re: Testbericht unter Linux

#575 Beitrag von Paneologe »

Und ein neues Problem? Hat das jemand schon gesehen?
Weiss nicht ob das mit der Umstellung auf dxvk zu tun hat (hab den Simulator seit dem nicht wirklich getestet) oder an Änderung von Einstellungen in ZusiDisplay.
Die Anzeige der Displays im Fahrzeug "lagt" einige Zeit hinterher (etliche sekunden) und flackert zwischen Einzelbildern.
als kleines mp4: https://www.swabian.net/extern/zusi/zus ... recode.mp4
originalscreen in mkv: https://www.swabian.net/extern/zusi/zusi_problem.mkv
[nur ein paar meter zur demo gefahren. die framerate ist durch das aufzeichnen eingebrochen, normalerweise > 30]

Edit: an dxvk liegt es wohl nicht, gerade deinstalliert, problem bleibt
Edit: hängt irgendwie mit ZusiDisplay Einstellung "Interner Bus für Diagnosedisplays verwenden" zusammen: https://www.forum.zusi.de/viewtopic.php ... 49#p345749
Dell Precision T7600, 2 x Intel(R) Xeon(R) CPU E5-2665 (8 cores per CPU, 2 threads per core, 20MB L3 cache, 2.4/3.1GHz) (⁼32 logische CPUs), 512 GiB DDR3 ECC registered 1600 MT/s, NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] (11GB GDDR5X 352 bit), SAS Hardware RAID Level 1

Flo Zille
Beiträge: 201
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#576 Beitrag von Flo Zille »

Also das "Hinterherhinken" war hier vor einiger Zeit glaube ich schon öfters Thema, und Bernhard K. hatte mir damals nach einiger "Fachsimpelei" per PN den Tipp gegeben, dass es mit fsync (was glaube ich bisher nur in Proton enthalten ist) besser wird. Wenn du wine-staging nutzt, ist standardmäßig vermutlich fsync nicht enthalten und esync zwar enthalten, aber nicht aktiviert. esync kann aber per Umgebungsvariable aktiviert werden (WINEESYNC=1 oder so) und könnte die Situation ebenfalls deutlich verbessern. In wine (ohne -staging) ist glaub ich weder esync noch fsync enthalten.

Meine Vermutung ist, dass hinterherhinkende "kleinere" integrierte Displays als Ursache tendenziell daran liegen, dass weder esync noch fsync aktiv ist, sondern die wineserver-basierte Synchronisierung. Hier müssen viele Dinge (z.B. das Warten auf Daten von einem anderen Prozess) per Kommunikation über den wineserver miteinander synchronisiert werden, was Performance frisst. Mit esync oder fsync kümmert sich der Linux-Kernel auf die eine oder andere Weise selbst darum.

Bei großen integrierten Displays (wenn man mit der "Kameraansicht" auf eine Großaufnahme eines Displays wechselt z.B.) kann die Ursache auch an einer zu langsamen gdiplus-Implementierung in wine liegen. Da hilft dann evtl. die Nutzung einer neueren wine-Version, oder Installation der "Microsoft-gdiplus" per winetricks, oder alternativ dazu für ganz Hartgesottene vielleicht auch meine gdiplus-Performance-Patches. Das ist aber zumindest mit einem Ryzen 5 1600 nach meiner Erfahrung in wine 8.3 schon nicht mehr wirklich nötig, denn die normale Proton-gdiplus (und vermutlich auch die aus wine-staging) ist schon ausreichend performant.

Benutzeravatar
Paneologe
Beiträge: 96
Registriert: 25.03.2023 13:49:28

Re: Testbericht unter Linux

#577 Beitrag von Paneologe »

Flo Zille hat geschrieben: 29.03.2023 21:12:02 Also das "Hinterherhinken" war hier vor einiger Zeit glaube ich schon öfters Thema, und Bernhard K. hatte mir damals nach einiger "Fachsimpelei" per PN den Tipp gegeben, dass es mit fsync (was glaube ich bisher nur in Proton enthalten ist) besser wird. Wenn du wine-staging nutzt, ist standardmäßig vermutlich fsync nicht enthalten und esync zwar enthalten, aber nicht aktiviert. esync kann aber per Umgebungsvariable aktiviert werden (WINEESYNC=1 oder so) und könnte die Situation ebenfalls deutlich verbessern. In wine (ohne -staging) ist glaub ich weder esync noch fsync enthalten.
Hab mal folgende Optimierungen versucht:
-__GL_THREADED_OPTIMIZATIONS=1 (ob das bei Verwendung von Vulkan überhaupt einen Einfluss hat?)
-fsync aktiviert (frage ob das überhaupt in wine-staging 8.4 enthalten ist?)
-esync aktiviert (daraufhin kommuniziert oftmals zudem ZusiDisplay nicht mit Zusi!?)
-CSMT aktiviert
keine dieser Versuche hat das Ergebnis (hab hier vor allem auf Framerate und ZusiDisplay-Trägheit) merklich beeinflusst.
Allgemein verursacht ZusiDisplay eine hohe CPU-Nutzung. Sind aber ausreichend Kerne/Threads vorhanden und daher eigentlich kein Problem. Ich denke es sind einfach die unmengen Daten die vom Protokoll verarbeitet werden müssen.

Weiss noch Jemand wie ich das loswerde (merke jedoch keine Funktionseinschränkung)
Bild
wine schreit hier noch in STDERR:

Code: Alles auswählen

Resolving ZusiBfpl.XmlSerializers, Version=3.5.0.0, Culture=neutral, PublicKeyToken=null, processorArchitecture=MSIL=> C:\Program Files\Zusi3\_InstSetup\lib\timetable\lib\ZusiBfpl.XmlSerializers.dll = no
Resolving ZusiBfpl.XmlSerializers, Version=3.5.0.0, Culture=neutral, PublicKeyToken=null, processorArchitecture=MSIL=> C:\Program Files\Zusi3\_InstSetup\lib\timetable\lib\lib\ZusiBfpl.XmlSerializers.exe = no
06b4:err:listview:LISTVIEW_WindowProc unknown msg 109d, wp 0, lp 0
06b4:err:listview:LISTVIEW_WindowProc unknown msg 109d, wp 0, lp 0
winetricks dotnet35 scheitert daran, dass das requirement(?) dotnet20 nicht auf 64bit installierbar ist.
Dell Precision T7600, 2 x Intel(R) Xeon(R) CPU E5-2665 (8 cores per CPU, 2 threads per core, 20MB L3 cache, 2.4/3.1GHz) (⁼32 logische CPUs), 512 GiB DDR3 ECC registered 1600 MT/s, NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] (11GB GDDR5X 352 bit), SAS Hardware RAID Level 1

Flo Zille
Beiträge: 201
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#578 Beitrag von Flo Zille »

Valve hat jetzt Proton 8.0 veröffentlicht, und es sieht auf den ersten Blick gut aus in Kombination mit Zusi, aber man benötigt glaub ich weiterhin die dxvk.conf. Ein hoffentlich recht selten nötiger "ZusiDisplay crasht beim Start"-Patch hat es noch nicht in Proton 8.0 geschafft, aber falls Proton irgendwann noch die Patches des bald erscheinenden Wine 8.0.1 übernimmt, wird sich das auch lösen (sonst eben in einem Jahr mit Proton 9).

dxvk hat auch kürzlich die "Sonderbehandlung" der neuen ZusiSim.64.exe zusätzlich zur ZusiSim.exe in ihrem Arbeitsstand akzeptiert. Das müsste dann mit dxvk 2.2 oder dxvk 2.1.1 oder so veröffentlicht werden, welches dann vielleicht in Proton 8.1 enthalten sein könnte. Sobald man diese neue dxvk-Version nutzt, kann man die dxvk.conf hoffentlich wieder löschen und/oder die als Workaround gegen die Grafik-Falschdarstellung der Führerstandsansichten ebenfalls mögliche PROTON_USE_WINED3D-Einstellung wieder deaktivieren. Zusi sollte dann also via Steam auf Linux wieder weitgehend ohne Bastelei "von Haus aus" einigermaßen ordentlich funktionieren. Sogar die Schriftarten im ZusiDisplay-Einstellungsmenü scheinen sich bei mir jetzt verbessert zu haben, so dass die Buttons unten wieder sichtbar sind, aber vielleicht hat hier auch Jens etwas in ZusiDisplay geändert und es ging schon eine ganze Weile? :applaus

Flo Zille
Beiträge: 201
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#579 Beitrag von Flo Zille »

Hat sonst jemand schon das neue Proton ausprobiert? Ich habe jetzt festgestellt, dass Steam bei mir der Meinung ist, dass Zusi nur in der Sprache "english" verfügbar ist, und es stellt beim Start von Zusi meine Umgebungsvariablen entsprechend auf "amerikanisch" um (WINEDEBUG=+steam):
0024:trace:steam:setup_steam_registry UI language: "german"
0024:trace:steam:setup_steam_registry appid: 1040730
0024:trace:steam:setup_steam_registry Game language "english", available "english"
0024:fixme:steam:setup_steam_registry Game language "english", defaulting LC_CTYPE / LC_MESSAGES to en_US.UTF-8.
Das hat dann zur Folge, dass die Uhrzeiten an einigen Stellen im "AM/PM"-12-Stunden-Format statt dem hier üblichen 24-Stunden-Format angegeben werden. In Proton 7 war dieser Automatismus mit der Einstellung von LC_CTYPE und LC_MESSAGES noch nicht enthalten. Ist das ein allgemeines Problem, oder hab ich irgend eine blöde Einstellung vorgenommen, die Steam jetzt denken lässt, das Spiel sei nur in Englisch verfügbar?

Falls es ein allgemeines Problem ist, dann hat vielleicht Aerosoft in den Steam-Shop-Einstellungen irgendwo vergessen, "german" als Sprache für Zusi hinzuzufügen? Wobei das ja auf Windows keine entsprechenden Auswirkungen an der Stelle zu haben scheint. Als Workaround kann man vermutlich LC_CTYPE und LC_MESSAGES manuell vor dem Spielstart auf die deutsche Variante setzen (de_DE.UTF-8?), aber ich bin immer ein Fan von "es läuft auch ohne Basteln". :D

Edit: Falls noch jemand das Problem hat, in Steam Rechtsklick auf Zusi in der Spieleliste -> Eigenschaften -> Allgemein -> Startoptionen und dort eintragen "LC_MESSAGES=de_DE.UTF-8 %command%" löst es erstmal, ist aber natürlich nicht ideal, dass das nötig ist.

Benutzeravatar
Bernhard K.
Beiträge: 167
Registriert: 23.06.2020 22:29:41
Aktuelle Projekte: Uni
Wohnort: VzG 5900, Km 9,4
Kontaktdaten:

Re: Testbericht unter Linux

#580 Beitrag von Bernhard K. »

Ne kleine Anekdote dazu: Wir haben das so gemacht, weil das Steam Deck die Locale bei Linux nicht richtig einstellt und wir immer Probleme mit asiatischen Spielen hatten... Somit wird nun die Locale per Spielsprache gesetzt. Eigentlich haben wir uns irgendwie mit Valve einigen wollen, dass man die Sprache aus irgendwelchen Deck Einstellungen ableitet, damit der Desktop wieder normal funktioniert. Das ist tatsächlich auch ein Blocker bei meinem Spracherkennungscode. Ich will mal probieren das neu anzustoßen.

Antworten