[eq-dev] Numerical Simulation and Visualization

[Andreas Kirsch (in.tum)]

Hello,
I want to write a PDE simulation and parallelize it using Equalizer. I
only have no idea how to go on about the exact design.

The application consists of two parts:
* simulation
* visualization
Simulation:
I have a volume of cells I need to update every frame (e.g. some fluid
or gas) using the GPU because of its parallel computing power. It's a
big cubic array of data and I'd like to split it up into sub cubes and
keep and update the data on different nodes.
That is every node contains a certain sub volume and the different nodes
only need to exchange the boundary data.

Visualization:
The visualization part would require volume rendering using a standard
approach ala eqEvolve to parallelize. Every node would contribute a
rendering of the data it has available locally.

I have no idea whether Equalizer offers any features for doing such
general purpose computing (that is, I haven't found any) and I'd like to
know whether there is already anything built in or if there is anything
planned.
Also I have difficulties imagining how to express both parts of the
application in the Node/Pipe/Window/Channel paradigm.

I also have a related question regarding the network code:
If I were to code the simulation part on my own, I'd need to send some
specific data to each node from each adjacent node. Using the current
network model my idea would be that each node has a "state" master
object and nodes that are interested in the node's state (it would
contain the boundary surface data for example) would subscribe to that
object and sync to it every time they need to access the data.
The question is how do I tell other nodes about my state node?
Is the only way using custom commands?
It would be nice if there was a way to do this transparently. I've seen
there exists a method called becomeMaster(), but it only updates the
former master object and not its slaves. My idea would have been to
create the state objects at the app node first, all nodes map the
general state object and each node then takes over ownership of its
corresponding state object, but this obviously will run into issues
using the current becomeMaster() method.

That's a lot of text, I hope I was able to communicate my problem(s). I
also hope that someone can help me with it and nudge me into the right
directions.
Also, if there is anything way too unclear, I'll be happy to elaborate
on it.

Thanks and cheers,
Andreas Kirsch

_______________________________________________
eq-dev mailing list
eq-...@equalizergraphics.com
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

[Philippe Robert]

Hi,

it's good that you bring this up. We indeed have concrete plans to
extend Equalizer in such a way that GPU based simulations and other
GPGPU applications can be integrated seamlessly. Until this is the
case you have to do a bit more work by yourself, but it is still
possible.

In your case you could integrate the compute tasks into the window's
or channel's draw function. To distribute the updated data you then
might want to use custom events and let the master send the relevant
changes to the clients on a per frame basis. Does this make sense to
you?

I am aware that this approach is probably not optimal, but it works.
We will soon provide a simple example that outlines the basic idea.

BTW if there are others on this list who are interested in doing GPU
computing using Eq, please let me know!

Cheers,
Philippe

Am Jun 30, 2009 um 22:11 schrieb "Andreas Kirsch (in.tum)" <kirs...@in.tum.de
>:

[Andreas Kirsch (in.tum)]

Hello Philippe,

Philippe Robert wrote:
> Hi,
>
> it's good that you bring this up. We indeed have concrete plans to
> extend Equalizer in such a way that GPU based simulations and other
> GPGPU applications can be integrated seamlessly. Until this is the
> case you have to do a bit more work by yourself, but it is still
> possible.
>
> In your case you could integrate the compute tasks into the window's
> or channel's draw function. To distribute the updated data you then
> might want to use custom events and let the master send the relevant
> changes to the clients on a per frame basis. Does this make sense to
> you?
>

Yeah, this sounds good. It would probably be better though to exchange
data directly between clients because otherwise the master might become
a bottleneck bandwidth-wise, but it should be sufficient for testing.

> I am aware that this approach is probably not optimal, but it works.
> We will soon provide a simple example that outlines the basic idea.
>

Neat, this sounds like a very good thing to do.

> BTW if there are others on this list who are interested in doing GPU
> computing using Eq, please let me know!
>
> Cheers,
> Philippe
>

In my opinion GPGPU support would be a major feature and supporting
things like load balancing inside the library would be a great selling
point, because that is generally a big PITA when working on
parallelizing projects and having a middle ware for that would be nifty.
Since support for FBOs and offscreen-rendering was added to Equalizer I
think one could naturally extend Equalizer's design from canvases and
frames, etc. to computing tasks and data dependencies that are more
complex than the currently supported ones.
Thanks for your quick and helpful reply.

Cheers,
Andreas

PS: Im resending this because there was a problem with my uni email
account and I couldnt find the message in the eqdev archive. My
apologies if you have already received it.

[Philippe C.D. Robert]

Hi,

On Jul 3, 2009, at 6:40 PM, Andreas Kirsch (in.tum) wrote:
>> In your case you could integrate the compute tasks into the window's
>> or channel's draw function. To distribute the updated data you then
>> might want to use custom events and let the master send the relevant
>> changes to the clients on a per frame basis. Does this make sense to
>> you?
>>
> Yeah, this sounds good. It would probably be better though to
> exchange
> data directly between clients because otherwise the master might
> become
> a bottleneck bandwidth-wise, but it should be sufficient for testing.

I have just committed a basic example which shows exactly how to
achieve that using sort-first distribution; i.e. using point-to-point
communication. It is a simple port of the nbody example from the CUDA
SDK. Hence, it is by no means efficient because there are far too many
memory transfers and GPU up/downloads involved, but it illustrates the
strategy quite well I hope.

More to come...

cheers,
Philippe

[Andreas Kirsch (in.tum)]

Hello Philippe,
thank you very much. I'm going to take a look at it now.
Cheers,
Andreas