Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung? Thema ist als GELÖST markiert

Probleme bei der Installation von Hardware unter Manjaro Linux? Hier wird geholfen.</span

Themen Author
Clemens
Forum Kenner
Forum Kenner
Beiträge: 155
Registriert: Donnerstag 9. Januar 2020, 18:16
Wohnort: Rottweil
CPU: Intel i5-7400
GPU: nVidia GTX 1650
Kernel: 5.5.19
DE: FXCE
GPU Treiber: Linux / nVidia free
Hat sich bedankt: 40 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#16

#16 Beitrag von Clemens »

Die Auto-Installation hat auf Anhieb funktioniert. Der Vorgang dauerte immerhin rund 3 Minuten. Dann lief alles. Sicherheitshalber habe ich rebootet.

Die für das Rendern mit Kdenlive wichtige Verbindung zwischen den nVidia-Treibern mit NVencode und ffmpeg habe ich wie folgt getestet:

Code: Alles auswählen

ffmpeg -help encoder=h264_nvenc
ffmpeg version n4.2.2 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 9.3.0 (Arch Linux 9.3.0-1)
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmfx --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3
  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100
Encoder h264_nvenc [NVIDIA NVENC H.264 encoder]:
    General capabilities: delay hardware 
    Threading capabilities: none
    Supported pixel formats: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 rgb0 cuda
h264_nvenc AVOptions:
  -preset            <int>        E..V..... Set the encoding preset (from 0 to 11) (default medium)
     default                      E..V..... 
     slow                         E..V..... hq 2 passes
     medium                       E..V..... hq 1 pass
     fast                         E..V..... hp 1 pass
     hp                           E..V..... 
     hq                           E..V..... 
     bd                           E..V..... 
     ll                           E..V..... low latency
     llhq                         E..V..... low latency hq
     llhp                         E..V..... low latency hp
     lossless                     E..V..... 
     losslesshp                   E..V..... 
  -profile           <int>        E..V..... Set the encoding profile (from 0 to 3) (default main)
     baseline                     E..V..... 
     main                         E..V..... 
     high                         E..V..... 
     high444p                     E..V..... 
  -level             <int>        E..V..... Set the encoding level restriction (from 0 to 51) (default auto)
     auto                         E..V..... 
     1                            E..V..... 
     1.0                          E..V..... 
     1b                           E..V..... 
     1.0b                         E..V..... 
     1.1                          E..V..... 
     1.2                          E..V..... 
     1.3                          E..V..... 
     2                            E..V..... 
     2.0                          E..V..... 
     2.1                          E..V..... 
     2.2                          E..V..... 
     3                            E..V..... 
     3.0                          E..V..... 
     3.1                          E..V..... 
     3.2                          E..V..... 
     4                            E..V..... 
     4.0                          E..V..... 
     4.1                          E..V..... 
     4.2                          E..V..... 
     5                            E..V..... 
     5.0                          E..V..... 
     5.1                          E..V..... 
  -rc                <int>        E..V..... Override the preset rate-control (from -1 to INT_MAX) (default -1)
     constqp                      E..V..... Constant QP mode
     vbr                          E..V..... Variable bitrate mode
     cbr                          E..V..... Constant bitrate mode
     vbr_minqp                    E..V..... Variable bitrate mode with MinQP (deprecated)
     ll_2pass_quality              E..V..... Multi-pass optimized for image quality (deprecated)
     ll_2pass_size                E..V..... Multi-pass optimized for constant frame size (deprecated)
     vbr_2pass                    E..V..... Multi-pass variable bitrate mode (deprecated)
     cbr_ld_hq                    E..V..... Constant bitrate low delay high quality mode
     cbr_hq                       E..V..... Constant bitrate high quality mode
     vbr_hq                       E..V..... Variable bitrate high quality mode
  -rc-lookahead      <int>        E..V..... Number of frames to look ahead for rate-control (from 0 to INT_MAX) (default 0)
  -surfaces          <int>        E..V..... Number of concurrent surfaces (from 0 to 64) (default 0)
  -cbr               <boolean>    E..V..... Use cbr encoding mode (default false)
  -2pass             <boolean>    E..V..... Use 2pass encoding mode (default auto)
  -gpu               <int>        E..V..... Selects which NVENC capable GPU to use. First GPU is 0, second is 1, and so on. (from -2 to INT_MAX) (default any)
     any                          E..V..... Pick the first device available
     list                         E..V..... List the available devices
  -delay             <int>        E..V..... Delay frame output by the given amount of frames (from 0 to INT_MAX) (default INT_MAX)
  -no-scenecut       <boolean>    E..V..... When lookahead is enabled, set this to 1 to disable adaptive I-frame insertion at scene cuts (default false)
  -forced-idr        <boolean>    E..V..... If forcing keyframes, force them as IDR frames. (default false)
  -b_adapt           <boolean>    E..V..... When lookahead is enabled, set this to 0 to disable adaptive B-frame decision (default true)
  -spatial-aq        <boolean>    E..V..... set to 1 to enable Spatial AQ (default false)
  -temporal-aq       <boolean>    E..V..... set to 1 to enable Temporal AQ (default false)
  -zerolatency       <boolean>    E..V..... Set 1 to indicate zero latency operation (no reordering delay) (default false)
  -nonref_p          <boolean>    E..V..... Set this to 1 to enable automatic insertion of non-reference P-frames (default false)
  -strict_gop        <boolean>    E..V..... Set 1 to minimize GOP-to-GOP rate fluctuations (default false)
  -aq-strength       <int>        E..V..... When Spatial AQ is enabled, this field is used to specify AQ strength. AQ strength scale is from 1 (low) - 15 (aggressive) (from 1 to 15) (default 8)
  -cq                <float>      E..V..... Set target quality level (0 to 51, 0 means automatic) for constant quality mode in VBR rate control (from 0 to 51) (default 0)
  -aud               <boolean>    E..V..... Use access unit delimiters (default false)
  -bluray-compat     <boolean>    E..V..... Bluray compatibility workarounds (default false)
  -init_qpP          <int>        E..V..... Initial QP value for P frame (from -1 to 51) (default -1)
  -init_qpB          <int>        E..V..... Initial QP value for B frame (from -1 to 51) (default -1)
  -init_qpI          <int>        E..V..... Initial QP value for I frame (from -1 to 51) (default -1)
  -qp                <int>        E..V..... Constant quantization parameter rate control method (from -1 to 51) (default -1)
  -weighted_pred     <int>        E..V..... Set 1 to enable weighted prediction (from 0 to 1) (default 0)
  -coder             <int>        E..V..... Coder type (from -1 to 2) (default default)
     default                      E..V..... 
     auto                         E..V..... 
     cabac                        E..V..... 
     cavlc                        E..V..... 
     ac                           E..V..... 
     vlc                          E..V..... 
  -b_ref_mode        <int>        E..V..... Use B frames as references (from 0 to 2) (default disabled)
     disabled                     E..V..... B frames will not be used for reference
     each                         E..V..... Each B frame will be used for reference
     middle                       E..V..... Only (number of B frames)/2 will be used for reference
  -a53cc             <boolean>    E..V..... Use A53 Closed Captions (if available) (default true)
So weit ich das beurteilen kann, ist die Verbindung hergestellt und müsste funktionieren, auch wenn wohl nicht alle möglichen Features aktiviert sind / aktiviert werden können.
Dann habe ich Kdenlive mit einem Test-Video gestartet und das Rendern gestartet. Das war enttäuschend:

Renderzeit nur mit Intel-Onboard-Grafik: ca. 2 Stunden 58 Minuten
Renderzeit mit nVidia GTX 1650 und Standard-OpenSource-Treibern: ca. 2 Stunden 49 Minuten (Graka-Temperatur ca. 3°C über Gehäuse)
Renderzeit jetzt mit proprietären nVidia-Treibern: ca. 2 Stunden 40 Minuten. (Graka-Temperatur ca. 8°C über Gehäuse)
Renderzeit wie vor aber mit 2 Threads in Kdenlive: ca. 2 Stunden 34 Minuten. (Graka-Temperatur ca. 8°C über Gehäuse)

Bei allen vier Rendervorgängen musste die CPU (des PC) immer ca. mit 70% Last arbeiten.

Mit den proprietären nVidia-Treibern startet Kdenlive erheblich schneller und nutzt dabei bis zu 45% GPU-Leistung und bis zu 38% des Graka-RAM (4 GB). Während des Rendervorgang werden durchschnittlich 5% der GPU-Leistung und bis zu 12% Graka-RAM benutzt.

Aber Achtung! Die o.g. Renderzeiten sind der Wert, den Kdenlive zu Beginn des Rendervorgang anzeigt. Während ich dies hier schrieb, ist das Rendern des letzgenannten Beispiel weiter voran geschritten. Jetzt zeigt Kdenlive plötzlich eine voraussichtliche Renderzeit von 3 Stunden 22 Minuten an, kurz darauf wieder 2 Stunden 42 Minuten....

Hätte ich das vorher gewusst, ich hätte keine Grafikkarte gekauft! – Mir bleibt nur die Hoffnung, dass Kdenlive möglichst bald ein verbessertes Rendering unter starker GPU-Ausnutzung in die Software einbaut. Oder ich muss es mit Blender versuchen. Das hat angeblich eine erheblich bessere Nutzung der GPU.

Herzlichen Dank an zompel und daemon! Ohne Eure Unterstützung wäre ich mal wieder voll aufgeschmissen gewesen.


Daemon
Forum Gott
Forum Gott
Beiträge: 338
Registriert: Freitag 22. Dezember 2017, 14:17
CPU: 6082
GPU: wtf
Kernel: pre-linux
DE: pre-linux
GPU Treiber: hab keine
Hat sich bedankt: 2 Mal
Danksagung erhalten: 25 Mal

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#17

#17 Beitrag von Daemon »

Verkaufe die Karte wieder, oder wenn es geht und du im Internet bestellt hast, nutze die 14 Tage Widerrufsrecht.

Die 1650, dazu noch mit nur 4GB RAM, ist echt nicht das gelbe vom Ei (wie du ja selbst festgestellt hast ;) ).

Mich würde jetzt mal interessieren, wie lange meine GPU brauchen würde.

Hast du nicht zufällig ein Video wo wir mal vergleichen können?


Themen Author
Clemens
Forum Kenner
Forum Kenner
Beiträge: 155
Registriert: Donnerstag 9. Januar 2020, 18:16
Wohnort: Rottweil
CPU: Intel i5-7400
GPU: nVidia GTX 1650
Kernel: 5.5.19
DE: FXCE
GPU Treiber: Linux / nVidia free
Hat sich bedankt: 40 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#18

#18 Beitrag von Clemens »

Mein Video ist aktuell knapp 30 Minuten lang bei 1080p @ 50fps. Gerendert wird das Schnitt-Ergebnis aus vier AV-Spuren und einer Videospur (Titel). Es werden weder im Bild noch im Ton Effekte, Filter, Grading usw. verwendet.
Das Rohmaterial umfasst 24 GB. Ich rendere das ganze wieder auf 1080p @ 50 fps.

Wenn du Renderzeiten vergleichen möchtest, dann müssten wir z.B. ein 5-minütiges Video in 1080p aussuchen, das einfach nur einen Titel drüber gelegt bekommt und dann im gleichen Ausgabeformat neu gerendert wird. Bist du daran interessiert?

Wenn ja, kannst du ja ein geeignetes Video auf deinen Webspace legen oder über WEtransfer mir zugänglich machen. Oder du möchtest, dass ich das Video auswähle? Lass es mich wissen, dann lege ich es für dich auf meinen Webspace.

Deiner Empfehlung, die Karte wieder zurück zu geben, mag ich zumindest derzeit nicht folgen (und später ist es wg. der 14 Tage zu spät). Einerseits fände ich es dem Händler gegenüber nicht fair und andererseits hatte ich ja hier schon mitgeteilt, dass die Grafikkarte nur mit minimaler Belastung beim Rendern arbeitet. Sie könnte also viel mehr leisten – geschätzt das mindestens 10-fache! (siehe die Werte unten)
Als Ursache für die geringe Leistung sehe ich entweder in der Ansteuerung bzw. der Treiberseite inclusive des ffmpeg-Framework oder aber in der Ansteuerung, die Kdenlive den Treibern bietet.

