Re: Problem with X forwarding GL/Glut app
Re: Problem with X forwarding GL/Glut app
- Subject: Re: Problem with X forwarding GL/Glut app
- From: Laurens Timmermans <email@hidden>
- Date: Fri, 20 May 2011 21:50:06 +0200
On May 20, 2011, at 18:31 , Jeremy Huddleston wrote:
> Yeah... AIGLX is rather grotesque. This is likely a bug in mesa on the remote machine.
>
> Try doing this before executing your application:
> export LIBGL_ALWAYS_INDIRECT=1
I have tried this, but it does not make any difference. From what glxinfo tells me it already disabled direct rendering by itself.
>
> On May 20, 2011, at 08:20, Philip J. Schneider wrote:
>
>> But, it does look in this case that it might be some flavor of the problem discussed in the other thread you mentioned:
>>
>> http://lists.apple.com/archives/X11-users/2010/Jan/msg00028.html
>>
>> in which case it might be possible to apply the same sort of fix they discussed...
>>
>> At 8:13 AM -0700 5/20/11, Philip J. Schneider wrote:
>>> Running a gl-using X program over ssh, or even setting the DISPLAY variable to a non-local display, will often fail for programs that are run and displayed locally.
>>>
>>> There can be (at least?) two reasons for this:
>>>
>>> 1. The remote machine's GL version and/or its graphics card do not support some particular GL command (usually an extension), and the extension is being used without a proper check for its presence.
>>>
>>> 2. Some GL calls, for various other reasons, don't work correctly across a network connection (failure of proper wrapping in X protocol, etc.)
>>>
>>> (My apologies to the "real" X and GL experts who might find my terminology a little casual :-) )
>>>
>>> Both of these can be hard to track down in any program of any size. You can probably distinguish which case it is: if the failing program works when run locally on the remote machine, then it's #1; otherwise, it's case #2 (and also maybe case #1).
>>>
>>> For case #1, I'd recommend gDEBugger, and set it to break on gl errors. Your program may be "fixable" by adding an alternate code path(s) for commands that aren't supported. GLEW (or any of its alternatives) might be good to utilize here...
>>>
>>> For case #2: I'm not sure if gDEBugger will be of any help, but you could try it. Using GLEW to check for support might work, as well. Alternatively, add in a check for gl errors after every gl command (not a fun task in a very large program).
>>>
>>> Hopefully, other folks might volunteer with better ideas...I've run into either/both of these any number of times, and it's never been an easy fix. GL across a network can't necessarily be assumed to work the same as GL locally...
I think case #2 is what is going on here. I was probably not complete enough in my description of the problem (sorry). The program I am trying to run remotely is a CUDA application. I could imagine that this complicates things especially when it is combined with OpenGL.
I am going to give this alternative solution a try: http://www.timelordz.com/blog/2010/08/548/
Thanks for your help! _______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden