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

#401 Beitrag von Flo Zille »

Also mir fällt da leider nichts ein, zumal ich nur die Steam-Version habe. Möglicherweise hilft es, mit einem "frischen" Wine-Prefix anzufangen, falls du das nicht schon getan hast? Dieser Fehler mit Z:\ bedeutet evtl. nur, dass die Partitionsbezeichnung nicht geladen werden kann, oder so.

Der Patch für "set_map_mode()", der gdiplus (und somit ZusiDisplay) bei mir recht erheblich beschleunigt, hat es jetzt nach etwas Nacharbeit von Huw Davies und ein paar Unmutsäußerungen in wine geschafft (ab wine 6.23). Mit dem noch etwas verbesserten dsound-Patch versuche ich es wohl nächste Woche mal, mal sehen was dabei herauskommt. Hoffentlich noch rechtzeitig für wine 7.

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

#402 Beitrag von Bernhard K. »

Super Sache. Ich werde kommende Woche nochmal meinen Patch bzgl. des unsichtbaren Buchfahrplans einschicken.
Leider gibt's immer noch Probleme mit der Performance in Gdiplus. Z.b. sind die Displays vom Talent2 schlichtweg unbenutzbar, wegen massiven Slowdowns.
Ich werde da dann mal als Nächstes darüberschauen.
Flo Zille hat geschrieben: 28.11.2021 13:35:11 Mit dem noch etwas verbesserten dsound-Patch versuche ich es wohl nächste Woche mal, mal sehen was dabei herauskommt. Hoffentlich noch rechtzeitig für wine 7.
Kleiner Tipp am Rande: Patches mit entsprechenden Tests kommen immer besser an, wie ich gemerkt habe.

LG

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

Re: Testbericht unter Linux

#403 Beitrag von Flo Zille »

Ist in dem Fall mit dem Test nicht so einfach, glaube ich (man müsste wohl im Test den fertigen Sound-Ausgabebuffer nach dem Mixen inspizieren und sehen, ob dort die richtigen Inhalte drin landen – wofür vermutlich bisher keine "Inspektionsmöglichkeiten" vorgesehen sind, und verwaltet wird der Ausgabebuffer in einem separaten Mixthread, was die Sache ohnehin brenzlig macht). Im Endeffekt sind es jetzt zwei ziemlich kleine Patches. Vielleicht geht es also auch so. :elk Aber der Tipp ist sehr gut und hat für die GdipSaveAdd*-Implementierung damals gut funktioniert.

Die gdiplus-Performance ist bei mir wie gesagt auch (lange noch?) nicht ausreichend. Als ich letztes Mal danach geschaut hatte (bevor durch die dotnet-core-Umstellung hier erstmal gar nichts mehr ging und ich das Handtuch geworfen hatte) konnte ich die wine-Bibliotheken noch mit sysprof profilen und dadurch sehen, wo es mit der Performance klemmt. Inzwischen geht es leider nicht mehr - offenbar hatte ich damals eine gdiplus.dll.so statt einer .dll. Weiß gerade nicht mehr, wie ich die erstellt habe. Damals war dann eines der Hauptprobleme wie gesagt das Resampling der Bitmaps in graphics.c. Das lässt sich zumindest für Fälle, in denen das Resampling keine Rotation beinhaltet, bestimmt auch noch gut beschleunigen. Es wird dort zum Beispiel für jeden Pixel des "Ziel-Bitmaps" neu ausgerechnet, welche Original-Pixel dort jetzt mit welcher Gewichtung einfließen müssen. Dabei lässt sich das glaube ich einmal für die X-Richtung und einmal für die Y-Richtung vorausberechnen und dann jeweils für jedes Ziel-Pixel entsprechend miteinander kombinieren, ohne es erneut auszurechnen. Die Art und Weise, wie das Resampling über viele verschiedene Funktionen springt und nicht gerade in einem "tight loop" abläuft, ist vielleicht auch nicht so ideal, auch wenn der Compiler das sicher noch optimiert.

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

Re: Testbericht unter Linux

#404 Beitrag von Johannes »

Flo Zille hat geschrieben: 28.11.2021 18:48:05Inzwischen geht es leider nicht mehr - offenbar hatte ich damals eine gdiplus.dll.so statt einer .dll. Weiß gerade nicht mehr, wie ich die erstellt habe.
Wine selbst hat da was geändert: https://www.winehq.org/announce/5.0
Most modules are built in PE format (Portable Executable, the
Windows binary format) instead of ELF when the MinGW compiler is
available. This helps various copy protection schemes that check
that the on-disk and in-memory contents of system modules are
identical.
"./configure --without-mingw" sollte helfen.

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

