Re: problem with opengl (glxgears) running on cygwin ....
On 2014-03-25 09:05, Jon TURNEY wrote: On 20/03/2014 08:41, Linda Walsh wrote: When I try to run glxgears locally, it displays the initial gears, but now they are just frozen. It doesn't work remotely, either, which was what I tried initially. It *used* to work -- remotely at 20-30 frames/second (as measured by fraps). Interestingly enough, I get a glx window, -- fraps will display 30 (the right number for my screen refresh rate), in the right corner of the glxgears window... but the gears don't move. Thanks for pointing out this issue. I think that currently glxgears doesn't work very well with the combination of indirect rendering and vsync-limited buffer swapping, so you are getting 30 fps, but they aren't useful frames. This should be fixed in mesa-demos-8.1.0-2. Yaakov Cygwin/X -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
remote desktop /session bus woes...(was Re: problem with opengl (glxgears) running on cygwin ....)
Yaakov (Cygwin/X) wrote: On 2014-03-25 09:05, Jon TURNEY wrote: On 20/03/2014 08:41, Linda Walsh wrote: When I try to run glxgears locally, it displays the initial gears, but now they are just frozen. It doesn't work remotely, either, which was what I tried initially. It *used* to work -- remotely at 20-30 frames/second (as measured by fraps). Interestingly enough, I get a glx window, -- fraps will display 30 (the right number for my screen refresh rate), in the right corner of the glxgears window... but the gears don't move. Thanks for pointing out this issue. I think that currently glxgears doesn't work very well with the combination of indirect rendering and vsync-limited buffer swapping, so you are getting 30 fps, but they aren't useful frames. This should be fixed in mesa-demos-8.1.0-2. FWIW, I tried another X server...VcXsrv?... Same with that program. I tried several, got some that worked, most didn't. Of the few that worked 'well' remotely, they were variations on the glgears... got about 400-500 FPS -- and about low 300's MB/s in bandwidth consumed... that sounds about right... but I think there are other problem in trying to get a remote desktop to work now... everything wants to connect to the session bus -- and many progs won't start if they can't. So if I can't figure out a way to get that to work, remote usage is left at a fairly primitive level despite the high frame rates on a 3x4 window... ;-) One of the demo progs said it required opengl 2.1 .. my card has V4.something. well above 2.1, so that seems like another latent problem. Will look for the fixed version ... thanks for the news... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: problem with opengl (glxgears) running on cygwin ....
On 20/03/2014 08:41, Linda Walsh wrote: When I try to run glxgears locally, it displays the initial gears, but now they are just frozen. It doesn't work remotely, either, which was what I tried initially. It *used* to work -- remotely at 20-30 frames/second (as measured by fraps). Interestingly enough, I get a glx window, -- fraps will display 30 (the right number for my screen refresh rate), in the right corner of the glxgears window... but the gears don't move. Same effect happens when I try remotely. Window comes up with gears displayed, but no motion. Fraps also shows 30 FPS. Thanks for pointing out this issue. I think that currently glxgears doesn't work very well with the combination of indirect rendering and vsync-limited buffer swapping, so you are getting 30 fps, but they aren't useful frames. Since [1], glxgears turns at a constant 70 degrees per second. glxSwapBuffers does not block when used with indirect rendering, which means that lots of frames can be rendered almost instantly, with no apparent rotation, since the elapsed time between frames is very small. glxgears is a very basic test that GLX is functioning, and definitely not a benchmark. Real GLX clients should have a better mechanism for ensuring their animation rate doesn't outrun the vsync frequency. If you have any problems with real GLX clients, I would be interested to hear them. [1] http://cgit.freedesktop.org/mesa/demos/commit/src/xdemos/glxgears.c?id=0b19fb0a5c6299baf28e26625e39773846f815b2 When I try remote display, the above is pretty much the same except I get an error on the client system that it can't load the 3d swrast.so driver on the other end. There is some problem with loading the swrast_dri.so renderer on the remote system, so it is falling back to indirect rendering. What is the OS of the remote system? But it sees pretty much the same capabilities -- FWIW, there is next to zilch network traffic happening when I try this.. I mean while it is happening. Before and after ~ 200-400KB/s (xosview), during, all my X windows become very slow and no longer refresh steadily. Network throughput registers a drop to 1-80KB/s. Despite that -- xwin pegs a cpu @100% and stays that way until I exit glxgears. I think this is because glxgears will send frames as fast as it can, and can saturate the X server. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: problem with opengl (glxgears) running on cygwin ....
Jon TURNEY wrote: Since [1], glxgears turns at a constant 70 degrees per second. --- 70 degress/s? How is that important? glxSwapBuffers does not block when used with indirect rendering, which means that lots of frames can be rendered almost instantly, with no apparent rotation, since the elapsed time between frames is very small. According to the text in the starting window it is rendering at 30FPS. -- I.e. it is sync'ed with my monitor's refresh rate (except for the 1st iteration when it acted unsynced) ... I.e. in starting window this was displayed: Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 45623 frames in 6.4 seconds = 7166.903 FPS 834 frames in 27.4 seconds = 30.428 FPS 822 frames in 28.8 seconds = 28.542 FPS With all X-window response degraded (Xserver process was peg'ed@100%cpu), virtually no network traffic -- dropped from a norm of 200-400KB/s down to between 1KB-80KB/s. glxgears is a very basic test that GLX is functioning, and definitely not a benchmark. Real GLX clients should have a better mechanism for ensuring their animation rate doesn't outrun the vsync frequency. I thought it was the most basic. It claims (except for the 1st iteration) that it is not outruning my monitor's refresh rate. If you have any problems with real GLX clients, I would be interested to hear them. I'd be interested in finding any that work and proves that it works locally. While my initial use was to try remote GLX, I reverted to trying it localling -- just to verify it worked as it used to. Thats what brought this on. What is the OS of the remote system? --- linux (opensuse 13.1). No one else on that list was able to see normal response... some got really sluggish response, others saw no movement or nothing. It was only after I ran glxgears locally that I figured I might also have a problem in Cygwin's X, in addition to any other problem I have w/remote display. I think this is because glxgears will send frames as fast as it can, and can saturate the X server. The demo claims to sync at the same rate the monitor is refreshing. i.e -- 30 FPS. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
problem with opengl (glxgears) running on cygwin ....
When I try to run glxgears locally, it displays the initial gears, but now they are just frozen. It doesn't work remotely, either, which was what I tried initially. It *used* to work -- remotely at 20-30 frames/second (as measured by fraps). Interestingly enough, I get a glx window, -- fraps will display 30 (the right number for my screen refresh rate), in the right corner of the glxgears window... but the gears don't move. Same effect happens when I try remotely. Window comes up with gears displayed, but no motion. Fraps also shows 30 FPS. When I do glxinfo (with LIBGL_DEBUG=verbose), I get (more below): name of display: :0 display: :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_get_proc_address, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, 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_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.4.0) OpenGL extensions: GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_framebuffer_object, 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_texture_rg, GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_texture_float, 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_blit, GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_object, GL_EXT_framebuffer_sRGB, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, 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_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_copy_depth_to_color, GL_NV_depth_clamp, GL_NV_fog_distance, GL_NV_fragment_program, GL_NV_fragment_program2, GL_NV_fragment_program_option, GL_NV_light_max_exponent, GL_NV_multisample_filter_hint, GL_NV_packed_depth_stencil, GL_NV_point_sprite, GL_NV_texgen_reflection, GL_NV_texture_compression_vtc, GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_NV_vertex_program2, GL_NV_vertex_program2_option, GL_NV_vertex_program3, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SUN_multi_draw_arrays, GL_SUN_slice_accum 98 GLX Visuals visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a F gb bf
