problem with opengl (glxgears) running on cygwin ....

problem with opengl (glxgears) running on cygwin ....

[Linda Walsh]

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 th cl  r  g  b  a ns b eat
----------------------------------------------------------------------------
0x021 24 tc  0  32  0 r  y .   8  8  8  8 .  .  4 24  8 16 16 16 16  0 0 None
....a bunch of lines....
323 GLXFBConfigs:
     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 th cl  r  g  b  a ns b eat
----------------------------------------------------------------------------
0x042 24 tc  0  32  0 r  . .   8  8  8  0 .  .  4 24  0 16 16 16 16  0 0 None
...a bunch more lines...
-------------------------------------

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.

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.

xwin log is below...  Any ideas?

> more /var/log/xwin/XWin.0.log
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.15.0.0
OS: CYGWIN_NT-6.1 Athenae 1.7.28(0.271/5/3) 2014-02-09 21:06 x86_64
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601](Win64)
Package: version 1.15.0-3 built 2014-02-25

XWin was started with the following command line:

/usr/bin/XWin -dpi 120 -nomultimonitors -clipboard -ac -unixkill
  -nowinkill +bs -fp
 
/windows/fonts,built-ins,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi
  -multiwindow

ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 2560 h 1600
winInitializeScreenDefaults - native DPI x 120 y 120
[ 86222.282] Initializing built-in extension Generic Event Extension
[ 86222.282] Initializing built-in extension SHAPE
[ 86222.282] Initializing built-in extension MIT-SHM
[ 86222.282] Initializing built-in extension XInputExtension
[ 86222.282] Initializing built-in extension XTEST
[ 86222.282] Initializing built-in extension BIG-REQUESTS
[ 86222.282] Initializing built-in extension SYNC
[ 86222.282] Initializing built-in extension XKEYBOARD
[ 86222.282] Initializing built-in extension XC-MISC
[ 86222.282] Initializing built-in extension XINERAMA
[ 86222.282] Initializing built-in extension XFIXES
[ 86222.282] Initializing built-in extension XFree86-Bigfont
[ 86222.282] Initializing built-in extension RENDER
[ 86222.282] Initializing built-in extension RANDR
[ 86222.282] Initializing built-in extension COMPOSITE
[ 86222.282] Initializing built-in extension DAMAGE
[ 86222.282] Initializing built-in extension MIT-SCREEN-SAVER
[ 86222.282] Initializing built-in extension DOUBLE-BUFFER
[ 86222.282] Initializing built-in extension RECORD
[ 86222.282] Initializing built-in extension DPMS
[ 86222.282] Initializing built-in extension Present
[ 86222.282] Initializing built-in extension X-Resource
[ 86222.282] Initializing built-in extension GLX
[ 86222.282] (II) xorg.conf is not supported
[ 86222.282] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more 
information
[ 86222.282] (++) FontPath set to 
"/windows/fonts,built-ins,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi"
[ 86222.282] LoadPreferences: Loading /Users/law.Bliss/.XWinrc
[ 86222.282] LoadPreferences: Done parsing the configuration file...
[ 86222.329] winDetectSupportedEngines - DirectDraw installed, allowing 
ShadowDD[ 86222.329] winDetectSupportedEngines - Windows NT, allowing PrimaryDD
[ 86222.329] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
[ 86222.345] winDetectSupportedEngines - Returning, supported engines 0000001f
[ 86222.345] winSetEngine - Multi Window or Rootless => ShadowGDI
[ 86222.345] winScreenInit - Using Windows display depth of 32 bits per pixel
[ 86222.345] winAllocateFBShadowGDI - Creating DIB with width: 2560 height: 1600 
depth: 32
[ 86222.345] winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
[ 86222.345] winInitVisualsShadowGDI - Masks 00ff0000 0000ff00 000000ff BPRGB 8
d 24 bpp 32
[ 86222.345] winInitMultiWindowWM - Calling pthread_mutex_lock ()
[ 86222.345] winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
[ 86222.360] MIT-SHM extension disabled due to lack of kernel support
[ 86222.360] XFree86-Bigfont extension local-client optimization disabled due to 
lack of shared memory support in the kernel
[ 86222.376] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'
[ 86222.532] GL_VERSION:     4.4.0
[ 86222.532] GL_VENDOR:      NVIDIA Corporation
[ 86222.532] GL_RENDERER:    GeForce GTX 590/PCIe/SSE2
[ 86222.532] (II) AIGLX: enabled GLX_SGI_make_current_read
[ 86222.532] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 86222.532] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[ 86222.532] (II) AIGLX: enabled GLX_SGIX_pbuffer
[ 86222.532] (II) AIGLX: enabled GLX_ARB_multisample and GLX_SGIS_multisample
[ 86222.532] (II) 482 pixel formats reported by wglGetPixelFormatAttribivARB
[ 86222.548] (II) AIGLX: Set GLX version to 1.4
[ 86222.548] (II) 323 fbConfigs
[ 86222.548] (II) GLX: Initialized Win32 native WGL GL provider for screen 0
[ 86222.548] [dix] Could not init font path element /windows/fonts, removing 
from list!
[ 86222.641] winPointerWarpCursor - Discarding first warp: 1280 800
[ 86222.641] (--) 5 mouse buttons found
[ 86222.641] (--) Setting autorepeat to delay=250, rate=31
[ 86222.641] (--) Windows keyboard layout: "00000409" (00000409) "US", type 4
[ 86222.641] (--) Found matching XKB configuration "English (USA)"
[ 86222.641] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none"
[ 86222.641] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" 
Options = "none"
[ 86222.641] winBlockHandler - pthread_mutex_unlock()
[ 86222.641] winInitMultiWindowWM - pthread_mutex_lock () returned.
[ 86222.641] winInitMultiWindowWM - pthread_mutex_unlock () returned.
[ 86222.641] winMultiWindowXMsgProc - pthread_mutex_lock () returned.
[ 86222.641] winInitMultiWindowWM - DISPLAY=:0.0
[ 86222.641] winMultiWindowXMsgProc - pthread_mutex_unlock () returned.
[ 86222.641] winMultiWindowXMsgProc - DISPLAY=:0.0
[ 86222.641] winProcEstablishConnection - winInitClipboard returned.
[ 86222.641] winInitMultiWindowWM - XOpenDisplay () returned and successfully 
opened the display.
[ 86222.641] winClipboardThreadProc - DISPLAY=:0.0
[ 86222.641] winMultiWindowXMsgProc - XOpenDisplay () returned and successfully
opened the display.
[ 86222.657] winClipboardProc - XOpenDisplay () returned and successfully opened 
the display.
[ 86226.307] winXCursorToHCURSOR - Windows requires 32x32 cursor but X requires
48x48
[105011.433] winGetWindowInfo: forcing window to exist
[105060.901] winGetWindowInfo: forcing window to exist
[105079.449] winGetWindowInfo: forcing window to exist
[105120.322] winGetWindowInfo: forcing window to exist
[105130.040] winGetWindowInfo: forcing window to exist
[105136.608] winGetWindowInfo: forcing window to exist
[105264.201] winGetWindowInfo: forcing window to exist
[105296.509] winGetWindowInfo: forcing window to exist
[105312.671] winGetWindowInfo: forcing window to exist




--
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]

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 ....

[Linda Walsh]

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/

Re: problem with opengl (glxgears) running on cygwin ....

[Yaakov (Cygwin/X)]

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 ....)

[Linda Walsh]

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 3"x4" 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/