Bugzilla – Bug 152140
Improve XVideo support for Xgl
Last modified: 2008-03-17 15:20:01 UTC
Before I installed Xgl I had mplayer working nicely on my box, both windowed and full-screen. While running Xgl, full-screen mplayer has serious problems. It runs at very few fps, and the video lags farther and farther behind the audio track. mplayer complains that my computer is too slow to play the video. Also, I can't switch back to windowed after going to full-screen (didn't have this problem without Xgl). If I use the '-vo gl2' switch with mplayer, full-screen plays properly, but I still have the problem of not being able to get out of full-screen once in full-screen. Also, I can't kill mplayer with the 'X' on the window decoration while running compiz + gnome-window-decorator. I have to Ctrl+C it from the terminal where I launched mplayer. I'm running: NLD10-beta4, xgl-cvs_060216-1, Pentium(R) 4 CPU 2.66GHz, 1GB RAM nVidia Corporation NV34 [GeForce FX 5200] (rev a1) 128MB VideoRAM 1680x1050@60 via DVI driver: NVIDIA-Linux-x86-1.0-8178 + NVIDIA_kernel-1.0-8178-U012206.diff.txt $ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap client glx vendor string: NVIDIA Corporation client glx version string: 1.3 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_NV_float_buffer, GLX_ARB_fbconfig_float GLX extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGIX_fbconfig, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce FX 5200/AGP/SSE2 OpenGL version string: 1.2 (2.0.1 NVIDIA 81.78) OpenGL extensions: GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, 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_lod, GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_vertex_array, GL_HP_occlusion_test, GL_IBM_texture_mirrored_repeat, GL_NV_blend_square, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_NV_texture_env_combine4, GL_SGIS_generate_mipmap, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x2c 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x2e 32 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 Ncon 0x2f 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon
Also, I've tried all of these different options, and all behave the same: DISPLAYMANAGER_XGL_OPTS="-accel glx:pbuffer -accel xv:pbuffer" DISPLAYMANAGER_XGL_OPTS="-accel glx:pbuffer -accel xv:fbo" DISPLAYMANAGER_XGL_OPTS="-accel glx:pbuffer -accel xv"
GeForce FX 5200 is too slow for accelerating XVideo using shaders. Once the software fallback code for XVideo in the server has been optimized it should perform at least as good as the gl output of mplayer.
Can't do anything about hardware not being fast enough.
I'm confused. Does this mean that some applications will run slower on Xgl, perhaps to the point of being unusable, when they ran just fine without Xgl? I thought Xgl was supposed to "accelerate" things.
Reopening to learn an answer for #4.
Xgl is design to run with a compositing manager and hence a compositied desktop. A compositied desktop allows for all these nice effects like shadows, translucent windows, transformed windows and so on. However, it requires much more from the graphics hardware than a normal desktop. Xgl accelerates the compositing and makes it possible to run a compositied desktop. Xgl can't accelerate the old 2D drawing operations that a regular X server accelerate better than before. It's actually much harder to accelerate those drawing operations on a compositied desktop so depending on the hardware you have things might be running at the same speed as before or much slower.
This is not a Novell Desktop only issue -> assigning to base product SL 10.1. Improving XVideo on Xgl (which is a new product) is low priority, and an enhancement. Assigning to myself. (In reply to comment #0) > Also, I can't switch back to windowed after going to full-screen (didn't have > this problem without Xgl). If I use the '-vo gl2' switch with mplayer, This is due to the mplayer x11 queue being saturated, and compiz doesn't have a possibility to *hard* kill an application window. > Also, I can't kill mplayer with the 'X' on the window decoration while running > compiz + gnome-window-decorator. I have to Ctrl+C it from the terminal where I > launched mplayer. Might be the same issue. You might want to create an own bug report for that. The glxinfo output is useless, unfortunately, because it was run on Xgl itself, so you only get the list of extensions exposed by Xgl, not the hardware capabilities. Please run glxinfo on top of Xorg again and post the output. (In reply to comment #2) > GeForce FX 5200 is too slow for accelerating XVideo using shaders. Once the Actually, the GeForce FX5 series should be fast enough. At least they support pixel shaders. Somehow we're hitting a software emulation path here (seen that on GeForce 5Go), and currently I don't know why. This has to be investigated, and there could also be a different acceleration approach working even on GeForce 4 cards using register combiners. Yes, the software fallback should be improved a lot as well. (In reply to comment #4) > I'm confused. Does this mean that some applications will run slower on Xgl, > perhaps to the point of being unusable, when they ran just fine without Xgl? I > thought Xgl was supposed to "accelerate" things. It is a common myth, that Xgl accelerates XVideo or OpenGL programs, the contrary is the case. It typically *does* accelerate Render operations, though.
Created attachment 73824 [details] glxinfo while running Xorg, not Xgl.
... contains GL_ARB_fragment_program. So the driver is definitvely capable of using pixel shaders for color conversion. Now we have to determine why we hit the slow path.
I have similar (even if not so bad) problems. My card is an ATI 9600 Mobility (M10), and I can "see" that xv is hardware acceleratd with xgl (I used "-accel xv:pbuffer"). However, the video and audio go out of sync really easily (and xine, mplayer or totem do not manage to re-sync them). In practice, I cannot use xgl to watch video files :-(
JFYI.
*** Bug 292026 has been marked as a duplicate of this bug. ***
Due to lack of time (and this bug only hitting GeForce 5 with is sort-of obsolete by now) I have to close this as WONTFIX.
Hasn't this been fixed? Since some update of Xgl/Compiz (xgl-git_071026-17.1) video is fast again.
That's interesting, since I have no idea what should have been changed in this area. Maybe you updated the nvidia driver as well? Can you verify this?
Yes, the driver is a never: 169.12_2.6.22.17_0.1-0.1
In that case they probably fixed a slow path in the driver. Phew! :-)