Mit Psensor erhalte ich alle Einzelheiten der Nvidia-Karte angezeigt:
Temperatur = 34°C = ca. 7′C oberhalb der Gehäusetemperatur
graphics = zwischen 3% und 10% schwankend, Spitzenlast kurzzeitig 48% = Start von Kdenlive
video = immer 0% (=verdächtig wenig!)
memory = zwischen 8% und 20% (von 4GB), kurzzeitiger Spitzenwert = 40% beim Start von Kdenlive
PCIe = 0% bis 1%, kurzzeitiger Spitzenwert bei 20% beim Systemstart
NVIDIA 0 fan level = 30% (lüfterlose Karte)

CPU beim Rendern = 65% bis 85%
RAM beim Rendern = ca. 45% (von 16GB)


Übrigens: Wenn ich über Kaffeine Digitales TV anschaue, wird die Grafikkarte endlich mal genutzt:
Temperatur = 38°C
graphics = 38%
video = 8% bis 12%
memory = 25% bis 35%
PCIe = 1%

CPU = 20%
RAM = 48%


Wie sehen deine Nvidia-Werte beim Rendern aus, wenn du ebenfalls Psensor benutzt?
Und welche Karte nutzt du und welche Treiber?

Benutzeravatar

zompel
Erfahrenes Foren Mitglied
Erfahrenes Foren Mitglied
Beiträge: 57
Registriert: Montag 9. Dezember 2019, 19:52
CPU: Intel Core i9-9900KF
GPU: nVidia GeForce RTX 2070
Kernel: Linux 5.4 LTS
DE: Gnome 3.36
GPU Treiber: nVidia 440.xx
Hat sich bedankt: 3 Mal
Danksagung erhalten: 10 Mal

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#19

#19 Beitrag von zompel »

Ich weiß nicht ob es dich interessiert, aber es gibt Benchmarkprogramme um die OpenCL Leistung zu testen.
Du könntest zumindest mal sehen was die Karte leistet wenn sie "vernünftig" eingebunden ist und du siehst dann auch ob treiberseitig alles ok ist wenn die Ergebnisse mit denen ähnlicher Grakas vergleichbar sind.
LuxMark und Geekbench habe ich durch googeln gefunden - sind beide auch im AUR enthalten.


Daemon
Forum Gott
Forum Gott
Beiträge: 338
Registriert: Freitag 22. Dezember 2017, 14:17
CPU: 6082
GPU: wtf
Kernel: pre-linux
DE: pre-linux
GPU Treiber: hab keine
Hat sich bedankt: 2 Mal
Danksagung erhalten: 25 Mal

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#20

#20 Beitrag von Daemon »

Ich habe keine nVidia Karte.

Das Video müsstest du bereitstellen, da ich mit Videos nichts am Hut habe.

Und ich bräuchte dann die genauen Einstellungen welche du auch in Kdenlive benutzt, ansonsten kann man das nicht wirklich vergleichen.


Themen Author
Clemens
Forum Kenner
Forum Kenner
Beiträge: 155
Registriert: Donnerstag 9. Januar 2020, 18:16
Wohnort: Rottweil
CPU: Intel i5-7400
GPU: nVidia GTX 1650
Kernel: 5.5.19
DE: FXCE
GPU Treiber: Linux / nVidia free
Hat sich bedankt: 40 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#21

#21 Beitrag von Clemens »

@zompel:
Bis auf Weiteres geht es mir nicht mehr um OpenCl, weil ich sowohl auf der nVidia-Website als auch auf der Arch-Website zu nVidia Hinweise gefunden habe, dass die proprietären nVidia-Treiber eine Schnittstelle zum ffmpeg-Framework hat, die nVidia mit NVencode und NVdecode bezeichnet. Damit sollte das Rendering in der GPU erfolgen und die Geschwindigkeit soll angeblich fast an eine CUDA-Lösung heran reichen.
Da Kdenlive bis heute auf dem MLT-Framework beruht und dieses noch keine Schnittstelle zu OpenCl bereit stellt, wohl aber betreffend Rendering / Encode / Decode auf dem ffmpeg-Framework, müsste eigentlich alles jetzt passen.

Die Belastungsdaten, die mir Psensor über meine nVidia-Karte liefert während ich mit Kdenlive ein Video rendere, zeigen aber, dass die Karte beim Rendern fast nichts tut und die meiste Last nach wie vor auf der CPU liegt. Warum das so ist, konnte ich bis jetzt noch nicht klären. – Aber aufgrund des Sachverhalt jetzt macht es wenig Sinn, dass ich OpenCl weiter verfolge, weil Kdenlive diese Schnittstelle nicht ansprechen kann.

Ich bin kein Programmierer und meine Fachbegriffe sind sicher nicht so korrekt. Es müsste aber verständlich sein, worum es derzeit geht. Luxmark würde OpenCl testen, während Geekbench anscheinend nur das RAM und die CPU testet. Ich müsste über ffmpeg die NVencode und NVdecode Schnittstelle testen können. Dafür habe ich weder bei nVidia noch bei Arch oder Manjaro geeignete Test-Tools gefunden.

Übrigens: Da ich heute Nachmittag beobachten konnte, dass in Verbindung mit Kaffeine und Digital-TV immerhin die Abteiliung "graphics" in der nVidia-Karte mit rund 40% ausgelastet ist, scheint ffmpeg und NVdecode wohl zu funktionieren. Für das Rendern mit Kdenlive müsste aber NVencode zusammen mit ffmpeg gut funktionieren.

Du hast offensichtlich eine nVidia-Karte in deinem PC. Ich würde mich freuen, wenn du wie Daemon das von mir bereit gestellte Video ebenfalls testweise mit Kdenlive rendern würdest. Bin gespannt auf die Ergebnisse / den Vergleich!

