From: Svilen K. <kru...@go...> - 2008-07-31 20:47:43
Attachments:
glxinfo.log
|
Hi, I'm having troubles obtaining GLX visual with accumulation buffers. It happens only on Fedora 9. Attached is glxinfo log. Problem never appears with fglrx drivers, but as you know it's not available for FC9. I'm really looking forward for your comments. Here is my platform: X1600 Mobility Radeon Linux, Fedora 9 Xorg 7.4 (unofficial) Mesa 7.1 (unofficial) xorg.conf ... Section "Device" Identifier "Videocard0" Driver "radeon" EndSection ... Regards |
From: Svilen <kru...@go...> - 2008-08-06 23:48:16
Attachments:
glxinfo.log
|
Hi, This is second time I'm trying to get your attention guys. Shall I flag it as a bug? Or it is not a DRI problem. I know at least a couple of similar platforms with the same trouble. If this is not a right place to ask the question, I'll appreciate if you point me another mailing list. I've already discussed this in xor...@li... but they claim it's not a driver problem. Regards Svilen Svilen Krustev wrote: > Hi, > > I'm having troubles obtaining GLX visual with accumulation buffers. It > happens only on Fedora 9. Attached is glxinfo log. > Problem never appears with fglrx drivers, but as you know it's not > available for FC9. > > I'm really looking forward for your comments. > > Here is my platform: > X1600 Mobility Radeon > Linux, Fedora 9 > Xorg 7.4 (unofficial) > Mesa 7.1 (unofficial) > > xorg.conf > ... > Section "Device" > Identifier "Videocard0" > Driver "radeon" > EndSection > ... > > Regards > |
From: Brian P. <bri...@tu...> - 2008-08-07 00:12:40
|
Svilen wrote: > Hi, > > This is second time I'm trying to get your attention guys. > Shall I flag it as a bug? Or it is not a DRI problem. I know at least a > couple of similar platforms with the same trouble. > > If this is not a right place to ask the question, I'll appreciate if you > point me another mailing list. I've already discussed this in > xor...@li... but they claim it's not a driver problem. > > Regards > Svilen > > Svilen Krustev wrote: >> Hi, >> >> I'm having troubles obtaining GLX visual with accumulation buffers. It >> happens only on Fedora 9. Attached is glxinfo log. >> Problem never appears with fglrx drivers, but as you know it's not >> available for FC9. >> >> I'm really looking forward for your comments. >> >> Here is my platform: >> X1600 Mobility Radeon >> Linux, Fedora 9 >> Xorg 7.4 (unofficial) >> Mesa 7.1 (unofficial) >> >> xorg.conf >> ... >> Section "Device" >> Identifier "Videocard0" >> Driver "radeon" >> EndSection >> ... >> >> Regards >> > > > ------------------------------------------------------------------------ > > name of display: :0.0 > display: :0 screen: 0 > direct rendering: Yes > server glx vendor string: SGI > server glx version string: 1.2 > server glx extensions: > GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, > GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, > GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group > client glx vendor string: SGI > client glx version string: 1.4 > client glx extensions: > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, > GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, > GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, > GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, > GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, > GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap > GLX version: 1.2 > GLX extensions: > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, > GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control, > GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, > GLX_SGIX_visual_select_group > OpenGL vendor string: DRI R300 Project > OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL > OpenGL version string: 1.3 Mesa 7.1 rc1 > OpenGL extensions: > GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_imaging, > GL_ARB_multisample, GL_ARB_multitexture, 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_MESAX_texture_float, > GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, > GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, > 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_logic_op, GL_EXT_blend_minmax, > GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, > GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, > GL_EXT_draw_range_elements, GL_EXT_gpu_program_parameters, > GL_EXT_histogram, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, > 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_blend_equation_separate, > GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, > GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, > GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, > GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, > GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, > GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, > GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, > GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, > GL_SUN_multi_draw_arrays > > 3 GLX Visuals > 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 > ---------------------------------------------------------------------- > 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x52 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None > > 16 GLXFBConfigs: > 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 > ---------------------------------------------------------------------- > 0x53 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None > 0x54 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow > 0x55 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None > 0x56 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow > 0x57 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x58 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x59 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x5a 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x5b 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None > 0x5c 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow > 0x5d 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None > 0x5e 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow > 0x5f 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x60 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x61 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x62 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow First, maybe another R300 user can say what 'glxinfo' says on their system. Off hand I'd expect more GLX visuals and fewer FBConfigs. -Brian |
From: Nicolai H. <nha...@gm...> - 2008-08-07 07:57:13
|
Am Donnerstag 07 August 2008 01:48:07 schrieb Svilen: > > I'm having troubles obtaining GLX visual with accumulation buffers. It > > happens only on Fedora 9. Attached is glxinfo log. > > Problem never appears with fglrx drivers, but as you know it's not > > available for FC9. > > > > I'm really looking forward for your comments. > > > > Here is my platform: > > X1600 Mobility Radeon > > Linux, Fedora 9 > > Xorg 7.4 (unofficial) > > Mesa 7.1 (unofficial) > > > > xorg.conf > > ... > > Section "Device" > > Identifier "Videocard0" > > Driver "radeon" > > EndSection > > ... > > > > Regards I don't think we have acceleration for accumulation buffers. You may still be able to obtain a GLX visual with accum buffers by what Michel said, but don't expect too great results. To be honest, you're the first person I've ever seen complaining about missing accumulation buffers, so I have no idea whether that will change any time soon. cu, Nicolai |
From: Svilen <kru...@go...> - 2008-08-07 20:10:48
|
Nicolai Hähnle wrote: > Am Donnerstag 07 August 2008 01:48:07 schrieb Svilen: > >>> I'm having troubles obtaining GLX visual with accumulation buffers. It >>> happens only on Fedora 9. Attached is glxinfo log. >>> Problem never appears with fglrx drivers, but as you know it's not >>> available for FC9. >>> >>> I'm really looking forward for your comments. >>> >>> Here is my platform: >>> X1600 Mobility Radeon >>> Linux, Fedora 9 >>> Xorg 7.4 (unofficial) >>> Mesa 7.1 (unofficial) >>> >>> xorg.conf >>> ... >>> Section "Device" >>> Identifier "Videocard0" >>> Driver "radeon" >>> EndSection >>> ... >>> >>> Regards >>> > > I don't think we have acceleration for accumulation buffers. You may still be > able to obtain a GLX visual with accum buffers by what Michel said, but don't > expect too great results. > > To be honest, you're the first person I've ever seen complaining about missing > accumulation buffers, so I have no idea whether that will change any time > soon. > I'm certainly not a great expert in OpenGL, but accumulation buffers can be quite handy. It seems highly unlikely that I'm the only one using them. Besides you can find a simple tricks with the accumulation buffers in every openGL book. It is certainly a surprise that I'm the first complaining about it. It certainly took me some time until I found the right place to ask the question. Maybe this is one of the reasons? Svilen |
From: Brian P. <bri...@tu...> - 2008-08-07 20:43:32
|
Svilen wrote: > Nicolai Hähnle wrote: >> Am Donnerstag 07 August 2008 01:48:07 schrieb Svilen: >> >>>> I'm having troubles obtaining GLX visual with accumulation buffers. It >>>> happens only on Fedora 9. Attached is glxinfo log. >>>> Problem never appears with fglrx drivers, but as you know it's not >>>> available for FC9. >>>> >>>> I'm really looking forward for your comments. >>>> >>>> Here is my platform: >>>> X1600 Mobility Radeon >>>> Linux, Fedora 9 >>>> Xorg 7.4 (unofficial) >>>> Mesa 7.1 (unofficial) >>>> >>>> xorg.conf >>>> ... >>>> Section "Device" >>>> Identifier "Videocard0" >>>> Driver "radeon" >>>> EndSection >>>> ... >>>> >>>> Regards >>>> >> I don't think we have acceleration for accumulation buffers. You may still be >> able to obtain a GLX visual with accum buffers by what Michel said, but don't >> expect too great results. >> >> To be honest, you're the first person I've ever seen complaining about missing >> accumulation buffers, so I have no idea whether that will change any time >> soon. >> > I'm certainly not a great expert in OpenGL, but accumulation buffers can > be quite handy. It seems highly unlikely that I'm the only one using > them. Besides you can find a simple tricks with the accumulation buffers > in every openGL book. > It is certainly a surprise that I'm the first complaining about it. It > certainly took me some time until I found the right place to ask the > question. Maybe this is one of the reasons? I agree that a GLX visual with an accum buffer should be present. Accum is always implemented in software with Mesa, but it's trivial to support. -Brian |
From: Stefan D. <st...@co...> - 2008-08-08 14:37:41
|
> I'm certainly not a great expert in OpenGL, but accumulation buffers > can be quite handy. It seems highly unlikely that I'm the only one using > them. Besides you can find a simple tricks with the accumulation > buffers in every openGL book. I think the more common way is to use frame buffer objects for this nowadays. They more flexible and closer to how the hardware works. I think accumulation buffers are going to be removed in OpenGL 3, but I haven't checked the latest spec. |
From: Michel D. <mi...@tu...> - 2008-08-07 07:09:00
|
On Wed, 2008-08-06 at 18:12 -0600, Brian Paul wrote: > Svilen wrote: > > > > 3 GLX Visuals > > 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 > > ---------------------------------------------------------------------- > > 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > > 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > > 0x52 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None > > > > 16 GLXFBConfigs: > > 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 > > ---------------------------------------------------------------------- > > 0x53 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None > > 0x54 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow > > 0x55 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None > > 0x56 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow > > 0x57 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > > 0x58 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > > 0x59 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > > 0x5a 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > > 0x5b 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None > > 0x5c 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow > > 0x5d 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None > > 0x5e 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow > > 0x5f 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > > 0x60 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > > 0x61 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > > 0x62 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > > First, maybe another R300 user can say what 'glxinfo' says on their system. I get the same. > Off hand I'd expect more GLX visuals and fewer FBConfigs. It's due to Kristian Høgsberg's GLX visual reworks. I think the idea is to only have GLX visuals for the common use cases by default and to stick to FBConfigs otherwise. There's a xorg.conf Option "GlxVisuals" to change this though which is documented in the xorg.conf manpage. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer |
From: Roland S. <sr...@tu...> - 2008-08-07 11:56:47
|
On 07.08.2008 09:08, Michel Dänzer wrote: > On Wed, 2008-08-06 at 18:12 -0600, Brian Paul wrote: >> Svilen wrote: >>> 3 GLX Visuals >>> 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 >>> ---------------------------------------------------------------------- >>> 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >>> 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >>> 0x52 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None >>> >>> 16 GLXFBConfigs: >>> 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 >>> ---------------------------------------------------------------------- >>> 0x53 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None >>> 0x54 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow >>> 0x55 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None >>> 0x56 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow >>> 0x57 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >>> 0x58 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow >>> 0x59 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >>> 0x5a 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow >>> 0x5b 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None >>> 0x5c 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow >>> 0x5d 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None >>> 0x5e 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow >>> 0x5f 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >>> 0x60 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow >>> 0x61 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >>> 0x62 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow >> First, maybe another R300 user can say what 'glxinfo' says on their system. > > I get the same. > >> Off hand I'd expect more GLX visuals and fewer FBConfigs. > > It's due to Kristian Høgsberg's GLX visual reworks. I think the idea is > to only have GLX visuals for the common use cases by default and to > stick to FBConfigs otherwise. There's a xorg.conf Option "GlxVisuals" to > change this though which is documented in the xorg.conf manpage. Hmm, "typical" and "minimal" seem to do the same thing. I'm not sure though I understand the rationale behind not exporting the full set, just because fb configs exists old apps are not magically going to use them. Also, glx (1.2, 1.3 does mention this only for fb configs but I'm sure it would apply there just as well due to backward compatibility) requires that a visual with a accumulation buffer be exported. Therefore, the minimal (and typical) set are not enough to satisfy glx requirements as they do not include any visual with an accumulation buffer. Roland |
From: Svilen <kru...@go...> - 2008-08-07 20:32:43
|
Michel Dänzer wrote: > On Wed, 2008-08-06 at 18:12 -0600, Brian Paul wrote: > >> Svilen wrote: >> >>> 3 GLX Visuals >>> 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 >>> ---------------------------------------------------------------------- >>> 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >>> 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >>> 0x52 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None >>> >>> 16 GLXFBConfigs: >>> 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 >>> ---------------------------------------------------------------------- >>> 0x53 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None >>> 0x54 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow >>> 0x55 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None >>> 0x56 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow >>> 0x57 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >>> 0x58 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow >>> 0x59 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >>> 0x5a 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow >>> 0x5b 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None >>> 0x5c 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow >>> 0x5d 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None >>> 0x5e 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow >>> 0x5f 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >>> 0x60 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow >>> 0x61 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >>> 0x62 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow >>> >> First, maybe another R300 user can say what 'glxinfo' says on their system. >> > > I get the same. > > >> Off hand I'd expect more GLX visuals and fewer FBConfigs. >> > > It's due to Kristian Høgsberg's GLX visual reworks. I think the idea is > to only have GLX visuals for the common use cases by default and to > stick to FBConfigs otherwise. There's a xorg.conf Option "GlxVisuals" to > change this though which is documented in the xorg.conf manpage. > > Phew! That was easy! Section "ServerLayout" ... Option "GlxVisuals" "all" EndSection ... and job done! Well, maybe it's too early to jump ?! Thanks Michel! A couple of questions. - Does anybody knows whether this is a problem with nVidia cards as well ? - What is the rationale behind hiding GLX visuals by default? Memory? Speed? - What was the version that introduced this change? - Maybe I need to read first about FBconfigs. Any links? Sorry about asking more questions, but I believe the answers will be helpful not only to me Regards Svilen |