ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/src/steam/engine/feed-manifold-obsolete.hpp

187 lines
6 KiB
C++
Raw Normal View History

Invocation: Identify parts relevant for a node builder The immediate next step is to build some render nodes directly in a test setting, without using any kind of ''node factory.'' Getting ahead with this task requires to identify the constituents to be represented on the first code layer for the reworked code (here ''first layer'' means any part that are ''not'' supplied by generic, templated building blocks). Notably we need to build a descriptor for the `FeedManifold` — which in turn implies we have to decide on some fundamental aspects of handling buffers in the render process. To allow rework of the `ProcNode` connectivity, a lot of presumably obsoleted draft code from 2011 has to be detached, to be able to keep it in-tree for further reference (until the rework and refactoring is settled).
2024-06-24 23:49:55 +02:00
/*
FEED-MANIFOLD.hpp - data feed connection system for render nodes
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)
2008, Hermann Vosseler <Ichthyostega@web.de>
2023, Hermann Vosseler <Ichthyostega@web.de>
  **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: Identify parts relevant for a node builder The immediate next step is to build some render nodes directly in a test setting, without using any kind of ''node factory.'' Getting ahead with this task requires to identify the constituents to be represented on the first code layer for the reworked code (here ''first layer'' means any part that are ''not'' supplied by generic, templated building blocks). Notably we need to build a descriptor for the `FeedManifold` — which in turn implies we have to decide on some fundamental aspects of handling buffers in the render process. To allow rework of the `ProcNode` connectivity, a lot of presumably obsoleted draft code from 2011 has to be detached, to be able to keep it in-tree for further reference (until the rework and refactoring is settled).
2024-06-24 23:49:55 +02:00
*/
/** @file feed-manifold-obsolete.hpp
** @todo staled since 2009, picked up in 2024 in an attempt to finish the node invocation.
** deprecated 2024 this file is a dead-end! It is retained in tree to keep other obsolete code buildable
** @see nodeinvocation.hpp
*/
#ifndef ENGINE_FEED_MANIFOLD_OBSOLETE_H
#define ENGINE_FEED_MANIFOLD_OBSOLETE_H
#include "lib/error.hpp"
#include "lib/nocopy.hpp"
Invocation: rearrange code and cut ties to obsolete implementation draft The latest phase of conception and planning moved this integration effort a big step ahead. It is now **basically settled how the invocation works** from top-down. Thus a lot of ties to ''obsoleted pieces of implementation code'' from the first draft from 2009 / 2012 can be severed now. * instead of a `StateProxy` most state management has been broken down into implementation parts * instead of orchestrating generic invocation building blocks we will parametrise »weaving-patterns«
2024-12-13 03:28:28 +01:00
#include "steam/engine/channel-descriptor-obsolete.hpp"
Invocation: Identify parts relevant for a node builder The immediate next step is to build some render nodes directly in a test setting, without using any kind of ''node factory.'' Getting ahead with this task requires to identify the constituents to be represented on the first code layer for the reworked code (here ''first layer'' means any part that are ''not'' supplied by generic, templated building blocks). Notably we need to build a descriptor for the `FeedManifold` — which in turn implies we have to decide on some fundamental aspects of handling buffers in the render process. To allow rework of the `ProcNode` connectivity, a lot of presumably obsoleted draft code from 2011 has to be detached, to be able to keep it in-tree for further reference (until the rework and refactoring is settled).
2024-06-24 23:49:55 +02:00
//#include "steam/engine/proc-node.hpp" ///////////////////////////////TODO this is a dead end
#include "steam/engine/connectivity-obsolete.hpp"
#include <vector>
#include <utility>
////////////////////////////////TICKET #826 will be reworked alltogether
namespace steam {
namespace engine {
using std::pair;
using std::vector;
/**
* Obsolete, to be rewritten /////TICKET #826
*
* Tables of buffer handles and corresponding dereferenced buffer pointers.
* Used within the invocation of a processing node to calculate data.
* The tables are further differentiated into input data buffers and output
* data buffers. The tables are supposed to be implemented as bare "C" arrays,
* thus the array of real buffer pointers can be fed directly to the
* processing function of the respective node.
*
* @todo this whole design is a first attempt and rather clumsy. It should be reworked
* to use a single contiguous memory area and just layer the object structure on top
* (by using placement new). Yet the idea of an stack-like organisation should be retained
*/
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
struct FeedManifold_BuffTable_OBSOLETE ///////////////////////////////////OOO this is obliterated by the new implementation of FeedManifold_BuffTable_OBSOLETE
Invocation: Identify parts relevant for a node builder The immediate next step is to build some render nodes directly in a test setting, without using any kind of ''node factory.'' Getting ahead with this task requires to identify the constituents to be represented on the first code layer for the reworked code (here ''first layer'' means any part that are ''not'' supplied by generic, templated building blocks). Notably we need to build a descriptor for the `FeedManifold` — which in turn implies we have to decide on some fundamental aspects of handling buffers in the render process. To allow rework of the `ProcNode` connectivity, a lot of presumably obsoleted draft code from 2011 has to be detached, to be able to keep it in-tree for further reference (until the rework and refactoring is settled).
2024-06-24 23:49:55 +02:00
{
typedef BuffHandle * PHa;
typedef BuffHandle::PBuff * PBu;
typedef pair<PHa const,PBu const> Chunk;
PHa outHandle;
PHa inHandle;
PBu outBuff;
PBu inBuff;
};
Invocation: clarify role of Buffer-Descriptor and Dependency-Injection It became clear that a secondary system of connections must be added, running top-down from a global model context, and thus contrary to the regular orientation of the node network, which connects upwards from predecessor to successor, in accordance with the pull principle. If we accept this wiring as part of the primary structure, it can be established immediately while building the nodes, thus adding a preconfigured ''pattern of Buffer Descriptors'' to each node, since there is no further ''moving part'' — beyond the wiring to the `BufferProvider`, which thus becomes part of a global `ModelContext` As an immediate consequence, the storage for this configuraion should also be switched to `lib::Several` and handled similar to the primary node wiring in the Builder...
2024-07-15 18:52:59 +02:00
class BuffDescr;
Invocation: Identify parts relevant for a node builder The immediate next step is to build some render nodes directly in a test setting, without using any kind of ''node factory.'' Getting ahead with this task requires to identify the constituents to be represented on the first code layer for the reworked code (here ''first layer'' means any part that are ''not'' supplied by generic, templated building blocks). Notably we need to build a descriptor for the `FeedManifold` — which in turn implies we have to decide on some fundamental aspects of handling buffers in the render process. To allow rework of the `ProcNode` connectivity, a lot of presumably obsoleted draft code from 2011 has to be detached, to be able to keep it in-tree for further reference (until the rework and refactoring is settled).
2024-06-24 23:49:55 +02:00
/** Obsolete, to be rewritten /////TICKET #826 */
class BuffTableStorage
{
/////////////////////////////////////////////////////////////////////////TICKET #826 need to be reworked entirely
/** just a placeholder to decouple the existing code
* from the reworked BuffHandle logic. The existing
* code in turn will be reworked rather fundamentally
*/
struct BuffHaXXXX
: BuffHandle
{
BuffHaXXXX() : BuffHandle(just_satisfy_the_compiler()) { /* wont work ever */ }
Invocation: clarify role of Buffer-Descriptor and Dependency-Injection It became clear that a secondary system of connections must be added, running top-down from a global model context, and thus contrary to the regular orientation of the node network, which connects upwards from predecessor to successor, in accordance with the pull principle. If we accept this wiring as part of the primary structure, it can be established immediately while building the nodes, thus adding a preconfigured ''pattern of Buffer Descriptors'' to each node, since there is no further ''moving part'' — beyond the wiring to the `BufferProvider`, which thus becomes part of a global `ModelContext` As an immediate consequence, the storage for this configuraion should also be switched to `lib::Several` and handled similar to the primary node wiring in the Builder...
2024-07-15 18:52:59 +02:00
static BuffDescr const&
Invocation: Identify parts relevant for a node builder The immediate next step is to build some render nodes directly in a test setting, without using any kind of ''node factory.'' Getting ahead with this task requires to identify the constituents to be represented on the first code layer for the reworked code (here ''first layer'' means any part that are ''not'' supplied by generic, templated building blocks). Notably we need to build a descriptor for the `FeedManifold` — which in turn implies we have to decide on some fundamental aspects of handling buffers in the render process. To allow rework of the `ProcNode` connectivity, a lot of presumably obsoleted draft code from 2011 has to be detached, to be able to keep it in-tree for further reference (until the rework and refactoring is settled).
2024-06-24 23:49:55 +02:00
just_satisfy_the_compiler() { }
};
////////////////////////////////////TICKET #825 should be backed by mpool and integrated with node invocation
vector<BuffHaXXXX> hTab_;
vector<BuffHandle::PBuff> pTab_;
size_t level_;
public:
BuffTableStorage (const size_t maxSiz)
: hTab_(maxSiz),
pTab_(maxSiz),
level_(0)
{ }
~BuffTableStorage() { ASSERT (0==level_, "buffer management logic broken."); }
protected:
friend class BuffTableChunk;
/** allocate the given number of slots
* starting at current level to be used
* by the newly created BuffTableChunk
*/
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
FeedManifold_BuffTable_OBSOLETE::Chunk
Invocation: Identify parts relevant for a node builder The immediate next step is to build some render nodes directly in a test setting, without using any kind of ''node factory.'' Getting ahead with this task requires to identify the constituents to be represented on the first code layer for the reworked code (here ''first layer'' means any part that are ''not'' supplied by generic, templated building blocks). Notably we need to build a descriptor for the `FeedManifold` — which in turn implies we have to decide on some fundamental aspects of handling buffers in the render process. To allow rework of the `ProcNode` connectivity, a lot of presumably obsoleted draft code from 2011 has to be detached, to be able to keep it in-tree for further reference (until the rework and refactoring is settled).
2024-06-24 23:49:55 +02:00
claim (uint slots)
{
ASSERT (pTab_.size() == hTab_.size());
REQUIRE (level_+slots <= hTab_.size());
size_t prev_level (level_);
level_ += slots;
return std::make_pair (&hTab_[prev_level],
&pTab_[prev_level]);
}
void
release (uint slots)
{
ASSERT (slots <= level_);
REQUIRE (level_ <= hTab_.size());
REQUIRE (level_ <= pTab_.size());
level_ -= slots;
}
bool
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
level_check (FeedManifold_BuffTable_OBSOLETE::Chunk& prev_level)
Invocation: Identify parts relevant for a node builder The immediate next step is to build some render nodes directly in a test setting, without using any kind of ''node factory.'' Getting ahead with this task requires to identify the constituents to be represented on the first code layer for the reworked code (here ''first layer'' means any part that are ''not'' supplied by generic, templated building blocks). Notably we need to build a descriptor for the `FeedManifold` — which in turn implies we have to decide on some fundamental aspects of handling buffers in the render process. To allow rework of the `ProcNode` connectivity, a lot of presumably obsoleted draft code from 2011 has to be detached, to be able to keep it in-tree for further reference (until the rework and refactoring is settled).
2024-06-24 23:49:55 +02:00
{
return prev_level.first == &hTab_[level_]
&& prev_level.second == &pTab_[level_];
}
};
/** Obsolete, to be rewritten /////TICKET #826
* to be allocated on the stack while evaluating a ProcNode#pull() call.
* The "current" State (StateProxy) maintains a BuffTableStorage (=pool),
* which can be used to crate such chunks. The claiming and releasing of
* slots in the BuffTableStorage is automatically tied to BuffTableChunk
* object's lifecycle.
*/
class BuffTableChunk
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
: public FeedManifold_BuffTable_OBSOLETE,
Invocation: Identify parts relevant for a node builder The immediate next step is to build some render nodes directly in a test setting, without using any kind of ''node factory.'' Getting ahead with this task requires to identify the constituents to be represented on the first code layer for the reworked code (here ''first layer'' means any part that are ''not'' supplied by generic, templated building blocks). Notably we need to build a descriptor for the `FeedManifold` — which in turn implies we have to decide on some fundamental aspects of handling buffers in the render process. To allow rework of the `ProcNode` connectivity, a lot of presumably obsoleted draft code from 2011 has to be detached, to be able to keep it in-tree for further reference (until the rework and refactoring is settled).
2024-06-24 23:49:55 +02:00
util::NonCopyable
{
const uint siz_;
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
FeedManifold_BuffTable_OBSOLETE::Chunk tab_;
Invocation: Identify parts relevant for a node builder The immediate next step is to build some render nodes directly in a test setting, without using any kind of ''node factory.'' Getting ahead with this task requires to identify the constituents to be represented on the first code layer for the reworked code (here ''first layer'' means any part that are ''not'' supplied by generic, templated building blocks). Notably we need to build a descriptor for the `FeedManifold` — which in turn implies we have to decide on some fundamental aspects of handling buffers in the render process. To allow rework of the `ProcNode` connectivity, a lot of presumably obsoleted draft code from 2011 has to be detached, to be able to keep it in-tree for further reference (until the rework and refactoring is settled).
2024-06-24 23:49:55 +02:00
BuffTableStorage& sto_;
public:
BuffTableChunk (Connectivity const& wd, BuffTableStorage& storage)
: siz_(wd.nrI + wd.nrO),
tab_(storage.claim (siz_)),
sto_(storage)
{
const uint nrO(wd.nrO);
// Setup the publicly visible table locations
this->outHandle = &tab_.first[ 0 ];
this->inHandle = &tab_.first[nrO];
this->outBuff = &tab_.second[ 0 ];
this->inBuff = &tab_.second[nrO];
}
~BuffTableChunk ()
{
sto_.release (siz_);
ASSERT ( sto_.level_check (tab_),
"buffer management logic broken.");
}
};
}} // namespace steam::engine
#endif /*ENGINE_FEED_MANIFOLD_OBSOLETE_H*/
Reference in a new issue Copy permalink