bb0b4578ec
move job planning implementation to separate compilation unit
2013-09-01 02:26:46 +02:00
3932a820a3
Job and JobClosure now located in the backend
...
- adjust namespaces
- fix imports
- forward the failure reason to the JobClosure implementation
2013-08-30 02:00:35 +02:00
488efdf783
WIP: relocate job descriptor into backend (Ticket #926 )
2013-08-30 01:23:07 +02:00
79370ad494
FrOSCon: review of job and job definition
2013-08-24 15:53:05 +01:00
ecf65a70fb
start a draft to shape the high-level interface for the Scheduler
2013-08-19 04:12:03 +02:00
f9cd80560c
complilation fixes
2013-08-18 03:16:49 +02:00
86e76bf7fe
define setup and chaining of render planning chunks ( #920 )
2013-08-17 03:37:36 +02:00
d192c42faa
fill in the definition how a job can be created
2013-08-17 01:35:07 +02:00
160dafebdb
WIP re-read the code, try to understand the problem to be solved
...
unfortunately there was an interruption of more than a month
since my last Lumiera contribution
2013-08-13 01:16:29 +02:00
1f1d478da2
WIP: move building of the follow-up anchor into the new closure
2013-06-16 04:36:32 +02:00
84281d5b60
WIP: CalcStream initialisation
...
especially: where to establish the effective Timings.
also fixed several compilation errors
2013-06-15 04:02:48 +02:00
77066ee3ce
WIP: how to start the actual calculation streams within EngineService
...
this draft fills in the structure how to get from an invocation
of the engine service to the starting of actual CalcStream instances.
Basically the EngineService implementation is repsonsile to
instruct the Segmentation to provide a suitable Dispatcher.
2013-06-03 05:25:13 +02:00
723096d3f2
WIP introduce a new kind of job closure to perform the planning
...
this might help solving that gordian knot related to the TimeAnchor,
the Dispatcher and the introduction of a possible playback strategy
2013-06-02 03:09:18 +02:00
082822fde8
relocate the JobClosure interface to be defined alongside of Job
...
This is necessary since the implementation of the job functions
calls through the VTable of the interface JobClosure. Thus this
interface (and the VTable definition) needs to reside within
some compilation unit linked together with the basic job class.
TODO: move class Job entirely into the Backend
2013-05-31 02:59:32 +02:00
56be672358
WIP: reworking the dispatcher interface
...
the goal is still how to introduce a playback strategy
2013-05-30 02:10:56 +02:00
8982223a4d
pondering about a suitable definition of a planning chunk ( #920 )
...
mostly this seems to be a matter of getting the terms
and meaning of the involved entities straight
2013-05-21 04:35:25 +02:00
e0c5b18740
draft indicator (helper) to support tree navigation
2013-04-29 01:36:32 +02:00
25be40bb4a
change PlanningStepGenerator end-of-sequence logic
...
basically I've changed my mind to prefer an
infinite JobPlanningSequence, which is just
evaluated partially. This removes the need to
embody the logic of planning chunk generation,
which really is a different concern.
2013-02-11 03:23:10 +01:00
7ada9ff291
consider how to integrate a playback mode strategy
2013-02-11 03:19:24 +01:00
30409e66bd
WIP: considering how to support non-linear playback modes
2013-01-13 23:20:20 +01:00
aca90f7ce8
DONE: mechanics of job planning
2013-01-12 14:36:01 +01:00
2b0e6d63c9
stop condition for chunk wise job planning
2013-01-12 12:49:26 +01:00
a4411d00b1
DONE: time anchor and latency handling for job planning
2013-01-12 12:38:33 +01:00
e40f3fe97f
introduce a render engine configuration facade
2013-01-12 11:17:29 +01:00
18605b0c19
handling of real time start offset
...
decision: the base for any deadline calculations
is the expected real time corresponding to the grid origin.
This value is contained in the Timings record.
2013-01-12 08:36:35 +01:00
72e5557d1e
locate the real time / nominal within engine::TimeAnchor
...
this clarifies the relation of TimeAnchor and Timings,
the latter act as a general spec and abstracted grid,
while the latter actually performs the conversion and
deadline checking
2013-01-11 18:12:40 +01:00
d18e36708d
re-read the code
...
OMG....
2013-01-11 16:48:28 +01:00
4ede0453be
resolve the remaining liblumieracommon.so dependency problems
...
now this library doesn't refer to any symbols from
Proc-Layer anymore. Resolving these problems
highlighted IMHO a serious shortcomming of our
interface system, which hinders the building
of abstractions at interface level
2013-01-04 07:45:18 +01:00
ef9a6e6f11
note some unresolved problems with our DummyPlayer
2013-01-04 06:00:35 +01:00
3d628b6eee
fix ill-guided linking of the DummyPlayer facade object type info
...
DummyPlayer is experimental code,
but actually we've established the convention
to linke the facade-proxies into common/interfaceproxy.cpp
2013-01-04 04:34:01 +01:00
1328ef4aa6
solution: how to retrieve syntactic representation
...
there is now a mechanism to allow sprcialised queries
to generate this syntactic representation only on demand
The actual concrete representation e.g. for scope queries
still remains TODO, but this won't really change
until we target the integration of a real resoloution engine
2013-01-02 04:18:05 +01:00
e902757a14
(DRAFT) refactor the way how to retrieve the syntactic query representation
...
there can't be a callback from the base ctor;
instead the subclass must pass a QueryText definition
2012-12-29 00:31:24 +01:00
a1d98eb457
restore and fix some broken tests
...
..more to come, especially several of the
QueryResolver based tests are still broken
2012-12-27 03:31:09 +01:00
933e486cf9
clarify some aspects of Session lifecycle
...
- consider especially where the reset of internal indices happens
- actively purge the Assets, the ConfigRules and Defaults
2012-12-27 02:31:58 +01:00
41f2820781
allow to clear the global Asset registration ( #154 )
2012-12-27 01:45:52 +01:00
384ee68129
allow simple query-for-pipe again (revert)
...
while refactoring, I thought it might be a good idea
only to use Query objects. But in this special case,
most often you'd just want to pass in a simple query
with a literal query string. So this convenience shortcut
indeed makes sense.
2012-12-26 02:20:11 +01:00
873d6c3d5c
re-activate some tests
2012-12-26 02:01:26 +01:00
1f6e71272a
simplify fake config rules table access
...
- since std::map is itself a smart-ptr, there is no need for an indirection
- directly use QueryKey as table key
2012-12-26 01:13:36 +01:00
d73c2fa842
adapt the fake-config-rules to use the new Query::Builder
2012-12-25 01:16:19 +01:00
bccb7a11b5
restore defs-registry Unit test
2012-12-22 22:01:51 +01:00
1bde72cccf
implement another builder function; adapt OutputDesignation
2012-12-11 04:45:18 +01:00
08ff817afd
implement builder/accesor function; adapt StructFactory
2012-12-09 02:42:36 +01:00
d306bb3cdf
fix includes
2012-12-03 00:18:18 +01:00
a79ba2c507
refactor use of HashVal typedef ( #722 )
2012-12-02 23:03:37 +01:00
5dfe5e099f
refactor namespaces for query and defaults manager
2012-12-01 08:44:07 +01:00
626b1d4356
re-arrange query- rules- and resolver facilities within Core
...
the rules-based configuration and query system
will be located within the core application,
while the concrete implementation facilities
are expected to reside within the session or
maybe also the GUI.
This is kind of a 'rochade' refactoring to resolve
circular library dependencies and confine the parts
dependant on the session and MObjects to the Proc-Layer
And while we're in the middle of chainsaw surgery,
we'll concentrate further query-based facilities
alongside the config-rules within the App core.
2012-11-27 02:17:21 +01:00
dd8a88d095
adjustments and stubbing to get it past the compiler
2012-11-26 01:22:01 +01:00
b5a7055f29
move Query interface to Lib
2012-11-25 02:29:52 +01:00
baefd74ae7
prepare refactoring of the Query interface
2012-11-25 02:04:19 +01:00
62bfccd67b
cleanup: remove the old factory template
...
This template was a leftover from the early days
of Lumiera development and doesn't provide any
substantial value as an abstraction.
For the more intricate cases, we're using the
lib::MultiFact template, which allows to install
several "fabrication" functions at runtime
2012-10-14 01:30:08 +02:00
954ebefc4c
draft implementation of the PlanningStepGenerator
2012-10-10 05:20:24 +02:00
44435fd1db
clarify and settle the relation between Dispatcher and PlanningStepGenerator
...
the solution is to introduce a superinterface
and let Dispatcher augment that with the specific parts.
This way, the Job planning only has to rely on the
rather generic stuff (TimeAnchor, FrameCoord)
NOTE: this commit makes the whole JobPlanning machinery
compilable for the first time!
2012-10-10 05:20:23 +02:00
3300d00cc8
WIP working towards a solution for generating frame location sequences
...
..the Idea is to rely on some kind of service,
to break the cyclic dependency with the Dispatcher.
But I seem unable to find a natural location or
concept to house that service.
2012-10-10 05:20:23 +02:00
ce5b940d39
WIP consider how to seed the evaluation of a JobTicket
2012-10-10 05:20:23 +02:00
14e6086488
better do initialisation by ctor
2012-10-10 05:20:22 +02:00
30cf0b5718
implementation of JobTicket::ExplorationState
2012-10-10 05:20:22 +02:00
062e1bbdc1
explicate the JobPlanningSequence definition
...
..causing the compiler to instantiate the
involved templates, i.e. get the complete
pipeline definition through the compiler
2012-10-10 05:20:22 +02:00
b52a1a8366
refactor JobTicket to remove the double layering
...
basically we had two lines of doubly nested capsules, due to
using the IterAdaptor template. Actually, the evaluation stack
within JobTicket can be considered an implementation detail and
thus doesn't require an iterator interface; the intention is to
use this through JobPlanning solely.
Thus this reworking removes the special iterator within JobTicket,
but retains the idea of exposing the "current" JobTicket through
a smart pointer or operator->()
work done during the FrOSCon travel
2012-10-10 05:20:21 +02:00
66defdc0cb
refactor JobPlanning to encapsulate all state mechanics into a "state core"
...
especially the exploration stack is pushed down
first successful definition of all the JobPlanning classes
just the framework of classes necessary to pass the compiler;
all implementation is still stubbed
2012-10-10 05:20:21 +02:00
a3bc69cc77
maybe a breakthrough on the job planning design quest?
...
why the hell is getting this design about right
such a chellenging task. Anyway, seems to be the
first step ahead after numerous failed attempts
2012-10-10 05:20:21 +02:00
e073d05f58
new header to define some class partially noncopyable
2012-10-10 05:20:20 +02:00
016a739a5c
WIP back to the original problem: how to dispatch jobs...
...
brainstorming how to implement the job planning stage
the idea is to built on top of the IterExplorer,
but have the "stack" of re-evaluation integrated
into a custom type, which exploits the static
node network structure to avoid heap allocations
solution idea: again use a builder function?
2012-10-10 05:20:20 +02:00
378ebe21f0
Fix naming of Iteration control API functions ( closes #410 )
...
comes in handy now, since IterStateWrapper uses a similar API
2012-10-10 05:20:15 +02:00
fa15a38016
draft JobTicket implementation datastructure
...
...but need an extension on our iterator helpers
to build a suitable functional datastructure
for generating Jobs.
2012-10-10 05:20:15 +02:00
3ef1fb7697
linked list helper template finished and passes test
2012-10-10 05:20:14 +02:00
ddff8b654b
WIP investigating the relation of Jobs, JobTicket and Closure in detail
2012-10-10 05:20:14 +02:00
4ceec90b9e
design decision how to invoke a job
...
without any trickery, we'll always get two indirections.
Thus, the decision is to turn the 2nd indirection
into a VTable call; this way, basically the JobClosure
also acts as job functor itself.
2012-10-10 05:20:13 +02:00
0320bc4b2c
considering the relation of Job and JobClosure
2012-10-10 05:20:13 +02:00
bb43c03ef9
stub all the job generating functions required for the dispatcher interface
2012-10-10 05:20:13 +02:00
79bd8b71e3
better treat the building of a continuation job separately
2012-10-10 05:20:13 +02:00
08d266819d
re-read my own code and pick up the design work
...
..next question is: how to shape the dispatcher interface,
in order to support ongoing chunk wise planning
of new jobs, including a continuation
2012-10-10 05:20:13 +02:00
7941865d5d
implement anchor against current system time
...
using CLOCK_REALTIME for now
2012-10-10 05:20:12 +02:00
882bcf07ae
define stubs for accessing the wall clock time (->Backend)
2012-10-10 05:20:12 +02:00
aa01813f52
TimeAnchor: draft calculating the start delay for rendering
2012-10-10 05:20:12 +02:00
ee1450a81a
rectify frame dispatch invocation
2012-10-10 05:20:12 +02:00
393a447861
test setup: simulated build proecss results, mock model port
2012-10-10 05:20:12 +02:00
f8f011bb44
rework Job representation
...
make class Job a real subclass of the
job definition struct and turn the
JobClosure into a trampoline
2012-10-10 05:20:12 +02:00
1e54b5d3e6
stubbing some job functions
2012-10-10 05:20:11 +02:00
db68577b4a
clarify relation of Job, JobTicket and channel number
2012-10-10 05:20:11 +02:00
875342fa40
initial draft for the job representation
...
this draft is based on
- Cehteh's draft for the scheduler
- my plannings about segmentation and JobTicket
it defines "Job" as a closure which can be invoked
from plain-C, using the information in the
job descriptor datastructure
2012-10-10 05:20:11 +02:00
e9dbb3bdb1
stubs for some important components of play/engine (JobTicket...)
...
also touches the question how to represent the job
descriptor datastructure. @Cehteh: I've just pasted
in your preliminary data struct definitinons
from the relevant mailing list discussions.
2012-10-10 05:20:11 +02:00
568fadd526
draft some steps of the dispatch operation
2012-10-10 05:20:10 +02:00
6772e94994
implement simple constant frame timings descriptor
2012-10-10 05:20:10 +02:00
157e3b6867
test-driven brainstorming: define default timings...
2012-10-10 05:20:10 +02:00
2cb254365c
some musing about timing constraints and quantisation
2012-10-10 05:20:10 +02:00
a4e3383367
turn Dispatcher into an interface
2012-10-10 05:20:09 +02:00
e581246f63
forming some entities to support the dispatch step
2012-10-10 05:19:56 +02:00
3768791c76
considerations how to connect exit nodes to external outputs
2012-10-10 05:18:58 +02:00
288b737718
dummy playback: stub the required operations
2012-10-10 05:18:58 +02:00
2eb39704fc
test-driven brainstorming: how to use the dummy playback?
...
this is an idea how to test a test setup :)
2012-10-10 05:18:58 +02:00
7e7ecc5d51
draft: integrating an engine mock implementation
2012-10-10 05:18:58 +02:00
ec659b7141
a better way to inject the Render-Engine Mock
...
instead of (ab)using the Timings spect for a
runtime switch, better use the existing
MockInjector facility and thus turn the
mock engine mode into a global switch
2012-10-10 05:18:57 +02:00
24911dc990
solution to integrate an Engine Mock implementation
2012-10-10 05:18:57 +02:00
687102feb3
planning next steps: how to transform DummyPlayer into a real player
2012-10-10 05:18:57 +02:00
f5290a99a3
OutputSlot : simulated usage protocol passes unit test
...
OutputSlotProtocol_test
Some parts are still missing
- timings
_ initialisation
2012-01-08 03:06:32 +01:00
d732e7e211
Lumiera Forward Iterators: remove support for post-increment
2012-01-08 01:14:36 +01:00
8de4ecc8ac
add diagnostic messages showing each connection access
...
currently the problem seems to be we're
accessing the wrong connection...
2012-01-07 21:22:35 +01:00
73cfef69c8
fix some problems with OutputSlotProtocol_test
...
still WIP...
- there is a logical contradiction with the frame numbers
- somehow, in diagnostics, we access the wrong sequence instance
2012-01-07 06:40:21 +01:00
5cc034d26b
refactor ScopedCollection to use an init() function
2012-01-07 04:44:48 +01:00
e41065101a
switch OutputSlot to use the ScopedCollection
...
..hehe, makes the code way more sane
2012-01-06 03:16:22 +01:00
f047069284
rearrange OutputSlot ConnectionStateManager
...
... shape the various APIs more clearly,
make most functions protected
2011-12-31 20:33:50 +01:00
06c7c27252
merge diagnostic facilities
2011-12-31 06:49:31 +01:00
dbb63ffc08
perfer STATIC_ASSERT to check for suitable placement-New buffer size
...
Still incomplete, but already this small change
detected an error in the output-designation. Cough.
2011-12-28 06:42:18 +01:00
50885a065b
move asside lib/format.hpp
...
...to make room for a new more specialised header
2011-12-27 07:44:49 +01:00
24a8d6a926
generalised diagnostic context passes unit test
2011-12-24 05:57:28 +01:00
451b0abec5
spelling and typos
2011-12-24 05:48:31 +01:00
d27e3b15a9
clarify the handling of specific output operation modes (e.g. number of channels)
2011-12-23 02:22:38 +01:00
7fc8473337
fix some size_t printf specs (32/64bit problem)
2011-12-19 03:02:48 +01:00
fa0588b584
refactor to simplify generating a PlayProcess
2011-12-18 02:02:55 +01:00
c4bc53b6f6
how to pass a render configuration strategy when creating a new play process
2011-12-17 22:37:53 +01:00
6852a6feff
WIP refactor building of the active render feeds
...
RenderConfigurator becomes an internal strategy
controlled by the PlayService
2011-12-17 04:45:42 +01:00
bda0dea990
clarify the relation of PlayProcess, CalcStream and EngineFacade
2011-12-17 02:20:48 +01:00
76b24ce50d
WIP draft the building of a render CalculationStream
2011-12-10 03:18:48 +01:00
8362145039
spelling and comments
2011-12-10 03:13:45 +01:00
477b443191
implement diagnostic OutputSlot simple frame tracking
...
...should be enough to run tests against the OutputSlot interface
2011-12-09 01:03:02 +01:00
aef3d50ffd
implement basics of the diagnostic OutputSlot
...
...specific diagnostic facilities still lacking
2011-12-08 23:02:19 +01:00
77548e74c6
document a weakness of boost::hash for strings
2011-12-03 03:18:03 +01:00
7fd28e23eb
cleanup configflags to use uint instead of char
...
using char for those flag template parameters
was never a good idea. It won't save us any space
and makes debugging harder
2011-12-03 03:16:08 +01:00
d9f84a9bfd
clean up lib/meta namespaces
2011-12-03 03:15:59 +01:00
b9d1899486
cleanup: rectify Proc-Layer namespaces (II)
2011-12-02 17:50:44 +01:00
eb79a00cf4
cleanup: rectify Proc-Layer namespaces (I)
2011-12-02 16:10:03 +01:00
89a9202c6c
cleanup: remove precompiled headers
...
we don't need them and they even tend to
increase build times due to unnecessary
compound-includes at some core headers
2011-12-01 23:32:34 +01:00
7ba8ff432f
BufferProvider interface finished thus far.
...
simulated lifecycle passes unit test
2011-11-26 00:09:59 +01:00
55a77bdd73
factor out and treat the attaching of objects separately
...
this is an advanced feature not required
in the standard buffer usage cycle
2011-11-25 20:23:31 +01:00
ce25be6fa3
refactor relation of BuffHandle and BufferDescriptor
...
they are now tightly coupled and assumed to
work together; there is no need to relay half
of BuffHandle's interface through BufferDescriptor
2011-11-25 18:20:01 +01:00
d6b069fbbd
clean-up after refactoring
2011-11-25 17:29:06 +01:00
eed6d8cd1e
split out obsolete ChannelDescriptor for later refactoring
...
Meanwhile, BuffHanle became way more concrete,
making the separation of any kind of buffer or channel
type management concievable.
Thus: extract the obsolete ChannelDescriptor
and use switch at any location where the old
(superseeded) buffer handle is still referred
2011-11-25 17:16:33 +01:00
74702ebecd
address the next test...
2011-11-24 03:33:23 +01:00
2ae1e3c8f9
test/dummy buffer provider finished and passes test
2011-11-21 03:26:08 +01:00
d6de8c8d1a
implement some missing nits and bits
2011-11-21 02:28:44 +01:00
91b74ad7bd
implement missing parts of test/dummy buffer provider
2011-11-20 01:35:52 +01:00
3830ff7ce1
refactor the test/dummy provider, based on ScopedPtrVect solely
...
instead of using a vector directy, move the
additionally required functinoality in the
utility class. This forced me to adjust
the IterAdapter, to allow working with
STL algorithms
2011-11-19 17:51:08 +01:00
27449c1438
implementation details of a test/dummy provider
2011-11-18 01:23:50 +01:00
623bb401af
clarify implementation extension points of BufferProvider
...
decide especially how to pass on the implementation
defined data like e.g. pointers to storage extents
2011-11-15 04:47:31 +01:00
d1d0f66fa8
allow LocalKey to carry arbitrary pointers or hashes as payload
...
...used to piggyback opaque implementation data,
deliberately no typecheck here
2011-11-15 04:46:00 +01:00
6bc94cccb5
WIP refactor BufferProvider public and protected API
2011-11-14 01:43:29 +01:00
890b6e8366
WIP implementation details of diagnostic BufferProvider
2011-11-13 04:20:14 +01:00
ca0aa23479
BufferProvider default impl: attaching a type
2011-11-12 00:36:53 +01:00
fd94367b9e
stubs and changes to make the test compile
2011-11-11 23:33:59 +01:00
fe1ae51b49
WIP draft test for internal test buffer provider
...
a test to cover a helper for writing tests ;-)
2011-11-11 01:44:01 +01:00
f75e55a060
nail down a lot of OutputSlot implementation details
2011-11-08 02:59:56 +01:00
59dfb7c660
start drafting a (dummy) output slot implementation
...
this implicates a first attempt to build a
dummy buffer provider implementation.
Mostly just defining stubs here....
2011-11-07 01:57:33 +01:00
c8458ab397
improved diagnostics
2011-11-07 00:50:03 +01:00
a88ccd219d
extract the diagnostic BufferProvider into separate header
2011-11-07 00:07:53 +01:00
7ab7c8073d
remold OutputSlot implementation structure
...
Better solution where to place the extension points
to be implemented by concrete output systems
2011-11-06 02:37:22 +01:00
63dbc89b6f
draft implementation setup for OutputSlot baseclass
2011-11-05 16:51:24 +01:00
d6e88c85e0
finish buffer metadata; cover state transitions
...
BufferMetadata complete and working for now
2011-11-02 01:34:05 +01:00
931dc3f883
draft: automatically invoke an attached ctor/dtor functor
2011-10-30 05:35:36 +01:00
ccd130966b
finish and pass the first round of tests
...
still missing:
- implementation of a Mock frame
- automatical invocation of the TypeHandler
2011-10-30 02:19:10 +02:00
e7f0211711
better solution for calculating the Key for a concrete Entry
2011-10-30 01:17:31 +02:00
