[franky]

Also bei meinem N3000 wie auch bei vielen anderen älteren Intel-Systemen wird der shared Memory abhängig von RAM fix über das BIOS zugewiesen.
Beim N3000 war shared Memory auf Auto konfiguriert und im Hauptmenü wird da bei 4GB RAM ein zugewiesener shared Memory von 256 MB angezeigt.
Ich kann dann aber in den erweiterten Einstellungen den shared Memory  auf 64, 128, 256 und 512 MB konfigurieren.
Da werde ich auch mal die 64 und 128 MB testen.

Laut intel-gpu-top wird die GPU des N3000 wie deine als Intel Cherryview (Gen8) GPU erkannt.
Meine GPU taktet abhängig von der Render Last zwischen 120 und 320MHz.
Bei meinen bisherigen Tests habe ich auch festgestellt, dass die GPU-Last besonders mit offenem OSD stark von der Auflösung und Wiederholfrequenz abhängt.
Die höchste habe ich FullHD 60Hz, wobei die Render-Last mit LCARS beim schnellen Scrollen bis auf 85% bei 320MHz GPU-Takt hochschnellt.
Wäre jetzt interessant wie hoch deine GPU maximal takten kann.
Die Render-Grundlast ohne offenem OSD liegt bei FullHD zwischen 20 und 25% bei ca. 150MHz GPU-Takt.
Bei aufwendigen Skins wie Skin-Designer geht die Last beim Scrollen im OSD bis auf 100% hoch und ich habe auch solche Effekte, von denen du berichtest.

Mit 50Hz ist die Render-Last dann etwas geringer.
Deutlich weniger Last (ca. die Hälfte) verursacht HD (1280x720) mit 50Hz.

Welche Auflösung und Wiederholfrequenz hast du im WebIF konfiguriert?
Falls du FullHD verwendest, versuche mal stattdessen HD.
Der Wyse3040 hat ja keinen HDMI-Port sondern DP-Ports.
Gehst du direkt mit DP auf einen Monitor mit DP-Port oder verwendest du einen aktiven DP-HDMI Adapter zum Monitor bzw. TV?

[Marcus]

Also bei meinem N3000 wie auch bei vielen anderen älteren Intel-Systemen wird der shared Memory abhängig von RAM fix über das BIOS zugewiesen.
Beim N3000 war shared Memory auf Auto konfiguriert und im Hauptmenü wird da bei 4GB RAM ein zugewiesener shared Memory von 256 MB angezeigt.
Ich kann dann aber in den erweiterten Einstellungen den shared Memory  auf 64, 128, 256 und 512 MB konfigurieren.
Da werde ich auch mal die 64 und 128 MB testen.

In meinem BIOS kann man diesbezüglich nichts konfigurieren. Interessant ist halt die Aussage von Intel, dass die iGPU auf 2 GB RAM zugreifen kann. Siehe dazu https://www.intel.de/content/www/de/de/products/sku/93361/intel-atom-x5z8350-processor-2m-cache-up-to-1-92-ghz/specifications.html

Laut intel-gpu-top wird die GPU des N3000 wie deine als Intel Cherryview (Gen8) GPU erkannt.
Meine GPU taktet abhängig von der Render Last zwischen 120 und 320MHz.
Bei meinen bisherigen Tests habe ich auch festgestellt, dass die GPU-Last besonders mit offenem OSD stark von der Auflösung und Wiederholfrequenz abhängt.
Die höchste habe ich FullHD 60Hz, wobei die Render-Last mit LCARS beim schnellen Scrollen bis auf 85% bei 320MHz GPU-Takt hochschnellt.
Wäre jetzt interessant wie hoch deine GPU maximal takten kann.
Die Render-Grundlast ohne offenem OSD liegt bei FullHD zwischen 20 und 25% bei ca. 150MHz GPU-Takt.
Bei aufwendigen Skins wie Skin-Designer geht die Last beim Scrollen im OSD bis auf 100% hoch und ich habe auch solche Effekte, von denen du berichtest.

