OpenCL plug-in

[Michael Nischt]

Hi all,

First of all I have to say the project looks really nice to me! 

I like very much that it is lightweight with no or little dependencies and pure Java. On the other hand I was wondering if there are any plans to use OpenCL (via. LWJGL and/or JogAmp) in the future? For example as an alternative 'broadphase' implementation.

Best,

 Michael

[Morten Silcowitz]

Hi Micheal

Thanks for your interest!

Actually, i just recently did some CUDA work, and OpenCL + jinngine
crossed my mind. So yes, that would be really interesting.

What kind of broadphase system did you have in mind?

-morten

[Michael Nischt]

Hi Morten,

Sounds great! 

I was thinking about a Uniform Grid method since Sweep & Prune isn't easily parallelized for more then 3 cores (sorting along the 3 axes). Uniform grids are naturally suited for parallel algorithms but the disadvantage is that the largest bounds of a body determine the grid resolution. 

Also once, I starting thinking about a hybrid grid-based SAP which shouldn't suffer from this problem. However, I didn't think it through yet.

Best,

 Michael

I assume you know these already, but in case you don't:

[1] http://http.developer.nvidia.com/GPUGems3/gpugems3_ch32.html (Uniform Grid testing with CUDA)

[2] http://www.nvidia.com/content/GTC/documents/1077_GTC09.pdf (Bullet's OpenCL efforts)

[mo]

You're right, SAP probably is hard to do much about in terms of parallelism. Actually, SAP is not really adequate for large scale simulations. Do you think you could implement the hybrid grid-based SAP that you mention? :) 

Something that really eats CPU time is the constraint solving, as Erwin also indicates in his slides ([2]). A OpenCL implementation of PGS or NNCG in jinngine would really be exciting.

Let me know what you think

Morten 

[Michael Nischt]

Sure, both sounds like interesting topics - though I yet have to read your paper and dive into the details of NNCG :-)

However, I have to say upfront that I probably can only spend some hours per week contributing.

Btw. I've quickly written a LWJGL counter-part of the JOGLRendering class in the trunk and would love to push the file into the repository. How's the typical procedure?

Best,

 Michael

[mo]

Sounds good, have you considered writing a counter part for the version in geometry_rework? it will soon replace the one in trunk. 

The rendering stuff is really just there to provide the demos, and it is not something I give a lot of focus. So the thought of having both a LWJGL and a JOGL version to maintain scares me a bit :)  It is probably possible to separate the OpenGL stuff so that jogl and lwgl be interchanged seamlessly. Any thoughts on that? 

I think my JOGLRendering class is kind of a mess :) I guess people should not be encouraged too much to use it as a base for their own applications. But maybe it is important to give people a good "boilerplate" to get started? I know that many people favor LWJGL, but I'm unsure why. Does it support a broader range of drivers? 

[Michael Nischt]

Sure, porting the JoglRendering class from geometry_rework should not be much of an effort too. The only issue could be that LWJGL has no built in .tga support, so I would simply save the screenshots as .bmp using javax.imagio.

Also I agree, that the idea to maintain two rendering classes isn't ideal. Yet, the pure rendering code is only a few functions and the rest can be shared. As you said, it's just some code to let people visualize the the samples. Nothing which needs to be optimized regularly or beautified.

Regarding driver support, I don't think there a real difference between LWJGL and Jogl. Actually, I used Jogl for a really long time until a bug related to stereo rendering forced me to switch. It's probably all fixed by now but the after having used LJWGL it feels much cleaner and simpler to me. :-)

So should I go ahead and port the JoglRendering class from the geometry_rework branch?

[mo]

Yes, give it a go :)  Just send me a patch, and I will throw it into svn.

Let me know if there is any problems.

-Mo

[Michael Nischt]

Ok, looks like the JoglRendering implementation of the "geometry_rework" branch is much more complex as the one in the trunk ;-)

Please find my first attempt attached as a diff patch. 

In principle everything should work as before yet there still some things to be done:

- the LWJLRendering does not support screenshots yet

- both Rendering implementations should be launched via java.awt.EventQueue.invokeXXX (the awt event thread)

- the use of the GLRendering base class is pretty ugly so far

- bugs, ..?

Let me know what you think!

Best,

 Micha

[Morten Silcowitz]

Hi micha,

Just to let you know, I've been occupied with some work-related stuff,
but I'll throw in the patch as soon as i get some time. Thanks for the
contribution. And let me know if you have other suggestions for
jinngine.

-morten

[Michael Nischt]

Hey Morten,

Same here, work keeps me busy as usual.. but thanks for the feedback! I hope to find the time to think about a parallelizable Broadphase algorithm. 

Probably it's a good idea to start with a "stress" sample with a lot of objects and visualize frame-rate. What do you think?

Oh and is there a way to measure execution times of sub-components? What kind of profiling do you currently use?

-micha

[Morten Silcowitz]

On Mon, Feb 7, 2011 at 1:48 PM, Michael Nischt <michael...@gmail.com> wrote:
> Hey Morten,
> Same here, work keeps me busy as usual.. but thanks for the feedback! I hope
> to find the time to think about a parallelizable Broadphase algorithm.
> Probably it's a good idea to start with a "stress" sample with a lot of
> objects and visualize frame-rate. What do you think?

sounds right :)

> Oh and is there a way to measure execution times of sub-components? What
> kind of profiling do you currently use?

I use the YourKit profiler for java. It's quite useful. But i'm not
into the details on how it actually measures the work-load of
different components/functions.