Here's why it may be handy to expose the thread parameter: Is the over() operator being called from one main thread, in which case the way to best utilize cores is for over() to launch a bunch of threads to divide its work? Or is over() being called by one thread within an already-multithreaded program, in which case it would not be wise to spawn a bunch of daughter threads, and instead you should just work with the one thread you are given. The over() op can't tell this, but its caller should know.
SSE is not threads. There's no reason why the core implementation of over() [or any other op] couldn't use SSE math internally. GPU is a harder call, but I suppose an op that internally can detect and use a GPU to accelerate its implementation could just ignore the threads parameter. On Jun 8, 2012, at 2:28 PM, Daniel Wexler wrote: > Yeah, what Larry said. > > I would NOT resize the destination image and just fail. For point-based image > ops, the images should be sized by the caller. For area ops, this gets much > harder. As always, hard failures are easier to debug than soft errors. > > I would NOT expose a thread argument directly. That is already too much of > the implementation exposed. There might be tons of ways to improve > performance via threads. I don't like the idea of somehow baking the > implementation into the public API. What about GPUs? SSE or other vector ops? > Do those count as threads? It is unclear, so I'd leave it out of the > top-level entry point and try to find some alternative way of controlling > those implementation details. > > I would expose a ROI in the public call. If this were my code, I'd require > the images to be the same size and NOT specify an ROI, but instead, the > typical solution is to define an ImageReference class, which derives from the > base Image class, defining a ROI, but only *referencing* the image data. But, > I'm not familiar enough with the OIIO image classes to know how this would > affect things. It generally means a more fundamental change to the way > everything works that probably won't work if it isn't already supported. So, > if that's not possible here, I'd pass an ROI. > > > On Fri, Jun 8, 2012 at 2:19 PM, Stefan Stavrev <[email protected]> > wrote: > 1. class ROI looks really nice. > > 2. Do we need a separate function "parallel_image" for each image processing > operation since most of them will have different signatures, different number > of input images, etc., and threads in parallel_image are managed in a way > that depends on the signature of the function being called? > > We can get away with something much better I think, could we have a case > statement on lines 455 and 462 in src/maketx/maketx.cpp, to handle functions > with different signatures? The case would branch based on a parameter that > would say which signature we are dealing with, it could be an enum. No matter > what the signature is, this should work, assuming the image processing > function works with image regions. I mean, if it works with image regions, it > can be divided, so we are fine. > > Stefan > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