#405 Beitrag von Bernhard K. »

Flo Zille hat geschrieben: 28.11.2021 18:48:05 Ist in dem Fall mit dem Test nicht so einfach [...]
In so einem Fall suche ich immer "Inspiration" an den schon bestehenden Tests, oder an Testcode, den ich in Windows erstelle.
Flo Zille hat geschrieben: 28.11.2021 18:48:05 [...] konnte ich die wine-Bibliotheken noch mit sysprof profilen und dadurch sehen, wo es mit der Performance klemmt. Inzwischen geht es leider nicht mehr [...]
Was sehr gut geht, ist das Profiling mit Perf. Hier mal ein Beispiel, das ich von einem Talent2-ZD gemacht hab:
Bild
Wichtig ist hierbei, dass man mit Debug-Symbolen (ist Standart) und am besten ohne Optimierung compiliert.

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

Re: Testbericht unter Linux

#406 Beitrag von Johannes »

Bernhard K. hat geschrieben: 28.11.2021 21:14:42 Wichtig ist hierbei, dass man mit Debug-Symbolen (ist Standart) und am besten ohne Optimierung compiliert.
Ohne Optimierung verfälscht natürlich die Ergebnisse. Man sollte entweder mit "-fno-omit-frame-pointer" kompilieren oder perf mit "--call-graph=lbr" aufrufen. Sonst kann er beim nicht sinnvoll feststellen, in welcher Funktion er 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

#407 Beitrag von Bernhard K. »

Johannes hat geschrieben: 28.11.2021 21:30:40 Ohne Optimierung verfälscht natürlich die Ergebnisse.
Stimmt ist ja logisch. :idee Danke für den Hinweis!
Edit: Also mit perf record -F 1000 -ag -p <prozess ID> kann ich hier sehr gute "Call-Graphen" erstellen.

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

Re: Testbericht unter Linux

#408 Beitrag von Flo Zille »

Vielleicht ist meine perf-Version zu alt (5.13.18 von Ubuntu 21.10), jedenfalls zeigt es mir in der Symbolspalte – wohl seit der von Johannes genannten Umstellung auf das PE-Format – nur die Adresse an, z.B. 000000000002cffb.

Ich habe jetzt aber sysprof so weit ergänzt, dass es auch Symbole aus dll-Dateien mit PE/COFF-Symboltabelle laden kann und das scheint tatsächlich zu funktionieren (der Code ist sehr weit weg von "Merge-Request-fähig", aber ich werde wohl im sysprof-gitlab beizeiten einen Branch erstellen, damit der Code nicht verloren geht). Und es sieht bei mir so aus, als ob auch heute noch das Resampling in gdiplus ein Problem ist, so wie in deinem Screenshot aus perf ja auch. Viele der dort sichtbaren Funktionen kommen aus der Ecke.

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

Re: Testbericht unter Linux

#409 Beitrag von Johannes »

Welche Schritte sind momentan nötig, um in einem frischen Wineprefix unter Standard-Wine ZusiDisplay zum Laufen zu bekommen? Dann könnte ich das mal in viewtopic.php?f=47&t=10844 schreiben.

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

#410 Beitrag von Bernhard K. »

Eigentlich nur winetricks dotnetcoredesktop3 und, wenn man keinen Lag will, winetricks gdiplus .
EDIT: Ganz wichtig, sonst geht's gar nicht: Man muss manuell irgendwo die Schriftart micross.ttf (Microsoft Sans Serif) herholen und in C:\Windows\Fonts packen.

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

Re: Testbericht unter Linux

#411 Beitrag von Flo Zille »

Und wenn man Proton nutzt, braucht man neuerdings die micross.ttf nicht mehr selbst reinkopieren, weil Valve jetzt eine entsprechende ähnlich aussehende Schriftart unter diesem "Microsoft Sans Serif"-Namen mitliefert. Ich kopiere mir nur den "dotnet"-Ordner, den ich ursprünglich mal von meiner Windows-Partition kopiert habe, in C:\Programme (x86)\ des Präfix rein. Dafür geht mit der neuesten Proton-Version das Standalone-Zusidisplay bei mir offenbar nicht mehr, sondern irgendwie nur noch in Wine-Präfixen, die ich mit einem alten wine erstelle (wine 5 zum Beispiel, von Ubuntu 21.10) und dann mit dieser neuesten Proton-wine-Version aktualisieren lasse. Wenn ich den Präfix direkt mit der neuesten Proton-Wine-.Version erstelle, stürzt das Standalone-Zusidiplay mit einer System.ArgumentOutOfRangeException ab. Mal sehen, was da jetzt los 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

#412 Beitrag von Bernhard K. »

Flo Zille hat geschrieben: 29.11.2021 16:00:52 Ich kopiere mir nur den "dotnet"-Ordner, den ich ursprünglich mal von meiner Windows-Partition kopiert habe, in C:\Programme (x86)\ des Präfix rein.
Kleiner Tipp, wie man das bei der Steam-Version einfacher hinbekommt: Man geht in die Spieledaten und nennt "installscript_dotnetcore.vdf" in "installscript.vdf" um und dann wird .Net Core automatisch ins Präfix installiert. (Normalerweise wird dieses Skript nämlich auf Windows auch nicht ausgeführt, weshalb hier im Forum auch oft die Frage kommt, warum die Displays denn nicht angezeigt werden... :rolleyes: )
Zuletzt geändert von Bernhard K. am 29.11.2021 17:34:39, insgesamt 1-mal geändert.

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

Re: Testbericht unter Linux

#413 Beitrag von Flo Zille »

Der Tipp ist auch gut, vielen Dank!

Als die Umstellung noch frisch war, hat sich die Installation bei mir tatsächlich mal automatisch erledigt. Das wurde dann wohl seitens Aerosoft (?) aber absichtlich oder versehentlich durch die Umbenennung kaputt gemacht.

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

Re: Testbericht unter Linux

#414 Beitrag von Flo Zille »

Ein weiteres Problem der wine-gdiplus ist ein zu kleiner "GDI-Fontcache". So ganz habe ich es nicht durchschaut, aber ich glaube, wenn mehr als 10 verschiedene Font-Konfigurationen (Schriftart, Größe und noch ein paar weniger offensichtliche Eigenschaften wie etwa eine "Breite" (?) der Schrift) genutzt werden, dann wird beim Laden der 11. Font-Konfiguration die erste wieder vollständig aus dem Speicher entfernt. Wenn eine ZusiDisplay-Maske also mehr als 10 verschiedene Schriftkonfigurationen nutzt (wobei hier anscheinend verschiedene Breiten zum Einsatz kommen – vermutlich errechnet sich das irgendwie intern in der gdiplus aus der zur Verfügung stehenden Breite für den Schriftzug), was durchaus der Fall ist z.B. beim ET422-Diagnosedisplay und vermutlich auch beim von Bernhard erwähnten Talent 2, dann müssen ständig Schriftarten komplett neu durch freetype2 geladen werden, was eine ganz ordentliche CPU-Belastung ist.

Der Font-Cache lässt sich recht einfach vergrößern, ich habe jetzt mal 30 statt 10 gewählt, und verbessert in diesen Situationen die Performance. Man muss "#define UNUSED_CACHE_SIZE 10" entsprechend anpassen, das findet sich in älteren wine-Versionen in dlls/gdi32/font.c und in neueren in dlls/win32u/font.c. Ob sich das irgendwie negativ auswirken kann (außer durch etwas mehr Speicherbedarf) ist mir nicht klar, aber vielleicht wäre das auch etwas, was man an wine-devel schicken könnte. Die Frage ist allerdings, was ein guter Wert ist (vielleicht ist 30 ja auch noch etwas zu knapp bemessen für manche Displays). Möglicherweise wäre eine bessere "Reparatur" aber auch anders möglich. Vielleicht kann die "Breite" der Schrift ja irgendwie zwischen den verschiedenen Nutzungen vereinheitlicht werden und dann genügen 10 Cache-Einträge schon, denn eigentlich nutzt ZusiDisplay ja gar nicht so viele verschiedene Schriftgrößen und -arten, habe ich jedenfalls den Eindruck. Dafür müsste man mal genauer anschauen, wie diese Breite berechnet wird und ob das überhaupt sinnvoll wäre.

Der Patch von Bernhard für die Reparatur der Buchfahrplan-Anzeige ist gestern über das offizielle wine-git-Repository hier angekommen und das funktioniert jetzt wieder super. :-) Hoffentlich schaffe ich es später noch, den dsound-Patch loszuschicken.

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

#415 Beitrag von Bernhard K. »