@Daemon:
Ich nehme morgen mal einige Kamera-Schwenks auf, damit wir sauberes MP4-Ausgangsmaterial haben. Hier lege ich dann einen Titel drüber und rendere das ganze und nehme die Zeit und die über Psensor zu sehende Belastung der Karte.
Das unbearbeitete Video ab Kamera stelle ich zugleich auf meiner Website bereit, sodass du es einfach runter laden und in ähnlicher Weise rendern kannst. – Natürlich nenne ich dir genau die Kdenlive-Einstellungen.

Hier noch ein Zitat von der nVidia-Website:
https://devblogs.nvidia.com/nvidia-ffmp ... ing-guide/
NVIDIA GPUs ship with an on-chip hardware encoder and decoder unit often referred to as NVENC and NVDEC. Separate from the CUDA cores, NVENC/NVDEC run encoding or decoding workloads without slowing the execution of graphics or CUDA workloads running at the same time.
NVENC and NVDEC support the many important codecs for encoding and decoding. Figure 1 lists many of the codecs, format and features supported with current NVIDIA hardware. Actual support depends on the GPU that is used. An up-to-date support matrix can be found at the Video Encode and Decode Support Matrix page.
Nun benötige ich ja kein "Transcoding", aber dabei wird ja ebenfalls gerendert, sodass die Beschreibungen dort auch für meine Anwendung zutreffen müssten. Betreffend ffmpeg und nVidiaencode / decode finde ich noch folgende Anleitung auf der o.g. Website, der ich aber nicht ganz folgen kann:
FFmpeg supports hardware accelerated decoding and encoding via the h264_cuvid, hevc_cuvid and h264_nvenc, hevc_nvenc modules. Activating support for hardware acceleration when building from source requires some extra steps:

Clone the FFmpeg git repository https://git.ffmpeg.org/ffmpeg.git
Download and install a compatible driver from the NVIDIA web site
Download and install the CUDA toolkit
Clone the nv-codec-headers repository and install using this repository as header-only: make install
Configure FFmpeg using the following command (use correct CUDA library path):

Code: Alles auswählen

./configure --enable-cuda --enable-cuvid --enable-nvenc --enable-nonfree --enable-libnpp --extra-cflags=-I/usr/local/cuda/include  --extra-ldflags=-L/usr/local/cuda/lib64
In diesem etwas älteren Beitrag aus 2017 fand ich eine sehr detaillierte Beschreibung zu genau meiner Schwierigkeit hier. Der Beitrag bezieht sich aber auf Ubuntu: https://www.linux-magazin.de/ausgaben/2 ... it-gpus/2/
Ich kann dem dort Beschrieben aber leider mangels Verständnis der Zusammenhänge nicht folgen und die Sorge, dass ich mir mein Produktivsystem zerschieße, hindert mich an Experimenten.

Herzlichen Dank für Eure Hilfe und Euer Engagement!


Themen Author
Clemens
Forum Kenner
Forum Kenner
Beiträge: 155
Registriert: Donnerstag 9. Januar 2020, 18:16
Wohnort: Rottweil
CPU: Intel i5-7400
GPU: nVidia GTX 1650
Kernel: 5.5.19
DE: FXCE
GPU Treiber: Linux / nVidia free
Hat sich bedankt: 40 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#22

#22 Beitrag von Clemens »

Hi!
Ich habe gerade auf Anregung dieses Video (puuhhhh ist das dort kompliziert!!!) meinen SimpleScreenrecorder angeworfen. Dort konnte ich als Encoder den gewünschten h264_nvenc und AAC auswählen. Die Aufnahme gelang einwandfrei.

Folglich ist dies ein Lichtblick, dass der nVidia Encoder (GPU) funktioniert... wenn man ihn richtig ansteuert. Ist also spannend, was ich in Kdenlive einstellen muss, damit ebenfalls dieser Encoder angesprochen wird.

Benutzeravatar

zompel
Erfahrenes Foren Mitglied
Erfahrenes Foren Mitglied
Beiträge: 57
Registriert: Montag 9. Dezember 2019, 19:52
CPU: Intel Core i9-9900KF
GPU: nVidia GeForce RTX 2070
Kernel: Linux 5.4 LTS
DE: Gnome 3.36
GPU Treiber: nVidia 440.xx
Hat sich bedankt: 3 Mal
Danksagung erhalten: 10 Mal

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#23

#23 Beitrag von zompel »

Ist bei dir auch das Paket "nvidia-440-utils" installiert?
Anosnsten könnte es wirklich nur noch an Einstellungen bei Kdenlive handeln denke ich...
Und was den Vergleich angeht... wäre mir zur Zeit etwas zu viel. Zudem habe ich auch ein völlig anderen PC, weshalb wahrscheinlich auch ohne NVENC erhebliche Unterschiede festzustellen wären.


Themen Author
Clemens
Forum Kenner
Forum Kenner
Beiträge: 155
Registriert: Donnerstag 9. Januar 2020, 18:16
Wohnort: Rottweil
CPU: Intel i5-7400
GPU: nVidia GTX 1650
Kernel: 5.5.19
DE: FXCE
GPU Treiber: Linux / nVidia free
Hat sich bedankt: 40 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Nvidia GTX 1650 für Kdenlive optimal

#24

#24 Beitrag von Clemens »

Nur die auf der Nvidia Website https://devblogs.nvidia.com/nvidia-ffmp ... ing-guide/ vorhandene Anleitung scheint mir auf dem neuesten Stand (24. Juli 2019) zu sein, während die anderen von mir zitierten Fundstellen alle ein bis drei Jahre alt sind. Gerade auf dem GPU-Sektor scheint die Technik rasant weiter entwickelt zu werden.

Nvidia rät zu folgender Installation:
FFmpeg supports hardware accelerated decoding and encoding via the h264_cuvid, hevc_cuvid and h264_nvenc, hevc_nvenc modules. Activating support for hardware acceleration when building from source requires some extra steps:

