[Xquartz-dev] 2.3.3_rc1

Jack Howarth howarth at bromo.med.uc.edu
Tue Mar 10 15:22:48 PDT 2009 

Jeremy,
  Okay. I have figured out the Apple Software Render usage. When that
was used for the OpenGL render in vmd-xplor, I had not deleted or
renamed the copies of libGL and libGLU provided in vmd-xplor-1.5.1-Darwin_8/bin.MACOSX.
If I remove those local copies from the vmd-xplor installation, hardware
rendering is used under X11 2.3.3-rc1 on a dual G4 with Radeon 7500 graphics
and vmd-xplor behaves normally. However if I do the same on my MacBook Pro
with Radeon X1600 graphics, I get the following errors with vmd-xplor
-debug -nowin and with...

LIBGL_DIAGNOSTIC=1
export LIBGL_DIAGNOSTIC

added to the vmd-xplor startup script...

Info) VMD for MACOSX, version 1.8.5 (September 19, 2006)
Info) http://www.ks.uiuc.edu/Research/vmd/                         
Info) Email questions and bug reports to vmd at ks.uiuc.edu           
Info) Please include this reference in published work using VMD:   
Info)    Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual   
Info)    Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
Info) -------------------------------------------------------------
Info) Multithreading available, 2 CPUs detected.
ERROR) filetype argument '-debug' needs a filename.
Xlib:  extension "Generic Event Extension" missing on display "/tmp/launch-FIgrW9/:0".
initializing libGL in apple_init_glx
DIAG: CGL major 1 minor 2
Xlib:  extension "Generic Event Extension" missing on display "/tmp/launch-FIgrW9/:0".
WARNING: unknown GLX tag from server: tag 0xb019fe04 value 0x1106b5
WARNING: unknown GLX tag from server: tag 0x17c7dab0 value 0x0
WARNING: unknown GLX tag from server: tag 0xb019fe04 value 0x4ce360
WARNING: unknown GLX tag from server: tag 0x4fe19b0 value 0xb5061100
WARNING: unknown GLX tag from server: tag 0xb0dac717 value 0x0
WARNING: unknown GLX tag from server: tag 0x4fe19b0 value 0x60e34c00
...
WARNING: unknown GLX tag from server: tag 0xb019fe04 value 0x4ce360
WARNING: unknown GLX tag from server: tag 0x4fe19b0 value 0xb5061100
WARNING: unknown GLX tag from server: tag 0xb0dac717 value 0x0
WARNING: unknown GLX tag from server: tag 0x4fe19b0 value 0x60e34c00
DIAG: apple_glx_create_context: ac 0xc4e080 ac->context_obj 0x100cc00
DIAG: apple_glx_drawable_create: new drawable 0x100f200
X Error of failed request:  BadRequest (invalid request code or no such operation)
  Major opcode of failed request:  128 (Apple-DRI)
  Minor opcode of failed request:  2 ()
  Serial number of failed request:  40
  Current serial number in output stream:  40
+ '[' 0 -eq 0 ']'
+ '[' 0 -eq 0 -a SS = DP ']'
+ rm -rf /var/tmp/howarth-ve0

If I set LIBGL_ALWAYS_SOFTWARE before running vmd-xplor, I still get a
failure...

Info) VMD for MACOSX, version 1.8.5 (September 19, 2006)
Info) http://www.ks.uiuc.edu/Research/vmd/                         
Info) Email questions and bug reports to vmd at ks.uiuc.edu           
Info) Please include this reference in published work using VMD:   
Info)    Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual   
Info)    Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
Info) -------------------------------------------------------------
Info) Multithreading available, 2 CPUs detected.
ERROR) filetype argument '-debug' needs a filename.
Xlib:  extension "Generic Event Extension" missing on display "/tmp/launch-FIgrW9/:0".
initializing libGL in apple_init_glx
DIAG: CGL major 1 minor 2
Xlib:  extension "Generic Event Extension" missing on display "/tmp/launch-FIgrW9/:0".
WARNING: unknown GLX tag from server: tag 0xb019fe04 value 0x1106b5
WARNING: unknown GLX tag from server: tag 0x17c7ed20 value 0x0
WARNING: unknown GLX tag from server: tag 0xb019fe04 value 0x4ce360
WARNING: unknown GLX tag from server: tag 0x4fe19b0 value 0xb5061100
WARNING: unknown GLX tag from server: tag 0x20edc717 value 0x0
WARNING: unknown GLX tag from server: tag 0x4fe19b0 value 0x60e34c00
WARNING: unknown GLX tag from server: tag 0xb019fe04 value 0x1106b5
...
WARNING: unknown GLX tag from server: tag 0xb019fe04 value 0x4ce360
WARNING: unknown GLX tag from server: tag 0x4fe19b0 value 0xb5061100
WARNING: unknown GLX tag from server: tag 0x20edc717 value 0x0
WARNING: unknown GLX tag from server: tag 0x4fe19b0 value 0x60e34c00
libGL: Software rendering forced.
DIAG: apple_glx_create_context: ac 0xc4e080 ac->context_obj 0x100cc00
DIAG: apple_glx_drawable_create: new drawable 0x1007e00
X Error of failed request:  BadRequest (invalid request code or no such operation)
  Major opcode of failed request:  128 (Apple-DRI)
  Minor opcode of failed request:  2 ()
  Serial number of failed request:  40
  Current serial number in output stream:  40

It is very strange that X11 2.3.3-rc1 with the test libGL.r304 works fine
on PPC but fails on Intel Darwin. I should note that vmd-xplor has had
problems on Intel Darwin for sometime now (hence the kludge of setting

               VMDSIMPLEGRAPHICS=1
                LIBGL_ALWAYS_INDIRECT=1

on that platform. Could you take a look at this to see if vmd-xplor
is tickling some latent bug with Rosetta and X11?
                Jack

On Tue, Mar 10, 2009 at 12:31:22PM -0700, Jeremy Huddleston wrote:
> 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

More information about the Xquartz-dev mailing list