Hi Gordon, On 11. Jan 2008, at 14:03, Gordon_Erlebacher wrote:
> 1) I am running from home, having logged into a 2-GPU machine via > "ssh -X". All 1-pipe configurations > run fine. However, when I try a 2-pipe configuration, I get that I > do not have a display :0.1 available. > That kind of makes sense since I am remote. Are there other > arguments I can use with ssh to make > more than one display available? My home machine is a Macbook-Pro > with built-in X11 server. If you are running ssh -X your DISPLAY is tunneled from the remote to the local machine. Your $DISPLAY is typically set to localhost:10 on the remote machine. The 1-pipe configurations do not set the device and therefore $DISPLAY is used, which causes the window to be opened on your local machine. The 2-pipe configurations set the device, and therefore the local display is used (see eq::Pipe::getXDisplayString). In your case that means that 1-pipe configs display remotely, which is not performant since you are using indirect glX rendering through an encrypted ssh tunnel, which is magnitudes slower than direct, local rendering. I am not sure what you want to achieve, but if you want to use the 2- GPU machine to render and display the result on your home machine, you can write a configuration where you have the source channels on pipes with the device set to 0 and 1, and the destination channel on a pipe with no device set. The fact that you can't open :0.1 means most likely that your 2-GPU machine's X-Server can not be accessed. This is normal since nowadays the default installation uses xauth for security reasons. You have to disable this so you can access the X- Server even when you are not locally logged in. I don't remember how this is done right now, but google should help. When you can run 'xdpyinfo -display :0.1' it is set up correctly. > > > 2) When running eqPly, I cannot seem to load the .ply files > (rockingArm.ply). I execute: > > eqPly.64 -m rockingArm.ply > > and while the program (almost) obviously tries to read it, nothing > displays. Note that we compiled Equalizer > in 64 bit mode. Might that be the reason since ints, floats and > addresses are now 8-bytes and perhaps the file > format can no longer be read? eqPly creates a binary cache on the first load of the ply file. There is a cache file each combination of 32/64 and little endian/big endian, so this is not the reason. I suspect this somehow comes down to the indirect rendering. Unfortunately I don't have a test setup right now. I think you don't want indirect rendering anyway (see above) - if not let me know and I'll try to test somehow. > > > 3) Do you know of anybody that has combined CUDA or RapidMind with > Equalizer? That would be a worthwhile > effort in my opinion. I haven't heard of it. I agree that it is worthwhile and an interesting use case. Feel free to post your questions here and I'll try to help where I can. > > > 4) Do you have an example where you specifically control what you > write to different Pipes? In all examples I have > seen, the low level Equalizer software takes care of making these > decisions, once a compound type is chosen. I don't know what you want to control. In Channel::frameDraw you get the rendering context (viewport, range, eye, etc.) as configured in the config file. One could for example use the DB-range to map different channels to different tasks. Can you elaborate a bit on what you want to do? Please bear in mind that I have an understanding what CUDA/RapidMind is, but I haven't programmed in it so far. Cheers, Stefan. _______________________________________________ eq-dev mailing list [email protected] https://in-zueri.ch/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