1. Clone the FFmpeg git repository https://git.ffmpeg.org/ffmpeg.git
2. Download and install a compatible driver from the NVIDIA web site
3. Download and install the CUDA toolkit = community Repo
4. Clone the nv-codec-headers repository and install using this repository as header-only: make install
5. Configure FFmpeg using the following command (use correct CUDA library path).....

Nun habe ich nach den von Nvidia genannten Ausdrücken / Begriffen in den Repos gesucht und fand für den Punkt 1 im AUR
ffmpeg-git-nc 4.3.r94543.g8fcc5d963e-1
Complete solution to record, convert and stream audio and video (all possible features including nvenc, qsv and libfdk-aac; Nonconflicting git version)

Punkt 2 der Nvidia-Anleitung hatte ich ja bereits über den Manjaro-Hardware-Manager ereldigt.

Zu Punkt 3 der Nvidia-Anleitung fand ich im extra Repo
cuda 10.2.89-5
The NVIDIA® CUDA® Toolkit provides a development environment for creating high performance GPU-accelerated applications. With the CUDA Toolkit, you can develop, optimize and deploy your applications on GPU-accelerated embedded systems

Und zu Punkt 4 der Nvidia-Anleitung fand ich ebenfalls im extra Repo
ffnvcodec-headers 9.1.23.1-1

Wenn ich also jetzt die oben genannten drei Pakete installiere und danach mit dem Schritt 5 der Nvidia-Anleitung konfiguriere, dann müsste eigentlich das Nvidia Hardware Encodig und Decoding aktiviert sein. Das GPU-Encoding über Kdenlive beim Rendern müsste dann auch funktionieren.
Aber sicher bin ich mir bei alledem nicht!

Daher habe ich nun folgende konkrete Fragen:
Gefährde ich mein derzeit stabil laufendes System, wenn ich die o.g. drei Pakete installiere?
Und kann ich bei Misserfolg die o.g. Pakete mittels Pacman rückstandsfrei wieder vom System deinstallieren?
Wie wahrscheinlich ist es, dass nach der Installation das Rendern von Kdenlive wirklich per Hardware / GPU ablaufen wird?


Themen Author
Clemens
Forum Kenner
Forum Kenner
Beiträge: 155
Registriert: Donnerstag 9. Januar 2020, 18:16
Wohnort: Rottweil
CPU: Intel i5-7400
GPU: nVidia GTX 1650
Kernel: 5.5.19
DE: FXCE
GPU Treiber: Linux / nVidia free
Hat sich bedankt: 40 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#25

#25 Beitrag von Clemens »

@zompel
Ja ich habe das Paket nvidia-440-utils installiert. Im Manjaro-Menü findet sich auch ein Punkt "Nvidia Xserver settings".

Meinen neuer Beitrag oben hatte ich geschrieben, während deiner gerade eintraf.

Ja, du hast sicher Recht, dass zewi ziemlich unterschiedliche Systeme zu vergleichen keinen Sinn macht.

Benutzeravatar

zompel
Erfahrenes Foren Mitglied
Erfahrenes Foren Mitglied
Beiträge: 57
Registriert: Montag 9. Dezember 2019, 19:52
CPU: Intel Core i9-9900KF
GPU: nVidia GeForce RTX 2070
Kernel: Linux 5.4 LTS
DE: Gnome 3.36
GPU Treiber: nVidia 440.xx
Hat sich bedankt: 3 Mal
Danksagung erhalten: 10 Mal

Re: Nvidia GTX 1650 für Kdenlive optimal

#26

#26 Beitrag von zompel »

Clemens hat geschrieben:
Mittwoch 29. April 2020, 22:15
Nvidia rät zu folgender Installation:
FFmpeg supports hardware accelerated decoding and encoding via the h264_cuvid, hevc_cuvid and h264_nvenc, hevc_nvenc modules. Activating support for hardware acceleration when building from source requires some extra steps:

1. Clone the FFmpeg git repository https://git.ffmpeg.org/ffmpeg.git
2. Download and install a compatible driver from the NVIDIA web site
3. Download and install the CUDA toolkit = community Repo
4. Clone the nv-codec-headers repository and install using this repository as header-only: make install
5. Configure FFmpeg using the following command (use correct CUDA library path).....
Nach meinem Verständnis würdest du dir damit aus dem Quellcode eine eigene ffmpeg Version kompilieren, wozu du allerdings auch eine Entwicklungsumgebung brauchst und sicherlich auch ein wenig Erfahrung mit Programmierung haben solltest... mir wäre das ein wenig zu viel.

Zudem meine ich dass du mit dem installiertem Treiber, den "nvidia-440-utils" und dem aktuellen ffmpgeg Paket eigentlich alles haben solltest damit andere Programme die nvenc Fähigkeiten der Gafikkarte nutzen können.
Schau mal im Pacman nach den (optionalen) Abhängigkeiten für das Paket ffmpeg - ich meine dort stand bei mir auch irgendwas mit "nvenc" und rechts daneben war nicht der [Installieren] Button, was also bedeutet das es installiert ist und demnach verfügbar.

Vielleicht findest du ja doch mal irgendeine andere Möglichkeit um festzustellen ob nvenc bei dir funktioniert.

Edit:

...gerade noch mal was gefunden...
https://www.slashcam.de/artikel/Ratgebe ... html#Softw
...Per GPU in Adobe Premiere CS5, CS5.5, CS6 und CC in der Mercury Playback Engine (MPE) die Wiedergabe, GPU-Effekte, Deinterlacing, Blenden, Skalierung, Previews und der finale Output beschleunigt (GPU-Modus: "GPU Acceleration" statt "Software Only") - nicht jedoch das Encoding und Decoding (das wird per CPU berechnet).
Das könnte auch dein "Problem" sein.


Daemon
Forum Gott
Forum Gott
Beiträge: 338
Registriert: Freitag 22. Dezember 2017, 14:17
CPU: 6082
GPU: wtf
Kernel: pre-linux
DE: pre-linux
GPU Treiber: hab keine
Hat sich bedankt: 2 Mal
Danksagung erhalten: 25 Mal

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#27

#27 Beitrag von Daemon »

