Well, IMO the way to go for parallelization should be done in the following
way
- Check for GPU support for OpenCL/CUDA. If yes, then use GPU for
parallelization.
- Else use threads, if there are multiple processors.
- Else carry on with the good old process.
Regarding the number of tasks in my application, and taking into
consideration the amount of work required just for parallelization of
lighter2, it is indeed too much for one summer.
I believe it would be great if Scott Johnson could let me know that exact
what amount of work can be done to improve the photon mapping module and how
much work would be required to make it integrate into lighter2 and b sure to
quite an extent that it is stable. I believe that it would require quite
some amount of actual testing before we can say that it is stable and
integrate it into the trunk.
I would probably add/remove tasks from my application appropriately.
Regards,
Mohit Taneja
On Tue, Mar 23, 2010 at 10:00 PM, res <re...@gmx.ch> wrote:
> On 23.03.2010 16:15, Christian Van Brussel wrote:
> > - you are talking about multi-threading the lighting process. It seems to
> > me that it is better to parallelize the process on the GPU instead of the
> > multi-cores CPU. I'm not sure whether it is better to do it through some
> > shaders or CUDA/OpenCL (which are not yet supported by all graphic
> cards).
>
> Some thoughts:
> - This is IMO better fitting for CUDA/OpenCL than OpenGL shaders: it
> fits better into lighter2's "no actual rendering" approach.
> - Isn't OpenCL intended to blur between GPU and CPU processing, anyway?
> That would take care of the multi-core vs GPU acceleration question anyway.
> - The problem could also be approached on a conceptual level: at the
> base, the currently serial lighting has to be turned into a processing
> of distinct, independent chunks. Once that is done, with correct
> abstraction it would arguably be possible to later add alternative
> processing implementations, eg "classic" threads in addition to OpenCL
> or vice versa.
> - For OpenCL, keep in mind that lighter2 should keep working even if
> OpenCL is not available! (Implementations only start to pop up now, so
> this is a very real possibility.) With this is mind, an approach like
> "flexible design, CPU/multi-core first, GPU/OpenCL later" might be most
> desireable.
>
> Hmm. This starts to look complicated. Networking is beyond the scope of
> any SoC project to start with... but even "simple" parallelization
> doesn't seem so simple any more. Taking all what I said above into
> consideration makes lighter2 parallelization a project on it's own
> merits, it certainly seems to be out of proportion as an "appendix" to
> photon lighting.
>
> With the specific application in question, points 1,2,4,5,6 without 3
> seem more than plenty for a project. They all fit nicely under an
> umbrella of "improved lighting with photon mapping". I'd rather see
> quality in implementation(+ results ;) than a quantity of features.
>
> -f.r.
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Crystal-main mailing list
> Crystal-main@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/crystal-main
> Unsubscribe: mailto:crystal-main-requ...@lists.sourceforge.net
> ?subject=unsubscribe
>
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Crystal-main mailing list
Crystal-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe:
mailto:crystal-main-requ...@lists.sourceforge.net?subject=unsubscribe
