<br><br><div class="gmail_quote">2008/12/2 David E DeMarle <span dir="ltr">&lt;<a href="mailto:dave.demarle@kitware.com">dave.demarle@kitware.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">&gt; One major goal of mine is to allow data to be processed in the background,<br>
&gt; and for it to &quot;appear&quot; on the screen when it is available.<br>
&gt;<br>
&gt; To cut a long story short (that long story is below if you keep reading), I<br>
&gt; want to know if VTK&#39;s pipeline can be part-push and part-pull ?<br>
<br>
</div>Theoretically one could modify vtkDemandDrivenPipeline (DDP) to<br>
support push. In practice writing a new Executive class would be far<br>
easier because DDP and its decendendents still need to do all the<br>
things there code is fairly complex,<br>
<div class="Ih2E3d"></div></blockquote><div><br>I&#39;ve noticed a lot of the filters seem to be built to directly support DDP, especially to support streamed or partial processing... so the work may be a lot broader than just a new Executive class.<br>
&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
&gt;<br>
&gt; longer story...<br>
&gt;<br>
&gt; I already have this working with a different 3D system... I have a data-push<br>
&gt; system that farms out jobs to a thread pool, and I had thought about<br>
&gt; reimplementing vtkDataDrivenPipeline so that certain jobs could be done in<br>
&gt; the background and when the job is complete, the data becomes available to<br>
&gt; the pipeline.<br>
&gt;<br>
&gt; But, I see a few problems with that...<br>
&gt;<br>
&gt; 1) I get the impression that when an actor or filter demands data, it<br>
&gt; expects to have the data after the call has completed.<br>
<br>
</div>This is true.<br>
<div class="Ih2E3d"></div></blockquote><div><br>another reason why Push would take a lot more work (i think) because the callers who are demanding data would have to be changed to either<br><br>a) filters expect async data in the middle of operations ... means they would have to be able to postpone their operations until later - difficult/impossible/slow if its in the middle of a lot of GL calls<br>
<br>b) know what it needs first, send the requests upstream, and only when the data is available, then process.&nbsp; forecasting requirements may be impossible in some filters, so it may just degenerate into a non-streaming/partial solution.<br>
<br>If you remove the need to support streaming, then all the filters could just execute and calculate their whole extents and then push that data up the chain...&nbsp; but you would need to ensure that all a filter&#39;s sources have finished updating before executing otherwise it would be either wasted computation or worse, executing on data sources that do not match up with each other.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
&gt; This can&#39;t be done in my thread-job world... the data is ready when its ready, and its pushed<br>
&gt; through the outputs, not pulled.<br>
&gt;<br>
&gt; 2) I am afraid that I&#39;ll lose the ability to use MPI to distribute load via<br>
&gt; the streaming system. &nbsp;In my system, the job is processed fully before the<br>
&gt; data is passed on (as a read-only reference or as a copy). &nbsp;Although that<br>
&gt; might be possible if I choose a filter at the end to put in a threaded job,<br>
&gt; and assign all its inputs into MPI executives. &nbsp;Then it&#39;ll execute in a<br>
&gt; thread but stream the data from its (MPI) inputs. &nbsp; That will benefit from<br>
&gt; task-level parallelism and better memory usage.<br>
&gt; Note that memory usage is not currently a problem, but things change...<br>
&gt;<br>
&gt; 3) This is doing things in threads. &nbsp;As we have said, its bad. &nbsp;I could<br>
&gt; potentially farm out the jobs to an MPI processor pool, which seems to be<br>
&gt; what VTK would do, but I am still stuck with a pull-based pipeline which<br>
&gt; freezes the GUI while it waits for processing to complete.<br>
&gt;<br>
&gt;<br>
&gt; What could I do?<br>
<br>
</div>I have done this before in ParaView by building a reader which has a<br>
method which can safely determine if the asynchronous process has new<br>
data ready (via asynchronous messages or file status) when it is<br>
ready, the reader calls Modified() on itself. Idle events at the<br>
source end of the pipeline (RenderWindowInteractor for example)<br>
periodically call this method and when necessary update the pipeline<br>
(pull) by calling render. In ParaView it is a bit more complicated<br>
than that because of the dataserver/renderserver/client breakup.<br>
</blockquote><div><br>when the reader calls Modified(), at which point is the data loaded into the pipeline?&nbsp; at the moment i must construct and copy the data into the pipeline while in the main thread, as I cannot build vtkDataObjects in a separate thread.<br>
<br></div></div>thanks,<br>Paul<br><br>