diff --git a/src/lib/iter-adapter.hpp b/src/lib/iter-adapter.hpp index 069d57fcd..261ce63ab 100644 --- a/src/lib/iter-adapter.hpp +++ b/src/lib/iter-adapter.hpp @@ -151,7 +151,7 @@ namespace lib { * -# it should be copy constructible * -# when IterAdapter is supposed to be assignable, then POS should be * -# it should provide embedded typedefs for pointer, reference and value_type, - * or alternatively resolve these types through specialisation of meta::TypeBinding. + * or alternatively resolve these types through specialisation of meta::ValueTypeBinding. * -# it should be convertible to the pointer type it declares * -# dereferencing should yield a type that is convertible to the reference type * - CON points to the data source of this iterator (typically a data container type) diff --git a/src/vault/gear/block-flow.hpp b/src/vault/gear/block-flow.hpp index 7cfd17229..7f405c645 100644 --- a/src/vault/gear/block-flow.hpp +++ b/src/vault/gear/block-flow.hpp @@ -197,7 +197,7 @@ namespace gear { currEpoch() { REQUIRE (bool(extent)); - return static_cast (extent->access()); ////////////////////////////OOO is it possible to adapt the iterator, so that dereferentiation directly yields the Extent? + return static_cast (*extent); } void* diff --git a/src/vault/mem/extent-family.hpp b/src/vault/mem/extent-family.hpp index bde17ca4d..170ecd1ac 100644 --- a/src/vault/mem/extent-family.hpp +++ b/src/vault/mem/extent-family.hpp @@ -109,9 +109,31 @@ namespace mem { ENSURE (get() != nullptr); return reinterpret_cast (*get()); } + + struct iterator + { + using value_type = Extent; + using reference = Extent&; + using pointer = Extent*; + + Storage* storageSlot; + + explicit + operator bool() const + { + return bool(storageSlot); + } + + Extent& + operator* () + { + REQUIRE (storageSlot and *storageSlot); + return storageSlot->access(); + } + }; }; using Extents = std::vector; - using RawIter = typename Extents::iterator; + using RawIter = typename Storage::iterator; /* ==== Management Data ==== */ diff --git a/tests/vault/mem/extent-family-test.cpp b/tests/vault/mem/extent-family-test.cpp index 2d5b612cf..d4fa7eed0 100644 --- a/tests/vault/mem/extent-family-test.cpp +++ b/tests/vault/mem/extent-family-test.cpp @@ -78,7 +78,7 @@ namespace test { simpleUsage() { Extents extents{5}; - Extent& extent = extents.active()->access(); //////////////////////////////////////////OOO better Iter implementation for direct access + Extent& extent = *extents.active(); CHECK (10 == extent.size()); int num = rand() % 1000; @@ -126,7 +126,7 @@ namespace test { Iter it = extents.active(); CHECK (it); - Extent& extent = it->access(); ////////////////////////////////////////////////////////OOO better Iter implementation for direct access + Extent& extent{*it}; CHECK (10 == extent.size()); int num = rand() % 1000; @@ -135,7 +135,7 @@ namespace test { ++it; CHECK (it); - Extent& nextEx = it->access(); + Extent& nextEx{*it}; CHECK (not isSameObject(extent, nextEx)); nextEx[5] = extent[2] + 1; CHECK (num == extent[2]); diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 7efe39a4a..3056f0eeb 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -6853,7 +6853,7 @@ At first sight the link between asset and clip-MO is a simple logical relation b {{red{Note 1/2015}}} several aspects regarding the relation of clips and single/multichannel media are not yet settled. There is a preliminary implementation in the code base, but it is not sure yet how multichnnel media will actually be modelled. Currently, we tend to treat the channel multiplicity rather as a property of the involved media, i.e we have //one// clip object. -
+
//Render Activities define the execution language of the render engine.//
 The [[Scheduler]] maintains the ability to perform these Activities, in a time-bound fashion, observing dependency relations; activities allow for notification of completed work, tracking of dependencies, timing measurements, re-scheduling of other activities -- and last but not least the dispatch of actual [[render jobs|RenderJob]]. Activities are what is actually enqueued with priority in the scheduler implementation, they are planned for a »µ-tick slot«, activated once when the activation time is reached, and then forgotten. Each Activity is a //verb//, but can be inhibited by conditions and carry operation object data. Formally, activating an Activity equates to a predication, and the subject of that utterance is »the render process«.
 
@@ -6882,6 +6882,9 @@ While Activities are logically polymorphic, they are implemented as »POD with c
 
 Activities are organised into ''chains'', allowing to express relations based on their respective verbs.
 There are //standard usage patters,// hard coded into the {{{ActivityLang}}} and expected by the {{{SchedulerCommutator}}}, to express all relevant patterns of operational logic necessary to represent time-bound and dependent playback and render tasks.
+
+!The Activity Language
+While the Activities are low-level primitives and can be handled directly by the scheduler, any actual rendering invocation must arrange several Activities into a suitable chain of operations. Thus the actual rendering invocation can be seen as a //sentence of the Activity Language.// Formally speaking, it is a //symbolic term.// Not every possible term (and thus sentence) leads to semantically sound behaviour, and thus the ''Scheduler Interface Setup'' is organised in the form of a //builder notation to construct viable Activity terms.// {{{vault::gear::ActivityLang}}} provides the framework for such builder invocations, and allows to create such terms as transient objects -- connected to the durable {{{Activity}}} records allocated into the [[»BlockFlow« memory manager|SchedulerMemory]] backing the Scheduler operation. The language term is thus a front-end, and exposes suitable extension and configuration points for the JobPlanningPipeline to instruct the necessary Scheduler operations to enact a specific [[render Job|RenderJob]].
@@ -7063,7 +7066,7 @@ Later on we expect a distinct __query subsystem__ to emerge, presumably embeddin → QuantiserImpl
-
+
//Invoke and control the dependency and time based execution of  [[render jobs|RenderJob]]//
 The Scheduler acts as the central hub in the implementation of the RenderEngine and coordinates the //processing resources// of the application. Regarding architecture, the Scheduler is located in the Vault-Layer and //running// the Scheduler is equivalent to activating the »Vault Subsystem«. An EngineFaçade acts as entrance point, providing high-level render services to other parts of the application: [[render jobs|RenderJob]] can be activated under various timing and dependency constraints. Internally, the implementation is segregated into two layers
 ;Layer-2: Coordination
@@ -7084,6 +7087,9 @@ The [[Language of render activities|RenderActivity]] forms the interface to the
 
 These ''Worker Threads'' will perform actual render activities most of the time (or be idle). However -- idle workers contend for new work, and for doing so, they //also perform the internal scheduler management activities.// As a consequence, all Scheduler coordination and [[memory management|SchedulerMemory]] is ''performed non-concurrent'': only a single Worker can acquire the {{{GroomingToken}}} and will then perform managment work until the next render activity is encountered at the top side of the //priority queue.//
 
+!!!Instructing the Scheduler
+The Scheduler is now considered an implementation-level facility with an interface specifically tailored at the JobPlanningPipeline: the [[»Render Activity Language«|RenderActivity]]. This //builder-style// setup allows to construct an ''~Activity-Term'' to model all the structural properties of an individual rendering invocation -- it is compriesed of a network of {{{Activity}}} records, which can be directly handled by the Scheduler.
+
 → [[Activity|RenderActivity]]
 → [[Memory|SchedulerMemory]]
 → [[Workers|SchedulerWorker]]
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 4acafbedc..8e0d87ea6 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -69785,9 +69785,9 @@
 
 
 
-
+
 
-
+
 
 
 
@@ -76586,6 +76586,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 
 
 
+
+
+
+
 
 
 
@@ -77013,6 +77017,11 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 
 
 
+
+
+
+
+
 
 
 
@@ -77760,9 +77769,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 
 
 
-
-
-
+
+
+
+
 
 
 
@@ -78045,6 +78055,223 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

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

+      Das ergibt sich unmittelbar aus den Prinzipien dieses Designs: Job-Planung läuft auf das Erstellen von Activities hinaus, und dies bedingt Speicherverwaltung — welche der grundlegenden Entscheidung gemäß nur in einem Thread (unter GroomingToken) stattfinden darf
+    

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

+      aus dem Term können die
+    

+    

+      Instruct-Daten gewonnen werden
+    

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

+      Builder-Operationen können auch nachher
+    

+    

+      (in Grenzen) noch stattfinden
+    

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

+      das Job-Planning „muß wissen was es tut“ — typischerweise müssen alle Zeitfenster hinreichend weit in der Zukunft liegen
+    

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

+      wenig Raum für Diskussionen — und zwar wegen der Memory-Allokation
+    

+  
+
+
+
+
+
+
+
 
 
 
@@ -78061,6 +78288,26 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -79674,6 +79921,15 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 
 
 
+
+
+
+
+
+
+
+
+
 
 
 
@@ -79976,7 +80232,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 
 
 
-
+