Re: [opensuse-factory] Re: When was it decided to stop supporting remote desktops?
On 2014-03-19 18:20, Claudio Freire wrote:
On Tue, Mar 18, 2014 at 8:54 PM, Carlos E. R. wrote:
Your post did not reach the list. The reason is that it contains an html part, thus the mail server rejects it. Silently, it seems. You have to configure your mail software to send pure plain text email only, at least to the lists. I'll copy your email back.
> It seems to be doing the rasterization in software on the X server, in > spite of having more than enough acceleration capabilities, resulting in > 8fps or less (couldn't accurately measure).
Well, that's expected for Nouveau, accel is not complete.
How come nouveau has enough acceleration support to run compositing desktops and even games I believe (haven't tested the more demanding ones), but not glxgears?
Does xgl impose some seldom-supported mode of operation? (I can't imagine that)
You could compare how fast it runs locally and how fast remotely. If they are very different, I can only guess that it does not use the same methods in each case. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Wed, Mar 19, 2014 at 4:30 PM, Carlos E. R.
On 2014-03-19 18:20, Claudio Freire wrote:
On Tue, Mar 18, 2014 at 8:54 PM, Carlos E. R. wrote:
Your post did not reach the list. The reason is that it contains an html part, thus the mail server rejects it. Silently, it seems.
You have to configure your mail software to send pure plain text email only, at least to the lists.
I had, but it resetted it self not sure why. Fixed now.
> It seems to be doing the rasterization in software on the X server, in > spite of having more than enough acceleration capabilities, resulting in > 8fps or less (couldn't accurately measure).
Well, that's expected for Nouveau, accel is not complete.
How come nouveau has enough acceleration support to run compositing desktops and even games I believe (haven't tested the more demanding ones), but not glxgears?
Does xgl impose some seldom-supported mode of operation? (I can't imagine that)
You could compare how fast it runs locally and how fast remotely. If they are very different, I can only guess that it does not use the same methods in each case.
It runs VERY differently. I think this is a bug, and the bug is synchronization. See: Local: 9320 frames in 5.0 seconds = 1863.014 FPS Remote: 27133 frames in 5.1 seconds = 5338.616 FPS 1855 frames in 6.4 seconds = 290.477 FPS 1935 frames in 6.4 seconds = 300.510 FPS 1901 frames in 6.4 seconds = 295.259 FPS 1887 frames in 6.4 seconds = 295.820 FPS 1951 frames in 6.5 seconds = 302.215 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:10.0" after 74656 requests (17638 known processed) with 0 events remaining. The XIO is when I closed the window. That's normal I guess. But the visible frames weren't nearly hundreds of FPS. I believe glXSwapBuffers() doesn't work as it's supposed to, only as documented. See, the manpage doesn't say it, but normally glXSwapBuffers blocks the rendering pipe until it's done swapping, and any subsequent calls to glXSwapBuffers will block if the previous swap hasn't finished (or, more precisely, when there's no available back buffer, since there can be many). This will make the application-level code to run at the monitor's refresh rate (if vsync is enabled, or the hardware's speed if not), and thus glxgears will output a nice animation since, between frames, cpu time does change. However, remote glxgears seems to be sending the swaps completely asynchronously, and they're getting queued in the renderer on the local machine. This screws up timing considerably. The renderer doesn't appear to be in software: $ glxgears -info GL_RENDERER = Gallium 0.4 on NVC1 GL_VERSION = 1.4 (3.0 Mesa 9.2.3) GL_VENDOR = nouveau GL_EXTENSIONS = GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow 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_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_copy_texture 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_polygon_offset 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_subtexture GL_EXT_texture GL_EXT_texture3D 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_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_ATIX_texture_env_combine3 GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_NV_blend_square GL_NV_depth_clamp GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (2)
-
Carlos E. R.
-
Claudio Freire