zompel hat geschrieben:
Mittwoch 29. April 2020, 21:47
Und was den Vergleich angeht... wäre mir zur Zeit etwas zu viel. Zudem habe ich auch ein völlig anderen PC, weshalb wahrscheinlich auch ohne NVENC erhebliche Unterschiede festzustellen wären.
Eigentlich wollte ich den Vergleich. :)


Themen Author
Clemens
Forum Kenner
Forum Kenner
Beiträge: 155
Registriert: Donnerstag 9. Januar 2020, 18:16
Wohnort: Rottweil
CPU: Intel i5-7400
GPU: nVidia GTX 1650
Kernel: 5.5.19
DE: FXCE
GPU Treiber: Linux / nVidia free
Hat sich bedankt: 40 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#28

#28 Beitrag von Clemens »

@ Daemon:
Deine Idee ist nicht dadurch „vom Tisch“, dass ich auch zompel angeboten habe, einen Geschwindigkeitstest zu machen. Aber damit wir vernünftige und aussagekräftige Ausgangsbedingungen haben, müsste ich erst noch die hier diskutierten Fragen geklärt haben und evtl. meine Installation ergänzen.
Anschließend würde ich schon gerne testen!

@zompel
Du schreibst:
Nach meinem Verständnis würdest du dir damit aus dem Quellcode eine eigene ffmpeg Version kompilieren, wozu du allerdings auch eine Entwicklungsumgebung brauchst und sicherlich auch ein wenig Erfahrung mit Programmierung haben solltest..
Hierzu schrieb ich ja bereits, dass es ein solches Paket im AUR gibt. Es nennt sich "ffmpeg-git-nc 4.3.r94543.g8fcc5d963e-1" und ich wüsste nicht, wozu ich Programmierkenntnisse benötige, wenn ich dieses Paket via Pacman herunter lade und automatisch kompilieren und installieren lasse.

Danke für deinen Hinweis betr. ffmpeg und Abhängigkeiten. Das hab ich geprüft. Ich habe ffmpeg 1:4.2.2-6 installiert und unter "optionale Abhängigkeiten" ist aufgeführt nvidia-utils: Nvidia NVDEC/NVENC support. Daneben ist kein "Installieren"-Button und das Paket habe ich zusätzlich überprüft, indem ich es angeklickt habe. Es ist der von dir genannten nvidia-440xx-utils 440.82-1. Und den habe ich ja ebenfalls bereits installiert gehabt.
cuda 10.2.89-5, das "Nvidia GPU programming toolkit" habe ich inzwischen auch installiert. Es ändert nichts an der Situation.

Ich hab bereits durch die Anregung in einem Internetbeitrag bedingt, den Simple Screenrecorder benutzt, um die Graka bzw. die Treibersituation zu testen. Ich konnte auf der zweiten Einstellungs-Seite des Screenrecorder in der Rubrik Video den Codec für die Aufnahme auswählen und fand in einer riesig langen Liste u.a. h264_nvenc. Die damit erstellte Aufnahme des Screenrecorder funktionierte einwandfrei! Also werden hier die Nvidia-Encoder angesprochen und wahrscheinlich auch die GPU.

Auch die Prüfung im Terminal zu den Encodern h264 und h265 zeigte die korrekte Installation und Verfügbarkeit:

Code: Alles auswählen

$ ffmpeg -h encoder=h264_nvenc
$ ffmpeg -h encoder=nvenc_hevc
Das sehr umfangreiche Ergebnis stelle ich hier mal nicht dar. :-)

Dann fand ich im Arch-Forum folgenden Thread, in dem genau die hier diskutierten Schwierigkeiten geklärt wurden:
https://bbs.archlinux.org/viewtopic.php ... 5#p1902005
Obwohl das Thema dort geschlossen wurde, habe ich mal versucht, mich noch dran zu hängen mit einer Nachfrage. Denn jetzt geht es darum, in Kdenlive ein neues Render-Profil anzulegen mitsamt der für die Nvidia-Encoder erforderlichen Parameter. Dazu gibt es anscheinend keine Dokumentation!

Weitere Websuche brachte mich zu folgendem YouTube-Video zum gleichen Thema:


In den Kommentaren zu diesem Video fand ich dann die passenden Renderprofile, sowohl für h264 als auch für h265:

Code: Alles auswählen

f=mp4 vcodec=nvenc_h264 acodec=aac g=120 global_quality=21 ab=384k vq=21 r=60 preset=slow bf=2

Code: Alles auswählen

f=mp4 vcodec=nvenc_hevc acodec=aac g=120 global_quality=23 ab=384k vq=23 r=60 preset=slow bf=2
Der h265 Encoder liefert allerdings nur eine Datei ohne Ton. Mirt ist aber der h264 zurzeit wichtiger.

Zum Vergleich das Renderprofil für den h264 Software Encoder:

Code: Alles auswählen

f=mp4 movflags=+faststart vcodec=libx264 progressive=1 g=15 bf=2 crf=%quality acodec=aac ab=%audiobitrate+'k'
Leider wird nirgends erklärt, wofür die einzelnen Parameter stehen. Ich fand durch experimentieren heraus, dass r=60 für die fps steht und preset=slow für die Rendergeschwindigkeit. g=120 steht vermutlich für die Videoqualität ab= steht vermutlich für die Audio-Qualität.

Nun habe ich mein fertig geschnittenes Projekt einmal mit dem Nvidia-GPU-Encoder gerendert und dann mit dem Software-Encoder.
Das Ausgangsmaterial stammt von meinen Sony a6400 und hat folgende Daten:
1920 x 1080 @50 fps 24248 kB/s and audio 48000 kHz PCM signed 1536 kB/s stereo.

Das sind die enttäuschenden Ergebnisse:
Mit dem o.g. h264 Nvidia-Profil dauert das Rendern ca. 3:32 Stunden. Mit dem h264 CPU-Render-Profil oben dauert es 4:05 Stunden, obwohl die Qualität des Software-Renderprofils deutlich geringer ist!

