From 8db1813831321fb935cbb429f6a71d99a1c2b8f7 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Mon, 29 Jun 2026 21:31:13 +0200 Subject: [PATCH] Invocation: adapt job parameters to requirements MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is the result of an requirement analysis, based on the current (better) understanding of ''render job invocation'' * the `InvocationInstanceID` is @deprecated, because rather a data based hash is required * instead, two free parameters are introduced, with a meaning defined by the specific `JobFunctor` * notably the functor for rendering, the `RenderInvocation´ can use these for the exit node and an output context **Note**: the C-structs for the `job` are no longer considered an interface (and will be remoulded into an internal detail of the dispatcher) --- src/steam/engine/job-ticket.cpp | 8 - src/steam/engine/job-ticket.hpp | 4 +- src/vault/gear/job.cpp | 53 +- src/vault/gear/job.h | 44 +- tests/steam/engine/mock-dispatcher.cpp | 2 +- tests/steam/engine/mock-support-test.cpp | 4 +- wiki/thinkPad.ichthyo.mm | 715 ++++++++++++++++++++++- 7 files changed, 721 insertions(+), 109 deletions(-) diff --git a/src/steam/engine/job-ticket.cpp b/src/steam/engine/job-ticket.cpp index 0396aa513..c0b7925ef 100644 --- a/src/steam/engine/job-ticket.cpp +++ b/src/steam/engine/job-ticket.cpp @@ -117,14 +117,6 @@ namespace engine { } - namespace { ///////////////////////////////////////////////////////////////////////////////////////////TICKET #1287 : temporary workaround until we get rid of the C base structs - inline bool - operator== (InvocationInstanceID const& l, InvocationInstanceID const& r) - { - return lumiera_invokey_eq (unConst(&l), unConst(&r)); - } - } - /** * Helper for tests: verify the given invocation parameters match this JobTicket. */ diff --git a/src/steam/engine/job-ticket.hpp b/src/steam/engine/job-ticket.hpp index 63ca5c04d..6ba258eb5 100644 --- a/src/steam/engine/job-ticket.hpp +++ b/src/steam/engine/job-ticket.hpp @@ -138,8 +138,8 @@ using lib::LUID; { if (empty()) return false; - InvocationInstanceID empty; /////////////////////////////////////////////////////////////////////TICKET #1287 : temporary workaround until we get rid of the C base structs - return not lumiera_invokey_eq (&util::unConst(provision_).invocationSeed, &empty) + InvocationInstanceID empty; //////////////////////////////////////////////////////////TICKET #1287 : temporary workaround until we get rid of the C base structs + return provision_.invocationSeed != empty and provision_.exitNode.isValid() and util::and_all (provision_.prerequisites ,[](auto& pq){ return pq.prereqTicket.isValid(); }); diff --git a/src/vault/gear/job.cpp b/src/vault/gear/job.cpp index 4d2b3e85c..3399ed4c7 100644 --- a/src/vault/gear/job.cpp +++ b/src/vault/gear/job.cpp @@ -32,6 +32,19 @@ #include +/** @deprecated 6/2026 very likely the InvocationInstanceID will be obsoleted, + * and instead just the two parameter values need to be compared. + * As an interim solution, comparing the two 64bit data words + */ +bool +operator== (InvocationInstanceID const& l, InvocationInstanceID const& r) +{ + return l.code.w1 == r.code.w1 + and l.code.w2 == r.code.w2; +} + + + namespace vault{ namespace gear { @@ -115,44 +128,4 @@ namespace gear { return hash; } - }} // namespace vault::gear - -namespace { - using vault::gear::Job; - - inline Job& - forwardInvocation (lumiera_jobDefinition& jobDef) - { - Job& job = static_cast (jobDef); - return job; - } -} - - - -extern "C" { /* ==== implementation C interface for job invocation ======= */ - -void -lumiera_job_invoke (LumieraJobDefinition jobDef) -{ - REQUIRE (jobDef); - forwardInvocation(*jobDef).triggerJob(); -} - -size_t -lumiera_job_get_hash (LumieraJobDefinition jobDef) -{ - REQUIRE (jobDef); - return hash_value (forwardInvocation (*jobDef)); -} - -/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1287 : temporary workaround until we get rid of the C base structs -#include "lib/luid.h" - -int -lumiera_invokey_eq (void* l, void* r) -{ - return lumiera_uid_eq ((LumieraUid)l, (LumieraUid)r); -} -}/* extern "C" */ diff --git a/src/vault/gear/job.h b/src/vault/gear/job.h index ca3785c50..6153e275d 100644 --- a/src/vault/gear/job.h +++ b/src/vault/gear/job.h @@ -32,6 +32,13 @@ ** the job over to the scheduler. ** ** @warning as of 4/2023 the Job datastructure will be remoulded ///////////////////////////////////////////TICKET #1280 + ** @deprecated in 2026 it does not seem like a good idea anymore to use "Render Jobs" + ** to act like an _interface_ between Steam and Vault layer. Meanwhile, while + ** the concept of **Jobs** (coroutines) is still upheld, the C datastructure job, + ** as defined in this header, seems to mix up the traits of an interface and + ** aspects of implementation. It is largely superseded by the _Activity Language_ + ** of the scheduler, and will likely be remoulded into a technical artifact of + ** preparing job definitions in the Dispatcher. ** ** @see SchedulerFrontend ** @see JobTicket @@ -100,6 +107,11 @@ typedef struct lumiera_jobClosure* LumieraJobClosure; * hash key for each invocation, which can be used for caching; obviously * this hash need to be built from the JobTicket, based on ProcNode structure * and the nominal Time. ///////////////////////////////////TICKET #1293 + * @deprecated 6/2026 now able to conduct a full analysis of required information, + * and it seems the job definition does not need any kind of identity marker; + * caching will rely on chained specification hash keys rather. + * The existing tests will have to switch over using the two free parameter + * values, now present in each LumieraJobParameter... */ union InvocationInstanceID { @@ -128,8 +140,9 @@ struct lumiera_jobParameter_struct raw_time_64 nominalTime; /////////////////////////////////////////////////////////////////////////TICKET #1295 job invocation parameter: framework to interpret this time InvocationInstanceID invoKey; //////////////////////////////////////////////////////////////TODO: place an additional parameter value here, or make the instanceID globally unique? - ////////////////////////////////////////////////////////////////////////////////////TICKET #1293 job invocation identity - ////////////////////////////////////////////////////////////////////////////////////TICKET #1295 : rework Job parameters to accommodate input / output info required for rendering + ////////////////////////////////////////////////////////////////////////////////////TICKET #1293 job invocation identity (possibly not needed anymore, can be derived from the data...) + size_t srcParam; + size_t sinkParam; }; typedef struct lumiera_jobParameter_struct lumiera_jobParameter; typedef lumiera_jobParameter* LumieraJobParameter; @@ -194,6 +207,9 @@ typedef lumiera_jobDescriptor* LumieraJobDescriptor; #include +/** @warning performs a comparison on the entire packed content */ +bool operator== (InvocationInstanceID const&, InvocationInstanceID const&); + namespace vault{ namespace gear { @@ -284,6 +300,8 @@ namespace gear { this->jobClosure = &specificJobDefinition; this->parameter.nominalTime = _raw(nominalFrameTime); this->parameter.invoKey = invoKey; + this->parameter.srcParam = 0; + this->parameter.sinkParam = 0; } // using standard copy operations @@ -326,28 +344,6 @@ namespace gear { - - }} // namespace vault::gear - - - - -extern "C" { -#endif /* =========================== C Interface ===================== */ - - -/** trigger execution of a specific job, - * assuming availability of all prerequisites */ -void lumiera_job_invoke (LumieraJobDefinition); - -/** calculate a hash value based on the Job's \em identity. */ -size_t lumiera_job_get_hash (LumieraJobDefinition); - -int lumiera_invokey_eq (void* l, void* r); - - -#ifdef __cplusplus -} #endif #endif /*VAULT_GEAR_JOB_H*/ diff --git a/tests/steam/engine/mock-dispatcher.cpp b/tests/steam/engine/mock-dispatcher.cpp index ccb9ab055..1617ff2c2 100644 --- a/tests/steam/engine/mock-dispatcher.cpp +++ b/tests/steam/engine/mock-dispatcher.cpp @@ -250,7 +250,7 @@ namespace test { { InvocationInstanceID empty; ///////////////////////////////////////////////////////////////////////TICKET #1287 : temporary workaround until we get rid of the C base structs JobClosure& jobFunctor = static_cast (*job.jobClosure); //////////////////////////TICKET #1287 : fix actual interface down to JobFunctor (after removing C structs) - return lumiera_invokey_eq (&util::unConst(job).parameter.invoKey, &empty) + return job.parameter.invoKey == empty and util::isSameObject (jobFunctor, nopFunctor()); } diff --git a/tests/steam/engine/mock-support-test.cpp b/tests/steam/engine/mock-support-test.cpp index 215934f20..839e8ae9d 100644 --- a/tests/steam/engine/mock-support-test.cpp +++ b/tests/steam/engine/mock-support-test.cpp @@ -127,7 +127,7 @@ namespace test { CHECK (INSTANCEOF (vault::gear::NopJobFunctor, static_cast (nopJob.jobClosure))); //////////TICKET #1287 : fix actual interface down to JobFunctor (after removing C structs) CHECK (nopJob.parameter.nominalTime == frameTime); InvocationInstanceID empty; ///////////////////////////////////////////////////////////////////////TICKET #1287 : temporary workaround until we get rid of the C base structs - CHECK (lumiera_invokey_eq (&nopJob.parameter.invoKey, &empty)); + CHECK (nopJob.parameter.invoKey == empty); CHECK (MockJob::isNopJob(nopJob)); // this diagnostic helper checks the same conditions as done here explicitly MockJobTicket mockTicket; @@ -211,7 +211,7 @@ namespace test { // create another job from the (empty) seg1 job = seg1.jobTicket(0).createJobFor (someTime); InvocationInstanceID empty; /////////////////////////////////////////////////////////////////////TICKET #1287 : temporary workaround until we get rid of the C base structs - CHECK (lumiera_invokey_eq (&job.parameter.invoKey, &empty)); // indicates that it's just a placeholder to mark a "NOP"-Job + CHECK (job.parameter.invoKey == empty); // indicates that it's just a placeholder to mark a "NOP"-Job CHECK (seg1.jobTicket(0).empty()); CHECK (seg1.empty()); CHECK (not seg2.empty()); diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 9a59b5dea..eb5a36bfb 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -82549,13 +82549,147 @@ - + + + + + + + + + + +
+
+

+ +

+

+ /** @internal extension point +

+

+ * Create the environment for rendering a connected and related set of output streams. +

+

+ * Configure and prepare all the internal components, pre-allocate resources and add +

+

+ * entries to the registration tables necessary to get the related render activities +

+

+ * into "running" state. The created setup will typically be used to generate all +

+

+ * the individual channel streams linked together for playback or rendering; +

+

+ * they all share the same media type and quality settings. +

+

+ * @return an abstracted representation of the specific setup for this render; +

+

+ * from this point on, this RenderEnvironment closure will be the only way +

+

+ * for client code to talk to "the engine". The actual instance of this +

+

+ * closure is just a handle and can be copied; any CalcStream created +

+

+ * off this closure will be linked to the same "environment" and be +

+

+ * tracked and managed for resource usage automatically. +

+

+ * @note variations and especially mock implementations of the render engine +

+

+ * might choose to configure internals differently. As long as the +

+

+ * CalcStream and the embedded RenderEnvironment are consistent, +

+

+ * such a specific configuration remains opaque for the user of +

+

+ * the created render activity +

+

+ */ +

+

+ RenderEnvironment& +

+

+ EngineService::configureCalculation (ModelPort  mPort, +

+

+ Timings nominalTimings, +

+

+ Quality serviceQuality) +

+

+ { +

+

+ UNIMPLEMENTED ("Access and wire to the Scheduler-frontend. " +

+

+ "Then access the Segmentation and invoke a builder function for a suitable dispatcher table. " +

+

+ "Package all of this into a suitable RenderEnvironementClosure subclass."); +

+

+ RenderEnvironment* todo_fake(0);  ////KABOOOM +

+

+ +

+

+ return *todo_fake;  +

+

+ } +

+

+ +

+
+
+ + + + + + + + + + + + + + + + + + + + + + @@ -89095,8 +89229,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + @@ -89835,6 +89969,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + @@ -89857,6 +89994,40 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Damit vollziehe ich lediglich eine Einsicht, die mir, auf allgemeinerer Ebene, schon seit langem vorschwebt: wenn ein Interface so unglaublich plausibel erscheint, daß man es in zwei Sätzen aussprechen kann, dann stimmt was nicht. Es geht mehr um Grenz- und Überganbsbereiche in der Architektur, in denen, auf verschiedenen Ebenen, einzelne Verknüpfungen hergestellt werden. Die Wichtigste in Lumiera ist das high-Level-Model (dessen Bedeutung ich durch die Diskussion mit Wouter auszuformulieren versuche). Eine weitere solche Grenzzone hat sich in den letzten Jahren aufgetan: der »Plugin-Adapter« bzw. die »Domain-Onology« +

+ + + + + @@ -89868,6 +90039,40 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + + + +

+ möglicherweise wird das die eigentliche Job-Repräsentation +

+ + + + + +

+ ...insofern sich mit fortschreitendem Design zunehmend »der Render-Job« als Interface auflöst und irrelevant wird. Aktuell (6/26) habe ich noch die alten C-Structs von Christian an zentraler Stelle, aber die könnte ich möglicherweise komplett verwerfen, da sie nicht mehr notwendig sind; benötigt wird nur noch eine Interface/Parameter-Repräsentation für die Job-Planning-Pipeline, aus der dann der Activity-Term generiert wird — und dem entsprechend am unteren Ende dann eine Definition für den JobFunctor, der diese Parameter vom Scheduler bekommt +

+ + + + + + + + + + + + + + + + + @@ -90736,7 +90941,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + @@ -90965,7 +91171,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + @@ -91046,7 +91252,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + @@ -91055,7 +91261,25 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 - + + + + + + +

+ Vorsicht: es gibt weitere halb-redundante Strukturen hier +

+ + + + + + + + + + @@ -91116,8 +91340,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + @@ -91126,7 +91350,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + @@ -91146,12 +91370,12 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- +

- CalcStream ≡ eine aktiv laufende Folge von Berechnungen für einen  Ausgabekanal + CalcStream ≡ eine aktiv laufende Folge von Berechnungen für einen Ausgabekanal/Strom

@@ -91167,7 +91391,16 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + + + +

+ Diese Sequenz ist ein atomarer Strom an der Ausgabeschnittstelle und besteht nur noch aus Daten-Frames für jeden Zeit-Schritt. Das ist ein Kriterium auf der explizit-technischen Implementierungs-Ebene. Unabhängig davon können die Daten in jedem Frame noch mehrere logische Kanäle als Multiplex enthalten, aber nur unter der Bedingung daß der Frame als Ganzes ohne weiteres de-Multiplexing an die unterliegende Ausgabe-Technologie weiterzugeben ist. +

+ + + @@ -91325,8 +91558,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + @@ -97305,9 +97539,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

- + @@ -98903,7 +99137,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + @@ -98912,7 +99146,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 - + @@ -117003,18 +117237,18 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + - +

- ...eine kurze Analyse zeigt sofort auf, daß hier so einige Informationen Redundant sind; das hat mich schon mehrfach in Verwirrung gebraucht — aber die Verwirrung besteht wohl ehr in einer Vermischung der Ebenen: lange Zeit (viel zu lange) habe ich den Job als eine Art »Interface« betrachtet (genauer gesagt, ich bin hier naiv Christian's "Analyse" aufgesessen). Das war keine gute Idee, weil damit die Parameter des Jobs eine universelle Gültigkeit beanspruchen, und »richtig« gewählt sein wollen. Tatsächlich ist aber der Job ein Artefakt der Implementierung, und bestimmt sich vornehmlich aus Überlegungen zur Performance; allein daran wäre zu bemessen, ob in diesem Fall Redundanz gut oder schlecht ist. Dem entsprechend sollte die Render-Invocation (die nächste Ebene darunter) wieder alle logisch benötigten Parameter explizit ausweisen. + ...eine kurze Analyse zeigt sofort auf, daß hier so einige Informationen redundant sind; das hat mich schon mehrfach in Verwirrung gebraucht — aber die Verwirrung besteht wohl ehr in einer Vermischung der Ebenen: lange Zeit (viel zu lange) habe ich den Job als so eine Art von »Interface« betrachtet (genauer gesagt, ich habe Christian's "Analyse" als gegeben betrachtet und das Thema einfach verschoben). Das war keine gute Idee, weil damit die Parameter des Jobs eine universelle Gültigkeit beanspruchen, und »richtig« gewählt sein wollen. Tatsächlich ist aber der Job ein Artefakt der Implementierung, und bestimmt sich vornehmlich aus Überlegungen zur Performance; allein daran wäre zu bemessen, ob in diesem Fall Redundanz gut oder schlecht ist. Dem entsprechend sollte die Render-Invocation (die nächste Ebene darunter) wieder alle logisch benötigten Parameter explizit ausweisen.

@@ -117069,7 +117303,14 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + + + + + + + + @@ -117077,28 +117318,433 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + - + + + + + + + + + +

+ Viel lieber würde ich jetzt nur das Thema »Invocation« halbwebs sauber abschließen, und mich dann zunächst um meinen FrOSCon-Vortrag kümmern (Thema io_uring). Danach könnte ich versuchen, von der anderen Seite her, also der Job-Planung nach unten zu bohren. Ehrlich gesagt, ich weiß, daß letzteres auch nur halbfertig ist; das Aufräumen der Planungs-Pipeline war nur das: ein Aufräumen. Letztlich ist das Design des Players noch auf dem Stand von 2014 steckengeblieben. Allerdings hatte ich für die überarbeitete Planungs-Pipeline ein komplettes Mock-System hochgezogen. Das könnte vielleicht schon tragfähig sein — oder aber ein komplettes Desaster. Deshalb habe ich jetzt Angst, von der (fertigen, aber noch in der Luft hängenden) Render-Node-Invocation blindlings nach oben zu springen. Angst deshalb, weil sich meine „gelungene Integration“ wieder einmal als Luftschloß herausstellen könnte. Leider ist bisher noch gar nix in Lumiera einfach fertig geworden — ohne daß das Ergebnis sofort wieder relativiert ist und auf ein ungelöstes Problem rekuriert. +

+ + + + + + + +

+ Also beschließe ich: das ist eine »Probe-Intgration« +

+ + + + + +

+ Das Ergebnis soll nicht jenseits dieses Systems der Unit-Tests nutzbar sein, aber aufzeigen, wo die bisher gebauten Strukturen nicht zusammenpassen. Induktiv, bottom-up ist für ein solches Unterfangen sogar besser, kann ich mir zum Trost sagen... +

+ + + + + + + + + +

+ Im Entwurf von 2023 bin ich davon ausgegangen, daß der Build-Prozeß bereits eine flache Liste von »Exit Nodes« liefert; demnach würde es ausreichen, den Index in dieser Liste zu speichern, um in jedem Segment die Exit-Node zu finden. Später aber habe ich das Verhältnis von Model-Port und Exit-Node genauer analysiert, und eine tiefere Strukturiertheit vorgefunden. Zwar habe ich noch nicht entschieden, ob alle Differenzierungen innerhalb eines »Model-Port« schon im Build-Prozeß flach ausgefaltet werden — das erscheint aber intuitiv nicht plausibel (da eine kombinatorische Explosion droht). Unabhängig davon habe ich dann ab 2024 in der Ausarbeitung des low-Level-Model stets innerhalb der ProcNode noch eine Differenzierung in Node-Ports vorgesehen. Diese sollen dazu dienen, verschiedene Spielarten der »gleichen« Pipeline bereitzustellen (bsp. Mono vs. Stereo, oder low-res vs. high-res). +

+ + + + + + + + + + +

+ im aktuellen Code des Render-Job fehlen ExitNode und DataSink +

+ + + + + +

+ warum? der aktuelle Code ist immer noch die (irgendwie hingebogene) C-Struct von Christian. Damals gab es diese Konzepte gar nicht, und Christian hat sich stets gegen meine Analyse gewehrt, daß es da noch weitere Abhängigkeiten geben sollte, weil das die ganze Schönheit des Designs mit dem Scheduler kaputt macht. Zur Überarbeitung der JobPlanung / JobTicket habe ich zumindest die ExitNode schon vorgesehen, aber mehr als Platzhalter behandelt. Das ganze Mock-Job-Universum kommt ohne diese Information aus, und auch das Scheduler-Stress-Testing hat spezielle Job-Funktoren verwendet (die diese Info nicht brauchen) +

+ + + + + + + +

+ tendentiell soll »die Exit Node« im Design eine Stufe hochwandern +

+ + + + + + + +

+ hatte dafür im Design erst den Namen NodeGraphAttachment vorgesehen, und die ExitNode als eine Subklasse von ProcNode angesetzt, dann aber festgestellt, daß es sich um diskunkte Betrachtungsweisen handelt. +

+ + + + + + + + + +

+ ...daß es sich um eine komplexe Wechselbeziehung handelt, die nicht sinnvoll in eine einzige Dimension niveliert werden sollte +

+
    +
  • + die Media-Channels habe ich als Kategorie komplett beseitigt (genauer: zu einem internen Detail des MediaStream-Type gemacht) +
    • +
  • + dafür aber nun die verschiedenen Spielarten der gleichen Pipeline eingeführt +
    • +
  • + außerdem ist auch noch ein PlayProcess inhärent strukturiert (z.B. Video und Sound) +
    • +
  • + insofern kommt stets ein Index-Key aus dem CalcStream hinzu +
    • +
  • + ⟹ die ExitNode kann dieses Mapping auflösen +
    • +
+ + + + + + + + + + + + + + + + +

+ kann er superseded werden? +

+ + + + + + + + + + + + +

+ Operative Logik sollte in ihrer jeweilgen Domain ausformuliert werden; Logik sollte dort stehen, wo ihr Sinn sich aus dem Kontext direkt erschließt. +

+

+ Beispiel Output-Frame-Nr: +

+
    +
  • + wenn ich einem Node-Pull eine »Frame-Nr« mitgebe, ist aus dem allgemeinen Wesen der Render-Pipeline nicht direkt ersichtlich, was diese Frame-Nr bedeuten soll; man müßte es unter Bezug auf anderweitigen Kontext erläutern +
    • +
  • + wenn ich einem Frame-Output-Mechanismus eine Zeitangabe gebe, is wiederum rein aus dem Output-Mechanismus auf generischer Ebene nicht klar, was diese Zeit soll; man müßte seine Implementierung öffnen, um z.B. einen Buffer-Flip zu sehen +
    • +
  • + wenn ich aber beide Informationen in einem Job-Planungs-Kontext verknüpfe, sind sie an ihrem Ort: denn dieser Kontext stellt eine Verbindung her zwischen einer nominellen Zeit und einem aktuellen Processing. +
    • +
+ + + + + + + + + + + + + + + + + + + + + + + + +

+ genauer gesagt: eine planlose Vermengung von Bedeutung, Repräsentation und Implementierungs-Tricks +

+ + + + + + + + +

+ ...das ist wohl der festeste Constraint... +

+
    +
  • + habe bisher 6 »slots« à 64bit vorgesehen +
    • +
  • + davon sind 2 »slots« noch frei +
    • +
  • + durch geschicktes Packen der Daten könnte man das aber wohl auf 4 »slots« reduzieren +
    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ trotz aller Diskrepanzen : es müßte sich irgendwie mappen lassen +

+ + + + + + + + + + + + + + + + + +

+ diese entspricht einer bestimmten Instantiierung einer ViewConnection(Template) und ist intern noch strukturiert, enthält also mehrere ModelPorts (mit Rückverweis auf die OutputDesignation und damit den StreamType) sowie dazugehörige Sub-Qualifikationen / Spielarten +

+ + + + + + + +

+ diese entspricht der Vereinigungsmenge aller derzeit im Model vermerkten ModelViewActivations +

+ + + + + + + +

+ diese sind bereits in der ModelViewActivation mit vermerkt, und übertragen sich dann direkt in den jeweilgen Feed bzw. CalcStream (ein Feed entspricht einem ModelPort) +

+ + + + + + + +

+ ...und diese kann die Ausprägung letztlich in eine konkrete Render-Node und einen Node-Port übersetzen +

+ + + + + + + + + + + + + + + + +

+ wenn es nur eine DataSink wäre, +

+

+ würde ich mich besser fühlen +

+ + + + + + + + + + + + +

+ »die Engine« als Kontext ist nur sinnvoll für Services und Prozesse, die direkt auf Ebene der Engine operieren +

+ + + + + + + +

+ weil wir damit den Zugang zum Dispatcher und zum Scheduler öffnen; somit wäre es implizit erlaubt, einen sich selbst modifizierenden Render-Job zu bauen. Das wollen wir aber nur kontrolliert, für die Planungs-Jobs zulassen +

+ + + + + + + + + + +

+ nicht nur, weil die Frame-Nr tatsächlich im Planungskontext explizit (als Treiber) vorliegt, sondern auch weil dies eine reine Sequenz-Nummer ist und eigentlich nach Belieben umgesetzt werden kann. Nun gut, dann müßte man eben die Zeitachse redefinieren... +

+ + + + + + + + + + + + +

+ Wie z.B. ein 32bit Frame-Nr: damit könnte man 90 Tage bei 256 fps bespielen. Eigentlich mehr als genug, und trotzdem eine akzidentelle Beschränkung. Analog für die Output-Spielart, die dann eben in eine Liste gepackt werden müßte... +

+ + + + + + + + + + + + + + + + + + + + + + + + +

+ insofern wir keine absolute UUID brauchen, sondern nur eine systematische Hash-ID für den Cache. Diese kann errechnet werden aus exakt den Daten der Invocation (ausgenommen die Output-Frame-Nr) +

+ + + + + + + + + + + + + + + - - - - - - + + + + + + @@ -117406,9 +118052,9 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)

- + @@ -126289,6 +126935,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + @@ -126298,6 +126945,9 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + @@ -151450,9 +152100,9 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + - @@ -152739,8 +153389,9 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - - + + +