Hi z,

Thank you for your followup.  Unfortunately we have this problem regardless of whether a valid xorg.conf exists on the remote system, or whether the X server is started on the remote system.

We have verified this problem using both the latest nvidia driver from elrepo and the latest driver from nvidia.com.

Any other suggestions would be greatly appreciated.  One workaround would be to install the nvidia driver on all systems regardless of what their graphics card is, but I'm somewhat reluctant to proliferate proprietary drivers where they shouldn't be needed.  This certainly wasn't needed with SL5.

It would also be helpful to know if anyone else with a mixed nvidia / non-nvidia environment can reproduce this proble

Thanks again,
Devin

On Apr 6, 2012, at 12:12 PM, Devin Bougie wrote:

> Hi, All.  We're seeing a problem running opengl on a remote SL6 system when the local system uses the proprietary nvidia drivers.  This does not seem to be a problem with remote SL5 systems.
> 
> The problem seems to only be when sitting at a local system with the nvidia drivers (tested with local SL5, SL6, and OS X) and running opengl on a remote SL6 system that doesn't have the nvidia drivers.
> 
> I think the example below probably demonstrates this better than my description.  Any suggestions would be greatly appreciated, and please let me know if there is any more information we can provide.
> 
> Many thanks,
> Devin
> 
> ------
> [dab66@lnx246 ~]% glxinfo |head -n 15
> name of display: :0.0
> display: :0  screen: 0
> direct rendering: Yes
> server glx vendor string: NVIDIA Corporation
> server glx version string: 1.4
> server glx extensions:
>   GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, 
>   GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, 
>   GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, 
>   GLX_ARB_create_context_profile, GLX_EXT_create_context_es2_profile, 
>   GLX_ARB_create_context_robustness, GLX_ARB_multisample, 
>   GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_framebuffer_sRGB
> client glx vendor string: NVIDIA Corporation
> client glx version string: 1.4
> client glx extensions:
> 
> [dab66@lnx246 ~]% ssh sl5-no-nvidia
> [dab66@sl5-no-nvidia ~]% glxinfo |head -n 15
> name of display: localhost:11.0
> display: localhost:11  screen: 0
> direct rendering: No
> server glx vendor string: NVIDIA Corporation
> server glx version string: 1.4
> server glx extensions:
>   GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, 
>   GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, 
>   GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, 
>   GLX_ARB_create_context_profile, GLX_EXT_create_context_es2_profile, 
>   GLX_ARB_create_context_robustness, GLX_ARB_multisample, 
>   GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_framebuffer_sRGB
> client glx vendor string: SGI
> client glx version string: 1.4
> client glx extensions:
> 
> [dab66@lnx246 ~]% ssh sl6-no-nvidia
> [dab66@sl6-no-nvidia ~]% glxinfo
> name of display: localhost:27.0
> Error: couldn't find RGB GLX visual or fbconfig
> 
> [dab66@lnx246 ~]% ssh sl6-nvidia
> [dab66@sl6-nvidia ~]% glxinfo |head -n 15
> NVIDIA: could not open the device file /dev/nvidiactl (Permission denied).
> name of display: localhost:10.0
> display: localhost:10  screen: 0
> direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
> server glx vendor string: NVIDIA Corporation
> server glx version string: 1.4
> server glx extensions:
>   GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, 
>   GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, 
>   GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, 
>   GLX_ARB_create_context_profile, GLX_EXT_create_context_es2_profile, 
>   GLX_ARB_create_context_robustness, GLX_ARB_multisample, 
>   GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_framebuffer_sRGB
> client glx vendor string: NVIDIA Corporation
> client glx version string: 1.4
> client glx extensions:
> ------

On Apr 6, 2012, at 6:49 PM, zxq9 wrote:
> Unfortunately I don't have any magical answer for you, but I can confirm that I can't reproduce this between Radeon HD 6310s and 4250s.
> 
> I do have a suspicion about what might be wrong, though...
> 
> Does the nVidia driver setup create an /etc/X11/xorg.conf during a post-install step? I SL6 doesn't have one by default but SL5 did. If something about the chipset or other detail of the X11 setup you've got is not detected correctly by default (as in, not detected correctly during the boot-time auto Xorg config step) then you might get problems. If the proprietary driver installation includes an xorg.conf creation step, however, this may be fixing the problem on the system with that driver installed, and thus produce this disparity.
> 
> I imagine that some chipsets will have this problem and some won't (regardless of maker), depending on how well the open source driver supports the specific chipset you've got.
> 
> I'm unclear on exactly how this impacts X11 forwarding, but this is an issue we danced around a bit on multi-head systems until we got our driver support sorted out (and subsequently we've stuck with the same few chip families from one maker now to narrow down our issues and knowledge requirement -- because no-3D is a show-stopper for us).