ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/core/steam/engine/mock-support-test.cpp

444 lines
21 KiB
C++
Raw Normal View History

Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
/*
MockSupport(Test) - verify test support for fixture and job dispatch
Copyright (C) Lumiera.org
2023, Hermann Vosseler <Ichthyostega@web.de>
This program 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.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* *****************************************************/
/** @file mock-support-test.cpp
** unit test \ref MockSupport_test
*/
#include "lib/test/run.hpp"
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
#include "lib/test/test-helper.hpp"
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
#include "steam/engine/mock-dispatcher.hpp"
Scheduler: devise the arrangement of basic components - define organisation of vault-layer namespaces - define the ground plan of the scheduler implementation
2023-06-24 03:14:17 +02:00
#include "vault/gear/nop-job-functor.hpp"
the new design takes the old name The second design from 2017, based on a pipeline builder, is now renamed `TreeExplorer` ⟼ `IterExplorer` and uses the memorable entrance point `lib::explore(<seq>)` ✔
2023-06-22 20:23:55 +02:00
#include "lib/iter-explorer.hpp"
Library: extract helper for unloading a sequence into a tuple
2023-05-10 13:50:19 +02:00
#include "lib/util-tuple.hpp"
Segmentation: simple implementation of time-based access - introduce a JobTicket::NOP (null-object pattern) - assuming that the function splitSplice() will retain complete coverage allways Remark: `Fixture::getPlaylistForRender()` is a leftover from the very early implementation drafts. This function was more or less based on the way Cinelerra works; it is clear by now that Lumiera can not possibly work this way, given that we'll build a low-level model and dispatch precompiled render jobs....
2023-04-27 22:30:49 +02:00
#include "lib/util.hpp"
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
using test::Test;
Library: extract helper for unloading a sequence into a tuple
2023-05-10 13:50:19 +02:00
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
namespace steam {
namespace engine{
namespace test {
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
using steam::fixture::Segment;
Job-Planning: Attempt to build a prerequisite-Pipeline failed -- investigate why To complete the mock setup, the next step would be to extend the GenNode-based spec langage to allow defining prerequisite Mock-JobTickets. Setting this up seems rather straight forward -- however, defining a simple testcase to cover this extension runs into surprisingly tricky problems.. - for one, the singleValIterator from Itertools has serious difficulties handling references - but even more surprising, it seems impossible to make the "prerequisites iterator" fit into the Tree-Explorer framework (which I intend to use as replacement for the monadic approach) after some extended analysis of generic types and template instances, it seems that not TreeExplorer as such is the primary problem, but rather there is a conceptual mismatch somewhere deep down in Itertools or Iter-Adapter
2023-05-15 23:25:29 +02:00
using lib::singleValIterator;
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
using util::isSameObject;
using util::seqTuple;
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
/**********************************************************************//**
* @test validate test support for render job planning and dispatch.
* - creating and invoking mock render jobs
* - a mocked JobTicket, generating mock render jobs
* - configurable test setup for a mocked Segmentation datastructure
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
* - configurable setup of a complete frame Dispatcher
Job-Planning: frame number now additionally required in FrameCoord ...which was the reason why the test failed; the calculation works as expected PS: rename JobPlanningSetup_test to JobPlanningPipeline_test
2023-06-17 03:10:57 +02:00
* @see JobPlanningPipeline_test
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
* @see Dispatcher
Scheduler: devise the arrangement of basic components - define organisation of vault-layer namespaces - define the ground plan of the scheduler implementation
2023-06-24 03:14:17 +02:00
* @see vault::gear::Job
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
* @see steam::fixture::Segmentation
*/
class MockSupport_test : public Test
{
virtual void
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
run (Arg)
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
{
simpleUsage();
verify_MockJob();
verify_MockJobTicket();
verify_MockSegmentation();
Job-Ticket: consider how to deal with channels and prerequisites By reasoning and analysis I conclude that the differentiation into multiple channels is likely misplaced in JobTicket; it belongs ratther into the Segment and should provide a suitable JobTicket for each ModelPort Handling of prerequisites also needs to be reshaped entirely after switching to a pipeline builder for the Job-planning pipeline; as preliminary access point, just add an iterator over the immediate prerequisites, thereby shifting the exploration mechanism entirely out of the JobTicket implementation
2023-05-11 22:47:56 +02:00
verify_MockPrerequisites();
Dispatcher-Pipeline: expected behaviour of (mock)Dispatcher
2023-06-12 23:15:39 +02:00
verify_MockDispatcherSetup();
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
}
/** @test simple usage example of the test helpers */
void
simpleUsage()
{
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
// Build a simple Segment at [10s ... 20s[
MockSegmentation mockSegs{MakeRec()
.attrib ("start", Time{0,10}
,"after", Time{0,20})
.genNode()};
CHECK (3 == mockSegs.size());
fixture::Segment const& seg = mockSegs[Time{0,15}]; // access anywhere 10s <= t < 20s
Job-Planning: implement braindead deadline calculation ...using hard coded values instead of observation of actual runtimes, but at least the calculation scheme (now relocated from TimeAnchor to JobPlanning) should be a reasonable starting point. TODO: test fails...
2023-06-16 04:09:38 +02:00
JobTicket& ticket = seg.jobTicket(0);
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
Job job = ticket.createJobFor (Time{0,15});
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
CHECK (MockJobTicket::isAssociated (job, ticket));
job.triggerJob();
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
CHECK (MockJob::was_invoked (job));
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
}
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
/** @test document and verify usage of a mock render job */
void
verify_MockJob()
{
Time nominalTime = lib::test::randTime();
int additionalKey = rand() % 5000;
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
MockJob mockJob{nominalTime, additionalKey};
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
CHECK (mockJob.getNominalTime() == nominalTime);
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
CHECK (not MockJob::was_invoked (mockJob));
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
mockJob.triggerJob();
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
CHECK (MockJob::was_invoked (mockJob));
CHECK (RealClock::wasRecently (MockJob::invocationTime (mockJob)));
CHECK (nominalTime == MockJob::invocationNominalTime (mockJob) );
CHECK (additionalKey == MockJob::invocationAdditionalKey(mockJob));
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
Time prevInvocation = MockJob::invocationTime (mockJob);
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
mockJob.triggerJob();
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
CHECK (prevInvocation < MockJob::invocationTime (mockJob)); // invoked again, recorded new invocation time
CHECK (nominalTime == MockJob::invocationNominalTime (mockJob) ); // all other Job parameter recorded again unaltered
CHECK (additionalKey == MockJob::invocationAdditionalKey(mockJob));
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
}
/** @test document and verify usage of a mock JobTicket for frame dispatch */
void
verify_MockJobTicket()
{
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
auto frameTime = lib::test::randTime();
Job-Planning: provide stub implementation for NOP job (see #1296) - can now create a Job from JobTicket::NIL - on invocation this Job will to nothing Only when the first real output backend is implemented, we can decide if this simplistic implementation is enough, or if an empty output must be explicitly generated...
2023-05-01 01:48:36 +02:00
// build a render job to do nothing....
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
Job nopJob = JobTicket::NOP.createJobFor (frameTime);
Scheduler: devise the arrangement of basic components - define organisation of vault-layer namespaces - define the ground plan of the scheduler implementation
2023-06-24 03:14:17 +02:00
CHECK (INSTANCEOF (vault::gear::NopJobFunctor, static_cast<JobClosure*> (nopJob.jobClosure))); //////////TICKET #1287 : fix actual interface down to JobFunctor (after removing C structs)
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
CHECK (nopJob.parameter.nominalTime == frameTime);
Job-Planning: simulate backing by specific JobTicket right now we're lacking a complete working implementation of render node invocation, and thus the Dispatcher implementation can only be verified with the help of mocked jobs. However, at least a preliminary implementation of tagging the invocation instance is available, and thus we're able to verify that a given job instance indeed belongs to and is "backed" by a specific JobTicket. This is prerequisite for building up a (likewise mocked) Fixture datastructure, and this in turn was meant to form the basis for attacking an actual Scheduler implementation, followed by a real render node invocation.
2023-05-01 14:07:21 +02:00
InvocationInstanceID empty; ///////////////////////////////////////////////////////////////////////TICKET #1287 : temporary workaround until we get rid of the C base structs
CHECK (lumiera_invokey_eq (&nopJob.parameter.invoKey, &empty));
Job-Planning: start rework of the planning data aggregation The initial implementation effort for Player and Job-Planning has been reviewed and largely reworked, and some parts are now obsoleted by the reworked alternative and can be disabled. The basic idea will be retained though: JobPlanning is a data aggregator and performs the final step of creating a Job
2023-06-15 03:51:07 +02:00
CHECK (MockJob::isNopJob(nopJob)); // this diagnostic helper checks the same conditions as done here explicitly
Job-Planning: provide stub implementation for NOP job (see #1296) - can now create a Job from JobTicket::NIL - on invocation this Job will to nothing Only when the first real output backend is implemented, we can decide if this simplistic implementation is enough, or if an empty output must be explicitly generated...
2023-05-01 01:48:36 +02:00
Job-Planning: investigate invocation of jobs ...using the MockJobTicket setup as point of reference, since the actual invocation of render nodes will only be drafted later in this "Vertical Slice" integration effort...
2023-04-30 02:18:56 +02:00
MockJobTicket mockTicket;
Job-Planning: start rework of the planning data aggregation The initial implementation effort for Player and Job-Planning has been reviewed and largely reworked, and some parts are now obsoleted by the reworked alternative and can be disabled. The basic idea will be retained though: JobPlanning is a data aggregator and performs the final step of creating a Job
2023-06-15 03:51:07 +02:00
CHECK (not mockTicket.empty());
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
Job mockJob = mockTicket.createJobFor (frameTime);
Job-Planning: simulate backing by specific JobTicket right now we're lacking a complete working implementation of render node invocation, and thus the Dispatcher implementation can only be verified with the help of mocked jobs. However, at least a preliminary implementation of tagging the invocation instance is available, and thus we're able to verify that a given job instance indeed belongs to and is "backed" by a specific JobTicket. This is prerequisite for building up a (likewise mocked) Fixture datastructure, and this in turn was meant to form the basis for attacking an actual Scheduler implementation, followed by a real render node invocation.
2023-05-01 14:07:21 +02:00
CHECK ( mockTicket.verify_associated (mockJob)); // proof by invocation hash : is indeed backed by this JobTicket
CHECK (not mockTicket.verify_associated (nopJob)); // ...while some random other job is not related
Job-Planning: start rework of the planning data aggregation The initial implementation effort for Player and Job-Planning has been reviewed and largely reworked, and some parts are now obsoleted by the reworked alternative and can be disabled. The basic idea will be retained though: JobPlanning is a data aggregator and performs the final step of creating a Job
2023-06-15 03:51:07 +02:00
CHECK (not MockJob::isNopJob(mockJob));
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
}
Job-Planning: verify and complete the build-up of mock structures (see #1294) The prototypical setup of data structures and test support components is largely complete by now — with the exception of the `MockDispatcher`, which will be completed while moving to the next steps pertaining the setup of a frame dispatch pipeline. * the existing `DummyJob` was augmented to allow verification of association between Job and `JobTicket` * the existing implementation of `JobTicket` was verified and augmented to allow coverage of the whole usage cycle * a `MockJobTicket` was implemented on top, which can be generated from a symbolical test specification (rather than from the real Fixture data structure) * a complete `MockSegmentation` was developed, allowing to establish all the aforementioned data structures without an actual backing Render Engine. Moreover, `MockSegmentation` can be generated from the aforementioned symbolic test specification. * as part of this work, an algorithm to split an existing Segmentation and to splice in new segments was developed and verified
2023-05-24 03:38:12 +02:00
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
/** @test document and verify usage of a complete mocked Segmentation
* to back frame dispatch
Job-Planning: verify and complete the build-up of mock structures (see #1294) The prototypical setup of data structures and test support components is largely complete by now — with the exception of the `MockDispatcher`, which will be completed while moving to the next steps pertaining the setup of a frame dispatch pipeline. * the existing `DummyJob` was augmented to allow verification of association between Job and `JobTicket` * the existing implementation of `JobTicket` was verified and augmented to allow coverage of the whole usage cycle * a `MockJobTicket` was implemented on top, which can be generated from a symbolical test specification (rather than from the real Fixture data structure) * a complete `MockSegmentation` was developed, allowing to establish all the aforementioned data structures without an actual backing Render Engine. Moreover, `MockSegmentation` can be generated from the aforementioned symbolic test specification. * as part of this work, an algorithm to split an existing Segmentation and to splice in new segments was developed and verified
2023-05-24 03:38:12 +02:00
* - default constructed: empty Segmentation
* - cover the whole axis with one segment
* - partition axis and verify the association of generated jobs
* - a fully defined segment within an otherwise empty axis
* - complex partitioning (using the »split-splice« mechanism
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
*/
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
void
verify_MockSegmentation()
{
Segmentation: draft simple mock-based setup for tests - how to pass-in a specification given as GenNode - now this might be translated into a MockJobTicket allocated in the MockSegmentation Unimplemented: actually build the Segment with suitable start/end time
2023-05-01 17:02:11 +02:00
Time someTime = lib::test::randTime();
Job-Planning: verify and complete the build-up of mock structures (see #1294) The prototypical setup of data structures and test support components is largely complete by now — with the exception of the `MockDispatcher`, which will be completed while moving to the next steps pertaining the setup of a frame dispatch pipeline. * the existing `DummyJob` was augmented to allow verification of association between Job and `JobTicket` * the existing implementation of `JobTicket` was verified and augmented to allow coverage of the whole usage cycle * a `MockJobTicket` was implemented on top, which can be generated from a symbolical test specification (rather than from the real Fixture data structure) * a complete `MockSegmentation` was developed, allowing to establish all the aforementioned data structures without an actual backing Render Engine. Moreover, `MockSegmentation` can be generated from the aforementioned symbolic test specification. * as part of this work, an algorithm to split an existing Segmentation and to splice in new segments was developed and verified
2023-05-24 03:38:12 +02:00
//
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
//-----------------------------------------------------------------/// Empty default Segmentation
Segmentation: draft simple mock-based setup for tests - how to pass-in a specification given as GenNode - now this might be translated into a MockJobTicket allocated in the MockSegmentation Unimplemented: actually build the Segment with suitable start/end time
2023-05-01 17:02:11 +02:00
{
MockSegmentation mockSeg;
CHECK (1 == mockSeg.size());
Dispatcher-Pipeline: allocate JobTicket in Segment PROBLEM: can not implement Spec-generation, since - we must use a λ for internal allocation of JobTickets - but recursive type inference is not possible Will thus need to abandon the Spec-Tuple and relocate this traversal-and-generation code into JobTicket itself
2023-06-09 02:48:38 +02:00
JobTicket const& ticket = mockSeg[someTime].jobTicket(0); // just probe JobTicket generated for Model-Port-Nr.0
Segmentation: draft simple mock-based setup for tests - how to pass-in a specification given as GenNode - now this might be translated into a MockJobTicket allocated in the MockSegmentation Unimplemented: actually build the Segment with suitable start/end time
2023-05-01 17:02:11 +02:00
CHECK (util::isSameObject (ticket, JobTicket::NOP));
}
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
//-----------------------------------------------------------------/// Segmentation with one default segment spanning complete timeline
Segmentation: draft simple mock-based setup for tests - how to pass-in a specification given as GenNode - now this might be translated into a MockJobTicket allocated in the MockSegmentation Unimplemented: actually build the Segment with suitable start/end time
2023-05-01 17:02:11 +02:00
{
Segmentation: integrate SplitSplice and build mock-segmentation ...now able to build a mock segmentation which issues dummy jobs, and is wired such as to verify the right job is invoked for each segment. And this allows to build and verify the Dispatcher, without being able to invoke actual render jobs yet.
2023-05-05 03:46:42 +02:00
MockSegmentation mockSegs{MakeRec().genNode()};
CHECK (1 == mockSegs.size());
CHECK (Time::MIN == mockSegs[someTime].start());
CHECK (Time::MAX == mockSegs[someTime].after());
Job-Planning: implement braindead deadline calculation ...using hard coded values instead of observation of actual runtimes, but at least the calculation scheme (now relocated from TimeAnchor to JobPlanning) should be a reasonable starting point. TODO: test fails...
2023-06-16 04:09:38 +02:00
JobTicket& ticket = mockSegs[someTime].jobTicket(0);
Segmentation: draft simple mock-based setup for tests - how to pass-in a specification given as GenNode - now this might be translated into a MockJobTicket allocated in the MockSegmentation Unimplemented: actually build the Segment with suitable start/end time
2023-05-01 17:02:11 +02:00
CHECK (not util::isSameObject (ticket, JobTicket::NOP));
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
Job someJob = ticket.createJobFor(someTime); // JobTicket uses, but does not check the time given
CHECK (someJob.parameter.nominalTime == someTime);
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
CHECK (MockJobTicket::isAssociated (someJob, ticket)); // but the generated Job is linked to the Closure backed by the JobTicket
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
CHECK (not MockJob::was_invoked (someJob));
Segmentation: draft simple mock-based setup for tests - how to pass-in a specification given as GenNode - now this might be translated into a MockJobTicket allocated in the MockSegmentation Unimplemented: actually build the Segment with suitable start/end time
2023-05-01 17:02:11 +02:00
someJob.triggerJob();
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
CHECK (MockJob::was_invoked (someJob));
CHECK (RealClock::wasRecently (MockJob::invocationTime (someJob)));
CHECK (someTime == MockJob::invocationNominalTime (someJob));
Segmentation: draft simple mock-based setup for tests - how to pass-in a specification given as GenNode - now this might be translated into a MockJobTicket allocated in the MockSegmentation Unimplemented: actually build the Segment with suitable start/end time
2023-05-01 17:02:11 +02:00
}
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
//-----------------------------------------------------------------/// Segmentation with a segment spanning part of the timeline > 10s
Segmentation: integrate SplitSplice and build mock-segmentation ...now able to build a mock segmentation which issues dummy jobs, and is wired such as to verify the right job is invoked for each segment. And this allows to build and verify the Dispatcher, without being able to invoke actual render jobs yet.
2023-05-05 03:46:42 +02:00
{
// Marker to verify the job calls back into the right segment
int marker = rand() % 1000;
Job-Planning: verify and complete the build-up of mock structures (see #1294) The prototypical setup of data structures and test support components is largely complete by now — with the exception of the `MockDispatcher`, which will be completed while moving to the next steps pertaining the setup of a frame dispatch pipeline. * the existing `DummyJob` was augmented to allow verification of association between Job and `JobTicket` * the existing implementation of `JobTicket` was verified and augmented to allow coverage of the whole usage cycle * a `MockJobTicket` was implemented on top, which can be generated from a symbolical test specification (rather than from the real Fixture data structure) * a complete `MockSegmentation` was developed, allowing to establish all the aforementioned data structures without an actual backing Render Engine. Moreover, `MockSegmentation` can be generated from the aforementioned symbolic test specification. * as part of this work, an algorithm to split an existing Segmentation and to splice in new segments was developed and verified
2023-05-24 03:38:12 +02:00
//
Segmentation: integrate SplitSplice and build mock-segmentation ...now able to build a mock segmentation which issues dummy jobs, and is wired such as to verify the right job is invoked for each segment. And this allows to build and verify the Dispatcher, without being able to invoke actual render jobs yet.
2023-05-05 03:46:42 +02:00
// Build a Segmentation partitioned at 10s
MockSegmentation mockSegs{MakeRec()
.attrib ("start", Time{0,10}
,"mark", marker)
.genNode()};
CHECK (2 == mockSegs.size());
// since only start-time was given, the SplitSplice-Algo will attach
// the new Segment starting at 10s and expand towards +∞,
// while the left part of the axis is marked as NOP / empty
fixture::Segment const& seg1 = mockSegs[Time::ZERO]; // access anywhere < 10s
fixture::Segment const& seg2 = mockSegs[Time{0,20}]; // access anywhere >= 10s
Dispatcher-Pipeline: allocate JobTicket in Segment PROBLEM: can not implement Spec-generation, since - we must use a λ for internal allocation of JobTickets - but recursive type inference is not possible Will thus need to abandon the Spec-Tuple and relocate this traversal-and-generation code into JobTicket itself
2023-06-09 02:48:38 +02:00
CHECK ( util::isSameObject (seg1.jobTicket(0),JobTicket::NOP));
CHECK (not util::isSameObject (seg2.jobTicket(0),JobTicket::NOP));// this one is the active segment
Segmentation: integrate SplitSplice and build mock-segmentation ...now able to build a mock segmentation which issues dummy jobs, and is wired such as to verify the right job is invoked for each segment. And this allows to build and verify the Dispatcher, without being able to invoke actual render jobs yet.
2023-05-05 03:46:42 +02:00
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
Job job = seg2.jobTicket(0).createJobFor(someTime);
Dispatcher-Pipeline: allocate JobTicket in Segment PROBLEM: can not implement Spec-generation, since - we must use a λ for internal allocation of JobTickets - but recursive type inference is not possible Will thus need to abandon the Spec-Tuple and relocate this traversal-and-generation code into JobTicket itself
2023-06-09 02:48:38 +02:00
CHECK (not MockJobTicket::isAssociated (job, seg1.jobTicket(0)));
CHECK ( MockJobTicket::isAssociated (job, seg2.jobTicket(0)));
Segmentation: integrate SplitSplice and build mock-segmentation ...now able to build a mock segmentation which issues dummy jobs, and is wired such as to verify the right job is invoked for each segment. And this allows to build and verify the Dispatcher, without being able to invoke actual render jobs yet.
2023-05-05 03:46:42 +02:00
CHECK (marker == job.parameter.invoKey.part.a);
job.triggerJob();
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
CHECK (MockJob::was_invoked (job));
CHECK (RealClock::wasRecently (MockJob::invocationTime (job)));
CHECK (marker == MockJob::invocationAdditionalKey (job)); // DummyClosure is rigged such as to feed back the seed in `part.a`
Segmentation: integrate SplitSplice and build mock-segmentation ...now able to build a mock segmentation which issues dummy jobs, and is wired such as to verify the right job is invoked for each segment. And this allows to build and verify the Dispatcher, without being able to invoke actual render jobs yet.
2023-05-05 03:46:42 +02:00
// and thus we can prove this job really belongs to the marked segment
// create another job from the (empty) seg1
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
job = seg1.jobTicket(0).createJobFor (someTime);
Segmentation: integrate SplitSplice and build mock-segmentation ...now able to build a mock segmentation which issues dummy jobs, and is wired such as to verify the right job is invoked for each segment. And this allows to build and verify the Dispatcher, without being able to invoke actual render jobs yet.
2023-05-05 03:46:42 +02:00
InvocationInstanceID empty; /////////////////////////////////////////////////////////////////////TICKET #1287 : temporary workaround until we get rid of the C base structs
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
CHECK (lumiera_invokey_eq (&job.parameter.invoKey, &empty)); // indicates that it's just a placeholder to mark a "NOP"-Job
Dispatcher-Pipeline: allocate JobTicket in Segment PROBLEM: can not implement Spec-generation, since - we must use a λ for internal allocation of JobTickets - but recursive type inference is not possible Will thus need to abandon the Spec-Tuple and relocate this traversal-and-generation code into JobTicket itself
2023-06-09 02:48:38 +02:00
CHECK (seg1.jobTicket(0).empty());
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
CHECK (seg1.empty());
CHECK (not seg2.empty());
}
//-----------------------------------------------------------------/// Segmentation with one delineated segment, and otherwise empty
{
int marker = rand() % 1000;
// Build Segmentation with one fully defined segment
MockSegmentation mockSegs{MakeRec()
.attrib ("start", Time{0,10}
,"after", Time{0,20}
,"mark", marker)
.genNode()};
CHECK (3 == mockSegs.size());
auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
CHECK (s1.empty());
CHECK (not s2.empty());
CHECK (s3.empty());
CHECK (isSameObject (s2, mockSegs[Time{0,10}]));
CHECK (Time::MIN == s1.start());
CHECK (Time(0,10) == s1.after());
CHECK (Time(0,10) == s2.start());
CHECK (Time(0,20) == s2.after());
CHECK (Time(0,20) == s3.start());
CHECK (Time::MAX == s3.after());
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
Job job = s2.jobTicket(0).createJobFor(someTime);
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
job.triggerJob();
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
CHECK (marker == MockJob::invocationAdditionalKey (job));
Segmentation: integrate SplitSplice and build mock-segmentation ...now able to build a mock segmentation which issues dummy jobs, and is wired such as to verify the right job is invoked for each segment. And this allows to build and verify the Dispatcher, without being able to invoke actual render jobs yet.
2023-05-05 03:46:42 +02:00
}
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
//-----------------------------------------------------------------/// Segmentation with several segments built in specific order
{
// Build Segmentation by partitioning in several steps
MockSegmentation mockSegs{MakeRec()
.attrib ("start", Time{0,20} // note: inverted segment definition is rectified automatically
,"after", Time{0,10}
,"mark", 1)
.genNode()
,MakeRec()
.attrib ("after", Time::ZERO
,"mark", 2)
.genNode()
,MakeRec()
.attrib ("start", Time{FSecs{-5}}
,"mark", 3)
.genNode()};
CHECK (5 == mockSegs.size());
auto const& [s1,s2,s3,s4,s5] = seqTuple<5> (mockSegs.eachSeg());
CHECK (not s1.empty());
CHECK (not s2.empty());
CHECK ( s3.empty());
CHECK (not s4.empty());
CHECK ( s5.empty());
CHECK (Time::MIN == s1.start()); // the second added segment has covered the whole negative axis
CHECK (-Time(0,5) == s1.after()); // ..up to the partitioning point -5
CHECK (-Time(0,5) == s2.start()); // ...while the rest was taken up by the third added segment
CHECK (Time(0, 0) == s2.after());
CHECK (Time(0, 0) == s3.start()); // an empty gap remains between [0 ... 10[
CHECK (Time(0,10) == s3.after());
CHECK (Time(0,10) == s4.start()); // here is the first added segment
CHECK (Time(0,20) == s4.after());
CHECK (Time(0,20) == s5.start()); // and the remaining part of the positive axis is empty
CHECK (Time::MAX == s5.after());
auto probeKey = [&](Segment const& segment)
{
if (segment.empty()) return 0;
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
Job job = segment.jobTicket(0).createJobFor(someTime);
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
job.triggerJob();
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
CHECK (MockJob::was_invoked (job));
CHECK (RealClock::wasRecently (MockJob::invocationTime (job)));
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
return MockJob::invocationAdditionalKey (job);
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
};
CHECK (2 == probeKey(s1)); // verify all generated jobs are wired back to the correct segment
CHECK (3 == probeKey(s2));
CHECK (0 == probeKey(s3));
CHECK (1 == probeKey(s4));
CHECK (0 == probeKey(s5));
}
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
}
Job-Ticket: consider how to deal with channels and prerequisites By reasoning and analysis I conclude that the differentiation into multiple channels is likely misplaced in JobTicket; it belongs ratther into the Segment and should provide a suitable JobTicket for each ModelPort Handling of prerequisites also needs to be reshaped entirely after switching to a pipeline builder for the Job-planning pipeline; as preliminary access point, just add an iterator over the immediate prerequisites, thereby shifting the exploration mechanism entirely out of the JobTicket implementation
2023-05-11 22:47:56 +02:00
/**
* @test build a Segment with additional prerequisites,
* resulting in additional JobTickets to explore and
* additional prerequisite Jobs to build for each frame.
*/
void
verify_MockPrerequisites()
{
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
Time someTime = lib::test::randTime();
Job-Ticket: consider how to deal with channels and prerequisites By reasoning and analysis I conclude that the differentiation into multiple channels is likely misplaced in JobTicket; it belongs ratther into the Segment and should provide a suitable JobTicket for each ModelPort Handling of prerequisites also needs to be reshaped entirely after switching to a pipeline builder for the Job-planning pipeline; as preliminary access point, just add an iterator over the immediate prerequisites, thereby shifting the exploration mechanism entirely out of the JobTicket implementation
2023-05-11 22:47:56 +02:00
//-----------------------------------------------------------------/// one Segment with one additional prerequisite
{
MockSegmentation mockSegs{MakeRec()
.attrib("mark", 11)
.scope(MakeRec()
.attrib("mark",23)
.genNode())
.genNode()};
CHECK (1 == mockSegs.size());
Dispatcher-Pipeline: now (finally) able to implement MockDispatcher MockSupport_test : PASS JobPlanningSetup_test : PASS(as far as defined)
2023-06-13 03:47:42 +02:00
JobTicket& ticket = mockSegs[Time::ZERO].jobTicket(0); // Model-PortNr.0
Job-Ticket: consider how to deal with channels and prerequisites By reasoning and analysis I conclude that the differentiation into multiple channels is likely misplaced in JobTicket; it belongs ratther into the Segment and should provide a suitable JobTicket for each ModelPort Handling of prerequisites also needs to be reshaped entirely after switching to a pipeline builder for the Job-planning pipeline; as preliminary access point, just add an iterator over the immediate prerequisites, thereby shifting the exploration mechanism entirely out of the JobTicket implementation
2023-05-11 22:47:56 +02:00
auto prereq = ticket.getPrerequisites();
CHECK (not isnil (prereq));
Job-Planning: implement braindead deadline calculation ...using hard coded values instead of observation of actual runtimes, but at least the calculation scheme (now relocated from TimeAnchor to JobPlanning) should be a reasonable starting point. TODO: test fails...
2023-06-16 04:09:38 +02:00
JobTicket& preTicket = *prereq;
Job-Ticket: consider how to deal with channels and prerequisites By reasoning and analysis I conclude that the differentiation into multiple channels is likely misplaced in JobTicket; it belongs ratther into the Segment and should provide a suitable JobTicket for each ModelPort Handling of prerequisites also needs to be reshaped entirely after switching to a pipeline builder for the Job-planning pipeline; as preliminary access point, just add an iterator over the immediate prerequisites, thereby shifting the exploration mechanism entirely out of the JobTicket implementation
2023-05-11 22:47:56 +02:00
++prereq;
CHECK (isnil (prereq));
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
Job job1 = preTicket.createJobFor (someTime);
Job job2 = ticket.createJobFor (someTime);
Job-Ticket: consider how to deal with channels and prerequisites By reasoning and analysis I conclude that the differentiation into multiple channels is likely misplaced in JobTicket; it belongs ratther into the Segment and should provide a suitable JobTicket for each ModelPort Handling of prerequisites also needs to be reshaped entirely after switching to a pipeline builder for the Job-planning pipeline; as preliminary access point, just add an iterator over the immediate prerequisites, thereby shifting the exploration mechanism entirely out of the JobTicket implementation
2023-05-11 22:47:56 +02:00
job1.triggerJob();
job2.triggerJob();
Dispatcher-Pipeline: mocked Dispatcher implementation complete (closes: #1294) `steam/engine/mock-dispatcher.hpp |cpp` now integrates this ''complete mock setup for render jobs and frame dispatching.'' The exising `DummyJob` has been slightly adapted and renamed to `MockJob` and is tightly integrated with the other mocks. The implementation of a `MockDispatcher` necessitated to change the use of `MockJobTicket`. The initial attempts used a complete mock implementation, but this approach turned out not to be viable. Instead — based on the ideas developed for the mock setup — now the prospective real implementation of `JobTicket` is available and will be used by the mock setup too. Instead of a synthetic spec, now a setup of recursively connected `ExitNode`(s) is used; the latter seems to develop into some kind of Facade for the render node network. Based on this mock setup, we can now demonstrate the (mostly) complete Job-Planning pipeline, starting from a segmentation up to render jobs, and verify proper connectivity and job invocation. ✔
2023-06-13 20:23:33 +02:00
CHECK (23 == MockJob::invocationAdditionalKey (job1));
CHECK (11 == MockJob::invocationAdditionalKey (job2));
Job-Ticket: consider how to deal with channels and prerequisites By reasoning and analysis I conclude that the differentiation into multiple channels is likely misplaced in JobTicket; it belongs ratther into the Segment and should provide a suitable JobTicket for each ModelPort Handling of prerequisites also needs to be reshaped entirely after switching to a pipeline builder for the Job-planning pipeline; as preliminary access point, just add an iterator over the immediate prerequisites, thereby shifting the exploration mechanism entirely out of the JobTicket implementation
2023-05-11 22:47:56 +02:00
}
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
//-----------------------------------------------------------------/// a tree of deep nested prerequisites
Job-Planning: Attempt to build a prerequisite-Pipeline failed -- investigate why To complete the mock setup, the next step would be to extend the GenNode-based spec langage to allow defining prerequisite Mock-JobTickets. Setting this up seems rather straight forward -- however, defining a simple testcase to cover this extension runs into surprisingly tricky problems.. - for one, the singleValIterator from Itertools has serious difficulties handling references - but even more surprising, it seems impossible to make the "prerequisites iterator" fit into the Tree-Explorer framework (which I intend to use as replacement for the monadic approach) after some extended analysis of generic types and template instances, it seems that not TreeExplorer as such is the primary problem, but rather there is a conceptual mismatch somewhere deep down in Itertools or Iter-Adapter
2023-05-15 23:25:29 +02:00
{
MockSegmentation mockSegs{MakeRec()
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
.attrib("mark", 11)
.scope(MakeRec()
.attrib("mark",33)
.scope(MakeRec()
.attrib("mark",55)
.genNode()
,MakeRec()
.attrib("mark",44)
.genNode()
)
.genNode()
,MakeRec()
.attrib("mark",22)
.genNode())
Job-Planning: Attempt to build a prerequisite-Pipeline failed -- investigate why To complete the mock setup, the next step would be to extend the GenNode-based spec langage to allow defining prerequisite Mock-JobTickets. Setting this up seems rather straight forward -- however, defining a simple testcase to cover this extension runs into surprisingly tricky problems.. - for one, the singleValIterator from Itertools has serious difficulties handling references - but even more surprising, it seems impossible to make the "prerequisites iterator" fit into the Tree-Explorer framework (which I intend to use as replacement for the monadic approach) after some extended analysis of generic types and template instances, it seems that not TreeExplorer as such is the primary problem, but rather there is a conceptual mismatch somewhere deep down in Itertools or Iter-Adapter
2023-05-15 23:25:29 +02:00
.genNode()};
Dispatcher-Pipeline: allocate JobTicket in Segment PROBLEM: can not implement Spec-generation, since - we must use a λ for internal allocation of JobTickets - but recursive type inference is not possible Will thus need to abandon the Spec-Tuple and relocate this traversal-and-generation code into JobTicket itself
2023-06-09 02:48:38 +02:00
auto start = singleValIterator (mockSegs[Time::ZERO].jobTicket(0));
Job-Planning: Attempt to build a prerequisite-Pipeline failed -- investigate why To complete the mock setup, the next step would be to extend the GenNode-based spec langage to allow defining prerequisite Mock-JobTickets. Setting this up seems rather straight forward -- however, defining a simple testcase to cover this extension runs into surprisingly tricky problems.. - for one, the singleValIterator from Itertools has serious difficulties handling references - but even more surprising, it seems impossible to make the "prerequisites iterator" fit into the Tree-Explorer framework (which I intend to use as replacement for the monadic approach) after some extended analysis of generic types and template instances, it seems that not TreeExplorer as such is the primary problem, but rather there is a conceptual mismatch somewhere deep down in Itertools or Iter-Adapter
2023-05-15 23:25:29 +02:00
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
auto it = lib::explore(start)
Dispatcher-Pipeline: now (finally) able to implement MockDispatcher MockSupport_test : PASS JobPlanningSetup_test : PASS(as far as defined)
2023-06-13 03:47:42 +02:00
.expand ([](JobTicket& ticket)
Job-Planning: Attempt to build a prerequisite-Pipeline failed -- investigate why To complete the mock setup, the next step would be to extend the GenNode-based spec langage to allow defining prerequisite Mock-JobTickets. Setting this up seems rather straight forward -- however, defining a simple testcase to cover this extension runs into surprisingly tricky problems.. - for one, the singleValIterator from Itertools has serious difficulties handling references - but even more surprising, it seems impossible to make the "prerequisites iterator" fit into the Tree-Explorer framework (which I intend to use as replacement for the monadic approach) after some extended analysis of generic types and template instances, it seems that not TreeExplorer as such is the primary problem, but rather there is a conceptual mismatch somewhere deep down in Itertools or Iter-Adapter
2023-05-15 23:25:29 +02:00
{
Job-Planning: switch to processing references ...which uncovers further deeply nested problems, especially when referring to non-copyable types. Thus need to construct a common type that can be used both to refer to the source elements and the expanded elements, and use this common type as result type and also attempt to produce better diagnostic messages on type mismatch....
2023-05-23 01:06:22 +02:00
return ticket.getPrerequisites();
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
})
Job-Planning: Attempt to build a prerequisite-Pipeline failed -- investigate why To complete the mock setup, the next step would be to extend the GenNode-based spec langage to allow defining prerequisite Mock-JobTickets. Setting this up seems rather straight forward -- however, defining a simple testcase to cover this extension runs into surprisingly tricky problems.. - for one, the singleValIterator from Itertools has serious difficulties handling references - but even more surprising, it seems impossible to make the "prerequisites iterator" fit into the Tree-Explorer framework (which I intend to use as replacement for the monadic approach) after some extended analysis of generic types and template instances, it seems that not TreeExplorer as such is the primary problem, but rather there is a conceptual mismatch somewhere deep down in Itertools or Iter-Adapter
2023-05-15 23:25:29 +02:00
.expandAll()
Job-Planning: implement braindead deadline calculation ...using hard coded values instead of observation of actual runtimes, but at least the calculation scheme (now relocated from TimeAnchor to JobPlanning) should be a reasonable starting point. TODO: test fails...
2023-06-16 04:09:38 +02:00
.transform ([&](JobTicket& ticket)
Job-Planning: Attempt to build a prerequisite-Pipeline failed -- investigate why To complete the mock setup, the next step would be to extend the GenNode-based spec langage to allow defining prerequisite Mock-JobTickets. Setting this up seems rather straight forward -- however, defining a simple testcase to cover this extension runs into surprisingly tricky problems.. - for one, the singleValIterator from Itertools has serious difficulties handling references - but even more surprising, it seems impossible to make the "prerequisites iterator" fit into the Tree-Explorer framework (which I intend to use as replacement for the monadic approach) after some extended analysis of generic types and template instances, it seems that not TreeExplorer as such is the primary problem, but rather there is a conceptual mismatch somewhere deep down in Itertools or Iter-Adapter
2023-05-15 23:25:29 +02:00
{
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
return ticket.createJobFor(someTime).parameter.invoKey.part.a;
Job-Planning: Attempt to build a prerequisite-Pipeline failed -- investigate why To complete the mock setup, the next step would be to extend the GenNode-based spec langage to allow defining prerequisite Mock-JobTickets. Setting this up seems rather straight forward -- however, defining a simple testcase to cover this extension runs into surprisingly tricky problems.. - for one, the singleValIterator from Itertools has serious difficulties handling references - but even more surprising, it seems impossible to make the "prerequisites iterator" fit into the Tree-Explorer framework (which I intend to use as replacement for the monadic approach) after some extended analysis of generic types and template instances, it seems that not TreeExplorer as such is the primary problem, but rather there is a conceptual mismatch somewhere deep down in Itertools or Iter-Adapter
2023-05-15 23:25:29 +02:00
});
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
CHECK (util::join(it,"-") == "11-22-33-44-55"_expect);
} // Note: Prerequisites are prepended (LinkedElements)
} // thus at each level the last ones appear first
Dispatcher-Pipeline: expected behaviour of (mock)Dispatcher
2023-06-12 23:15:39 +02:00
/** @test verify setup of a mocked Dispatcher instance
* - by default, MockDispatcher generates a single segment
* to span the whole Time-axis and with some random yet valid pipeline-ID,
* so that a single job ticket can be generated for each port everywhere
* - in addition, it is possible to use the same specification language
* as for Segmentation to define a more complex (mock)processing graph
* @note lacklustre ModelPort handling: processing graph is just duplicated for
* each valid model port — not clear yet if we ever need something better...
*/
void
verify_MockDispatcherSetup()
{
{
MockDispatcher dispatcher;
// automatically generates some fake connection points...
auto [port0,sink0] = dispatcher.getDummyConnection(0);
auto [port1,sink1] = dispatcher.getDummyConnection(1);
CHECK (port0 != port1);
CHECK (sink0 != sink1);
CHECK (port0.isValid());
CHECK (port1.isValid());
CHECK (sink0.isValid());
CHECK (sink1.isValid());
CHECK (not ModelPort().isValid());
CHECK (not DataSink().isValid());
CHECK (0 == dispatcher.resolveModelPort(port0));
CHECK (1 == dispatcher.resolveModelPort(port1));
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
Time frameTime{0,30};
size_t modelPortIDX = 0;
Job job0 = dispatcher.createJobFor (modelPortIDX, frameTime);
modelPortIDX = 1;
Job job1 = dispatcher.createJobFor (modelPortIDX, frameTime);
Dispatcher-Pipeline: expected behaviour of (mock)Dispatcher
2023-06-12 23:15:39 +02:00
CHECK (dispatcher.verify(job0, port0, sink0));
CHECK (dispatcher.verify(job1, port1, sink1));
}
//-----------------------------------------------------------------/// can define multiple Segments
{
MockDispatcher dispatcher{MakeRec()
.attrib("mark", 11)
.genNode()
,MakeRec()
.attrib("mark", 22)
.attrib("start", Time{0,10}) // second segment covers 10s … +Time::MAX
.genNode()};
Job-Planning: dispose of FrameCoord in pipeline and Dispatcher interface ...as a preparation for solving a logical problem with the Planning-Pipeline; it can not quite work as intended just by passing down the pair of current ticket and dependent ticket, since we have to calculate a chained calculation of job deadlines, leading up to the root ticket for a frame. My solution idea is to create the JobPlanning earlier in the pipeline, already *before* the expansion of prerequisites, and rather to integrate the representation of the dependency relation direcly into JobPlanning
2023-06-18 03:50:48 +02:00
size_t modelPortIDX = 1;
Job job0 = dispatcher.createJobFor (modelPortIDX, Time{0,5});
Job job1 = dispatcher.createJobFor (modelPortIDX, Time{0,25});
Dispatcher-Pipeline: expected behaviour of (mock)Dispatcher
2023-06-12 23:15:39 +02:00
CHECK (11 == job0.parameter.invoKey.part.a);
CHECK (22 == job1.parameter.invoKey.part.a);
}
}
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
};
/** Register this test class... */
LAUNCHER (MockSupport_test, "unit engine");
}}} // namespace steam::engine::test
Reference in a new issue Copy permalink