Re: Remote OpenGL -- getting it to work?
On 11/06/16 12:30, L. A. Walsh wrote: > Antoine Martin wrote: >> On 11/06/16 01:02, L. A. Walsh wrote: >> >>> Antoine Martin wrote: >>> >> .0 NVIDIA 355.98) >> FWIW: xpra + virtualgl works very well and is often considerably faster than doing GL over a remote display connection. More info here: https://xpra.org/trac/wiki/Usage/OpenGL >>> --- >>> Will have to try that -- not sure if xpra is supported by the cygwin/X >>> server or not... >>> >> No, you do not need cygwin or anything else: the client runs native on >> all supported platforms, including MS Windows. >> > --- >And it includes the X-server as well? Not sure what "it" is. Xpra uses a virtual display server (Xvfb or Xorg+dummy) on the server side, which is provided by your distribution. On the client side, it runs *native* via GTK: so no need for X11 on MS Windows or Mac OSX. Cheers Antoine ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Remote OpenGL -- getting it to work?
Antoine Martin wrote: On 11/06/16 01:02, L. A. Walsh wrote: Antoine Martin wrote: .0 NVIDIA 355.98) FWIW: xpra + virtualgl works very well and is often considerably faster than doing GL over a remote display connection. More info here: https://xpra.org/trac/wiki/Usage/OpenGL --- Will have to try that -- not sure if xpra is supported by the cygwin/X server or not... No, you do not need cygwin or anything else: the client runs native on all supported platforms, including MS Windows. --- And it includes the X-server as well? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Remote OpenGL -- getting it to work?
On 11/06/16 01:02, L. A. Walsh wrote: > Antoine Martin wrote: .0 NVIDIA 355.98) >>> >> FWIW: xpra + virtualgl works very well and is often considerably faster >> than doing GL over a remote display connection. More info here: >> https://xpra.org/trac/wiki/Usage/OpenGL >> > --- > Will have to try that -- not sure if xpra is supported by the cygwin/X > server or not... No, you do not need cygwin or anything else: the client runs native on all supported platforms, including MS Windows. Antoine ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Remote OpenGL -- getting it to work?
Antoine Martin wrote: .0 NVIDIA 355.98) FWIW: xpra + virtualgl works very well and is often considerably faster than doing GL over a remote display connection. More info here: https://xpra.org/trac/wiki/Usage/OpenGL --- Will have to try that -- not sure if xpra is supported by the cygwin/X server or not... tnx, -l ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Remote OpenGL -- getting it to work?
On 01/06/16 05:13, Thomas Lübking wrote: > On Tue, May 31, 2016 at 08:33:14AM -0700, L. A. Walsh wrote: >> Glynn Clements wrote: >>> L. A. Walsh wrote: >>> I have sometimes gotten some GLX programs to work for a short while, but more often than not, I don't get them to work at all. >>> >>> The most likely reason for this is that the program needs a later >>> version of OpenGL than Cygwin's X server provides. >> >> Hmmmwhat does this mean, then? >> OpenGL vendor string: NVIDIA Corporation >> OpenGL renderer string: GeForce GTX 590/PCIe/SSE2 >> OpenGL version string: 1.4 (4.5.0 NVIDIA 355.98) > > Indirect GL is confined to GL 1.4 (ie. fixed function path, notably no > glsl) > The driver and GPU support 4.5, but only on direct contexts. > > You should check whether indirect GL works generally (there're somet > pitfalls), ie. whether glxgears works. > If so, you best contact the authors of the failing GL clients and ask > whether they provide a fixed function path (and how to select it) > > If everything else fails, you'll have to resort to eg. VNC (afair > only x11vnc will work for you) FWIW: xpra + virtualgl works very well and is often considerably faster than doing GL over a remote display connection. More info here: https://xpra.org/trac/wiki/Usage/OpenGL Cheers Antoine ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Remote OpenGL -- getting it to work?
On Tue, May 31, 2016 at 08:33:14AM -0700, L. A. Walsh wrote: Glynn Clements wrote: L. A. Walsh wrote: I have sometimes gotten some GLX programs to work for a short while, but more often than not, I don't get them to work at all. The most likely reason for this is that the program needs a later version of OpenGL than Cygwin's X server provides. Hmmmwhat does this mean, then? OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 590/PCIe/SSE2 OpenGL version string: 1.4 (4.5.0 NVIDIA 355.98) Indirect GL is confined to GL 1.4 (ie. fixed function path, notably no glsl) The driver and GPU support 4.5, but only on direct contexts. You should check whether indirect GL works generally (there're somet pitfalls), ie. whether glxgears works. If so, you best contact the authors of the failing GL clients and ask whether they provide a fixed function path (and how to select it) If everything else fails, you'll have to resort to eg. VNC (afair only x11vnc will work for you) Cheers, Thomas ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Remote OpenGL -- getting it to work?
Glynn Clements wrote: L. A. Walsh wrote: I have sometimes gotten some GLX programs to work for a short while, but more often than not, I don't get them to work at all. The most likely reason for this is that the program needs a later version of OpenGL than Cygwin's X server provides. Hmmmwhat does this mean, then? OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 590/PCIe/SSE2 OpenGL version string: 1.4 (4.5.0 NVIDIA 355.98) --- That's the OpenGL version that comes with graphics card driver on the X-server -- i.e. Nvidia provides upgraded versions of openGL for my OS. I thought the X-server provided a pass-through for the openGL protocol? I'm not sure where to look for how to configure it to be allowed, No configuration is required. but on the client end, it doesn't seem to ever want to load swrast. swrast isn't relevant for indirect rendering. The fact that libGL even attempts to load it when $DISPLAY refers to a remote server is less than desirable, but ultimately doesn't matter. What should it load instead? Isn't openGL handled by the server's graphics hardware? The swrast load is happening on the client, which doesn't have graphics HW -- so I thought it would or should send it's graphics commands to the remote server to be executed? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Remote OpenGL -- getting it to work?
L. A. Walsh wrote: > I have sometimes gotten some GLX programs to work for a short while, > but more often than not, I don't get them to work at all. The most likely reason for this is that the program needs a later version of OpenGL than Cygwin's X server provides. > I'm not sure where to look for how to configure it to be allowed, No configuration is required. > but on the client end, it doesn't seem to ever want to load swrast. swrast isn't relevant for indirect rendering. The fact that libGL even attempts to load it when $DISPLAY refers to a remote server is less than desirable, but ultimately doesn't matter. -- Glynn Clements ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Remote OpenGL -- getting it to work?
I have sometimes gotten some GLX programs to work for a short while,
but more often than not, I don't get them to work at all.
I'm not sure where to look for how to configure it to be allowed, but
on the client end, it doesn't seem to ever want to load swrast.
The glxinfo cmd looks like it is detecting GLX stuff on the cygwin-X
server, which _looks_ hopeful, but I've never figured out the what's wrong
with swrast. I have swrast.so on my system:
ll /usr/lib64/dri/{,updates}swrast_dri.so
-rwxr-xr-x 7 8036024 Jan 27 2015 /usr/lib64/dri/swrast_dri.so*
lrwxrwxrwx 1 28 Dec 12 2013 /usr/lib64/driupdates/swrast_dri.so ->
/usr/lib64/dri/swrast_dri.so*
And it doesn't seem to have any problems "loading" according to "ldd" --
I've added on the output from "ldd /usr/lib64/dri/swrast_dri.so" after
the glxinfo output, below.
If there's any other output that would be helpful, would be happy
to supply it!
Thanks for any help!
My glxinfo, BTW, is a softpointer:
ll /usr/bin/glxinfo
lrwxrwxrwx 1 34 May 27 2015 /usr/bin/glxinfo ->
../lib64/mesa-demos/xdemos/glxinfo*
Presetting LIBGL_DEBUG=verbose, as recommended by a previous
run, I get:
-glxinfo output w/DEBUG---
libGL error: failed to load driver: swrast
name of display: athenae:0
display: athenae:0 screen: 0
direct rendering: No (If you want to find out why, try setting
LIBGL_DEBUG=verbose)
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info,
GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGI_make_current_read, GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile,
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address,
GLX_ARB_multisample,
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB,
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info,
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read,
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_MESA_multithread_makecurrent, GLX_OML_swap_method,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGI_make_current_read, GLX_SGI_swap_control
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 590/PCIe/SSE2
OpenGL version string: 1.4 (4.5.0 NVIDIA 355.98)
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program,
GL_ARB_fragment_program_shadow, GL_ARB_imaging, GL_ARB_multisample,
GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters,
GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_texture_border_clamp,
GL_ARB_texture_compression, GL_ARB_texture_cube_map,
GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,
GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two,
GL_ARB_texture_rectangle, GL_ARB_transpose_matrix,
GL_ARB_vertex_program,
GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_texture_mirror_once,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_draw_range_elements,
GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays,
GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal,
GL_EXT_secondary_color, GL_EXT_separate_specular_color,
GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap,
GL_EXT_texture3D, GL_EXT_texture_compression_dxt1,
GL_EXT_texture_compression_s3tc, GL_EXT_texture_edge_clamp,
GL_EXT_texture_env_add, GL_EXT_texture_env_combine,
GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic,
GL_EXT_texture_lod, GL_EXT_texture_lod_bias,
GL_EXT_texture_mirror_clamp,
GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array,
GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
GL_NV_blend_square, GL_NV_depth_clamp, GL_NV_fog_distance,
GL_NV_fragment_program2, GL_NV_fragment_program_option,
GL_NV_light_max_exponent, GL_NV_multisample_filter_hint,
GL_NV_point_sprite, GL_NV_texgen_reflection,
GL_NV_texture_compression_vtc, GL_NV_texture_env_combine4,
GL_NV_texture_re
