<div dir="ltr">Hi Sujin,<div><br></div><div>What I want is a clear path for the transition from the current situation (all image filters implemented with vtkMultiThreader) to the eventual destination (all image filters implemented solely with vtkSMPTools).</div><div><br></div><div>Clearly, we're not at the "destination" yet.  The default vtkSMPTools backend is Sequential, which is an unsuitable replacement for vtkMultiThreader for obvious reasons.  You say we should remove Simple in favour of OpenMP, but you said the same thing many months ago :)  When is that actually going to happen?</div><div><br></div><div>The VTK imaging pipeline has been multithreaded for nearly as long as VTK has existed, so I'm not going to move forward into a situation where a VTK build with default cmake config causes these filters to run sequential.  That would be a nasty surprise to the users who depend on these filters.</div><div><br></div><div>That's why, at least for the transition period, I want these filters to use the old vtkMultiThreader implementation if the "Sequential" backend is selected.  I don't want any nasty surprises for the users of these filters, who expect them to continue to be multi-threaded just as they have been for the past 15 years.</div><div><br></div><div> - David </div><div><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 7:13 AM, Sujin Philip <span dir="ltr"><<a href="mailto:sujin.philip@kitware.com" target="_blank">sujin.philip@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi David,<br><br></div>I get what you are saying. Thanks for the correction :). <br><br>Why would you want to continue using vtkMultiThreader when Sequential or Simple is used? In fact, now that there is an openmp backend, we should be removing simple. It was only there to ease debugging since tbb had very complex back-traces. Openmp back-traces are much more readable. Do you want the algorithm to be multithreaded even when Sequential is used?<br><br>I think it should be quite easy to add a compile time "#define" based on VTK_SMP_IMPLEMENTATION_TYPE.<br><br></div>Thanks<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888">Sujin<br><br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 8, 2016 at 5:50 PM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Feb 8, 2016 at 3:37 PM, Sujin Philip <span dir="ltr"><<a href="mailto:sujin.philip@kitware.com" target="_blank">sujin.philip@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi David,<br><br></div>There is no official API to find out what the back-end is. I don't think there is a simple hack either. The back-end is supposed to be transparent to the user with the only visible difference being the performance. Why do you want to know?<br></div></div></div></blockquote><div><br></div></span><div>It's for the new vtkSMPTools implementation of vtkThreadedImageAlgorithm.  It would be nice if it could automatically default to using vtkSMPTools if a suitable backend is present, or use vtkMultiThreader if a vtkSMPTools backend is "Sequential" or "Simple".</div><div><br></div><div>Also, if there is no way to know what the backend is, then isn't it "opaque" rather than "transparent"?  :)</div><span><font color="#888888"><div><br></div><div> - David</div><div><br></div><div><br></div></font></span></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div>