[Xquartz-dev] 2.3.3_rc1

[George Peter Staplin]

Quoted Jeremy Huddleston <jeremyhu at apple.com>:

> BTW, one more point I just want to clarify.  Are you certain that the
> version of vmd-xplor on all machines is identical and that they are all
> linking against the libGL in /usr/X11/lib/libGL.dylib?

Good point.  This may help identify what it's linked with:

otool -L /path/to/vmd-xplor

> You're good about that sort of thing, but I just wanted to be explicit
> since it might be possible to link against a Mesa libGL if it was built
> with MacPorts or Fink or some other package system.
>
> Also, as for dropping down to software rendering goes, I added support
> for two environment variables: LIBGL_ALWAYS_HARDWARE and
> LIBGL_ALWAYS_SOFTWARE.  See
> http://xquartz.macosforge.org/trac/changeset/304
>
>
> I'm thinking we should just eliminate LIBGL_ALWAYS_HARDWARE and default
> to that, but I'm going to let it sit for a few moments to see if George
> knows of a good reason why we might want to avoid that.

As I understand it, one argument against the kCGLPFANoRecovery I think  
I recall reading about involves multiple shared displays.

"kCGLPFANoRecovery
This constant is a Boolean attribute. If it is present in the  
attributes array, the OpenGL failure recovery mechanisms are disabled.  
Normally, if an accelerated renderer fails due to lack of resources,  
OpenGL automatically switches to another renderer. This attribute  
disables these features so that rendering is always performed by the  
chosen renderer. This attribute is not generally useful. Do not supply  
a value with this constant because its presence in the array implies  
true."

If you try to drag a window using that pixel format between multiple  
displays it might fail.

> You can grab this new lib here:
> http://people.freedesktop.org/~jeremyhu/libGL.1.2.dylib-r304.bz2
>
> Decompress it and replace /usr/X11/lib/libGL.1.2.dylib with it.
>
> Then on your 2008 MBP, try starting vmd-xplor with the
> LIBGL_ALWAYS_SOFTWARE environment variable set.  Similarly, try
> starting up on the older machines with LIBGL_ALWAYS_HARDWARE set
>
> Let me know how it goes.
> Jeremy
>
> On Mar 10, 2009, at 06:59, Jack Howarth wrote:
>
>> Jeremy,
>>  Could you clarify something here. When I run vmd-xplor (a ppc
>> legacy binary) under X11 2.3.3-rc1 on the following configurations...
>>
>> 1) dual G4 QuickSilver with Radeon 7500
>> 2) dual G5 Powermac with Radeon 9600
>> 3) late 2006 MacBook Pro with Radeon X1600
>>
>> in all those cases the OpenGL render reported by vmd-xplor is Apple
>> Software Render. Only in the instance of my 2008 MacPro with HD2600
>> graphics does it report hardware rendering. In the first three
>> cases vmd-xplor works fine. This would seem to imply that software
>> rendering in GLX is indeed possible but only that the LIBGL_ALWAYS_INDIRECT
>> isn't allowing the software rendering to be forced when hardware rendering
>> is the available.
>>  I could understand your decision to disable LIBGL_ALWAYS_INDIRECT
>> if the Apple Software Render was in fact being removed from X11's OpenGL
>> support but this certainly doesn't seem to be the case in X11 2.3.3-rc1.
>> It would seem rather arbitrary if that were true to disable
>> LIBGL_ALWAYS_INDIRECT since it prohibits the user from dropping down
>> into software rendering if there is bugs in the hardware rendering.
>>                                Jack
>>
>> On Tue, Mar 10, 2009 at 02:34:15AM -0700, Jeremy Huddleston wrote:
>>> Still not 100% correct.
>>>
>>> The SERVER still supports indirect rendering.  Our libGL does NOT
>>> support indirect rendering.  This means that you can ssh to your linux
>>> box and run OpenGL applications there, and they will use indirect
>>> rendering on the server.  This is hardware accelerated, but very slow
>>> since you're bottlenecking the rendering with the network latency.
>>>
>>> What you can't do is ssh to an OSX box and run OpenGL applications on
>>> the remote OSX box on your local X server.  If you *REALLY* want to do
>>> that, then you can compile your own libGL from mesa, and use that for
>>> the indirect GLX capability, but I think this is really an edge case of
>>> an edge use that I don't think will really affect many users.
>>>
>>> On Mar 9, 2009, at 23:47, Jordan K. Hubbard wrote:
>>>
>>>>
>>>> On Mar 9, 2009, at 11:34 PM, Martin Costabel wrote:
>>>>
>>>>> I don't understand what you are saying here. Or rather, I don't
>>>>> believe you are really saying what this sounds like. You are no
>>>>> longer supporting running X clients on remote machines? No more "ssh
>>>>> -Y"? This is too horrible to be true; please clarify.
>>>>
>>>> Jeremy is talking about OpenGL indirect rendering mode, not the
>>>> ability to run remote X clients.  Running an xterm over the wire is
>>>> fine, in other words, but if you're trying to run OpenGL apps remotely
>>>> then you won't be able to use the GLX extension (though you could
>>>> always use a software renderer like Mesa, of course).  Given the total
>>>> lack of sense in trying to use the fastest possible 3D acceleration
>>>> while simultaneously putting the client "far away" from the server,
>>>> this is nowhere near as limiting (or "horrible") as it sounds.
>>>>
>>>> - Jordan

George
-- 
http://people.freedesktop.org/~gstaplin/