OutputSlot: consider how to integrate the proxy provider

...which still looks like a nasty task
 * the good part is, we have a working `BufferProxyAdaptor` now
 * yet this setup does not seem to fit into the `OutputSlot::AllocState`

As an aside, several test definitions need to be relocated to the Vault,
since the whole compound around `BufferProvider` migrated down

src/vault/mem/buffer-proxy-adaptor.hpp

@@ -86,20 +86,21 @@ namespace mem  {
           BuffAlloc
           provideBuffer (HashVal,size_t siz,LocalTag targetMarker)  override
             {
-              CONF::on_lock();
+              BuffAlloc storageSlot{asBuffer(targetMarker), siz, targetMarker};
-              return {asBuffer(targetMarker), siz, targetMarker};
+              CONF::on_lock (storageSlot);
+              return storageSlot;
             }
           
           void
           mark_emitted (HashVal, BuffAlloc storageSlot)  override
             {
-              CONF::on_emit();
+              CONF::on_emit (storageSlot);
             }
           
           void
           detachBuffer (HashVal, BuffAlloc storageSlot)  override
             {
-              CONF::on_release();
+              CONF::on_release (storageSlot);
             }
           
         public:
@@ -142,11 +143,18 @@ namespace mem  {
         : proxyProvider_{Setup{move(policy)}}
         { }
       
+      template<typename TAR>
+      BuffDescr
+      getDescriptorFor (TAR& dataBlock)
+        {
+          return proxyProvider_.registerBuffer(&dataBlock, sizeof(TAR));
+        }
+      
       template<typename TAR>
       BuffHandle
       lockBuffer (TAR& dataBlock)
         {
-          BuffDescr buffType = proxyProvider_.registerBuffer(&dataBlock, sizeof(TAR));
+          BuffDescr buffType = getDescriptorFor<TAR> (dataBlock);
           ENSURE (buffType.isValid());
           return buffType.lockBuffer();
         }

tests/47engine.tests

@@ -27,7 +27,7 @@ return: 0
 END
 
 
-PLANNED "Proxy Buffer-provider" BufferProxyProvider_test <<END
+TEST "Proxy Buffer-provider" BufferProxyAdaptor_test <<END
 return: 0
 END
 

tests/vault/mem/buffer-proxy-adaptor-test.cpp

@@ -1,5 +1,5 @@
 /*
-  OutputProxyProvider(Test)  -  verify accessing an output sink via BufferProvider protocol
+  BufferProxyAdaptor(Test)  -  verify accessing an output sink via BufferProvider protocol
 
    Copyright (C)
      2024,            Hermann Vosseler <Ichthyostega@web.de>
@@ -11,8 +11,8 @@
 
 * *****************************************************************/
 
-/** @file output-proxy-provider-test.cpp 
+/** @file buffer-proxy-adaptorr-test.cpp
- ** unit test \ref OutputProxyProvider_test
+ ** unit test \ref BufferProxyAdaptor_test
  */
 
 
@@ -37,12 +37,16 @@ namespace test  {
   
   
   /***************************************************************//**
-   * @test verify the design of OutputSlot and BufferProvider by
+   * @test demonstrate a configuration of the BufferProvider implementation,
-   *       implementing a delegating BufferProvider to expose
+   *       rigged such that a pre-existing given buffer (address) can be
-   *       output data buffers provided from _some implementation._
+   *       passed through and exposed as BuffHandle.
-   * @todo 2/2026 now using this setup for prototyping        /////////////////////////////////////////////////TICKET #1415 : explore this design idea through prototyping
+   * @remark while this looks like a rather convoluted implementation setup,
+   *       this feature is crucial to make the »Output Slot Protocol«
+   *       mesh up well ([1415]) with the »Buffer Provider Protocol«,
+   *       used internally within the Render Engine
+   * [1415]: https://issues.lumiera.org/ticket/1415]
    */
-  class OutputProxyProvider_test : public Test
+  class BufferProxyAdaptor_test : public Test
     {
       virtual void
       run (Arg)
@@ -51,9 +55,9 @@ namespace test  {
           
           // setup with notification callback
           BufferProxyAdaptor proxPro{PropBuilder()
-                                      .define (PROP_FIELD(on_lock),   [&]{ state = LOCKED; })
+                                      .define (PROP_FIELD(on_lock),   [&](BuffAlloc){ state = LOCKED; })
-                                      .define (PROP_FIELD(on_emit),   [&]{ state = EMITTED;})
+                                      .define (PROP_FIELD(on_emit),   [&](BuffAlloc){ state = EMITTED;})
-                                      .define (PROP_FIELD(on_release),[&]{ state = FREE;   })
+                                      .define (PROP_FIELD(on_release),[&](BuffAlloc){ state = FREE;   })
                                     };
           
           // Assuming some data block is »given«
@@ -90,7 +94,7 @@ namespace test  {
   
   
   /** Register this test class... */
-  LAUNCHER (OutputProxyProvider_test, "unit play");
+  LAUNCHER (BufferProxyAdaptor_test, "unit play");
   
   
   

wiki/thinkPad.ichthyo.mm

@@ -115054,7 +115054,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
 <node COLOR="#338800" CREATED="1773604361248" ID="ID_720105604" MODIFIED="1773604407072" TEXT="in das BufferStore-API und Implementierungen">
 <icon BUILTIN="button_ok"/>
 </node>
-<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1773604377214" FOLDED="true" ID="ID_200162330" MODIFIED="1773700514964" TEXT="mu&#xdf; die Size-Info in die Metadaten weitergeben">
+<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1773604377214" ID="ID_200162330" MODIFIED="1773704036391" TEXT="mu&#xdf; die Size-Info in die Metadaten weitergeben">
 <linktarget COLOR="#1c07d0" DESTINATION="ID_200162330" ENDARROW="Default" ENDINCLINATION="-77;817;" ID="Arrow_ID_1474651143" SOURCE="ID_49953306" STARTARROW="None" STARTINCLINATION="1030;40;"/>
 <icon BUILTIN="messagebox_warning"/>
 <node CREATED="1773606726737" ID="ID_1617991320" MODIFIED="1773606747708" TEXT="die BufferMetadata::markLocked() mu&#xdf; eine abweichende BufferSize speichern"/>
@@ -115179,8 +115179,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
       Und damit spielt sich das System dann irgendwann auf einen festen Pool von Buffer-&#187;Slots&#171; ein, die permanent im Speicher bleiben. Allerdings bedeutet das dann f&#252;r die Metadaten ein <b>Cartesisches Produkt</b>&#160; zwischen der Zahl der Memory-Slots und der Zahl der verschiedenen Buffer-Typen....
     </p>
   </body>
-</html>
+</html></richcontent>
-</richcontent>
 </node>
 <node CREATED="1773684209259" ID="ID_1502362582" MODIFIED="1773685168035" TEXT="zur Beurteilung dessen brauchen wir aber Praxiserfahrung">
 <richcontent TYPE="NOTE"><html>
@@ -115190,8 +115189,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
       Ob das also gef&#228;hrlich wird, oder eine etwas ausufernde Metadaten-Storage durchaus &#252;berkompensiert wird von dem Wegfall der permanenten Allokation/Deallokation (und Hashtable-Pflege), kann nicht auf theoretischer Ebene abgehandelt werden. Mehr noch: es ist sogar zweifelhaft, ob sich <i>diese Frage &#252;berhaupt zuverl&#228;ssig beantworten l&#228;&#223;t, auch empirisch!</i>&#160;Dazu m&#252;&#223;te man einen Weg finden, um die <i>Stabilit&#228;t</i>&#160;des Verhaltens zu beurteilen, &#252;ber verschieden Nutzszenarien hinweg
     </p>
   </body>
-</html>
+</html></richcontent>
-</richcontent>
 </node>
 <node CREATED="1773684267099" ID="ID_223570720" MODIFIED="1773685274668" TEXT="und dann m&#xf6;glicherweise einen Garbage-sweep">
 <richcontent TYPE="NOTE"><html>
@@ -115201,8 +115199,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
       Allerdings, wenn man sich darauf einl&#228;&#223;t, Speicher nicht wegzur&#228;umen, dann mu&#223; man explizit den Fall betrachten, da&#223; der Speicher voll&#228;uft. In dem Fall br&#228;uchte es einen &#187;Sweep&#171;, der &#252;ber die Metadaten-Tabelle iteriert und alle Eintr&#228;ge pauschal l&#246;scht, die als FREE markiert sind. <i>The usual trade-offs apply.</i>
     </p>
   </body>
-</html>
+</html></richcontent>
-</richcontent>
 </node>
 </node>
 </node>
@@ -115214,8 +115211,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
       Einsicht: nicht re-Locking sondern das <font face="Monospaced" color="#684e4e"><b>onlyNew</b></font>&#160;ist hier redundant
     </p>
   </body>
-</html>
+</html></richcontent>
-</richcontent>
 <icon BUILTIN="idea"/>
 <node CREATED="1773686546507" ID="ID_1896242135" MODIFIED="1773686555542" TEXT="das ist so ein pseudo-Konsistenzcheck"/>
 <node CREATED="1773686569345" ID="ID_811960003" MODIFIED="1773686579555" TEXT="dabei haben wir ohnehin eine State-Machine"/>
@@ -137523,8 +137519,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
       fragw&#252;rdig ist im Besonderen der hierarchische Ansatz, der die konkreten Storage-Metadaten als Spezialisierung eines Typ-Eintrags behandelt.
     </p>
   </body>
-</html>
+</html></richcontent>
-</richcontent>
 </node>
 <node CREATED="1773685436937" ID="ID_1194997795" MODIFIED="1773685524347" TEXT="Buffer-Metadaten werden mutma&#xdf;lich auch vom Storage-Backend mitverwendet">
 <richcontent TYPE="NOTE"><html>
@@ -137534,8 +137529,10 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
       Im Besonderen stehen dort all die relevanten Infos, die jeder Memory-Allocator ben&#246;tigt: die konkrete Adresse und die Size (m&#246;glicherweise sogar ein MRU-counter, oder &#228;hnliche technische Informationen)
     </p>
   </body>
-</html>
+</html></richcontent>
-</richcontent>
+<node CREATED="1773703954354" ID="ID_1415408255" MODIFIED="1773703991156" TEXT="m&#xf6;glicherweise will man gemeinsame Metadaten-Tabellen">
+<linktarget COLOR="#76516c" DESTINATION="ID_1415408255" ENDARROW="Default" ENDINCLINATION="779;39;" ID="Arrow_ID_1408352744" SOURCE="ID_340628735" STARTARROW="None" STARTINCLINATION="468;17;"/>
+</node>
 </node>
 <node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1773686351857" ID="ID_867612305" MODIFIED="1773686475190" TEXT="Performance und Zusammenspiel mit dem Betriebszustand?">
 <linktarget COLOR="#794397" DESTINATION="ID_867612305" ENDARROW="Default" ENDINCLINATION="-1231;58;" ID="Arrow_ID_535246973" SOURCE="ID_339106431" STARTARROW="None" STARTINCLINATION="-148;960;"/>
@@ -138021,6 +138018,23 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
 <linktarget COLOR="#4b1ec1" DESTINATION="ID_49953306" ENDARROW="Default" ENDINCLINATION="-1107;45;" ID="Arrow_ID_474360109" SOURCE="ID_497122958" STARTARROW="None" STARTINCLINATION="687;22;"/>
 <linktarget COLOR="#5a22df" DESTINATION="ID_49953306" ENDARROW="Default" ENDINCLINATION="770;-33;" ID="Arrow_ID_886780269" SOURCE="ID_1831855764" STARTARROW="None" STARTINCLINATION="751;0;"/>
 <icon BUILTIN="messagebox_warning"/>
+<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1773703618287" HGAP="62" ID="ID_914494536" MODIFIED="1773703647578" TEXT="mu&#xdf; BufferProxyAdaptor in OutputSlot::Allocstate integrieren" VSHIFT="33">
+<icon BUILTIN="pencil"/>
+<node CREATED="1773703751137" ID="ID_340628735" MODIFIED="1773703998020" TEXT="&#xdc;berlegung am Rande: l&#xe4;ngerfristig wollen wir einen globalen Metadaten-Store">
+<richcontent TYPE="NOTE"><html>
+  <head>
+    
+  </head>
+  <body>
+    <p>
+      In der aktuellen Konfiguration hat jeder BufferProvider seine eigenes BufferStage-Implementierung, und darin eingebettet eine eigene Metadaten-Hashtable. Im Falle des BufferProxyAdaptors bedeutet das, f&#252;r jede Allokation eines OutputSlot erneut eine Metadaten-Verwaltung zu konstruieren, die dann aber nur f&#252;r wenige Buffer-Eintr&#228;ge genutzt wird. Da Output-Slots durchaus l&#228;ngerfristig leben, stellt das kein Performance-Problem da, aber k&#246;nnte letztlich schon zu einigem Bloat f&#252;hren
+    </p>
+  </body>
+</html>
+</richcontent>
+<arrowlink COLOR="#76516c" DESTINATION="ID_1415408255" ENDARROW="Default" ENDINCLINATION="779;39;" ID="Arrow_ID_1408352744" STARTARROW="None" STARTINCLINATION="468;17;"/>
+</node>
+</node>
 </node>
 </node>
 <node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1773456815562" ID="ID_1123444875" MODIFIED="1773589752521" TEXT="Doku">