[Xquartz-dev] 2.3.3_rc1

[Jeremy Huddleston]

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?

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.

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
>>>
>>> _______________________________________________
>>> Xquartz-dev mailing list
>>> Xquartz-dev at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev