Testbericht unter Linux
Re: Testbericht unter Linux
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.
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.
- 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
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.
LG
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.
Kleiner Tipp am Rande: Patches mit entsprechenden Tests kommen immer besser an, wie ich gemerkt habe.
LG
Re: Testbericht unter Linux
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. 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.
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.
- Johannes
- Beiträge: 3202
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: Testbericht unter Linux
Wine selbst hat da was geändert: https://www.winehq.org/announce/5.0
"./configure --without-mingw" sollte helfen.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.
- 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
In so einem Fall suche ich immer "Inspiration" an den schon bestehenden Tests, oder an Testcode, den ich in Windows erstelle.
Was sehr gut geht, ist das Profiling mit Perf. Hier mal ein Beispiel, das ich von einem Talent2-ZD gemacht hab:
Wichtig ist hierbei, dass man mit Debug-Symbolen (ist Standart) und am besten ohne Optimierung compiliert.
- Johannes
- Beiträge: 3202
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: Testbericht unter Linux
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.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.
- 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
Stimmt ist ja logisch. Danke für den Hinweis!
Edit: Also mit perf record -F 1000 -ag -p <prozess ID> kann ich hier sehr gute "Call-Graphen" erstellen.
Re: Testbericht unter Linux
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.
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.
- Johannes
- Beiträge: 3202
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: Testbericht unter Linux
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.
- 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
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.
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.
Re: Testbericht unter Linux
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...
- 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
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... )
Zuletzt geändert von Bernhard K. am 29.11.2021 17:34:39, insgesamt 1-mal geändert.
Re: Testbericht unter Linux
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.
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.
Re: Testbericht unter Linux
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.
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.
- 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
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)
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.
Re: Testbericht unter Linux
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
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.
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.
Re: Testbericht unter Linux
winetricks dotnetcoredesktop3 führt bei mir zu: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.
Code: Alles auswählen
Unknown arg dotnetcoredesktop3
- 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
Notfalls mal winetricks updaten mit sudo winetricks --self-update
Re: Testbericht unter Linux
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.Bernhard K. hat geschrieben: ↑01.12.2021 19:53:10 Notfalls mal winetricks updaten mit sudo winetricks --self-update
Mit wine 6.22 startet Zusi auch nach der Installation von dotnetcoredesktop3 leider immer noch nicht.
- Johannes
- Beiträge: 3202
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: Testbericht unter Linux
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.)