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. > Am Jun 30, 2009 um 22:11 schrieb "Andreas Kirsch (in.tum)" > <[email protected] > >: > > >> 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 >> [email protected] >> http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev >> http://www.equalizergraphics.com >> > > _______________________________________________ > eq-dev mailing list > [email protected] > http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev > http://www.equalizergraphics.com > > _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