Flo Zille hat geschrieben: 01.12.2021 11:25:50 [...] ist z.B. beim ET422-Diagnosedisplay und vermutlich auch beim von Bernhard erwähnten Talent 2, dann müssen ständig Schriftarten komplett neu durch freetype2 geladen werden, was eine ganz ordentliche CPU-Belastung ist.
Interessant. Ich habe gestern auch eine enorme Performanceverbesserung bemerkt, nachdem ich alle Fonts, außer micross.ttf und den standard Schriftarten, aus meinem Präfix gelöscht habe. (Waren dann nur 4 Stück)
Flo Zille hat geschrieben: 01.12.2021 11:25:50 Die Frage ist allerdings, was ein guter Wert ist (vielleicht ist 30 ja auch noch etwas zu knapp bemessen für manche Displays).
Sehr spannend wäre hier zu wissen, wie denn Windows das ganze handhabt.

Ich bin jetzt aktuell dran bisschen was an der Performance von GdipDrawImagePointsRect zu schrauben. Diese Funktion wird anscheinend sehr häufig von ZD verwendet.

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

Re: Testbericht unter Linux

#416 Beitrag von Flo Zille »

Ich glaube, innerhalb dieser Funktion wird unter manchen Umständen ja auch resampled (Aufruf von resample_bitmap_pixel). Nach langer Bastelei (und entsprechend furchtbar ist der Code auch) konnte ich die Laufzeit eines solchen Resampling-Vorgangs für das Vergrößern von 800x600 auf 1251x907 (diese Situation entsteht z.B., wenn man in der Kölner S6 per Pfeiltaste nach links das linke Display auf Großansicht hat, müsste BR 422 sein) reduzieren von ca. 320ms mit dem Original-Code auf ca. 80ms mit dem optimierten Code. Leider fallen dabei auch einige Dinge unter den Tisch, die vielleicht für ZusiDisplay nicht so wichtig sind, für wine allgemein aber schon, das kann so also auch nicht bleiben. Alpha-Werte werden z.B. nicht korrekt berücksichtigt und auch sonst läuft sicher einiges falsch. Ich muss die Tage mal sehen, ob sich das erägnzen lässt, ohne zu viel an Performance-Vorteilen zu verlieren. Ein anderes Problem ist, dass der optimierte Code prinzipiell keine Rotation während des Resamplings unterstützt, was der Standard-Code aber kann – für solche Fälle muss der also sowieso drin bleiben und kann nicht entfernt werden. Das würde die wine-Maintainer sicherlich nicht gerade begeistern, wenn es zwei Codepfade für die gleiche Sache gibt, nur einmal für häufige Anwendungsfälle optimiert, was dann aber nicht immer genutzt werden kann, und einmal in langsam für die restlichen Anwendungsfälle. Doppelter Pflegeaufwand, doppeltes Potential für Bugs :rolleyes:

Trotzdem genügt die Performance leider immer noch nicht ganz, um das FIS in besagter S-Bahn auf meinem Phenom 2 ordentlich zu bedienen. ZusiDisplay fällt zeitlich zurück, sobald man das FIS-Menü öffnet. Vielleicht könnte man in der alpha_blend_bmp_pixels() noch etwas herausholen, die sehr vielen Aufrufe von GdipBitmapSetPixel und evtl. GdipBitmapGetPixel sind ja sicherlich auch nicht optimal.

mitropam
Beiträge: 166
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#417 Beitrag von mitropam »

Bernhard K. hat geschrieben: 29.11.2021 15:38:39 Eigentlich nur winetricks dotnetcoredesktop3 und, wenn man keinen Lag will, winetricks gdiplus .
EDIT: Ganz wichtig, sonst geht's gar nicht: Man muss manuell irgendwo die Schriftart micross.ttf (Microsoft Sans Serif) herholen und in C:\Windows\Fonts packen.
winetricks dotnetcoredesktop3 führt bei mir zu:

Code: Alles auswählen

Unknown arg dotnetcoredesktop3
?(

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

#418 Beitrag von Bernhard K. »

Notfalls mal winetricks updaten mit sudo winetricks --self-update

mitropam
Beiträge: 166
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#419 Beitrag von mitropam »

Bernhard K. hat geschrieben: 01.12.2021 19:53:10 Notfalls mal winetricks updaten mit sudo winetricks --self-update
Das hat schonmal geholfen. Unter wine 6.0.2 bleiben bei mir die Displays aber immer noch schwarz. Auch der TCP-Server muss immer noch manuell gestartet werden.
Mit wine 6.22 startet Zusi auch nach der Installation von dotnetcoredesktop3 leider immer noch nicht.

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

Re: Testbericht unter Linux

#420 Beitrag von Johannes »

Du kannst ein unter Wine <= 6.2 installiertes Zusi nicht mit Wine >6.2 nutzen und umgekehrt. Du musst Zusi jeweils neu installieren. (Gilt nur für die Stick-Version.)

Antworten