Wahrscheinlich ist DaVinci Resolve + BRAW so konzipiert, unabhängig von der "Hardware Configuration"->GPU Processing , den GPU/Grafikbeschleuniger sowieso zu nutzen (also egal was der Nutzer unter GPU processing auswählt, läuft im Hintergrund für BRAW immer die Hardwaregrafikbeschleunigung).dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 13:04 Inwieweit hängt denn die Verarbeitung von BRAW vom Grafikkartentreiber ab?
Wahrscheinlich ist das nicht so, aber egal.roki100 hat geschrieben: ↑So 01 Dez, 2019 14:10Wahrscheinlich ist DaVinci Resolve + BRAW so konzipiert, unabhängig von der "Hardware Configuration"->GPU Processing , den GPU/Grafikbeschleuniger sowieso zu nutzen (also egal was der Nutzer unter GPU processing auswählt, läuft im Hintergrund für BRAW immer die Hardwaregrafikbeschleunigung).dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 13:04 Inwieweit hängt denn die Verarbeitung von BRAW vom Grafikkartentreiber ab?
BRAW muss ja schneller als alles andere da stehen. Das hat scheinbar eine höhere Priorität, auch dann, wenn das gesamte Programm instabil wird oder komplett abstürzt.
@mash_gh4
Linux User, der DaVinci aus der (bash) Konsole startet, sieht (im Fall eines Absturzes) öfter die Fehlermeldung. ;) So wie es also aussieht, gibt es schon eingebaute Fehlermeldung...nur nicht für die GUI.
Wenn in den Resolve- Preferences die Option "" aktiviert ist: dann wird eben die GPU für die BRAW- Verarbeitung genutzt. Diese Option kann man abwählen, dann funktioniert Resolve auch problemlos mit dem aktuellen V441.28 Treiber. Allerdings ist dann der Workflow an einigen anderen Stellen deutlich zäher. Den Unterschied spürt man vor allem, wenn man eine schnelle GraKa hat (2080Ti).dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 13:04 Inwieweit hängt denn die Verarbeitung von BRAW vom Grafikkartentreiber ab?
Gute Idee, darauf bin ich noch garnicht gekommen. Könnte man mal ausprobieren - aber das mache ich erst, wenn der nächste neue Studiotreiber auch nicht funktionieren sollte. Vielleicht hat jemand hier noch das Problem und kann das mal testen...dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 14:37Ein Test mit OpenCL hätte vielleicht schon Abhilfe geschaffen.
das ist mal wieder ein typischer Roki - nichts verstanden, aber Verschwörungstheorien ausbrüten...roki100 hat geschrieben: ↑So 01 Dez, 2019 14:10 Wahrscheinlich ist DaVinci Resolve + BRAW so konzipiert, unabhängig von der "Hardware Configuration"->GPU Processing , den GPU/Grafikbeschleuniger sowieso zu nutzen (also egal was der Nutzer unter GPU processing auswählt, läuft im Hintergrund für BRAW immer die Hardwaregrafikbeschleunigung).
BRAW muss ja schneller als alles andere da stehen. Das hat scheinbar eine höhere Priorität, auch dann, wenn das gesamte Programm instabil wird oder komplett abstürzt.
Quatsch. Ich versuche es eben zu verstehen. Hast Du eine andere Erklärung? Wieso gibt es einen extra (aktivieren/deaktivieren) Schalter - "use GPU..." BRAW?
Ja. Im Zusammenspiel zwischen dem neuesten NVIDIA- Treiber und Resolve gibt es ein Problem beim Decoden von BRAW. Kann man auch bei NVIDIA nachlesen. Wenn man das Decodieren per GPU deaktiviert, sind diese Probleme verschwunden (dafür wird's langsamer).roki100 hat geschrieben: ...Hast Du eine bessere Erklärung?
Dann hast Du etwas missverstanden, obwohl deine Erklärung sich von meine kaum unterscheidet (ich habe es fettmarkiert). Ich schreibe nichts anderes: Wahrscheinlich ist DaVinci Resolve + BRAW so konzipiert, unabhängig von der "Hardware Configuration"->GPU Processing , den GPU/Grafikbeschleuniger sowieso zu nutzen (also egal was der Nutzer unter GPU processing auswählt, läuft im Hintergrund für BRAW immer die Hardwaregrafikbeschleunigung).AndySeeon hat geschrieben: ↑So 01 Dez, 2019 15:27Ja. Im Zusammenspiel zwischen dem neuesten NVIDIA- Treiber und Resolve gibt es ein Problem beim Decoden von BRAW. Kann man auch bei NVIDIA nachlesen. Wenn man das Decodieren per GPU deaktiviert, sind diese Probleme verschwunden (dafür wird's langsamer).roki100 hat geschrieben: ...Hast Du eine bessere Erklärung?
Ich denke (ohne es genau zu wissen), dass die Ursache nicht allein bei NVIDIA liegt, sondern auch bei Resolve bzw. dem BRAW- Decoder von BM, denn der spricht den Treiber von NVIDIA an und irgendetwas in dieser Kommunikation geht schief, so dass Resolve einfriert. Dieser Fehler (das Einfrieren) muss eindeutig von Resolve abgefangen und behandelt werden und das ist derzeit nicht der Fall.
Nur Du behauptest, dass BM absichtlich trotz abgeschalteter GPU- Beschleunigung die GPU nutzt um besser dazustehen und weil das nicht stimmt ist das eine Verschwörungstheorie - sieh es ein! xp
Ich sehe immer noch nicht wo der Quatsch ist?dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 16:13 Bevor es richtiger Quatsch wird:
*Blackmagic RAW is also GPU accelerated and works with Apple Metal, CUDA and OpenCL.*
Prinzipiell wird bei Nvidia Hardware Cuda genutzt, wenn man OpenCL will, dann muss man das explizit auswählen, wenn es denn überhaupt in der entsprechenden Anwendung einen Weg dafür gibt. Zusätzlich muss man sich darüber klar sein, dass OpenCL von Nvidia nicht so unterstützt wird wie Cuda, man also auch mit Leistungseinbußen rechnen muss.roki100 hat geschrieben: ↑So 01 Dez, 2019 16:29Ich sehe immer noch nicht wo der Quatsch ist?dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 16:13 Bevor es richtiger Quatsch wird:
*Blackmagic RAW is also GPU accelerated and works with Apple Metal, CUDA and OpenCL.*
Das ist klar. Was ich aber angesprochen habe ist, dass BRAW eigene Leitung/Port hat, für das aktivieren und deaktivieren von GPU Hardwarebeschleuniger. Dieser funktioniert unabhängig davon, was unter "Hardware Configuration"->GPU processing mode ausgewählt ist. Das hat BMD u.a. deswegen gemacht, damit Drittentwickler, die sich mit BRAW SDK bedienen, BRAW mit GPU Hardwarebeschleuniger auch für andere NLE's zur Verfügung zu stellen (möglich ist also CUDA, Metal, OpenCL). Die Idee ist gut, doch dass es damit Probleme gibt, beweist sogar der Erfinder selbst und zwar mit der eigene NLE Software (DaVinci)... Denn, es ist von GPU Library Version abhängig, womit BRAW (SDK) compiliert ist. Und das funktioniert leider nicht immer gut. BMD selbst und auch die, die sich mit BRAW SDK bedienen, müssen bei eine Änderung (seitens GPU Hersteller) immer hinterherlaufen. Betroffen sind am ende die Nutzer, die sich darüber beklagen, dass die BRAW+GPU Wiedergabe das Programm zum Absturz bringt, dass das BRAW Plugin für Adobe nicht funktioniert... das Rosa streifen... oder schwarze Bild ..oder andere Artefakte beim BRAW abspielen zum Vorschein kommen usw. usf. ALL das hat damit zu tun, was ich versuche zu erklären. Apple hat das einfach gelöst, indem sie ein Treiber verwenden der bei MacOS standardmäßig dabei ist. Die Entwickler (außer Adobe ;) ) wissen und nutzen die eine GPU Library für eigene MacOS-Programme...dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 16:38Prinzipiell wird bei Nvidia Hardware Cuda genutzt, wenn man OpenCL will, dann muss man das explizit auswählen, wenn es denn überhaupt in der entsprechenden Anwendung einen Weg dafür gibt. Zusätzlich muss man sich darüber klar sein, dass OpenCL von Nvidia nicht so unterstützt wird wie Cuda, man also auch mit Leistungseinbußen rechnen muss.
ich verwende zwar resolve in genau dieser weise, aber auch hier schaut es leider icht wesentlich anders aus. du brauchst dir nur die unzähligen beispiele solcher ausgaben im resolve forum ansehen, um zu erkennen, wie wenig information über die tatsächlichen absturzursachen diesen logs zu entnehmen ist. nur in den allerseltensten fällen lässt sich daraus auf umwegen irgendwas sinnvolles od. gar eindeutiges ableiten. am ehesten noch aus den backtraces bzw. core dumps bei richtig gravierenden abstürzen. aber auch diese information kann man als endanwender ohne zugriff auf den zugrundeliegenden code im regelfall nicht wirklich sinnvoll nutzen od. nachvollziehen.
dann beschreib doch mal du oder vielleicht auch mash-gh4, aus eurer programmierersicht, wie zutreffend solche ausgaben von fehlermeldungen von programmen sind bzw sein könnten, kostet das nicht auch rechenleistung damit ein prozess dan anderen zuverlässig überwacht? ich würde mir das gerne näher vorstellen können.roki100 hat geschrieben: ↑So 01 Dez, 2019 19:34 ja da hast Du recht. Ich hatte letztens so ein Fehler und als ich Resolve aus der Konsole gestartet habe, wusste ich genau, es liegt an falsch verlinkte lib Datei (ln -s ... war dann die Lösung).
Ich finde sowieso, wenn ein Softwareentwickler auf Ausgabe von Fehlermeldungen verzichtet, ist m.M. kein guter Entwickler.
Lade folgende Bibliothek -> Bibliothek gefunden J/N -> Bibliothek nicht gefunden -> weiter ohne (oder Absturz)srone hat geschrieben: ↑So 01 Dez, 2019 20:01dann beschreib doch mal du oder vielleicht auch mash-gh4, aus eurer programmierersicht, wie zutreffend solche ausgaben von fehlermeldungen von programmen sind bzw sein könnten, kostet das nicht auch rechenleistung damit ein prozess dan anderen zuverlässig überwacht? ich würde mir das gerne näher vorstellen können.roki100 hat geschrieben: ↑So 01 Dez, 2019 19:34 ja da hast Du recht. Ich hatte letztens so ein Fehler und als ich Resolve aus der Konsole gestartet habe, wusste ich genau, es liegt an falsch verlinkte lib Datei (ln -s ... war dann die Lösung).
Ich finde sowieso, wenn ein Softwareentwickler auf Ausgabe von Fehlermeldungen verzichtet, ist m.M. kein guter Entwickler.
lg
srone
in meinem verständnis einen prozess oder handle der das j/n interpretiert und die fehlermeldung ausgibt, deswegen meine frage.dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 20:08Lade folgende Bibliothek -> Bibliothek gefunden J/N -> Bibliothek nicht gefunden -> weiter ohne (oder Absturz)srone hat geschrieben: ↑So 01 Dez, 2019 20:01
dann beschreib doch mal du oder vielleicht auch mash-gh4, aus eurer programmierersicht, wie zutreffend solche ausgaben von fehlermeldungen von programmen sind bzw sein könnten, kostet das nicht auch rechenleistung damit ein prozess dan anderen zuverlässig überwacht? ich würde mir das gerne näher vorstellen können.
lg
srone
Dafür braucht es keinen eigenen Prozess.
Ob eine Bibliothek geladen wurde oder nicht sollte ein Programm sowieso wissen, sonst wird's wild.srone hat geschrieben: ↑So 01 Dez, 2019 20:13in meinem verständnis einen prozess oder handle der das j/n interpretiert und die fehlermeldung ausgibt, deswegen meine frage.dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 20:08
Lade folgende Bibliothek -> Bibliothek gefunden J/N -> Bibliothek nicht gefunden -> weiter ohne (oder Absturz)
Dafür braucht es keinen eigenen Prozess.
lg
srone
genau und auch dafür wird es wohl eine routine geben,welches selbiges erfasst, es nützt nix wenn wir da oberflächlich bleiben.dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 20:19Ob eine Bibliothek geladen wurde oder nicht sollte ein Programm sowieso wissen, sonst wird's wild.
Eine Fehlermeldung ist eine Textausgabe, mehr nicht.srone hat geschrieben: ↑So 01 Dez, 2019 20:26genau und auch dafür wird es wohl eine routine geben,welches selbiges erfasst, es nützt nix wenn wir da oberflächlich bleiben.dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 20:19
Ob eine Bibliothek geladen wurde oder nicht sollte ein Programm sowieso wissen, sonst wird's wild.
lg
srone
Es ist einfache Methode für die Entwickler um Fehler zu analysieren...Überwachungsprozess muss der Entwickler selbst einbauen, wie bereits erwähnt, handelt es sich dabei öfter um ein elseif (also wenn if x/y nicht zutrifft, dann else und wenn das auch nicht zutrifft, dann elseif...) und sowie es aussieht, fehlt einige elseif Zeilen bzw. falschwerte abgreifen, auswerten, (fehler) ausgeben und/oder weitere Prozesse starten - wie Beispiel: wenn das verdammte "use GPU BRAW" Probleme macht, dann markiere es grau und informiere den AndySeeon dass er "use GPU BRAW" nicht aktivieren/deaktivieren kann, weil es Probleme bei #include nvidia.so gibt und funktioniere trotzdem weiter... ;)
danke roki, für deine erläuterung, so wild brauch ichs nicht, ich wollte eigentlich nicht finale programme analysieren, sondern nur verstehen wie so eine fehleranalyse programmtechnisch ausschaut.roki100 hat geschrieben: ↑So 01 Dez, 2019 20:50Es ist einfache Methode für die Entwickler um Fehler zu analysieren...Überwachungsprozess muss der Entwickler selbst einbauen, wie bereits erwähnt, handelt es sich dabei öfter um ein elseif (also wenn if x/y nicht zutrifft, dann else und wenn das auch nicht zutrifft, dann elseif...) und sowie es aussieht, fehlt einige elseif Zeilen bzw. falschwerte abgreifen, auswerten, (fehler) ausgeben und/oder weitere Prozesse starten - wie Beispiel: wenn das verdammte "use GPU BRAW" Probleme macht, dann markiere es grau und informiere den AndySeeon dass er "use GPU BRAW" nicht aktivieren/deaktivieren kann, weil es Probleme bei #include nvidia.so gibt und funktioniere trotzdem weiter... ;)
BMD macht aber, wenn das verdammte "use GPU BRAW" Probleme macht, NIX = Absturz. ;)
Es gibt auch Debugger, die ein kompiliertes (C++) Programm auf Fehler Analysieren, siehe gdb: https://www.uni-muenster.de/AMM/num/Vor ... bugger.pdf
Programmtechnisch wird man natürlich erstmal das protokollieren, was man sowieso abfragt. Debugging geht tiefer und hilft beim Suchen nach Fehlern im Programm.srone hat geschrieben: ↑So 01 Dez, 2019 21:09danke roki, für deine erläuterung, so wild brauch ichs nicht, ich wollte eigentlich nicht finale programme analysieren, sondern nur verstehen wie so eine fehleranalyse programmtechnisch ausschaut.roki100 hat geschrieben: ↑So 01 Dez, 2019 20:50
Es ist einfache Methode für die Entwickler um Fehler zu analysieren...Überwachungsprozess muss der Entwickler selbst einbauen, wie bereits erwähnt, handelt es sich dabei öfter um ein elseif (also wenn if x/y nicht zutrifft, dann else und wenn das auch nicht zutrifft, dann elseif...) und sowie es aussieht, fehlt einige elseif Zeilen bzw. falschwerte abgreifen, auswerten, (fehler) ausgeben und/oder weitere Prozesse starten - wie Beispiel: wenn das verdammte "use GPU BRAW" Probleme macht, dann markiere es grau und informiere den AndySeeon dass er "use GPU BRAW" nicht aktivieren/deaktivieren kann, weil es Probleme bei #include nvidia.so gibt und funktioniere trotzdem weiter... ;)
BMD macht aber, wenn das verdammte "use GPU BRAW" Probleme macht, NIX = Absturz. ;)
Es gibt auch Debugger, die ein kompiliertes (C++) Programm auf Fehler Analysieren, siehe gdb: https://www.uni-muenster.de/AMM/num/Vor ... bugger.pdf
lg
srone
ja, verstanden, aber wie läuft das genau ab? wieviel systemzeit verbraucht der debugger?dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 21:24Programmtechnisch wird man natürlich erstmal das protokollieren, was man sowieso abfragt. Debugging geht tiefer und hilft beim Suchen nach Fehlern im Programm.
Debugger sind, wie der Name sagt, Werkzeuge um Bugs zu finden. Wenn z.B. Resolve ausgeführt wird, läuft kein Debugger.srone hat geschrieben: ↑So 01 Dez, 2019 21:28ja, verstanden, aber wie läuft das genau ab? wieviel systemzeit verbraucht der debugger?dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 21:24
Programmtechnisch wird man natürlich erstmal das protokollieren, was man sowieso abfragt. Debugging geht tiefer und hilft beim Suchen nach Fehlern im Programm.
lg
srone
ach so, aber wer entscheidet dann über die finale fehlermeldung im laufenden betrieb und deren ressourcenverbrauch, darum gings mir....;-)dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 21:31Debugger sind, wie der Name sagt, Werkzeuge um Bugs zu finden. Wenn z.B. Resolve ausgeführt wird, läuft kein Debugger.
Das ist natürlich alles etwas komplexer, als hier besprochen werden kann, aber wie oben schon geschrieben, können Abfragen einfach protokolliert werden. Das kostet eher keine Ressourcen, z.B. Nvidia vorhanden, verwende Cuda. So eine Meldung hilft allerdings nicht, wenn im Treiber von Cuda ein Fehler auftritt. Nur die Programmierer der Anwendung können letztlich entscheiden, an welchen Punkten sie Meldungen generieren lassen, um im Fehlerfall Hilfestellungen zu haben.srone hat geschrieben: ↑So 01 Dez, 2019 21:33ach so, aber wer entscheidet dann über die finale fehlermeldung im laufenden betrieb, darum gings mir....;-)dienstag_01 hat geschrieben: ↑So 01 Dez, 2019 21:31
Debugger sind, wie der Name sagt, Werkzeuge um Bugs zu finden. Wenn z.B. Resolve ausgeführt wird, läuft kein Debugger.
lg
stone
Code ist ok, wenn er läuft.