I have looked through a good deal of the forum posts in regard to running the ATI stream apps remotely. Some posters claim that it is possible to run remotely. I have attempted both the official AMD recipe for running remotely, to no avail and the other ones (there is an example for a CentOS box, for example). I am running openSUSE 11.1 on an AMD64 box, with an ATI HD 4850 card.
Is there any possibility of running the examples via ssh without any tricks to the X server? My needs are not gaming, but, rather, scientific computing. I would like to run some jobs batched without necessarily logging into the box via console.
Thank you all!
Hi Greg, unfortunately, ultimately CAL still needs to go through the display driver for now and that path is through the X Windows server.
When you disable the security feature of the X server and log in via ssh and set your DISPLAY variable to :0.0, are you able to do an xdpyinfo?
I run the xdpyinfo and get:
No protocol specified
xdpyinfo: unable to open display ":0.0"
PS Great job on this stream project and related technologies...
Just take make sure it is just the security setting that are getting messed up, try this first...
At the console, log into the X server and then in an xterm or other shell, type "xhost +" to effectively disable security.
Then, without logging out of the X server, ssh into the machine remotely and try xdpyinfo with your DISPLAY set to :0.0
This should work.
Then, try running FindNumDevices in the /usr/local/atical bin directory. That should work as well.
If this all works, we just need to figure out why your X server config file changes didn't take. Which file did you modify and what did you do to it?
Yes, Michael! That did the trick.
I modified my bash.bashrc file to get the DISPLAY set.
In /etc/gdm/custom.conf, I added:
command=/usr/bin/Xorg -br -ac -audit 0
I do notice that
# SuSEconfig: displaymanagerISPLAYMANAGER_ROOT_LOGIN_REMOTE,DISPLAYMANAGER_SHUTDOWN, securityERMISSION_SECURITY
I wonder if this is/was the culprit?
In my /etc/gdm/Init/Default file I have set:
chmod uog+rw /dev/dri/card*
Thank you very much!
Yeah, this is the catch about this workaround... different systems have slightly different X Windows setups. Were you sshing as root or as a normal user?
One thing I've done in the past when debugging X Windows setup issues for remote stream app execution was to do a "ps ax | grep X" and look for the "/usr/bin/Xorg -br -ac -audit 0" to make sure that it was being executed instead of the default X server invocation. I've found that what worked on one distro didn't work on another distro.
There is a project going on in parallel to look into get rid of this necessity, but for the time being, this trick is what I use on the machine sitting in my office. 🙂
I was ssh-ing in as a regular user and then su to root. Do you think that matters?
I have checked for the Xorg server's instance using ps ax | grep X, but I never see "/usr/bin/Xorg -br -ac -audit 0"
Hmm... it would seem then that the changes you made didn't take. I don't have an openSUSE system setup here (it's not yet an officially setup for ATI Stream SDK v1.4). I'll try to setup an openSUSE machine (probably under VMWare) and fiddle around with the settings. It might take a week or 2 though since I've got to take care of some other things first.
Hi Greg, managed to try this with OpenSUSE 11.0 on VMWare...
I modified /etc/gdm/custom.conf with the updates you made. When I kill the X server and it restarted, it didn't have "-ac" in it. But, when I rebooted, I discovered that "-ac" was now in the command line of the X process and when I did an export DISPLAY=:0.0 and ran xdpyinfo, it worked.
Did you reboot? Or I think you can also run gdm-restart to get it to reread the config file.