Peppermintpost hat geschrieben: ↑Mi 11 Apr, 2018 15:34
ne mash, da biste der Autodesk Werbung auf den Leim gegangen. Reactor ist eine Gaming Engine.
lieber peppermint! ich schätze deine sachkundikeit und erfahrung in sachen compositing bzw. deine diesbezüglichen einschätzungen hier im forum wirklich sehr, aber derartige untergriffigkeit scheint mir wirklich deutlich hinter dem angesprochenen erwartungen an dich zurückzubleiben.
ich glaube schon, dass ich hier über über technische details rede, die mich wirklich interessieren -- mehr als für die ganz praktische nutzung oft gut ist --, wo ich zumindest ansatzweise wirklich mitreden kann.
OpenGL ausschließlich nur als "gaming engine" zu verstehen, klingt für mich fast so dumm als würde man behaupten, GPUs könnnte man nicht zum rechnen benutzen, sondern ausschließlich nur zur ausgabe von grafiken am bildschirm.
das was du wohl eher damit ansprichst bzw. kritisierst, ist die nutzung von
GLSL (OpenGL Shading Language) fragment shaders. ja, darüber kann man in der tat diskutieren.
prinzipiell ist es zwar so, das GLSL, genauso wie CUDA, OpenCL, SPIR-V u.ä. von grafikkartenspezifischen treiber-bestandteilen in letztlich ganz ähnlich wirkenden kartenspezifischen maschinencode übersetzte werden, der dann tatsächlich dort ausgeführt wird. aber damit erfasst man natürlich nur einen recht allgemeinen groben blick auf das ganze. in der praxis machts schon einigen unterschied aus, welche möglichkeiten sich dadurch ergeben, den tatsächlich ablauf der verarbeitung zu optimieren.
GLSL ist hier gewissermaßen als älteste bzw. konservativste herangehensweise anzusehen, die zwar aus heutiger sicht einige ganz gravierende nachteile bzw. beschränkungen mit sich bringt, sich dafür aber in puncto kompatibilität und ausgereiftheit ausgesprochen positiv von anderen varianten unterscheidet. das ist auch der grund, warum selbst in verhältnismäßig naher vergangenheit projekte ganz bewusst diesen weg beschritten haben.
siehe dazu bspw. die erklärungen zu
movit:
"Movit has chosen to run all pixel processing on the GPU, using GLSL—OpenCL is
way too young, and CUDA is single-vendor (and also surprisingly hard to
get good performance from for anything nontrivial). While “run on the GPU”
does not equal “infinite speed” (I am fairly certain that for many common
filters, I can beat the Intel-based GPU in my laptop with multithreaded SSE
code on the CPU—especially as moving the data to and from the GPU has a cost that is not
to be taken lightly), GPU programming is probably the _simplest_ way of writing
highly parallel code, and it also frees the CPU to do other things like video
decoding."
auch die meisten OpenFX-plugins sind nicht wirklich in der lage wesentlich mehr zu nutzen, da, die dort bisher standardisierte OpenGL suite, nicht wesentlich mehr erlaubt, während CUDA- und OpenCL-unterstützung, aber auch eine verbesserte OpenGL suite 2.0, es noch immer nicht über das entwurfsstadium hinaus geschafft haben: :(
http://openeffects.org/standard_changes
für die praktische anwendung hat das deshalb derart fatale folgen, weil genau jene optimierungen, von denen oben die rede war, hier also maximal über fragwürdige umwege möglich sind (im falle von resolve, erzwingt man bspw., dass nicht standard-konforme propritäre OpenFX-erweiterungen in entsprechenden plugins genutzt werden müssen).
es gibt aber natürlich auch noch andere techn. gesichtspunkte, in denen sich GLSL fragment shader von den anderen ansätzen unterscheiden. dort wo es die "genauigkeit" betrifft, die ich aus deiner kritik herausgehört habe, hat das z.t. mit der etwas gewöhnungsbedürftigen handhabung von textures bzw. der interpolation zwischen pixeln zu tun, die natürlich in anderen ansätzen, die von vornherein mit tensoren bzw. mehrdimensionalen arrays von einer festgelegten größe arbeiten, anders gehandhabt wird. auch in puncto rechengenauigkeit und der spezifischen arbeits- und definitionsweise von fragment shadern, ergeben sich einschränkungen, die mit anderen mitteln tlw. besser gelöst werden können. trotzdem, dass alles ist noch lange kein grund, es als bloße "spielerei" abzutun.
ansätze, die das von grund auf konsequenter machen, und wirklich nur eine familie von grafikkarten möglichst optimal zu nutzen versuchen, bringen ja auch wieder andere ganz einschneidende nachteile mit sich. apple nutzer und AMD liebhaber zeigen sich ja [berechtigter maßen] regelmäßig wieder darüber entsetzt, wenn ihre hardware nicht in gleicher weise genutzt werden kann. aber um diese einschränkung kommt man in wahrheit fast nicht herum, wenn man es wirklich effizienter lösen will.
Peppermintpost hat geschrieben: ↑Mi 11 Apr, 2018 15:34
Flame hat immer und vom ersten Tag an OpenGL zum rendern benutzt. Das jetzt alle so viel wie möglich auf der GPU machen ist bei Flame ein super alter Hut. Das hatte auch die ganze Reihe - Flint, Flame, Inferno, Smoke, Fire, die alle konnten das. Was sich geändert hat ist lediglich das die OpenGL gegen Reactor getauscht haben, mehr nicht.
Reactor ist im Grunde OpenGL mit der Ansage "uns sind Farben und präzision egal solange es nur schneller rechnet"
der springende punkt an der ganzen sache ist gar nicht so sehr die tatsache, dass die entsprechenden berechnungen tatsächlich auf der grafikkarten mit ihren unglaublichen parallelisierungsmöglichkeiten ausgeführt werden, sondern dass die einzelnen arbeitsschritte auch tatsächlich dort in einer einheitlichen "engine" verkettet und abgearbeitet werden, so dass die daten nicht unnötig ständig hin und her gschoben werden müssen. dass ist der entscheidenden vorzug, der sich hinter dieser mittlerweile durchgängigen nutzung von "rector 2.0" beim flame für alle bildberechnungen bzw. der spezifischen arbeitsweise von mistika verbirgt.
das beste beispiel, um zu sehen, wie gravierend sich diese kluft zwischen der traditonellen herangehensweise und den angesprochenen beiden ausnahmelösungen manifestiert, bildet meiner ansicht nach nuke, wo dieser vereinheitlichung in der abarbeitung bis heute nicht vollzogen wurde, und desshalb weiterhin nur ein paar wenige echtzeit-effekte in der nuke studio timeline zur verfügung stehen, während der rest weiterhin in gänzlich anderer weise abgearbeitet wird -- genau so also, wie du das auch dem flame zuschreibst, obwohl es eben dort mittlerweile nicht mehr in dieser weise zutrifft.
ich denke, dass wir im resolve bzw. seiner fusion integration vorerst einmal auch nur eine genau solche hybride lösung vorfinden werden -- wobei ich mich hier natürlich irren könnte, weil es natürlich jeder heute gerne lieber in dieser anderen deutlich anspruchsvolleren weise lösen würde. vielleicht ist ihnen das ja auch tatsächlich gelungen? -- ich bezweifle es halt, weil ich einfach schon zu viel relativ unbefriedigendes bzw. oberflächliches zusammenmanschen von unterschiedlichen ansätzen und code im resolve in den letzten jahren beobachten konnte. das ist eben genau jener aspekt, wo ich diese anderen, weit weniger populären lösungen wirklich für wesentlich konsequenter und sauberer halte.
Peppermintpost hat geschrieben: ↑Mi 11 Apr, 2018 15:34
Mystica hat das aber auch schon immer schon seit dem es Jaleo heist, das ding ist ja (fast) genau so alt wie die Flame. Nur das die es halt nicht mit einer Gaming Engine machen sondern halt mit OpenGL oder was immer die heute benutzen, aber ich glaube OpenGL.
ich denke, dass zumindest mistika ultima ziemlich konsequent direkt und ausschließlich auf CUDA und dort zur verfügung stehende optimierungen setzt, wie sie auch tatsächlich nur in den professionellen nvidia karten zugänglich sind. GTX gamer karten sind ja bekanntlich diesbezüglich [ursprünglich nur treiberseitig, aber mittlerweile auch hardwarebedingt] ganz bewusst beschränkt. so toll sich das natürlich in puncto verarbeitungseffizienz im professionellen einsatz niederschlägt, so sehr grenzt das natürlich die größerer verbeitung bzw. nutzung auf erschwinglicherer hardware ein. resolve und das dortige gestolpere von einer "GPU out of memory"-meldung zur nächsten, ist zwar in meinen augen auch nicht unbedingt die wahre alternative, und in meinen augen weiterhin ziemlich ressourcenverschwenderisch, aber zumindest bemüht man sich nach kräften um relativ niederschwellige einstiegshürden und hardware-kompatibilität.