Intel Iris Xe Graphics 96 mit diversen CPUs

[linuxnutzer]

Mit Strix Point

Du gibst meinen Überlegungen neuen Raum, aber das Budget liegt bei ca. 1000€, kommt ja noch eine 4TB NVME dazu.

Ich habe ein paar Sachen entdeckt:

https://forum.ubuntuusers.de/topic/neuer-rechner-mit-amd-ryzen9-ai370-cpu-gpu-890/
Kurz: könnte unter 24.04.3, das im August kommen soll, funktionieren, ansonsten Trickserei unter Linux.

Nicht uninteressant ist:

Beelink SER9 Pro AMD Ryzen™ AI 9 HX 370
https://www.bee-link.com/products/beelink-ser9-ai-9-hx-370?variant=47266587541746

Liegt vom Preis aber weit von meinen Vorstellungen entfernt. Vielleicht kommen spezielle Rabatte.

Wie würdest du den Performance-Unterscheid zwischen

Intel Arc8
und
HX 370

mit opencl und Darktable vermuten?

Intel hätte den Voteil, dass ich weiß wie man das simpel installiert. Mit den AMD-Treibern habe ich ziemlich gekämpft, kann natürlich auch mit meiner iGPU zu tun haben.

 

[Powl_0]

Was ist das dann für eine Arc Version?

Das findest du übrigens alles sehr genau bei Notebookcheck, was bereits mehrmals verlinkt wurde. Da ist jede mobile CPU mit der jeweiligen iGPU gelistet und hat oftmals direkt reihenweise Benchmarks dabei.

 

[linuxnutzer]

Fedora 42 mit OpenCL: 4.384 secs

Vom Benchmark ist die B580 ca 3 mal so schnell

Also wenn ich jetzt hochrechne, dann ist die B580 3x so schnell wie die Arc8, also 1,4x3=4,2 sec.

Du hast mit der HX370 4.3sec gebraucht. Damit sind beide iGPU ziemlich gleich.

Das findest du übrigens alles sehr genau bei Notebookcheck

Mit Darktable unter Linux? Ray519 hat mit DT getestet. Windows-Werte sind offensichtlich nicht vergleichbar.

Bei 300€ mehr für Beelink SER9 HX 370 und meine Erfahrungen unter Linux mit Intel und AMD, wird es da schwierig Richtung HX370 zu argumentieren. Aber ich lasse mich überraschen.

 

[Powl_0]

Mit Darktable unter Linux

Das nicht, aber zumindest welche iGPU mit welchen Features und welcher Architektur in welcher CPU sitzt.
Und relativ zueinander vergleichbare Benchmarks auch in OpenCL. Wie die dann zu Darktable skalieren, musst du dann leider trotzdem selbst rausfinden.

 

[linuxnutzer]

Das nicht

Das Problem allein schon ist Darktable-Tests untereinander zu vergleichen.

Windows mit OpenCL: 6.894 secs
Fedora 42 mit OpenCL: 4.384 secs

Also Windows-Tests kann man mal ausschließen. Die richtige Darktable-Konfiguration ist dann auch so eine Sache, nicht optimal konfiguriert und schon dauert der Benchmark doppelt so lange.

Für die CPU hat das von 8.1sec auf 8.2 gebracht

Mir fällt noch ein, es könnte entscheidend sein, wieviel Speicher man der iGPU gibt. Der muss soviel sein, dass man im Log kein Tiling sieht. Ich sag mal mit 16G für die iGPU sollte man auf der sicheren Seite sein. Das hängt natürlich auch vom Testfile ab.

Das sieht dann zB so aus:

2.9273 [dev_pixelpipe] took 0.794 secs (1.262 CPU) [export] processed `atrous' on GPU with tiling, blended on CPU

Ich hatte Tiling mit einer 12GB-Grafikkarte und Default-Settings. Nach Änderung auf "large" (siehe oben) war das weg.

Da bleibt dann letztlich nur mit Vermutungen einzugrenzen und dann zurückzuschicken, wenn es nicht passt.

Aber ihr habt mich sowieso schon sehr viel weiter gebracht.

 

[Ray519]

es könnte entscheidend sein, wieviel Speicher man der iGPU gibt.

Wo?

Wenn du von BIOS Settings redest, dann ist die Software einfach von vorne herein Scheiße für iGPUs / shared memory.
Weil die iGPU kann einfach direkt auf dem RAM arbeiten ohne Limits und genau nichts muss durch die Gegend kopiert werden.

Das ist nur etwas das mit dGPUs mit separatem VRAM so gar nicht geht und Software muss beide Fälle verstehen. Eine iGPU wie eine dGPU zu behandeln ist immer imperformant und nur dafür helfen diese schrecklichen BIOS Reserve Memory Optionen.

Und der Windows AMD Treiber scheint da noch hässliche Dinge zu machen, weil er die von Windows erlaubten 32 GiB aufteilt in 10 GiB und 20 GiB mit unterschiedlichen Eigenschaften. Bei Intel ist das einfach 1 Speicher, keinen Grund die Größen aufzuteilen.

Aber ich habe mich auch nicht damit beschäftigt, wie viel davon von OpenCL überhaupt sichtbar ist, weil die Reports kommen alle aus der Vulkan API (aber die Größen stimmen überein).

 

[linuxnutzer]

Wenn du von BIOS Settings redest, dann ist die Software einfach von vorne herein Scheiße für iGPUs / shared memory.

Keine Ahnung, aber vermutlich. 99% der User verwenden wohl keine iGPU für Darktable. Bei mir ist eine ganz spezielle Situation. Ich habe ja einen "ordentlichen" PC mit Ryzen 9 9900X und Intel B580, aber kann den oft aus örtlichen Gründen nicht nutzen. Ich muss mich in einem bestimmten Raum in "Bereitschaft" halten, kann dort lange Zeiten tun was ich will, nur der Platz dort ist 65cm breit und 50cm tief. Auf dieser Fläche muss alles unterkommen und bei Bedarf schnell weggeben werden können. Zur Zeit ist ein Minipc (ohne opencl) auf dem Standfuß des Monitors (VESA nicht möglich).

Bei Intel ist das einfach 1 Speicher, keinen Grund die Größen aufzuteilen.

Grund für Intel, keine Ahnung was da Linux macht.

Das war nur so eine Idee mit der Speicherzuteilung im UEFI. Ich habe keine Erfahrung damit. Der jetzige MiniPC hat sich von 16GB RAM einfach 4GB genommen und das habe ich so gelassen.

Entscheidung ist alles, wo auch immer, so zu konfigurieren, dass es kein Tiling gibt. Tiling entsteht bei sonst richtiger Konfiguration dann, wenn der Grafikkarten-Speicher der dGPU zu klein ist. Das Umschalten zwischen GPU und CPU kostet sehr viel Zeit. Für "normale" Fotos reichen 4GB bei der Graka. Das verlinkte Testfoto ist anspruchsvoll und hat höhere Anforderungen.

Was wäre denn eine "kleine" dGPU die bzgl. opencl merklich schneller ist als eine iGPU? Es geht immer nur um die Performance von opencl und den benötigten Platz. Vielleicht geht sich ein Mini-ATX-Gehäuse mit dGPU als Monitorständer aus?

Ich sage jetzt absichtlich keine Chip-Hersteller, die ich ausschließe. Meine Priorität wäre Intel, Nvidia und zum Schluss AMD.

 

[Langi1]

Wenn du von BIOS Settings redest, dann ist die Software einfach von vorne herein Scheiße für iGPUs / shared memory.
Weil die iGPU kann einfach direkt auf dem RAM arbeiten ohne Limits und genau nichts muss durch die Gegend kopiert werden.

Du hast so dermassen wenig Ahnung von integrierter Grafik und warum man der im UEFI fix was zuteilen sollte.

Google mal.

 

[Ray519]

Du hast so dermassen wenig Ahnung von integrierter Grafik und warum man der im UEFI fix was zuteilen sollte.

Wenn du meinst...

Sich nicht Mal auf eine Begründung festlegen zu können kommt übrigens immer sehr überzeugend.

Der einzige Grund warum eine iGPU eine erhöhte Menge statisch zugeteilt bekommen sollte ist genau, dass die Software nicht mit Shared Memory umgehen kann und man die iGPU so eher wie eine dGPU wirken lässt. Im besten Fall kostet das nur RAM der nicht mehr normal genutzt werden kann, weil permanent für die iGPU reserviert.

Die iGPU selbst braucht das nicht und wird dadurch in keinster Weise schneller. Den Speicher zu behandeln wie als wäre er separat kostet nur extra Zeit für unnötige Kopien. Im besten Fall ist das nur beim Start und Ende nötig. Wenn die Laufzeit von der eigentlich Berechnung dominiert und mehr als genug RAM im System ist, kann das also vernachlässigbar sein.

Software die die iGPU nicht versteht und wie eine dGPU behandelt mag natürlich schneller werden, wenn sie eine dGPU mit mehr Speicher sieht. Aber das kommt eben nur durch Limitierungen und falsche Behandlung der Software und liegt nicht an der iGPU selbst.

Das ist also mehr ein temporärer Workaround um schlechte Software herum.