Mit 50Hz ist die Render-Last dann etwas geringer.
Deutlich weniger Last (ca. die Hälfte) verursacht HD (1280x720) mit 50Hz.

Bei mir ist die CPU das limitierende Element. intel_gpu_top zeigt eine Auslastung des Render/3D bis zu 65% bei 350 MHz an, wenn das OSD offen ist und ich scrolle. Im Normalbetrieb ohne OSD  rund 25% bei 200MHz. Die GPU kann bis 500 MHz takten. Wenn das Scrollen ins Stocken gerät, lastet ein VDR Thread einen CPU-Kern zu 100% aus. Da klemmt es dann. Meine Vermutung ist: Da der Blitter nicht zum Verschieben des OSD benutzt wird, muss alles vom GPU-RAM zum CPU-RAM kopiert werden, dort wird der Speicher von der CPU manipuliert (der OSD-Inhalt um eine Zeile verschoben), wieder zum GPU-RAM kopiert und dort dann ausgegeben. Der Blitter könnte das selbst im VRAM erledigen und ist dabei dank DMA ein Vielfaches schneller. Der Blitter ist das, was damals in den 90ern umgangssprachlich als "2D-Windows-Beschleuniger" bezeichnet wurde. Weil es mit ihm erstmals möglich war, Fenster ruckelfrei auf dem Desktop zu verschieben, während der Fensterinhalt angezeigt wurde. Der Blitter ist quasi der VRAM-Copyshop in Hardware. Leider wird er offensichtlich (siehe intel_gpu_top) nicht benutzt. Ich könnte wetten, dass das beim Raspberry gemacht wird. Klar ist auch, wenn die CPU mehr Power hat (Speicherbandbreite spielt da auch eine große Rolle, der z8350 hat 12,5 GB/s, single-channel) fällt das immer weniger auf.

Welche Auflösung und Wiederholfrequenz hast du im WebIF konfiguriert?
Falls du FullHD verwendest, versuche mal stattdessen HD.
Der Wyse3040 hat ja keinen HDMI-Port sondern DP-Ports.
Gehst du direkt mit DP auf einen Monitor mit DP-Port oder verwendest du einen aktiven DP-HDMI Adapter zum Monitor bzw. TV?

Ich habe FullHD 50Hz eingestellt. Ich habe einen passiven DP1.1->HDMI Adapter und daran eine 32" Full-HD Fernseher.
Es ist tatsächlich ein passiver Adapter, obwohl bei Parkytowers steht, dass nur aktive funktionieren. Mein Adapter ist ein DeLOCK 61849. Es ist lediglich ein Levelshifter (NXP PTN3361) verbaut. Ich habe einen anderen passiven Adapter, China-Noname der angeblich 4k kann. Mit diesem bootet der Wyse nicht. Wenn ich mit dem DeLOCK boote und die Adapter im laufenden Betrieb austausche, funktioniert auch der andere einwandfrei. Keine Ahnung was der Wyse da für ein Problem mit hat.

[Marcus]

Ich habe nochmal im BIOS nachgesehen. Man kann zwar nichts einstellen, aber vom RAM werden dort 64 MB abgezweigt. Vermutlich ist das der exklusive VRAM. Das wird dann zur Laufzeit mit shared memory ergänzt. Und das geht dann bis zu den vollen 2 GB. Zumindest theoretisch. Praktisch braucht die CPU natürlich auch noch was.

Ich bin aber immernoch der Meinung, dass die iGPU hier kein Problem erzeugt. Ich änge mal zwei Screenshots an, wenn das langsame Scrollen auftritt.

[franky]

OK, dann scheint das limitierende bei Dir die CPU zu sein.
Mich wundert aber, dass der überlastete CPU-Kern nicht hoch taktet, denn eigentlich sollte deine CPU bis 1920 MHz hoch gehen können.
In deinem Screenshot bleibt sie aber bei 479MHz und ist mit 100% am Anschlag.

Ich hab's mir mal bei meinem N3000 angeschaut und dieses mal nur mit 64 MB shared Mem im Bios.
Da taktet ein CPU-Kern von den beiden auf über 2GHz hoch und hat dabei eine Auslastung von 61,2%.
Die GPU taktet auf 440MHz hoch bei einer Render-Last von knapp 80%.
Daher auch durchgängig flüssiges Scrollen.

[Marcus]

Jup, das ist eine Eigenart des z8350 Atom. Der hat eine SDP von nur 2 Watt. Sobald die GPU zu tun bekommt, bleiben von den 2 Watt nicht mehr viel für die CPU übrig. Dann bleiben die Kerne auf ihrer Grundtaktfrequenz. Das kann man ändern, in dem man neue Leistungslimits in

Code: [Select]

/sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
/sys/class/powercap/intel-rapl:0/constraint_1_power_limit_uwschreibt. Dann takten die Kerne trotz GPU-Aktivität wieder bis 1920 MHz. Dazu braucht man einen entsprechenden Kühlkörper, den der Wyse 3040 hat. Wenn man die CPU und GPU maximal auslastet, geht die Temperatur bis rund 70°C hoch. Das funktioniert bei der MLD aber erstmal nicht, da wohl der Intel RAPL Treiber fehlt?

Aber: Das ist mMn garnicht nötig. Es bleibt weiterhin die Frage, warum scrollen alle Menüs OHNE nennenswert erhöhte CPU-Aktivität, außer das "Sonstiges" Menü? Und warum funktioniert das Scrollen in EPG und Aufnahmen (alles wo der OSD-Inhalt durch zeilenweises Scrolling verschoben werden muss) mit der MLD 5.4 soviel besser? Benutzt softhddevice hier vielleicht den Blitter und in MLD 6.5 nicht? Oder liegt es an was ganz anderem?

Unter Debian 12 benutze ich die gleiche Hardware zum Transcodieren von zwei Webcams (3D-Drucker) und streame die per rtsp. Wenn ich das Video per RAW von der Webcam hole, wird der Blitter nicht benutzt. Ist wohl nicht nötig. Wenn ich das Video per mjpeg hole, schon. Da werden dann die Bilder vom Blitter von einer vaapi-surface zur anderen kopiert. Ich habe keine Ahnung, warum das bei mjpeg nötig ist und bei RAW nicht. Was ich damit sagen wollte, die Hardware ist vorhanden und funktioniert für den vorgesehenen Anwendugszweck, die CPU zu entlasten.

[Marcus]

Hier noch ein Screenshot während ich die beiden Webcam Videos transcodiere.

[Marcus]

Ich habe eben nochmal mit der MLD 5.4 rumgespielt. So viel deutlich besser ist die doch nicht. Das Problem scheint dort nur minimal besser zu sein. Und es ist im Grenzbereich. Bei der MLD 5.4 ist ebenfalls ein Kern am Anschlag und das scrollen wird, wenn man genau drauf achtet, auch minimal langsamer, wenn der OSD-Inhalt gescrollt werden muss. Es geht mit der MLD 5.4 wohl nur gerade so noch. Mit der 6.5 wahrscheinlich gerade so nicht mehr.

Vielleicht würde es wirklich Sinn machen, die 2 Watt SDP des Atom aufzubohren. Das habe ich bei dem anderen, der am 3D-Drucker hängt, auch schon gemacht, weil ffmpeg auch ziemlich viel CPU-overhead erzeugt und das zum limitierenden Faktor wurde. Der Leistungsgewinn dadurch ist deutlich. Kann man die dazu nötigen Treiber / Kernelmodule mit einbauen? https://docs.kernel.org/power/powercap/powercap.html

[clausmuus]

Welche Kernel Module sind es denn, die Du dafür benötigst, bzw. wie heißen die entsprechenden Kernel Config Optionen?

[Marcus]

Ja, wenn ich das wüsste. Bei Debian habe ich einfach die zwei Dateien beschrieben. Da war der Kernel schon entsprechend konfiguriert. Ein Schuss ins Blaue:

https://www.kernelconfig.io/config_intel_rapl