ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/src/steam/engine/weaving-pattern-builder.hpp

418 lines
19 KiB
C++
Raw Normal View History

Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
/*
WEAVING-PATTERN-BUILDER.hpp - build an invocation pattern for media calculations
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
Copyright (C)
2024, Hermann Vosseler <Ichthyostega@web.de>
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
  **Lumiera** is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
  Free Software Foundation; either version 2 of the License, or (at your
  option) any later version. See the file COPYING for further details.
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
*/
/** @file weaving-pattern-builder.hpp
Invocation: work out solution for a precisely fitting allocation Conduct in-depth analysis to handle a secondary, implementation-related (and frankly quite challenging) concern regarding the placement of node and port connectivity data in memory. The intention is for the low-level model to use a custom data structure based on `lib::Several`, allowing for flexible and compact arrangement of the connectivity descriptors within tiled memory blocks, which can then later be discarded in bulk, whenever a segment of the render graph is superseded. Yet since the generated descriptors are heterogeneous and, due to virtual functions, can not be trivially copied, the corresponding placement invocations on the data builder API must not be mixed, but rather given in ordered strikes and preceded by a dimensioning call to pre-reserve a bulk of storage However, doing so directly would jeopardise the open and flexible nature of the node builder API, thereby creating a dangerous coupling between the implementation levels of the node graph and of prospective library wrapper plug-ins in charge of controlling details of the graph layout. The solution devised here entails a functional helper data structure created temporarily within the builder API stack frames; the detailed and local type information provided from within the library plug-in can thereby be embedded into opaque builder functors, allowing to delay the actual data generation up until the final builder step, at which point the complete number and size requirements of connectivity data is known and can be used for dimensioning.
2024-10-20 21:51:34 +02:00
** Construction kit to establish an invocation scheme for media calculations.
Invocation: solve passing of the function definition - the chaining constructor is picked reliably when the slicing is done by a direct static_cast - the function definition can be passed reliably in all cases after it has been ''decayed,'' which is done here simply by taking it by-value. This is adequate, since the function definition must be copied / inlined for each invocation. With these fixes, the simplest test case now for the first time **runs through without failure**
2024-10-22 05:59:00 +02:00
** Adapters and configuration is provided to invoke the actual _media processing function_
Invocation: code clean-up and documentation Remove left-overs from the preceding prototypical implementation, which is now obliterated by the change to a flexibly configured `FeedManifold` with structured, typed storage for buffers and for parameter data. The Render Node invocation sequence, as rearranged and reworked for the »Playback Vertical Slice«, now seems reasonably clear and settled. Adding extensive documentation to describe the conventions and structures worked out thus far; moreover, start makeover of old documentation in the !TiddlyWiki to remove concepts obviously obsoleted now...
2024-12-21 23:58:56 +01:00
** in accordance to a wiring scheme as implied by the _signature_ of the bound function.
** - the function takes one to three arguments
** - these are related to the parameters, the input and the output (always in that order)
** - the specification of at least one output buffer is mandatory
** - a function may omit input and / or the parameter «slot»
** - multiple items of the same kind (output, input, parameter) can be packaged
** into a heterogeneous tuple, or given as an array of identically typed elements;
** yet a single value can be accepted directly as function argument.
** - input/output buffers are recognisable as pointers, while parameters are value data.
** - pointers and parameter values are typed, which is used internally to ensure passing
** the right value to the corresponding item and to ensure suitable memory allocations.
Invocation: this »weaving-pattern« evolves into a default Starting from a prototypical implementation, where each »slot« in the function is directly connected to the corresponding lead / port, the implementation of the `SimpleWeavingPattern` (as it was called previously) could be augmented and adapted gradually — and seems well suited to cover most standard cases of ''media processing'' So a name change is mandated, and the code is also extracted and relocated, possibly even to be combined with the code of the `InvocationAdapter`, thereby hopefully making the implementation more accessible Generally speaking, ''weaving patterns'' take on the role of the prime extension point regarding `Port` implementation.
2024-12-14 03:50:10 +01:00
** @note steam::engine::Turnout mixes-in the steam::engine::MediaWeavingPattern, which in turn
Invocation: code clean-up and documentation Remove left-overs from the preceding prototypical implementation, which is now obliterated by the change to a flexibly configured `FeedManifold` with structured, typed storage for buffers and for parameter data. The Render Node invocation sequence, as rearranged and reworked for the »Playback Vertical Slice«, now seems reasonably clear and settled. Adding extensive documentation to describe the conventions and structures worked out thus far; moreover, start makeover of old documentation in the !TiddlyWiki to remove concepts obviously obsoleted now...
2024-12-21 23:58:56 +01:00
** inherits from a FeedManifold given as template parameter. So this constitutes an
** **extension point** where other, more elaborate invocation schemes could be integrated.
**
** # Preparing a FeedManifold and handling invocation parameters
**
** Detection of the processing function signature with all possible variations as detailed above
** is the responsibility of the [FeedManifold template](\ref feed-manifold.hpp). For each distinct
** signature, a suitable data layout is generated, including storage to hold the processing-functor
** itself (which is embedded as a clone-copy to expose the actual invocation to the optimiser in
** the C++ compiler). The WeavingBuilder defined here is used to build a Port implementation and
** thus a specific »Weaving Pattern«, which — at the actual Node invocation — will in turn build
** the concrete FeedManifold instance into local stack memory. For this reason, the Port can be
** understood as the Level-1 builder, whereas the Port / Weaving Builder is classified as Level-2
** and a processing and link-builder operating on top of the former is designated as Level-3.
**
** The actual type of the FeedManifold, including all the specifics of the data layout, becomes
** embedded into the Port implementation (≙Weaving Pattern) by means of a FeedPrototype instance.
** Furthermore, a parameter-functor can be installed there, to generate actual parameter data
** whenever the FeedPrototype generates a new FeedManifold instance for the next render invocation.
** The parameter data (and a copy of the processing-functor) is stored alongside in this generation
** step, and thus available in local stack memory during an extended (possibly recursive) render
** invocation sequence.
**
** Invocation parameters are a crucial ingredient for each invocation, yet the responsibility for
** the parameter-functor to produce these parameters lies in a different part of the system than
** the responsibility for configuring the processing functor. The reason is simply that the
** setup of actual parameters is an essential part of the user's work on the edit in the Session.
** The control flow for parameter thus traces back into the session, while on the other hand the
** processing-functor must be configured by an external media-library adapter Plug-in. So this
** creates the challenge that in actual use the PortBuilder will be passed through several realms.
** Firstly, the external library binding will be invoked to set up a processing-functor, and then,
** in a separate step, the same PortBuilder instance, unfinished at that point, will be passed to
** the code responsible for configuring parameters and _Parameter Automation._ Only after that,
** the _terminal builder operation_ WeavingBuilder::build() will be invoked, and the control
** flow in the Lumiera Builder subsystem proceeds to outfitting the next Render Node.
** This intricate sequence of configuration step translates into the necessity to build the
** FeedPrototype first in its basic form, without a parameter-functor. The second configuration
** step performed later will then have to re-shape the FeedPrototype to add a parameter-functor.
** This amounts to a move-copy, thereby changing the FeedPrototype's template arguments to
** the full signature, including the type of the parameter functor. In this final shape,
** it can be integrated into a Turnout instance and dropped off into the PatternData, which
** is used to record configuration for the actual storage allocation and node generation step
** performed later.
Invocation: solve passing of the function definition - the chaining constructor is picked reliably when the slicing is done by a direct static_cast - the function definition can be passed reliably in all cases after it has been ''decayed,'' which is done here simply by taking it by-value. This is adequate, since the function definition must be copied / inlined for each invocation. With these fixes, the simplest test case now for the first time **runs through without failure**
2024-10-22 05:59:00 +02:00
**
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
**
Invocation: solve passing of the function definition - the chaining constructor is picked reliably when the slicing is done by a direct static_cast - the function definition can be passed reliably in all cases after it has been ''decayed,'' which is done here simply by taking it by-value. This is adequate, since the function definition must be copied / inlined for each invocation. With these fixes, the simplest test case now for the first time **runs through without failure**
2024-10-22 05:59:00 +02:00
** # Interplay of NodeBuider, PortBuilder and WeavingBuilder
**
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
** The steam::engine::WeavingBuilder defined here serves as the low-level builder and adapter
** to prepare the wiring and invocation. The builder-API allows to setup the wiring of input
** and output-»slots« and control some detail aspects like caching. However, without defining
** any connections explicitly, a simple 1:1 wiring scheme is employed
Invocation: solve passing of the function definition - the chaining constructor is picked reliably when the slicing is done by a direct static_cast - the function definition can be passed reliably in all cases after it has been ''decayed,'' which is done here simply by taking it by-value. This is adequate, since the function definition must be copied / inlined for each invocation. With these fixes, the simplest test case now for the first time **runs through without failure**
2024-10-22 05:59:00 +02:00
** - each _input slot_ of the function gets an input buffer, which is filled by _pulling_
** (i.e. invoking) a predecessor node (a so called »lead«).
** - for each _output slot_ a buffer is allocated for the processing function to drop off
** the calculated media data
** - only one of these output buffers is used as actual result, while the other buffers
** are just discarded (but may possibly be fed to the frame cache).
**
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
** Each [Processing Node](\ref ProcNode) represents one specific processing functionality on a
** logical level; yet such a node may be able to generate several „flavours“ of this processing,
Invocation: solve passing of the function definition - the chaining constructor is picked reliably when the slicing is done by a direct static_cast - the function definition can be passed reliably in all cases after it has been ''decayed,'' which is done here simply by taking it by-value. This is adequate, since the function definition must be copied / inlined for each invocation. With these fixes, the simplest test case now for the first time **runs through without failure**
2024-10-22 05:59:00 +02:00
** which are represented as *ports* on this node. Actually, each such port stands for one specific
** setup of a function invocation, with appropriate _wiring_ of input and output connections.
** For example, an audio filtering function may be exposed on port-#1 for stereo sound, while
** port-#2 may process the left, and port-#3 the right channel in isolation. It is entirely
Invocation: code clean-up and documentation Remove left-overs from the preceding prototypical implementation, which is now obliterated by the change to a flexibly configured `FeedManifold` with structured, typed storage for buffers and for parameter data. The Render Node invocation sequence, as rearranged and reworked for the »Playback Vertical Slice«, now seems reasonably clear and settled. Adding extensive documentation to describe the conventions and structures worked out thus far; moreover, start makeover of old documentation in the !TiddlyWiki to remove concepts obviously obsoleted now...
2024-12-21 23:58:56 +01:00
** up to the library-adapter-plug-in to decide what processing functions to expose, and in
** which flavours. The WeavingBuilder is used to generate a single \ref Turnout object,
** which corresponds to the invocation of a single port and thus one flavour of processing.
Invocation: solve passing of the function definition - the chaining constructor is picked reliably when the slicing is done by a direct static_cast - the function definition can be passed reliably in all cases after it has been ''decayed,'' which is done here simply by taking it by-value. This is adequate, since the function definition must be copied / inlined for each invocation. With these fixes, the simplest test case now for the first time **runs through without failure**
2024-10-22 05:59:00 +02:00
**
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
** At one architectural level above, the \ref NodeBuilder exposes the ability to set up a
Invocation: solve passing of the function definition - the chaining constructor is picked reliably when the slicing is done by a direct static_cast - the function definition can be passed reliably in all cases after it has been ''decayed,'' which is done here simply by taking it by-value. This is adequate, since the function definition must be copied / inlined for each invocation. With these fixes, the simplest test case now for the first time **runs through without failure**
2024-10-22 05:59:00 +02:00
** ProcNode, complete with several ports and connected to possibly several predecessor nodes.
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
** Using a sequence of NodeBuilder invocations, the _processing node graph_ can be built gradually,
** starting from the source (predecessors) and moving up to the _exit nodes,_ which produce the
** desired calculation results. The NodeBuilder offers a function to define the predecessor nodes
** (also designated as _lead nodes_), and it offers an [entrance point](\ref NodeBuilder::preparePort)
** to descend into a \ref PortBuilder, allowing to add the port definitions for this node step by step.
Invocation: solve passing of the function definition - the chaining constructor is picked reliably when the slicing is done by a direct static_cast - the function definition can be passed reliably in all cases after it has been ''decayed,'' which is done here simply by taking it by-value. This is adequate, since the function definition must be copied / inlined for each invocation. With these fixes, the simplest test case now for the first time **runs through without failure**
2024-10-22 05:59:00 +02:00
**
** On the implementation level, the PortBuilder inherits from the NodeBuilder and embeds a
** WeavingBuilder instance. Moreover, the actual parametrisations of the NodeBuilder template
** are chained to create a _functional data structure._ This intricate setup is necessary because
** the actual data structure of the node graph comprises several small descriptor arrays and
** interconnected pointers, which are all placed into consecutive chunks of memory, using a
** custom allocator, the AllocationCluster. The lib::Several is used as front-end to access
** these small collections of related objects, and the associated lib::SeveralBuilder provides
** the low-level memory allocation and object creation functionality. The purpose of this
** admittedly quite elaborate scheme is to generate a compact data structure, with high
** cache locality and without wasting too much memory. Since the exact number of elements
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
** and the size of those elements can be deduced only after the builder-API usage has
Invocation: solve passing of the function definition - the chaining constructor is picked reliably when the slicing is done by a direct static_cast - the function definition can be passed reliably in all cases after it has been ''decayed,'' which is done here simply by taking it by-value. This is adequate, since the function definition must be copied / inlined for each invocation. With these fixes, the simplest test case now for the first time **runs through without failure**
2024-10-22 05:59:00 +02:00
** been completed, the aforementioned functional datastructure is used to collect the
** parametrisation information for all ports, while delaying the actual object creation.
** With this technique, it is possible to generate all descriptors or entries of one
** kind in a single run, and placed optimally and compact into the memory allocation.
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
**
** @see turnout.hpp
** @see node-builder.hpp
Invocation: rearrange the Render Node development tests This is an attempt to take aim at the next step, which is to fill in the missing part for an actual node invocation... ''...still fighting to get ahead, due to complexity of involced concerns...''
2024-12-06 23:43:18 +01:00
** @see NodeLink_test
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
**
Invocation: solve passing of the function definition - the chaining constructor is picked reliably when the slicing is done by a direct static_cast - the function definition can be passed reliably in all cases after it has been ''decayed,'' which is done here simply by taking it by-value. This is adequate, since the function definition must be copied / inlined for each invocation. With these fixes, the simplest test case now for the first time **runs through without failure**
2024-10-22 05:59:00 +02:00
** @todo WIP-WIP-WIP as of 10/2024 prototyping how to build and invoke render nodes /////////////////////////TICKET #1371
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
**
*/
#ifndef STEAM_ENGINE_WEAVING_PATTERN_BUILDER_H
#define STEAM_ENGINE_WEAVING_PATTERN_BUILDER_H
Invocation: runtime error checks for auto-wiring Since it would in fact be possible to access and write beyond the configured storage, simply by using the builder API without considering consistency, it seems advisable to use explicit runtime checks here, instead of only assertions, and to throw an exception when violating bounds. Moreover, unsuccessfully attempted to better arrange the functionality between PortBuilder and WeavingBuilder; seemingly we have an rather tight coupling here, and also the expectations regarding the processing function seem to be too tight (but that's the reason why it's an prototype...)
2024-10-26 03:03:11 +02:00
#include "lib/error.hpp"
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
#include "lib/several-builder.hpp"
Invocation: consider how to establish a stable cache key Building a precise Frame Cache is a tough job, and is doomed to fail when attempting to tie cache invalidation to state changes. The only viable path is to create a system of systematic tagging of processing steps, and use this as foundation for chained hash values, linked in accordance to the actual processing structure. This is complicated by the secondary concern of maintaining memory efficacy for the render node model, which can be expected to grow to massive scale. And even while this invocation can not be fully devised right now, an attempt can be made to build a foundation that is not outright wasteful, by detaching the logical information from the specific weaving pattern used for implementation, and by minimising the representation in memory and computing the compound information on-demand....
2024-11-02 23:54:41 +01:00
#include "steam/engine/proc-id.hpp"
Invocation: introduce engine-context for dependency injection ...by relying on DI for some effectively global services, notably the cache provider, the API for building and wiring render nodes can be simplified to cover only the actual node connectivity
2024-08-03 03:21:59 +02:00
#include "steam/engine/engine-ctx.hpp"
Invocation: this »weaving-pattern« evolves into a default Starting from a prototypical implementation, where each »slot« in the function is directly connected to the corresponding lead / port, the implementation of the `SimpleWeavingPattern` (as it was called previously) could be augmented and adapted gradually — and seems well suited to cover most standard cases of ''media processing'' So a name change is mandated, and the code is also extracted and relocated, possibly even to be combined with the code of the `InvocationAdapter`, thereby hopefully making the implementation more accessible Generally speaking, ''weaving patterns'' take on the role of the prime extension point regarding `Port` implementation.
2024-12-14 03:50:10 +01:00
#include "steam/engine/weaving-pattern.hpp"
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
#include "steam/engine/buffer-provider.hpp"
Invocation: draft how the 1:1-fallback wiring could work ...and as expected, this turns up quite some inconsistencies, especially regarding usage of the »buffer types«. Basically, the `PortBuilder` is responsible for the high-level functionality and thus must ensure the nested `WiringBuilder` is addressed and parameterised properly to connect all »slots« of the processing function. - can use a helper function in the WiringBuilder to fill in connections - but the actual buffer types passed over these connectinos are totally unchecked at that level, and can not see yet how this danger can be mitigated one level above, where the PortBuilder is used. - it is still unclear what a »buffer type« actually means; it could be the pointer type, but it could also imply a class or struct type to be emplaced into the buffer, which is a special extension to the `BufferProvider` protocol, yet seems to be used here rather to transport specific data types required by the actual media handling library (e.g. FFmpeg)
2024-10-14 04:07:47 +02:00
#include "steam/engine/buffhandle-attach.hpp" /////////////////OOO why do we need to include this? we need the accessAs<TY>() template function
Invocation: switch `WeavingPattern` and Level-1 builder to the reworked `FeedManifold` After the complete makeover of the `FeedManifold` structure, which among other entails a switch from ''buffer arrays'' to tuples and the ''introduction of a parameter tuple'', this changeset now switches the „downstream code“ of the builder and node invocation, relying on an largely identical invocation API. The partially finished NodeLink_test now **runs as before** but on top of a drastically more flexible and open infrastructure. Quite a feat.
2024-12-01 05:24:12 +01:00
#include "lib/meta/tuple-helper.hpp"
Invocation: code clean-up and documentation Remove left-overs from the preceding prototypical implementation, which is now obliterated by the change to a flexibly configured `FeedManifold` with structured, typed storage for buffers and for parameter data. The Render Node invocation sequence, as rearranged and reworked for the »Playback Vertical Slice«, now seems reasonably clear and settled. Adding extensive documentation to describe the conventions and structures worked out thus far; moreover, start makeover of old documentation in the !TiddlyWiki to remove concepts obviously obsoleted now...
2024-12-21 23:58:56 +01:00
//#include "lib/test/test-helper.hpp" ////////////////////////////OOO TODO added for test
Invocation: runtime error checks for auto-wiring Since it would in fact be possible to access and write beyond the configured storage, simply by using the builder API without considering consistency, it seems advisable to use explicit runtime checks here, instead of only assertions, and to throw an exception when violating bounds. Moreover, unsuccessfully attempted to better arrange the functionality between PortBuilder and WeavingBuilder; seemingly we have an rather tight coupling here, and also the expectations regarding the processing function seem to be too tight (but that's the reason why it's an prototype...)
2024-10-26 03:03:11 +02:00
#include "lib/format-string.hpp"
Invocation: develop a plan how to integrate a Parameter functor This is one remaining tricky detail to be solved. The underlying difficulty is architectural: - the processing functor will be supplied by the Media-Lib-Plug-in - while a functor to set parameters and automation will be added from another context Yet both have to work together, and both together will determine the effective type of the ''Weaving Pattern'' Thus we'll have to get both functors somehow integrated into the Level-2-Builder, yet we must be able first to pass this builder instance to the Library-Plug-in and then, in a second step, another part of the Lumiera Builder logic will have to add the Parameter wiring. The solution I'm proposing is to exploit the observation that in fact the processing functor is stored as a kind of »Prototype« within the ''Weaving Pattern'' and will be ''copied'' from there for each individual Render Node invocation. The reasons for this is, we want the optimiser to see the full instantiation of the library function and thus get maximum leverage; thus the code doing the actual call must see the functor or lambda to be able to inline it. This leads to the idea to ''separate'' this »prototype« from the `FeedManifold`; the latter thereby becomes mostly agnostic of parameter processing. However, `FeedManifold` must then accept a copy of the parameter values as constructor argument and pass it into its internal storage. This forces yet another reorganisation of the class structure. Basically the storage modules for `FeedManifold` are now prepared within a configuratiton class, which actually helps to simplify the metaprogramming definitions and keeps the enclosing namespace clean.
2024-12-19 04:06:26 +01:00
#include "lib/iter-zip.hpp"
Invocation: work out solution for a precisely fitting allocation Conduct in-depth analysis to handle a secondary, implementation-related (and frankly quite challenging) concern regarding the placement of node and port connectivity data in memory. The intention is for the low-level model to use a custom data structure based on `lib::Several`, allowing for flexible and compact arrangement of the connectivity descriptors within tiled memory blocks, which can then later be discarded in bulk, whenever a segment of the render graph is superseded. Yet since the generated descriptors are heterogeneous and, due to virtual functions, can not be trivially copied, the corresponding placement invocations on the data builder API must not be mixed, but rather given in ordered strikes and preceded by a dimensioning call to pre-reserve a bulk of storage However, doing so directly would jeopardise the open and flexible nature of the node builder API, thereby creating a dangerous coupling between the implementation levels of the node graph and of prospective library wrapper plug-ins in charge of controlling details of the graph layout. The solution devised here entails a functional helper data structure created temporarily within the builder API stack frames; the detailed and local type information provided from within the library plug-in can thereby be embedded into opaque builder functors, allowing to delay the actual data generation up until the final builder step, at which point the complete number and size requirements of connectivity data is known and can be used for dimensioning.
2024-10-20 21:51:34 +02:00
#include "lib/util.hpp"
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
#include <functional>
Invocation: code clean-up and documentation Remove left-overs from the preceding prototypical implementation, which is now obliterated by the change to a flexibly configured `FeedManifold` with structured, typed storage for buffers and for parameter data. The Render Node invocation sequence, as rearranged and reworked for the »Playback Vertical Slice«, now seems reasonably clear and settled. Adding extensive documentation to describe the conventions and structures worked out thus far; moreover, start makeover of old documentation in the !TiddlyWiki to remove concepts obviously obsoleted now...
2024-12-21 23:58:56 +01:00
#include <utility>
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
#include <vector>
Invocation: pass symbolic spec through the node builder ...taking into account the prospecive usage context where the builder expressions will be invoked from within a media-library plug-in, using std::string_view to pass the symbolic information seems like a good fit, because the given spec will typically be assembled from some building blocks, and thus in itself not be literal data.
2024-11-03 22:55:06 +01:00
#include <string>
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
namespace steam {
namespace engine {
Invocation: runtime error checks for auto-wiring Since it would in fact be possible to access and write beyond the configured storage, simply by using the builder API without considering consistency, it seems advisable to use explicit runtime checks here, instead of only assertions, and to throw an exception when violating bounds. Moreover, unsuccessfully attempted to better arrange the functionality between PortBuilder and WeavingBuilder; seemingly we have an rather tight coupling here, and also the expectations regarding the processing function seem to be too tight (but that's the reason why it's an prototype...)
2024-10-26 03:03:11 +02:00
namespace err = lumiera::error;
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
Invocation: pass symbolic spec through the node builder ...taking into account the prospecive usage context where the builder expressions will be invoked from within a media-library plug-in, using std::string_view to pass the symbolic information seems like a good fit, because the given spec will typically be assembled from some building blocks, and thus in itself not be literal data.
2024-11-03 22:55:06 +01:00
using StrView = std::string_view;
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
using std::forward;
Invocation: setup preliminary engine-context * decision how to provide a default service for tests while also allow for configuration of more specific services * as starting point for the prototype: use the `TrackingHeapBlockProvider` (simply because this is the only implementation available and tested)
2024-10-12 04:17:39 +02:00
using lib::Depend;
Invocation: develop a plan how to integrate a Parameter functor This is one remaining tricky detail to be solved. The underlying difficulty is architectural: - the processing functor will be supplied by the Media-Lib-Plug-in - while a functor to set parameters and automation will be added from another context Yet both have to work together, and both together will determine the effective type of the ''Weaving Pattern'' Thus we'll have to get both functors somehow integrated into the Level-2-Builder, yet we must be able first to pass this builder instance to the Library-Plug-in and then, in a second step, another part of the Lumiera Builder logic will have to add the Parameter wiring. The solution I'm proposing is to exploit the observation that in fact the processing functor is stored as a kind of »Prototype« within the ''Weaving Pattern'' and will be ''copied'' from there for each individual Render Node invocation. The reasons for this is, we want the optimiser to see the full instantiation of the library function and thus get maximum leverage; thus the code doing the actual call must see the functor or lambda to be able to inline it. This leads to the idea to ''separate'' this »prototype« from the `FeedManifold`; the latter thereby becomes mostly agnostic of parameter processing. However, `FeedManifold` must then accept a copy of the parameter values as constructor argument and pass it into its internal storage. This forces yet another reorganisation of the class structure. Basically the storage modules for `FeedManifold` are now prepared within a configuratiton class, which actually helps to simplify the metaprogramming definitions and keeps the enclosing namespace clean.
2024-12-19 04:06:26 +01:00
using lib::izip;
Invocation: runtime error checks for auto-wiring Since it would in fact be possible to access and write beyond the configured storage, simply by using the builder API without considering consistency, it seems advisable to use explicit runtime checks here, instead of only assertions, and to throw an exception when violating bounds. Moreover, unsuccessfully attempted to better arrange the functionality between PortBuilder and WeavingBuilder; seemingly we have an rather tight coupling here, and also the expectations regarding the processing function seem to be too tight (but that's the reason why it's an prototype...)
2024-10-26 03:03:11 +02:00
using util::_Fmt;
Invocation: work out solution for a precisely fitting allocation Conduct in-depth analysis to handle a secondary, implementation-related (and frankly quite challenging) concern regarding the placement of node and port connectivity data in memory. The intention is for the low-level model to use a custom data structure based on `lib::Several`, allowing for flexible and compact arrangement of the connectivity descriptors within tiled memory blocks, which can then later be discarded in bulk, whenever a segment of the render graph is superseded. Yet since the generated descriptors are heterogeneous and, due to virtual functions, can not be trivially copied, the corresponding placement invocations on the data builder API must not be mixed, but rather given in ordered strikes and preceded by a dimensioning call to pre-reserve a bulk of storage However, doing so directly would jeopardise the open and flexible nature of the node builder API, thereby creating a dangerous coupling between the implementation levels of the node graph and of prospective library wrapper plug-ins in charge of controlling details of the graph layout. The solution devised here entails a functional helper data structure created temporarily within the builder API stack frames; the detailed and local type information provided from within the library plug-in can thereby be embedded into opaque builder functors, allowing to delay the actual data generation up until the final builder step, at which point the complete number and size requirements of connectivity data is known and can be used for dimensioning.
2024-10-20 21:51:34 +02:00
using util::max;
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
Invocation: pass the actual processing function ...need to pass a binding for the actual processing function in a way that it acts as a ''prototype'' — since the `Feed`, i.e. the ''Invocation Adapter'' must be generated for each invocation anew within the current stack frame (so to avoid spurious heap allocations)
2024-10-11 03:33:05 +02:00
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
template<class POL, class I, class E=I>
using DataBuilder = lib::SeveralBuilder<I,E, POL::template Policy>;
Invocation: switch `WeavingBuilder` to produce the result via λ This change allows to disentangle the usages of `lib::SeveralBuilder`, so that at any time during the build process only a single instance is actively populated, all in one row — and thus the required storage can either be pre-allocated, or dynamically extended and shrinked (when filling elements into the last `SeveralBuilder` currently activated) By packaging into a λ-closure, the building of the actual `Port` implementation objects (≙ `Turnout` instances) is delayed until the very end of the build process, and then unloaded into yet another `lib::Several` in one strike. Temporarily, those building functor objects are „hidden“ in the current stack frame, as a new `NodeBuilder` instance is dropped off with an adapted type parameter (embedding the λ-type produced by the last nested `PortBuilder` invocation, while inheriting from previous ones. However, defining a special constructor to cause this »chaining« poses some challenge (regarding overload resolution). Moreover, since the actual processing function shall be embedded directly (as opposed to wrapping it into a `std::function`), further problems can arise when this function is given as a ''function reference''
2024-10-22 03:20:50 +02:00
template<uint siz>
using SizMark = std::integral_constant<uint,siz>;
Invocation: code clean-up and documentation Remove left-overs from the preceding prototypical implementation, which is now obliterated by the change to a flexibly configured `FeedManifold` with structured, typed storage for buffers and for parameter data. The Render Node invocation sequence, as rearranged and reworked for the »Playback Vertical Slice«, now seems reasonably clear and settled. Adding extensive documentation to describe the conventions and structures worked out thus far; moreover, start makeover of old documentation in the !TiddlyWiki to remove concepts obviously obsoleted now...
2024-12-21 23:58:56 +01:00
Invocation: work out solution for a precisely fitting allocation Conduct in-depth analysis to handle a secondary, implementation-related (and frankly quite challenging) concern regarding the placement of node and port connectivity data in memory. The intention is for the low-level model to use a custom data structure based on `lib::Several`, allowing for flexible and compact arrangement of the connectivity descriptors within tiled memory blocks, which can then later be discarded in bulk, whenever a segment of the render graph is superseded. Yet since the generated descriptors are heterogeneous and, due to virtual functions, can not be trivially copied, the corresponding placement invocations on the data builder API must not be mixed, but rather given in ordered strikes and preceded by a dimensioning call to pre-reserve a bulk of storage However, doing so directly would jeopardise the open and flexible nature of the node builder API, thereby creating a dangerous coupling between the implementation levels of the node graph and of prospective library wrapper plug-ins in charge of controlling details of the graph layout. The solution devised here entails a functional helper data structure created temporarily within the builder API stack frames; the detailed and local type information provided from within the library plug-in can thereby be embedded into opaque builder functors, allowing to delay the actual data generation up until the final builder step, at which point the complete number and size requirements of connectivity data is known and can be used for dimensioning.
2024-10-20 21:51:34 +02:00
/**
* Recursive functional data structure to collect weaving pattern data
* and finally to emplace a Turnout instance into the data storage
* for each port, as specified by preceding builder-API invocations.
* @tparam PAR recursive layering for preceding entries
* @tparam BUILD a builder functor to emplace one Turnout instance,
Invocation: further rearrange and rework `FeedManifold` What I'm about to do amounts to a massive generalisation, which is tricky. Instead of having a fixed array-style layout, we want to accept arbitrary and mixed arguments. Notably, we want to give the ''actual Library Plug-in'' a lot of leeway for binding: - optionally, the library might want to require **Parameters** (which is the reason for this change) - moreover, accepting input-buffers shall now be optional, since many generation functions do not need them - and on top of all this, we want to accept an arbitrary mix of types for each kind. So conceptually we are switching from C-style arrays to tuples with full type safety ''this going to become quite nasty and technical, I'm afraid...''
2024-12-15 18:53:50 +01:00
* thereby opaquely embedding all specific data typing.
Invocation: work out solution for a precisely fitting allocation Conduct in-depth analysis to handle a secondary, implementation-related (and frankly quite challenging) concern regarding the placement of node and port connectivity data in memory. The intention is for the low-level model to use a custom data structure based on `lib::Several`, allowing for flexible and compact arrangement of the connectivity descriptors within tiled memory blocks, which can then later be discarded in bulk, whenever a segment of the render graph is superseded. Yet since the generated descriptors are heterogeneous and, due to virtual functions, can not be trivially copied, the corresponding placement invocations on the data builder API must not be mixed, but rather given in ordered strikes and preceded by a dimensioning call to pre-reserve a bulk of storage However, doing so directly would jeopardise the open and flexible nature of the node builder API, thereby creating a dangerous coupling between the implementation levels of the node graph and of prospective library wrapper plug-ins in charge of controlling details of the graph layout. The solution devised here entails a functional helper data structure created temporarily within the builder API stack frames; the detailed and local type information provided from within the library plug-in can thereby be embedded into opaque builder functors, allowing to delay the actual data generation up until the final builder step, at which point the complete number and size requirements of connectivity data is known and can be used for dimensioning.
2024-10-20 21:51:34 +02:00
* @tparam siz storage in bytes to hold data produced by \a BUILD
*/
template<class PAR, class BUILD, uint siz>
struct PatternData
: PAR
{
BUILD buildEntry;
Invocation: provide functionality to connect lead ports explicitly ...which then also allow to fill in the missing parts for the default 1:1 wiring scheme, which connects each »input slot« of the processing function with the corresponding ''lead node''
2024-10-25 18:13:55 +02:00
uint size() { return 1 + PAR::size(); }
Invocation: work out solution for a precisely fitting allocation Conduct in-depth analysis to handle a secondary, implementation-related (and frankly quite challenging) concern regarding the placement of node and port connectivity data in memory. The intention is for the low-level model to use a custom data structure based on `lib::Several`, allowing for flexible and compact arrangement of the connectivity descriptors within tiled memory blocks, which can then later be discarded in bulk, whenever a segment of the render graph is superseded. Yet since the generated descriptors are heterogeneous and, due to virtual functions, can not be trivially copied, the corresponding placement invocations on the data builder API must not be mixed, but rather given in ordered strikes and preceded by a dimensioning call to pre-reserve a bulk of storage However, doing so directly would jeopardise the open and flexible nature of the node builder API, thereby creating a dangerous coupling between the implementation levels of the node graph and of prospective library wrapper plug-ins in charge of controlling details of the graph layout. The solution devised here entails a functional helper data structure created temporarily within the builder API stack frames; the detailed and local type information provided from within the library plug-in can thereby be embedded into opaque builder functors, allowing to delay the actual data generation up until the final builder step, at which point the complete number and size requirements of connectivity data is known and can be used for dimensioning.
2024-10-20 21:51:34 +02:00
template<class DAB>
void
collectEntries (DAB& dataBuilder, uint cntElm =0, uint maxSiz =0)
{
PAR::collectEntries (dataBuilder, cntElm+1, max (siz,maxSiz));
buildEntry (dataBuilder);
}
Invocation: introduce pattern data holder into `NodeBuilder` - add an unspecified data holder type into the NodeBuilder - establish ability to cross-build a `NodeBuilder` with adapted data holder
2024-10-21 03:40:19 +02:00
PatternData(PAR&& predecessor, BUILD&& entryBuilder)
: PAR{move (predecessor)}
, buildEntry{move (entryBuilder)}
{ }
Invocation: work out solution for a precisely fitting allocation Conduct in-depth analysis to handle a secondary, implementation-related (and frankly quite challenging) concern regarding the placement of node and port connectivity data in memory. The intention is for the low-level model to use a custom data structure based on `lib::Several`, allowing for flexible and compact arrangement of the connectivity descriptors within tiled memory blocks, which can then later be discarded in bulk, whenever a segment of the render graph is superseded. Yet since the generated descriptors are heterogeneous and, due to virtual functions, can not be trivially copied, the corresponding placement invocations on the data builder API must not be mixed, but rather given in ordered strikes and preceded by a dimensioning call to pre-reserve a bulk of storage However, doing so directly would jeopardise the open and flexible nature of the node builder API, thereby creating a dangerous coupling between the implementation levels of the node graph and of prospective library wrapper plug-ins in charge of controlling details of the graph layout. The solution devised here entails a functional helper data structure created temporarily within the builder API stack frames; the detailed and local type information provided from within the library plug-in can thereby be embedded into opaque builder functors, allowing to delay the actual data generation up until the final builder step, at which point the complete number and size requirements of connectivity data is known and can be used for dimensioning.
2024-10-20 21:51:34 +02:00
};
/**
* Data recursion end: prime the port data storage
* by reserving appropriate storage to hold all known Turnout elements.
*/
Invocation: introduce pattern data holder into `NodeBuilder` - add an unspecified data holder type into the NodeBuilder - establish ability to cross-build a `NodeBuilder` with adapted data holder
2024-10-21 03:40:19 +02:00
struct PatternDataAnchor
Invocation: work out solution for a precisely fitting allocation Conduct in-depth analysis to handle a secondary, implementation-related (and frankly quite challenging) concern regarding the placement of node and port connectivity data in memory. The intention is for the low-level model to use a custom data structure based on `lib::Several`, allowing for flexible and compact arrangement of the connectivity descriptors within tiled memory blocks, which can then later be discarded in bulk, whenever a segment of the render graph is superseded. Yet since the generated descriptors are heterogeneous and, due to virtual functions, can not be trivially copied, the corresponding placement invocations on the data builder API must not be mixed, but rather given in ordered strikes and preceded by a dimensioning call to pre-reserve a bulk of storage However, doing so directly would jeopardise the open and flexible nature of the node builder API, thereby creating a dangerous coupling between the implementation levels of the node graph and of prospective library wrapper plug-ins in charge of controlling details of the graph layout. The solution devised here entails a functional helper data structure created temporarily within the builder API stack frames; the detailed and local type information provided from within the library plug-in can thereby be embedded into opaque builder functors, allowing to delay the actual data generation up until the final builder step, at which point the complete number and size requirements of connectivity data is known and can be used for dimensioning.
2024-10-20 21:51:34 +02:00
{
Invocation: provide functionality to connect lead ports explicitly ...which then also allow to fill in the missing parts for the default 1:1 wiring scheme, which connects each »input slot« of the processing function with the corresponding ''lead node''
2024-10-25 18:13:55 +02:00
uint size() { return 0; }
Invocation: work out solution for a precisely fitting allocation Conduct in-depth analysis to handle a secondary, implementation-related (and frankly quite challenging) concern regarding the placement of node and port connectivity data in memory. The intention is for the low-level model to use a custom data structure based on `lib::Several`, allowing for flexible and compact arrangement of the connectivity descriptors within tiled memory blocks, which can then later be discarded in bulk, whenever a segment of the render graph is superseded. Yet since the generated descriptors are heterogeneous and, due to virtual functions, can not be trivially copied, the corresponding placement invocations on the data builder API must not be mixed, but rather given in ordered strikes and preceded by a dimensioning call to pre-reserve a bulk of storage However, doing so directly would jeopardise the open and flexible nature of the node builder API, thereby creating a dangerous coupling between the implementation levels of the node graph and of prospective library wrapper plug-ins in charge of controlling details of the graph layout. The solution devised here entails a functional helper data structure created temporarily within the builder API stack frames; the detailed and local type information provided from within the library plug-in can thereby be embedded into opaque builder functors, allowing to delay the actual data generation up until the final builder step, at which point the complete number and size requirements of connectivity data is known and can be used for dimensioning.
2024-10-20 21:51:34 +02:00
template<class DAB>
void
collectEntries (DAB& dataBuilder, uint cntElm, uint maxSiz)
{
dataBuilder.reserve (cntElm, maxSiz);
}
};
Invocation: introduce pattern data holder into `NodeBuilder` - add an unspecified data holder type into the NodeBuilder - establish ability to cross-build a `NodeBuilder` with adapted data holder
2024-10-21 03:40:19 +02:00
Invocation: solve passing of the function definition - the chaining constructor is picked reliably when the slicing is done by a direct static_cast - the function definition can be passed reliably in all cases after it has been ''decayed,'' which is done here simply by taking it by-value. This is adequate, since the function definition must be copied / inlined for each invocation. With these fixes, the simplest test case now for the first time **runs through without failure**
2024-10-22 05:59:00 +02:00
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
Invocation: solve passing of the function definition - the chaining constructor is picked reliably when the slicing is done by a direct static_cast - the function definition can be passed reliably in all cases after it has been ''decayed,'' which is done here simply by taking it by-value. This is adequate, since the function definition must be copied / inlined for each invocation. With these fixes, the simplest test case now for the first time **runs through without failure**
2024-10-22 05:59:00 +02:00
Invocation: establish a concept how to handle parameter data This was an extended digression into architecture planning, which became necessary in order to suitably map out the role for the `TurnoutSystem` — which can now be defined as ''mediator'' to connect and forward control- and parameter data while specific render invocation proceeds through the render node network.
2024-12-05 23:58:22 +01:00
/**
* A low-level Builder to prepare and adapt for a specific node invocation.
* In this context, »weaving« refers to the way parameters and results of an
* processing function are provided, combined and forwarded within the setup
* for an actual Render Node invocation. When the invocation happens, a kind
* of preconfigured _blue print_ or invocation plan is executed; the purpose
* of the build at »Level-2« (≙the purpose of this code) is to preconfigure
* this invocation scheme. Using a _low level builder_ as controlled by the
* actual NodeBuilder and PortBuilder allows to introduce extension points
* and helps to abstract away internal technical details of the invocation.
* @tparam POL allocation and context configuration policy
* @tparam FUN function or invocation adapter to invoke
*/
Invocation: reconsider how layout of the `FeedManifold` is established This is a first step towards the goal to introduce a ''parameter tuple'' into the `FeedManifold`. Doing so invalidates some of the previously taken decisions regarding the `FeedManifold`; at that time I was still under the impression of the old design from 2012, which called for a ''Buffer Table''. Now we are forced to allow for more leeway in the function definition; even more so, since the limitation to one single input and output Buffer type can be deemed unrealistic anyway. So why sticking to an array at all? ''Buffers could also be a tuple...'' Seemingly another reason why I used an array was the idea to somehow limit the number of template instances, by grouping them into a few number of array sizes, like 1,2,5 and 10. This idea falls short, since in reality it can not be avoided to have the processing function on the type signature anyway. Thus, the only point where the number of templates could be limited lies in the library plug-in, where this »processing function« is actually defined as an adapter.
2024-12-14 19:09:22 +01:00
template<class POL, class FUN>
Invocation: integrate WeavingBuilder into PortBuilder ...seems that the former is well suited to serve as detail builder used internally by the latter to provide a simplified standard adaptation for a given processing function. The integration can be achieved to layer a specialised detail builder class on top, which can be entered only by specifying the concrete function or lambda to wrap for the processing; the further builder-API-functions to control the wiring in detail become thus only accessible after the function type is known; this allows to place the detail builder as member into the enclosing port builder and thus to allocate everything within the current stack frame invoking the builder chain.
2024-10-11 02:45:51 +02:00
struct WeavingBuilder
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
: util::MoveOnly
{
Invocation: switch `WeavingPattern` and Level-1 builder to the reworked `FeedManifold` After the complete makeover of the `FeedManifold` structure, which among other entails a switch from ''buffer arrays'' to tuples and the ''introduction of a parameter tuple'', this changeset now switches the „downstream code“ of the builder and node invocation, relying on an largely identical invocation API. The partially finished NodeLink_test now **runs as before** but on top of a drastically more flexible and open infrastructure. Quite a feat.
2024-12-01 05:24:12 +01:00
using Prototype = typename FeedManifold<FUN>::Prototype;
using WeavingPattern = MediaWeavingPattern<Prototype>;
using TurnoutWeaving = Turnout<WeavingPattern>;
Invocation: switch `WeavingBuilder` to produce the result via λ This change allows to disentangle the usages of `lib::SeveralBuilder`, so that at any time during the build process only a single instance is actively populated, all in one row — and thus the required storage can either be pre-allocated, or dynamically extended and shrinked (when filling elements into the last `SeveralBuilder` currently activated) By packaging into a λ-closure, the building of the actual `Port` implementation objects (≙ `Turnout` instances) is delayed until the very end of the build process, and then unloaded into yet another `lib::Several` in one strike. Temporarily, those building functor objects are „hidden“ in the current stack frame, as a new `NodeBuilder` instance is dropped off with an adapted type parameter (embedding the λ-type produced by the last nested `PortBuilder` invocation, while inheriting from previous ones. However, defining a special constructor to cause this »chaining« poses some challenge (regarding overload resolution). Moreover, since the actual processing function shall be embedded directly (as opposed to wrapping it into a `std::function`), further problems can arise when this function is given as a ''function reference''
2024-10-22 03:20:50 +02:00
static constexpr SizMark<sizeof(TurnoutWeaving)> sizMark{};
Invocation: switch `WeavingPattern` and Level-1 builder to the reworked `FeedManifold` After the complete makeover of the `FeedManifold` structure, which among other entails a switch from ''buffer arrays'' to tuples and the ''introduction of a parameter tuple'', this changeset now switches the „downstream code“ of the builder and node invocation, relying on an largely identical invocation API. The partially finished NodeLink_test now **runs as before** but on top of a drastically more flexible and open infrastructure. Quite a feat.
2024-12-01 05:24:12 +01:00
static constexpr uint FAN_I = Prototype::FAN_I;
static constexpr uint FAN_O = Prototype::FAN_O;
Invocation: runtime error checks for auto-wiring Since it would in fact be possible to access and write beyond the configured storage, simply by using the builder API without considering consistency, it seems advisable to use explicit runtime checks here, instead of only assertions, and to throw an exception when violating bounds. Moreover, unsuccessfully attempted to better arrange the functionality between PortBuilder and WeavingBuilder; seemingly we have an rather tight coupling here, and also the expectations regarding the processing function seem to be too tight (but that's the reason why it's an prototype...)
2024-10-26 03:03:11 +02:00
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
using TypeMarker = std::function<BuffDescr(BufferProvider&)>;
using ProviderRef = std::reference_wrapper<BufferProvider>;
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
DataBuilder<POL, PortRef> leadPorts;
std::vector<TypeMarker> buffTypes;
std::vector<ProviderRef> providers;
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
Invocation: investigate ways to configure the output-info ...still not convinced that this is a good design, since it seems to subvert the general design to treat one special case. However, I can't see a good way to address this special case directly
2024-07-30 23:44:55 +02:00
uint resultSlot{0};
Invocation: setup preliminary engine-context * decision how to provide a default service for tests while also allow for configuration of more specific services * as starting point for the prototype: use the `TrackingHeapBlockProvider` (simply because this is the only implementation available and tested)
2024-10-12 04:17:39 +02:00
Depend<EngineCtx> ctx;
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
Invocation: pass symbolic spec through the node builder ...taking into account the prospecive usage context where the builder expressions will be invoked from within a media-library plug-in, using std::string_view to pass the symbolic information seems like a good fit, because the given spec will typically be assembled from some building blocks, and thus in itself not be literal data.
2024-11-03 22:55:06 +01:00
StrView nodeSymb_;
StrView portSpec_;
Invocation: pass the actual processing function ...need to pass a binding for the actual processing function in a way that it acts as a ''prototype'' — since the `Feed`, i.e. the ''Invocation Adapter'' must be generated for each invocation anew within the current stack frame (so to avoid spurious heap allocations)
2024-10-11 03:33:05 +02:00
FUN fun_;
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
template<typename...INIT>
Invocation: pass symbolic spec through the node builder ...taking into account the prospecive usage context where the builder expressions will be invoked from within a media-library plug-in, using std::string_view to pass the symbolic information seems like a good fit, because the given spec will typically be assembled from some building blocks, and thus in itself not be literal data.
2024-11-03 22:55:06 +01:00
WeavingBuilder(FUN&& init, StrView nodeSymb, StrView portSpec, INIT&& ...alloInit)
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
: leadPorts{forward<INIT> (alloInit)...}
Invocation: switch `WeavingPattern` and Level-1 builder to the reworked `FeedManifold` After the complete makeover of the `FeedManifold` structure, which among other entails a switch from ''buffer arrays'' to tuples and the ''introduction of a parameter tuple'', this changeset now switches the „downstream code“ of the builder and node invocation, relying on an largely identical invocation API. The partially finished NodeLink_test now **runs as before** but on top of a drastically more flexible and open infrastructure. Quite a feat.
2024-12-01 05:24:12 +01:00
, buffTypes{fillDefaultBufferTypes()}
Invocation: pass symbolic spec through the node builder ...taking into account the prospecive usage context where the builder expressions will be invoked from within a media-library plug-in, using std::string_view to pass the symbolic information seems like a good fit, because the given spec will typically be assembled from some building blocks, and thus in itself not be literal data.
2024-11-03 22:55:06 +01:00
, nodeSymb_{nodeSymb}
, portSpec_{portSpec}
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
, fun_{move(init)}
Invocation: pass the actual processing function ...need to pass a binding for the actual processing function in a way that it acts as a ''prototype'' — since the `Feed`, i.e. the ''Invocation Adapter'' must be generated for each invocation anew within the current stack frame (so to avoid spurious heap allocations)
2024-10-11 03:33:05 +02:00
{ }
Invocation: provide functionality to connect lead ports explicitly ...which then also allow to fill in the missing parts for the default 1:1 wiring scheme, which connects each »input slot« of the processing function with the corresponding ''lead node''
2024-10-25 18:13:55 +02:00
WeavingBuilder&&
attachToLeadPort (ProcNode& lead, uint portNr)
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
{
Invocation: runtime error checks for auto-wiring Since it would in fact be possible to access and write beyond the configured storage, simply by using the builder API without considering consistency, it seems advisable to use explicit runtime checks here, instead of only assertions, and to throw an exception when violating bounds. Moreover, unsuccessfully attempted to better arrange the functionality between PortBuilder and WeavingBuilder; seemingly we have an rather tight coupling here, and also the expectations regarding the processing function seem to be too tight (but that's the reason why it's an prototype...)
2024-10-26 03:03:11 +02:00
if (leadPorts.size() >= FAN_I)
throw err::Logic{_Fmt{"Builder: attempt to add further input, "
"but all %d »input slots« of the processing function are already connected."}
% FAN_I
};
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
PortRef portRef{lead.getPort (portNr)};
leadPorts.append (portRef);
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
return move(*this);
}
Invocation: draft how the 1:1-fallback wiring could work ...and as expected, this turns up quite some inconsistencies, especially regarding usage of the »buffer types«. Basically, the `PortBuilder` is responsible for the high-level functionality and thus must ensure the nested `WiringBuilder` is addressed and parameterised properly to connect all »slots« of the processing function. - can use a helper function in the WiringBuilder to fill in connections - but the actual buffer types passed over these connectinos are totally unchecked at that level, and can not see yet how this danger can be mitigated one level above, where the PortBuilder is used. - it is still unclear what a »buffer type« actually means; it could be the pointer type, but it could also imply a class or struct type to be emplaced into the buffer, which is a special extension to the `BufferProvider` protocol, yet seems to be used here rather to transport specific data types required by the actual media handling library (e.g. FFmpeg)
2024-10-14 04:07:47 +02:00
Invocation: provide functionality to connect lead ports explicitly ...which then also allow to fill in the missing parts for the default 1:1 wiring scheme, which connects each »input slot« of the processing function with the corresponding ''lead node''
2024-10-25 18:13:55 +02:00
WeavingBuilder&&
connectRemainingInputs (DataBuilder<POL, ProcNodeRef>& knownLeads, uint defaultPort)
{
REQUIRE (leadPorts.size() <= FAN_I);
uint cnt = FAN_I - leadPorts.size();
Invocation: runtime error checks for auto-wiring Since it would in fact be possible to access and write beyond the configured storage, simply by using the builder API without considering consistency, it seems advisable to use explicit runtime checks here, instead of only assertions, and to throw an exception when violating bounds. Moreover, unsuccessfully attempted to better arrange the functionality between PortBuilder and WeavingBuilder; seemingly we have an rather tight coupling here, and also the expectations regarding the processing function seem to be too tight (but that's the reason why it's an prototype...)
2024-10-26 03:03:11 +02:00
if (FAN_I > knownLeads.size())
throw err::Logic{_Fmt{"Builder: attempt to auto-connect %d further »input slots«, "
"but this ProcNode has only %d predecessor nodes, while the "
"given processing function expects %d inputs."}
% cnt % knownLeads.size() % FAN_I
};
Invocation: provide functionality to connect lead ports explicitly ...which then also allow to fill in the missing parts for the default 1:1 wiring scheme, which connects each »input slot« of the processing function with the corresponding ''lead node''
2024-10-25 18:13:55 +02:00
while (cnt--)
attachToLeadPort (knownLeads[leadPorts.size()], defaultPort);
return move(*this);
}
WeavingBuilder&&
selectResultSlot (uint idx)
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
{
Invocation: investigate ways to configure the output-info ...still not convinced that this is a good design, since it seems to subvert the general design to treat one special case. However, I can't see a good way to address this special case directly
2024-07-30 23:44:55 +02:00
this->resultSlot = idx;
return move(*this);
}
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
auto
build()
{
Invocation: switch `WeavingBuilder` to produce the result via λ This change allows to disentangle the usages of `lib::SeveralBuilder`, so that at any time during the build process only a single instance is actively populated, all in one row — and thus the required storage can either be pre-allocated, or dynamically extended and shrinked (when filling elements into the last `SeveralBuilder` currently activated) By packaging into a λ-closure, the building of the actual `Port` implementation objects (≙ `Turnout` instances) is delayed until the very end of the build process, and then unloaded into yet another `lib::Several` in one strike. Temporarily, those building functor objects are „hidden“ in the current stack frame, as a new `NodeBuilder` instance is dropped off with an adapted type parameter (embedding the λ-type produced by the last nested `PortBuilder` invocation, while inheriting from previous ones. However, defining a special constructor to cause this »chaining« poses some challenge (regarding overload resolution). Moreover, since the actual processing function shall be embedded directly (as opposed to wrapping it into a `std::function`), further problems can arise when this function is given as a ''function reference''
2024-10-22 03:20:50 +02:00
// discard excess storage prior to allocating the output types sequence
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
leadPorts.shrinkFit();
Invocation: switch `WeavingBuilder` to produce the result via λ This change allows to disentangle the usages of `lib::SeveralBuilder`, so that at any time during the build process only a single instance is actively populated, all in one row — and thus the required storage can either be pre-allocated, or dynamically extended and shrinked (when filling elements into the last `SeveralBuilder` currently activated) By packaging into a λ-closure, the building of the actual `Port` implementation objects (≙ `Turnout` instances) is delayed until the very end of the build process, and then unloaded into yet another `lib::Several` in one strike. Temporarily, those building functor objects are „hidden“ in the current stack frame, as a new `NodeBuilder` instance is dropped off with an adapted type parameter (embedding the λ-type produced by the last nested `PortBuilder` invocation, while inheriting from previous ones. However, defining a special constructor to cause this »chaining« poses some challenge (regarding overload resolution). Moreover, since the actual processing function shall be embedded directly (as opposed to wrapping it into a `std::function`), further problems can arise when this function is given as a ''function reference''
2024-10-22 03:20:50 +02:00
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
maybeFillDefaultProviders (buffTypes.size());
Invocation: draft how the 1:1-fallback wiring could work ...and as expected, this turns up quite some inconsistencies, especially regarding usage of the »buffer types«. Basically, the `PortBuilder` is responsible for the high-level functionality and thus must ensure the nested `WiringBuilder` is addressed and parameterised properly to connect all »slots« of the processing function. - can use a helper function in the WiringBuilder to fill in connections - but the actual buffer types passed over these connectinos are totally unchecked at that level, and can not see yet how this danger can be mitigated one level above, where the PortBuilder is used. - it is still unclear what a »buffer type« actually means; it could be the pointer type, but it could also imply a class or struct type to be emplaced into the buffer, which is a special extension to the `BufferProvider` protocol, yet seems to be used here rather to transport specific data types required by the actual media handling library (e.g. FFmpeg)
2024-10-14 04:07:47 +02:00
REQUIRE (providers.size() == buffTypes.size());
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
auto outTypes = DataBuilder<POL, BuffDescr>{leadPorts.policyConnect()}
Invocation: switch `WeavingBuilder` to produce the result via λ This change allows to disentangle the usages of `lib::SeveralBuilder`, so that at any time during the build process only a single instance is actively populated, all in one row — and thus the required storage can either be pre-allocated, or dynamically extended and shrinked (when filling elements into the last `SeveralBuilder` currently activated) By packaging into a λ-closure, the building of the actual `Port` implementation objects (≙ `Turnout` instances) is delayed until the very end of the build process, and then unloaded into yet another `lib::Several` in one strike. Temporarily, those building functor objects are „hidden“ in the current stack frame, as a new `NodeBuilder` instance is dropped off with an adapted type parameter (embedding the λ-type produced by the last nested `PortBuilder` invocation, while inheriting from previous ones. However, defining a special constructor to cause this »chaining« poses some challenge (regarding overload resolution). Moreover, since the actual processing function shall be embedded directly (as opposed to wrapping it into a `std::function`), further problems can arise when this function is given as a ''function reference''
2024-10-22 03:20:50 +02:00
.reserve (buffTypes.size());
Invocation: develop a plan how to integrate a Parameter functor This is one remaining tricky detail to be solved. The underlying difficulty is architectural: - the processing functor will be supplied by the Media-Lib-Plug-in - while a functor to set parameters and automation will be added from another context Yet both have to work together, and both together will determine the effective type of the ''Weaving Pattern'' Thus we'll have to get both functors somehow integrated into the Level-2-Builder, yet we must be able first to pass this builder instance to the Library-Plug-in and then, in a second step, another part of the Lumiera Builder logic will have to add the Parameter wiring. The solution I'm proposing is to exploit the observation that in fact the processing functor is stored as a kind of »Prototype« within the ''Weaving Pattern'' and will be ''copied'' from there for each individual Render Node invocation. The reasons for this is, we want the optimiser to see the full instantiation of the library function and thus get maximum leverage; thus the code doing the actual call must see the functor or lambda to be able to inline it. This leads to the idea to ''separate'' this »prototype« from the `FeedManifold`; the latter thereby becomes mostly agnostic of parameter processing. However, `FeedManifold` must then accept a copy of the parameter values as constructor argument and pass it into its internal storage. This forces yet another reorganisation of the class structure. Basically the storage modules for `FeedManifold` are now prepared within a configuratiton class, which actually helps to simplify the metaprogramming definitions and keeps the enclosing namespace clean.
2024-12-19 04:06:26 +01:00
for (auto& [i,typeConstructor] : izip(buffTypes))
Invocation: draft how the 1:1-fallback wiring could work ...and as expected, this turns up quite some inconsistencies, especially regarding usage of the »buffer types«. Basically, the `PortBuilder` is responsible for the high-level functionality and thus must ensure the nested `WiringBuilder` is addressed and parameterised properly to connect all »slots« of the processing function. - can use a helper function in the WiringBuilder to fill in connections - but the actual buffer types passed over these connectinos are totally unchecked at that level, and can not see yet how this danger can be mitigated one level above, where the PortBuilder is used. - it is still unclear what a »buffer type« actually means; it could be the pointer type, but it could also imply a class or struct type to be emplaced into the buffer, which is a special extension to the `BufferProvider` protocol, yet seems to be used here rather to transport specific data types required by the actual media handling library (e.g. FFmpeg)
2024-10-14 04:07:47 +02:00
outTypes.append (
Invocation: develop a plan how to integrate a Parameter functor This is one remaining tricky detail to be solved. The underlying difficulty is architectural: - the processing functor will be supplied by the Media-Lib-Plug-in - while a functor to set parameters and automation will be added from another context Yet both have to work together, and both together will determine the effective type of the ''Weaving Pattern'' Thus we'll have to get both functors somehow integrated into the Level-2-Builder, yet we must be able first to pass this builder instance to the Library-Plug-in and then, in a second step, another part of the Lumiera Builder logic will have to add the Parameter wiring. The solution I'm proposing is to exploit the observation that in fact the processing functor is stored as a kind of »Prototype« within the ''Weaving Pattern'' and will be ''copied'' from there for each individual Render Node invocation. The reasons for this is, we want the optimiser to see the full instantiation of the library function and thus get maximum leverage; thus the code doing the actual call must see the functor or lambda to be able to inline it. This leads to the idea to ''separate'' this »prototype« from the `FeedManifold`; the latter thereby becomes mostly agnostic of parameter processing. However, `FeedManifold` must then accept a copy of the parameter values as constructor argument and pass it into its internal storage. This forces yet another reorganisation of the class structure. Basically the storage modules for `FeedManifold` are now prepared within a configuratiton class, which actually helps to simplify the metaprogramming definitions and keeps the enclosing namespace clean.
2024-12-19 04:06:26 +01:00
typeConstructor (providers[i]));
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
Invocation: switch `WeavingPattern` and Level-1 builder to the reworked `FeedManifold` After the complete makeover of the `FeedManifold` structure, which among other entails a switch from ''buffer arrays'' to tuples and the ''introduction of a parameter tuple'', this changeset now switches the „downstream code“ of the builder and node invocation, relying on an largely identical invocation API. The partially finished NodeLink_test now **runs as before** but on top of a drastically more flexible and open infrastructure. Quite a feat.
2024-12-01 05:24:12 +01:00
ENSURE (leadPorts.size() == FAN_I);
ENSURE (outTypes.size() == FAN_O);
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
Invocation: switch `WeavingBuilder` to produce the result via λ This change allows to disentangle the usages of `lib::SeveralBuilder`, so that at any time during the build process only a single instance is actively populated, all in one row — and thus the required storage can either be pre-allocated, or dynamically extended and shrinked (when filling elements into the last `SeveralBuilder` currently activated) By packaging into a λ-closure, the building of the actual `Port` implementation objects (≙ `Turnout` instances) is delayed until the very end of the build process, and then unloaded into yet another `lib::Several` in one strike. Temporarily, those building functor objects are „hidden“ in the current stack frame, as a new `NodeBuilder` instance is dropped off with an adapted type parameter (embedding the λ-type produced by the last nested `PortBuilder` invocation, while inheriting from previous ones. However, defining a special constructor to cause this »chaining« poses some challenge (regarding overload resolution). Moreover, since the actual processing function shall be embedded directly (as opposed to wrapping it into a `std::function`), further problems can arise when this function is given as a ''function reference''
2024-10-22 03:20:50 +02:00
using PortDataBuilder = DataBuilder<POL, Port>;
// provide a free-standing functor to build a suitable Port impl (≙Turnout)
Invocation: reconsider data access and allocator usage from Builder The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
2024-10-23 16:27:09 +02:00
return [leads = move(leadPorts.build())
Invocation: switch `WeavingBuilder` to produce the result via λ This change allows to disentangle the usages of `lib::SeveralBuilder`, so that at any time during the build process only a single instance is actively populated, all in one row — and thus the required storage can either be pre-allocated, or dynamically extended and shrinked (when filling elements into the last `SeveralBuilder` currently activated) By packaging into a λ-closure, the building of the actual `Port` implementation objects (≙ `Turnout` instances) is delayed until the very end of the build process, and then unloaded into yet another `lib::Several` in one strike. Temporarily, those building functor objects are „hidden“ in the current stack frame, as a new `NodeBuilder` instance is dropped off with an adapted type parameter (embedding the λ-type produced by the last nested `PortBuilder` invocation, while inheriting from previous ones. However, defining a special constructor to cause this »chaining« poses some challenge (regarding overload resolution). Moreover, since the actual processing function shall be embedded directly (as opposed to wrapping it into a `std::function`), further problems can arise when this function is given as a ''function reference''
2024-10-22 03:20:50 +02:00
,types = move(outTypes.build())
,procFun = move(fun_)
,resultIdx = resultSlot
Invocation: pass symbolic spec through the node builder ...taking into account the prospecive usage context where the builder expressions will be invoked from within a media-library plug-in, using std::string_view to pass the symbolic information seems like a good fit, because the given spec will typically be assembled from some building blocks, and thus in itself not be literal data.
2024-11-03 22:55:06 +01:00
,procID = ProcID::describe (nodeSymb_,portSpec_)
Invocation: switch `WeavingBuilder` to produce the result via λ This change allows to disentangle the usages of `lib::SeveralBuilder`, so that at any time during the build process only a single instance is actively populated, all in one row — and thus the required storage can either be pre-allocated, or dynamically extended and shrinked (when filling elements into the last `SeveralBuilder` currently activated) By packaging into a λ-closure, the building of the actual `Port` implementation objects (≙ `Turnout` instances) is delayed until the very end of the build process, and then unloaded into yet another `lib::Several` in one strike. Temporarily, those building functor objects are „hidden“ in the current stack frame, as a new `NodeBuilder` instance is dropped off with an adapted type parameter (embedding the λ-type produced by the last nested `PortBuilder` invocation, while inheriting from previous ones. However, defining a special constructor to cause this »chaining« poses some challenge (regarding overload resolution). Moreover, since the actual processing function shall be embedded directly (as opposed to wrapping it into a `std::function`), further problems can arise when this function is given as a ''function reference''
2024-10-22 03:20:50 +02:00
]
(PortDataBuilder& portData) mutable -> void
{
Invocation: pass symbolic spec through the node builder ...taking into account the prospecive usage context where the builder expressions will be invoked from within a media-library plug-in, using std::string_view to pass the symbolic information seems like a good fit, because the given spec will typically be assembled from some building blocks, and thus in itself not be literal data.
2024-11-03 22:55:06 +01:00
portData.template emplace<TurnoutWeaving> (procID
Invocation: consider how to establish a stable cache key Building a precise Frame Cache is a tough job, and is doomed to fail when attempting to tie cache invalidation to state changes. The only viable path is to create a system of systematic tagging of processing steps, and use this as foundation for chained hash values, linked in accordance to the actual processing structure. This is complicated by the secondary concern of maintaining memory efficacy for the render node model, which can be expected to grow to massive scale. And even while this invocation can not be fully devised right now, an attempt can be made to build a foundation that is not outright wasteful, by detaching the logical information from the specific weaving pattern used for implementation, and by minimising the representation in memory and computing the compound information on-demand....
2024-11-02 23:54:41 +01:00
,move(leads)
Invocation: switch `WeavingBuilder` to produce the result via λ This change allows to disentangle the usages of `lib::SeveralBuilder`, so that at any time during the build process only a single instance is actively populated, all in one row — and thus the required storage can either be pre-allocated, or dynamically extended and shrinked (when filling elements into the last `SeveralBuilder` currently activated) By packaging into a λ-closure, the building of the actual `Port` implementation objects (≙ `Turnout` instances) is delayed until the very end of the build process, and then unloaded into yet another `lib::Several` in one strike. Temporarily, those building functor objects are „hidden“ in the current stack frame, as a new `NodeBuilder` instance is dropped off with an adapted type parameter (embedding the λ-type produced by the last nested `PortBuilder` invocation, while inheriting from previous ones. However, defining a special constructor to cause this »chaining« poses some challenge (regarding overload resolution). Moreover, since the actual processing function shall be embedded directly (as opposed to wrapping it into a `std::function`), further problems can arise when this function is given as a ''function reference''
2024-10-22 03:20:50 +02:00
,move(types)
,resultIdx
,move(procFun)
);
};
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
}
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
Invocation: code clean-up and documentation Remove left-overs from the preceding prototypical implementation, which is now obliterated by the change to a flexibly configured `FeedManifold` with structured, typed storage for buffers and for parameter data. The Render Node invocation sequence, as rearranged and reworked for the »Playback Vertical Slice«, now seems reasonably clear and settled. Adding extensive documentation to describe the conventions and structures worked out thus far; moreover, start makeover of old documentation in the !TiddlyWiki to remove concepts obviously obsoleted now...
2024-12-21 23:58:56 +01:00
private: /* ====== WeavingBuilder implementation details ====== */
void
maybeFillDefaultProviders (size_t maxSlots)
{
for (uint i=providers.size(); i < maxSlots; ++i)
providers.emplace_back (ctx().mem);
}
/**
* @internal configuration builder for buffer descriptors
* @tparam BU target type of the buffer (without pointer)
* The FeedPrototype can generate for the given \a FUN a
* type sequence of output buffer types, which are used
* to instantiate this template and then later to work
* on specific output buffer slots.
*/
template<typename BU>
struct BufferDescriptor
{
/**
* Setup the constructor function for the default BufferDescriptors.
* @return a functor that can be applied to the actual BufferProviders
* at the point when everything for this port is configured.
*/
TypeMarker
makeBufferDescriptor() const
{
return [](BufferProvider& provider)
{ return provider.getDescriptor<BU>(); };
}
};
using OutTypesDescriptors = typename Prototype::template OutTypesApply<BufferDescriptor>;
using OutDescriptorTup = lib::meta::Tuple<OutTypesDescriptors>;
/** A tuple of BufferDescriptor instances for all output buffer types */
static constexpr OutDescriptorTup outDescriptors{};
/** @internal pre-initialise the buffTypes vector with a default configuration.
* @remarks In the _terminal step,_ the buffTypes will be transformed into a
* sequence of BufferDescriptor entries, which can later be used
* by the node invocation to prepare a set of output buffers.
* - each slot holds a function<BufferDescripter(BufferProvider&)>
* - these can be used to configure specific setup for some buffers
* - the default BufferDescriptor will just default-construct the
* designated «output slot» of the media processing-function.
*/
static auto
fillDefaultBufferTypes()
{
std::vector<TypeMarker> defaultBufferTypes;
defaultBufferTypes.reserve (std::tuple_size_v<OutDescriptorTup>);
lib::meta::forEach(outDescriptors
,[&](auto& desc)
{
defaultBufferTypes.emplace_back(
desc.makeBufferDescriptor());
});
return defaultBufferTypes;
}
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
};
}}// namespace steam::engine
#endif /*STEAM_ENGINE_WEAVING_PATTERN_BUILDER_H*/
Reference in a new issue Copy permalink