![]() |
AW: Grafikperformance von Virtual Treeview
Ich konnte das Problem ausfindig machen. Es liegt an der Kombination von Win-10-Gast, Grafikemulation und Paravirtualisierung. Nach vielen Stunden Testen hat sich die Kombination aus VirtualBox 6.0.5 (neuestes Test-Build), VBoxSVGA-Emulation (deshalb auch 6.0.5 weil mein Gast eine EFI-Installation ist und vor 6.0.5 funktioniert VBoxSVGA nicht EFI) sowie der KVM-Paravirtualisierung als funktionierend herausgestellt. Vorher hatte ich VBoxVGA und Hyper-V.
Die GDI-Grafik ist jetzt deutlich flüssiger. Merkt man schon wenn man nur ein Fenster verschiebt. Vorher nur auf dem Host flüssig und in der VM ruckelig, jetzt beides fast identisch. Halten wir mal fest, dass VirtualTree an dem beschriebenen Problem unschuldig war. Trotzdem hat das Problem schön gezeigt, dass die Art und Weise, wie der VST sich zeichnet, doch recht aufwendig ist. Auf bestimmten, recht schwachen Maschinen kann das zum Problem werden. So auch bei meinem Testanwender, der gar keine VM nutzt sondern eine Intel-iGPU mit einem nativen Windows. Ferner bleibt die Feststellung, dass Intel zwar (zumindest bis der AMD Ryzen kam) die besten CPUs baut(e), jedoch bei den GPUs kläglichst versagt. |
AW: Grafikperformance von Virtual Treeview
Zitat:
Von kläglich versagen kann man hier in keinem Fall reden. Genau so wenig kann man Äpfel mit Birnen vergleichen. AMD hat, und das auch noch nach über 15 Jahren und länger, die wohl schlechtesten Sockets die es gibt. Von PGA mal ganz abgesehen, obwohl LGA oder BGA der Stand der Dinge ist. Wenn man dann auch noch eine schlecht konfigurierte VM nutzt, dort die Grafikleistung schlecht ist und dann Intel schlecht macht, finde ich das ein sehr schwaches Argument. |
AW: Grafikperformance von Virtual Treeview
Doch doch, ich bleib dabei. Um zu präzisieren: Die OpenGL-Treiber von Intel sind schlecht. Das scheint bei manchen Programmen, wozu VirtualBox zählt, aber auch manche Grafiksoftware wie z.B. PaintShop Pro, gewaltig Probleme zu machen. Dedizierte Grakas sind wohl auch deshalb eine Hilfe, weil es eben keine dedizierten Intel-Grakas gibt. Insofern kann da nicht so viel schief gehen.
Stand heute würde ich jedenfalls niemandem mehr zu Intel-Prozessoren im Office-Segment raten. Die Ryzen-G mit Vega-11 sind da aktuell das Maß der Dinge. |
AW: Grafikperformance von Virtual Treeview
Preis-/Leistung = AMD (low budget, PGA = sehr schlecht)
Qualität = Intel (LGA, wenig anfällig) |
AW: Grafikperformance von Virtual Treeview
Zitat:
|
AW: Grafikperformance von Virtual Treeview
So, spätes Update zum Thema:
Ich habe die VM deutlich beschleunigen können und zwar ohne jegliche Änderungen an der Hardware. Nur durch Einstellungen:
Die Kombination VBoxSVGA mit DEaktivierter Beschleunigung führt zu einer rapiden BEschleunigung. Eigentlich widersinnig bis man in den Wikis bei Oracle den Hinweis findet, dass sie die 2D-Beschleunigung auf Intel-CPUs in Software emulieren, auf AMD dagegen in Hardware umsetzen. Auf Intel also sozusagen entschleunigte Beschleunigung :evil: Jetzt hoffe ich nur, dass das Win10 die manuell eingetragene Hardware-UUID so akzeptiert und nicht aufgrund der ganzen "Hardware"-Änderungen mit einer Neuaktivierung kommt. Ich hasse diesen blöden Sprachcomputer von Microsoft! Und dann war da noch... doch eine kleine Hardware-Modifikation: Ich beging Genozid an einer recht ausgeprägten Wollmaus-Population :lol: |
AW: Grafikperformance von Virtual Treeview
Und noch ein Update:
Ich habe zunächst bei meinem Linux-Host vom Cinnamon-Desktop auf LXDE4 XFCE4 gewechselt, weil Cinnamon gerne mal 3 GB RAM belegt hat. Das hat aber kaum Auswirkungen auf die VM gezeigt. Kam mir sogar etwas langsamer vor. Allerdings nimmt sich LXDE4 XFCE4 nur 300 MB RAM, daher belasse ich das so. Danach hab ich mir das BIOS vorgenommen und Schritt für Schritt Einstellungen geändert und getestet. Nach und nach ließ sich da ein Muster ableiten: Je mehr Energiesparoptionen ich deaktiviert habe, umso flotter lief die VM. Am meisten gebracht hat eine Option "Dem Prozessor erlauben, auf die Spannungsregler zuzugreifen", welche ich DEaktiviert habe. Summa summarum laufen die Änderungen im BIOS auf ein typisches Overclocking-Szenario hinaus. Allerdings ohne aufgedrehte Taktraten oder Kernspannungen. Vorallem dynamische Taktveränderungen scheint VBox gar nicht zu mögen. Details zu nennen wäre wohl müßig, weil jedes BIOS anders aussieht und die Optionen anders nennt. Man muss sich wohl rantasten. Im Moment bin ich sehr zufrieden mit der Performance. Ich könnte mir vorstellen, der Code von VirtualBox ist nicht optimiert auf das teils exzessive dynamische Throttling moderner CPUs. |
AW: Grafikperformance von Virtual Treeview
Eine weitere Erkenntnis der letzten Tage möchte ich hier noch ergänzen: Man sollte die VirtualBox-VM nicht mit einer ungeraden Zahl CPU-Cores konfigurieren. Als es zuletzt so warm war ist mir aufgefallen, dass der CPU-Lüfter alle 10 Sekunden plötzlich hoch drehte, ein laufender Radiostream plötzlich Schluckauf bekam und der Mauszeiger bei Bewegungen Hopser machte.
Ein Blick in die CPU-Auslastung und die Thermalsensoren der Hostmaschine zeigte, dass VirtualBox zwar tatsächlich so viele Cores nutzte wie zugeteilt waren (in dem Fall drei). Jedoch lief einer davon zyklisch mit 100% Auslastung und stieß fast an die 80°C-Grenze, während die anderen Cores bei ~ 40°C lagen. Der Effekt tritt reproduzierbar NICHT auf, wenn ich die VM mit zwei oder vier Cores konfiguriere. Ob das nun eine Eigenart von VirtualBox oder dem Win10-Gast ist kann ich nicht genau sagen. Ich würde auf Windows tippen, weil ich ähnliches nicht beobachten konnte wenn ich eine identisch konfigurierte VM mit Linux-Gast gestartet habe. Möglich dass der Windows-Kernel auf einem Single- oder Triple-Core nicht richtig skaliert. Vielleicht weil es die in freier Wildbahn so gut wie nicht gibt? |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:07 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz