Grafiktreiber nachträglich / zusätzlich installieren?

[Mosed]

Grund: Es werden Bauteile/Komponente des DisplayPort Systems der Grafikkarte aktualisiert, ein per DP angeschlossener Monitor verhindert das Update.

Sowas sollte ja eigentlich trotzdem funktionieren. Dann wird das Bild halt eine Weile schwarz.
Es wird ja nur die Software/Firmware aktualisiert und nicht die Hardware.

Wenn der Monitor kein HDMI bietet, wäre so eine Zwangsbedingungen reichlich dämlich.

 

[linuxnutzer]

Den Anschluss per HDMI brauchst du nur zur Installation des Treibers

Ich glaube die 2. Intel-Graka (Astrock) hängt an einem HDMI-Kabel. Ist für das Update die HDMI-Version entscheidend?

Kommt es auf die Auflösung des Monitors an?

Am anderen PC hängt ein FHD-Monitor, weil es auch die Situation gibt, dass Installationen mit UHD-Monitoren nur mit Glück funktionieren. Nach der Installation ist UHD kein Problem.

Also besser zuerst UHD-Monitor anstecken?

 

[Mosed]

weil es auch die Situation gibt, dass Installationen mit UHD-Monitoren nur mit Glück funktionieren.

Kenne ich nicht und habe ich auch noch nie von gelesen. Hast du ein Beispiel?
Eine zu hohe Auflösung dürfte eigentlich keine Schwierigkeit machen, eher eine zu niedrige, weil das Fenster dann zu groß ist.

Wie lautet denn die Warnung bei der Treiberinstallation? Wenn es kein FW-Update ist, ergibt eine Warnung gar keinen Sinn meiner Meinung nach.

 

[linuxnutzer]

Hast du ein Beispiel?

Zur Zeit nicht, aber dieser PC ist predestiniert für problematische UHD-Installation mit 2 verschiedenen 32°-Asus Proart UHD

---

System:
  Kernel: 6.14.0-33-generic arch: x86_64 bits: 64
  Console: pty pts/0 Distro: Xubuntu 24.04.3 LTS (Noble Numbat)
Machine:
  Type: Desktop Mobo: Micro-Star model: MPG X570 GAMING PRO CARBON WIFI
    (MS-7B93) v: 1.0 serial: <superuser required> UEFI: American Megatrends
    LLC. v: 1.P0 date: 09/05/2025
CPU:
  Info: 8-core model: AMD Ryzen 7 3700X bits: 64 type: MT MCP cache: L2: 4 MiB
  Speed (MHz): avg: 2219 min/max: 550/4426 cores: 1: 3600 2: 1760 3: 1760
    4: 3600 5: 1760 6: 1760 7: 1760 8: 1760 9: 1760 10: 1760 11: 1760 12: 3599
    13: 1760 14: 3600 15: 1760 16: 1760
Graphics:
  Device-1: NVIDIA TU116 [GeForce GTX 1660] driver: nvidia v: 580.95.05
  Display: server: X.org v: 1.21.1.11 driver: X: loaded: nvidia
    unloaded: fbdev,modesetting,nouveau,vesa gpu: nvidia tty: 80x24
  API: EGL v: 1.5 drivers: nvidia,swrast platforms: surfaceless,device
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: mesa v: 25.0.7-0ubuntu0.24.04.2
    note: console (EGL sourced) renderer: NVIDIA GeForce GTX 1660/PCIe/SSE2,
    llvmpipe (LLVM 20.1.2 256 bits)
  API: Vulkan v: 1.3.275 drivers: N/A surfaces: N/A

Mit FHD-Display noch nie ein Problem.

Ein anderer sehr alter scheitert auch, aber da kann die Graka die UHD nicht darstellen, den gibt es nur mehr in Restteilen.

Irritierend ist ja immer, wenn etwas manchmal nicht funktioniert. Wenn es immer nicht geht, ok, dann ist das so.

 

[Nero FX]

@linuxnutzer

Ist vollkommen egal, haptsache nur HDMI. Die karten sind aber in getrennten PCs oder?
Wenn in einem PC dann bitte eine Ausbauen und einzeln updaten wenn du nur 1 HDMI Kabel hast.

Vorher idealerweise die AMD Grafik abschalten.

@linuxnutzer
Du bringst hier vieles durcheinander, jetzt kommt ein Log mit einer Nvidia Grafikkarte und Ryzen 3700X dazu...
Bitte pro Thread nur einen PC betrachten, gerne weitere Threads für die anderen PCs mit anderer Hardware.

 

[linuxnutzer]

Die karten sind aber in getrennten PCs oder?

Ja völlig getrennte PCs. Ich denke sonst würde man das in den Screenshots am Anfang sehen. Da scheint keine alte Nvidia auf. Muss ich die interne AMD-Graka von der CPU im UEFI auch für ein eventuelles FW-Update deaktivieren?

Genau deswegen ist die aktiv, um mir bei Problemen ein CMOS-Reset zu sparen.

 

[Nero FX]

@linuxnutzer

Du musst Sie nicht abschalten, ich würde es aber zur Sicherheit tun.
Ein BIOS Reset würde ich da nicht als Hürde sehen.

 

[linuxnutzer]

Du musst Sie nicht abschalten, ich würde es aber zur Sicherheit tun.

Sollte man annehmen. Bei NVME-FW-Updates hätte ich schon mal Fremdhersteller flashen können, zumindest anfangen.

Ergänzung (3. November 2025)

Wenn der Monitor kein HDMI bietet, wäre so eine Zwangsbedingungen reichlich dämlich.

So ist es. Hier ist die Warnung:

Kann man den Installer beliebig oft starten? Es wird jedesmal neu entpackt. Ich vermute da wird eine .bat gestartet, aber wissen tu ich das nicht.

Wie kann man ohne Nachschauen abfragen, ob der Monitor via HDMI angeschlossen ist? Bei mir ist das abstecken eine Fummelei.

 

[DerkleineGrisu]

Sollte man annehmen. Bei NVME-FW-Updates hätte ich schon mal Fremdhersteller flashen können, zumindest anfangen.

Ergänzung (3. November 2025)

Kann man den Installer beliebig oft starten? Es wird jedesmal neu entpackt. Ich vermute da wird eine .bat gestartet, aber wissen tu ich das nicht.

Wie kann man ohne Nachschauen abfragen, ob der Monitor via HDMI angeschlossen ist? Bei mir ist das abstecken eine Fummelei.

Also, das HDMI Kabel wird anscheinend " Gebraucht" damit die firmeware für den HDMI anschluss auch richtig durchgeführt werden kann.
Wenn halt der HDMI anschluss nicht verwendet wird sollte auch das HDMI update halt nicht durchgeführt werden.
Mehr sagt diese " warnung" nicht aus.
Intel geht halt davon auch das noch "Tausende" ihrer Benutzer nur HDMI als anschluss benutzen.

 

[linuxnutzer]

Also, das HDMI Kabel wird anscheinend " Gebraucht" damit die firmeware für den HDMI anschluss auch richtig durchgeführt werden kann.

Also ich habe jetzt alles gemacht, inkl. FW-Update, aber opencl funktioniert noch immer nicht. Muss man das irgendwo aktvieren?

Natürlich habe ich den PC danach heruntergefahren und neu gestartet.

Wie kann ich die Firmware abfragen?

Ergänzung

darktable-cltest.exe

darktable 5.2.1
Copyright (C) 2012-2025 Johannes Hanika and other contributors.

Compile options:
  Bit depth              -> 64 bit
  Exiv2                  -> 0.27.7
  Lensfun                -> 0.3.4
  Debug                  -> DISABLED
  SSE2 optimizations     -> ENABLED
  OpenMP                 -> ENABLED
  OpenCL                 -> ENABLED

Das sieht danach aus, dass das ein Darktable-Konfigurationsproblem bei 2 Grafikkarten ist. Eigentlich sollte die eindeutig stärkere Graka automatisch verwendet werden. Der AMD-Treiber wurde sogar in DT deaktiviert.

 

[linuxnutzer]

Damit fehlt mit höher Wahrscheinlichkeit sogar der OpenCL Treiber.
Gerade bei Intel Grafikkarten ist ein aktueller Treiber das A und O!

Und jetzt kommt die Ohrfeige, der Intel-Neo-Treiber steht bei Darktable mit opencl auf einer Blacklist.

 

[Nero FX]

@linuxnutzer

Das liegt aber an Darktable, die Entwickler sehen OpenCL als nicht notwendig an.

Letztlich gibt es in darktable nichts, was nur auf dem Grafikprozessor (GPU) läuft. Das Fehlen von OpenCL muss nicht entmutigen – auch darktables CPU-Code ist hochgradig auf Leistung optimiert!

 

[linuxnutzer]

Das liegt aber an Darktable, die Entwickler sehen OpenCL als nicht notwendig an

Ich denke das interpretierst du falsch. Ja opencl ist nicht zwingend notwendig, macht das Rendern aber deutlich schneller. Unter Linux funktioniert darktable mit opencl problemlos und sehr schnell. Da hat Nvidia eine große Konkurrenz. Ich glaube es liegt daran, dass darktable anfangs nicht für Windows entwickelt wurde, aber schön langsam Interesse auch für Win besteht.

 

[linuxnutzer]

Geschafft, man muss in

C:\Users\ich\AppData\Local\darktable\darktablerc

1 Wert von 1 auf 0 setzen:

cldevice_v5_intelropenclgraphicsintelrarctmb580graphics=0 250 0 16 16 128 0 1 0,000 0,000 0,250

zu

cldevice_v5_intelropenclgraphicsintelrarctmb580graphics=0 250 0 16 16 128 0 0 0,000 0,000 0,250

Damit ist die Blacklist aufgehoben. Achtung man braucht einen passenden Editor dazu, zB npp++

Dann noch in den Einstellungen opencl erlauben und die Hardware sonst passend konfigurieren und es kann klappen. Bei manchen funktioniert es, bei anderen gibt es lt. Webdiskussionen Abstürze. Bei mir gab es mit aktuellem 24H2 keinen Absturz.

Windows-Benchmark:
4,8348 [dev_process_export] pixel pipeline processing took 1,941 secs (2,438 CPU)

Linux-Benchmark:
2.9135 [dev_process_export] pixel pipeline processing took 1.513 secs (2.311 CPU)

Also je nachdem wie man es betrachtet. Unter Win dauert das Testfoto inkl. Initialisierung 5sec und unter Linux 3sec. Nur GPU: Win 2, Linux 1.5sec. Damit erklären sich dann auch die Nvidia-Vergleiche mit Benchmarks, die ich im Netz fand. Darktable ist unter Windows einfach langsamer und das muss man bei der Grafikkarten-Wahl berücksichtigen, wenn man vergleicht. Ich hatte das nicht vermutet, dass der Unterschied so deutlich ist.