Schwermetall hat geschrieben: ↑Mi 14 Mär, 2018 07:56
Ich habe als Test eine Sequenz mit ein wenig Bildkorrektur und dem Filmconvert Plugin gerendert und benötigte vorher wie nachher exakt 50s.
Für mich klingt das so, als ob nicht die CPU das Nadelöhr ist.
naja -- da kommen ein paar verschiedene sachen zusammen:
externe plugins von drittherstellern müssen sich normierter bzw. von resolve in leicht modifizierter form freigegebener schnittstellen bedienen, die einfach von grund auf techn. nachteile gegenüber einer optimierten internen verarbeitungskette aufweisen -- egal, ob es dabei um openfx-plugins od. eigentlich unnötig aufwendige 3d-lut umsetzungen geht. der i/o-aufwand bzw. das unnötige kopieren von speicherinhalten od. aber der rechenaufwand werden gleich einmal zum spürbaren problem.
leider ist diese problematik aber nicht ausschließlich nur auf externe zusätze eingeschränkt. auch das programm selbst kann natürlich manche sachen in einer etwas weniger idealen weise umsetzten. die meisten kollegen sind zwar der meinung, dass resolve diesebzüglich ohnehin realtiv vorbildlich wirkt, ich dagegen teile diese einschätzung nicht unbedingt. ich glaube, dass man im vergleich mit anderer ähnlicher high-end software ziemlich eindeutig zeigen kann, dass das leider so uneingeschränkt nicht stimmt. ich verstehe aber sehr gut, dass man zu dieser einschätzung gelangen kann. es hat einfach damit zu tun, dass die meisten mathematischen operationen, auf die man sich beim colorgraden stützt, verhältnismäßig einfach bzw. effizient auf der GPU umgesetzt werden können. auch wenn das ganze nach außen hin sehr eindrucksvoll und kompliziert wirkt, bringt es in der berechnung meist viel weniger komplikationen mit sich als irgendwelche anderen unscheinbaren effekte, denen man gar nicht ansieht, wie viel praktische rechenlast sie bedingen.
diese geschichten sind halt von außen unheimlich schwer objektiv nachzuvollziehen od. gar zu optimieren, weil resolve bekanntlich eine völlig undurchsichtige black box bildet. die paar elementaren parameter, die du z.b. mit gpu-z angezeigt bekommst, sind jedenfalls völlig untauglich, um solchen problemene wirklich auf den grund zu gehen. dafür verendet man eher div. profiling und performance tracing techniken, wie man sie z.t. direkt im linux kernel, aber auch in speziellen werkzeugen der gpu-hersteller findet, um die beteiligten abläufe und engpässe zu entflechten und ggf. sinnvoll zu optimieren. als normaler endanwender macht das aber natürlich überhaupt keinen sinn. da bist wirklich weitgehend darauf angewiesen, dass die hersteller ihre hausaufgaben sauber gemacht haben -- was halt leider nicht immer in überzeugender weise der fall ist.