Die Belastung von CPU und GPU beim Rendern konnte ich wieder mit Psensor erkennen: Erstaunlicher Weise ist die Belastung bei beiden Renderprofilen sehr ähnlich: Die CPU wird mit ca. 60% belastet und die Grafikkarte bei "graphics" und bei "video" mit geringen einstelligen Prozentwerten, also gar nicht wirklich! Auch die Temperatur der Grafikkarte erhöht sich kaum beim Rendern.

Anhand der Bitrate und Audio-Bitrate kann ich aber erkennen, dass die Einstellungen der Renderprofile eindeutige Wirkung zeigen.

Insgesamt bin ich also deutlich weiter gekommen. Aber es ist immer noch etwas faul!

Was kann ich jetzt noch tun?

Benutzeravatar

zompel
Erfahrenes Foren Mitglied
Erfahrenes Foren Mitglied
Beiträge: 57
Registriert: Montag 9. Dezember 2019, 19:52
CPU: Intel Core i9-9900KF
GPU: nVidia GeForce RTX 2070
Kernel: Linux 5.4 LTS
DE: Gnome 3.36
GPU Treiber: nVidia 440.xx
Hat sich bedankt: 3 Mal
Danksagung erhalten: 10 Mal

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#29

#29 Beitrag von zompel »

Hattest du dich eigentlich schon mal mit anderen Videoschnittprogrammen auseinandergesetzt?
Vielleicht wäre Cinelerra GG Infinity interessant. Ich denke (ohne es bisher selbst getestet zu haben) dass es das beste freie Videoschnittprogramm für Linux ist und eventuell klappt es ja mit der Hardwareunterstützung besser.

edit:
Ist unter "cin-git" im AUR zu finden.


Themen Author
Clemens
Forum Kenner
Forum Kenner
Beiträge: 155
Registriert: Donnerstag 9. Januar 2020, 18:16
Wohnort: Rottweil
CPU: Intel i5-7400
GPU: nVidia GTX 1650
Kernel: 5.5.19
DE: FXCE
GPU Treiber: Linux / nVidia free
Hat sich bedankt: 40 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Nvidia GTX 1650 neu installiert - Überprüfung korrekter Einbindung?

#30

#30 Beitrag von Clemens »

Danke für den Tipp. Hab's sogleich geprüft und auch deren sehr gut gemachte Dokumentation gelesen, speziell zum Thema Rendern.
Cinelerra ist wohl von Anfang an stark darauf programmiert worden, das Rendern auf mehrere separate Rechner zu verteilen (distributed computing), evtl. auch, um als eines der ersten Schnittprogramme mit 8K Videos arbeiten zu können.

Auf Einzel-Computern wird nur Software-Rendering erwähnt. Falls man Harwdare-Rendern möchte, wird Intel mit der VA_API empfohlen. Von Nvidia keine Spur. In einem Ergänzungs-Dokument Ende 2019 wird beschrieben, dass GPU-Rendern über Nvidia von Usern zwar versucht werden kann, aber derzeit nichts supported wird und das eher nicht funktionieren wird. So jedenfalls habe ich deren Beschreibung verstanden.

Es sieht also eher danach aus, dass Cinelerra keine Alternative für mich ist. Würde ich es probehalber installieren, so würden damit zugleich etliche weitere Video / Grafiktreiber installiert (https://www.cinelerra-gg.org/download/pkgs/README.arch), sodass ich Konflikte mit meiner derzeitigen Konfiguration befürchten muss.

Ich hatte ja mein 6GB großes Referenz-Projekt bisher zum Rendern benutzt. Ich gebe zu, dass die Anforderungen dort sehr hoch sind, weil die Datenmenge groß ist. Das von den Kameras stammend Material hat folgende Daten:
1920x1080 @50fps - VideoBitrate 24.248 kB/s - yuv420p – Audio 48000 Hz 1536 kB/s PCM signed 16-bit

Die Render-Parameter finden sich in einer nicht alphabetischen sondern in einem voll chaotischen Verzeichnis mit zahlreichen Doppel-Einträgen bei MLT unter https://www.mltframework.org/plugins/ConsumerAvformat/

Ich habe die Empfehlungen der Render-Einstellungen aus den YouTube-Kommentaren genommen und mit dem MLT-Verzeichnis verglichen. Dabei fand ich dann folgenden Erklärungen der Parameter:

Code: Alles auswählen

f=
Format
description: Use "list" to see the list of formats.
type: string
readonly: no
required: no
default: mpeg

vcodec=
Video codec
description: Use "list" to see the list of video codecs.
type:
readonly: no
required: no
default: mpeg2video

acodec=
Audio codec
description: Use "list" to see the list of audio codecs.
type:
readonly: no
required: no
default: mp2

g=
set the group of picture (GOP) size
type: integer
readonly: no
required: no
default: 12

global_quality=
type: integer
readonly: no
required: no
default: 0

ab=
Audio bitrate
description: Normally this is an integer, but you can append a K suffix for convenience.
type: string
readonly: no
required: no
unit: bits/second

vq= ?????

r=
Frame rate
description: This is a ffmpeg-compatible equivalent to the MLT profile and frame rate parameters.
type: float
readonly: no
required: no
minimum: 5.0

preset=
Set the encoding preset (cf. x264 –fullhelp) (libx264)
type: string
readonly: no
required: no
default: ‘medium’

bf=
set maximum number of B-frames between non-B-frames
type: integer
readonly: no
required: no
minimum: -1
default: 0

progressive=
type: integer
readonly: no
required: no
minimum: 0
maximum: 1
widget: checkbox

crf=
Select the quality for constant quality mode (libx264)
type: float
readonly: no
required: no
minimum: -1
default: -1
Demnach bedeuten die im YouTube-Kommentar vorgeschlagenen Rendering-Einstellungen:

Code: Alles auswählen

f=mp4 vcodec=nvenc_h264 acodec=aac g=120 global_quality=21 ab=384k vq=21 r=60 preset=slow bf=2
Erstelle eine MP4-Datei in h264-Coierung unter Verwendung des Nvidia-GPU-Encoder und für Audio nehme dazu den AAC-Codec.
Wähle für GOP (Group of Pictures) 120 statt dem Standard von 12. – Was bewirkt das?
Wähle eine "Globale Qualität" von 21 statt dem Standard von 0. – Was bewirkt das?
Setze die Audio-Bitrate auf 384k. (und weil "ab=%audiobitrate+'k'" den Wert von der GUI übernimmt, geht auch das)
Den vq-Parameter gibt es bei MLT nicht in der Liste! Falls die Liste veraltet ist, könnte dieser Wert wegfallen.
r=60 ist die Vorgabe der Framerate. (lässt man diese Angabe weg, wird die Framerate des Ausgnagsmaterial genommen)
preset=slow = Langsamerer Render-Vorgang (lässt man die Angabe weg, greift der über die GUI definierte Wert)
bf=2 setzt die maximale Anzahl der B-frames zwischen nicht-B-frames - Standard ist 0 – Was bewirkt das?

Und im Kdenlive Render-Profil für MP4 ist noch crf=%quality enthalten. Minimum und Default-Wete sind 1. Ich hätte erwartet, dass der Prozentwert nun durch die Kdenlive-GUI einstellbar wird. Das ist aber nicht der Fall.

Ferner ist im Kdenlive Render-Profil für MP4 ist noch der Wert "progressive=1" enthalten. Wenn dies aktiv ist, läuft das Rendern schneller. Eigentlich bedeutet "progressive" doch nur das Gegenteil von Interlaced. Es sollte also eigentlich immer 1 sein, oder? Oder erhalte ich interlaced Ergebnisse, wenn ich es auf 1 setze?


Zur Vereinfachung habe ich jetzt einen TV-Mitschnitt als Probematerial. Spieldauer nach Schnitt 2:16 Minuten
Original-Material: 1280x720 @25fps - VideoBitrate 3591 kB/s - yuv420p - Audio 48000 Hz 189 kB/s AAC

Mein nach obigen Erkenntnissen abgespecktes Render-Profil:

Code: Alles auswählen

f=mp4 vcodec=nvenc_h264 progressive=1 global_quality=21 bf=2 acodec=aac ab=%audiobitrate+'k'
Audiobitrate war per GUI einstellbar. Ich setzte 192kB/s Codiergeschwindigkeit ist eine Stufe unter Maximum, Threads = 0

Das Rendern des TV-Mitschnitt benötigte 2:47 Minuten; das entstandenen Video hatte folgende Daten:
1280x720 @25fps - VideoBitrate 1724 kB/s - yuv420p - Audio 48000 Hz 192 kB/s AAC Dateigröße 31,3 MB Progressive

Rendern wie vor jedoch mit "progressive=0":
Das Rendern des TV-Mitschnitt benötigte 2:39 Minuten; das entstandenen Video hatte folgende Daten:
1280x720 @25fps - VideoBitrate 2037 kB/s - yuv420p - Audio 48000 Hz 192 kB/s AAC Dateigröße 36,4 MB Interlaced!

Rendern ohne Parameter von "progressive", jedoch mit "g=120" (GOP-Wert):
Das Rendern des TV-Mitschnitt benötigte 2:47 Minuten; das entstandenen Video hatte folgende Daten:
1280x720 @25fps - VideoBitrate 1833 kB/s - yuv420p - Audio 48000 Hz 192 kB/s AAC Dateigröße 33,1 MB Progressive

Rendern wie vor, jedoch mit "global_quality=32":
Das Rendern des TV-Mitschnitt benötigte 2:40 Minuten; das entstandenen Video hatte folgende Daten:
1280x720 @25fps - VideoBitrate 344 kB/s - yuv420p - Audio 48000 Hz 192 kB/s AAC Dateigröße 8,8 MB Progressive

Rendern wie vor, jedoch mit "global_quality=16":
Das Rendern des TV-Mitschnitt benötigte 2:49 Minuten; das entstandenen Video hatte folgende Daten:
1280x720 @25fps - VideoBitrate 4671 kB/s - yuv420p - Audio 48000 Hz 192 kB/s AAC Dateigröße 79,3 MB Progressive

Verblüffend ist hier also, dass das Rendern mit einer besseren Ergebnisqualität nur wenig Einfluss auf die Renderzeit hat!

Bei allen obigen Versuchen lag gemäß Angaben von Psensor die CPU-Last zwischen 65% und 70%. Die Temperatur und die Last der Grafikkarte blieb weitgehend gleich, egal ob gerendert wurde oder nicht. (graphics und video ca. 1% bis 4% schwankend)

Mit den nun gefundenen Rendersettings

Code: Alles auswählen

f=mp4 vcodec=nvenc_h264 g=120 global_quality=16 bf=2 acodec=aac ab=%audiobitrate+'k'
habe ich nun wieder das Rendern des großen 30-minütigen Video-Projekt gestartet. Zur Erinnerung:
Das von den Kameras stammend Material hat folgende Daten:
1920x1080 @50fps - VideoBitrate 24.248 kB/s - yuv420p – Audio 48000 Hz 1536 kB/s PCM signed 16-bit

Kurz nach dem Start des Rendern zeigte Kdenlive vorläufig 2:05:24 an, um dann auf 2:34:32 zu erhöhen und nach ca. 5 Minuten wieder auf 1:56:58 herunter zu gehen. Die wirkliche Zeit wird wohl erst am Ende fest stehen.
Die CPU-Last schwankt nun zwischen 60% und 90%. Die Lastwerte für graphics und video der GPU schwanken zwischen 3% und 20% und die Grafikkarte erwärmt sich auf 44°C (von 37°C ausgehend).

Die endgültig reale Renderzeit teile ich in Kürze mit.

Resultat: Ich hab die Render-Parameter besser verstanden (aber noch nicht alle). Die Grafikkarte arbeitet offensichtlich, bringt aber weiterhin bei Weitem nicht die von mir erhofften Verbesserungen (schnelles Rendern).

Ich werde die Diskussion nicht schließen, weil ich weiterhin dazu einlade, Anregungen zur Verbesserung der Render-Geschwindigkeit einzubringen!

Antworten