From: Andreas S. <A.S...@gm...> - 2004-02-03 22:03:41
|
after setting LIBGL_ALWAYS_INDIRECT=3D1 glxinfo shows OpenGL version string: 1.5 Mesa 6.0 but doesnt show all extensions necessary for OpenGL 1.5 An application only checking for GL_VERSION 1.5 would probably fail. Any idea what would happen with libGL.so / libGLcore.a from different versi= ons of XFree86 / DRI and/or different vendors (nvidia) on the client/server mac= hines? "indirect" extensions (libGL.so from DRI): OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.5 Mesa 6.0 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture,=20 GL_ARB_point_parameters, GL_ARB_shadow, GL_ARB_shadow_ambient,=20 GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map,=20 GL_ARB_texture_env_add, GL_ARB_texture_env_combine,=20 GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,=20 GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix,=20 GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,=20 GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax,= =20 GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_copy_texture,=20 GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,= =20 GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal,=20 GL_EXT_secondary_color, GL_EXT_separate_specular_color,=20 GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap,=20 GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D,=20 GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,=20 GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,=20 GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangl= e,=20 GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_mirror_once= ,=20 GL_ATI_texture_env_combine3, GL_IBM_texture_mirrored_repeat,=20 GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square,=20 GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_SGIS_generate_mipm= ap,=20 GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp,=20 GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow,=20 GL_SGIX_shadow_ambient Mesa extensions (libGL.so from an older build of mesa): OpenGL vendor string: Brian Paul OpenGL renderer string: Mesa X11 OpenGL version string: 1.5 Mesa 6.0 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_imaging,=20 GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query,=20 GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow,=20 GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp,=20 GL_ARB_texture_compression, GL_ARB_texture_cube_map,=20 GL_ARB_texture_env_add, GL_ARB_texture_env_combine,=20 GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,=20 GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two,=20 GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object,=20 GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra,=20 GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op,= =20 GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,=20 GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture,= =20 GL_EXT_depth_bounds_test, GL_EXT_draw_range_elements, GL_EXT_fog_coord,= =20 GL_EXT_histogram, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels,=20 GL_EXT_paletted_texture, GL_EXT_point_parameters, GL_EXT_polygon_offset= ,=20 GL_EXT_rescale_normal, GL_EXT_secondary_color,=20 GL_EXT_separate_specular_color, GL_EXT_shadow_funcs,=20 GL_EXT_shared_texture_palette, GL_EXT_stencil_two_side,=20 GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3= D,=20 GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,=20 GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,=20 GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp,=20 GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array,= =20 GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3,=20 GL_ATI_texture_mirror_once, GL_HP_occlusion_test,=20 GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip,=20 GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,=20 GL_MESA_pack_invert, GL_MESA_program_debug, GL_MESA_resize_buffers,=20 GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square,=20 GL_NV_fragment_program, GL_NV_light_max_exponent, GL_NV_point_sprite,= =20 GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program,= =20 GL_NV_vertex_program1_1, GL_SGI_color_matrix, GL_SGI_color_table,=20 GL_SGI_texture_color_table, GL_SGIS_generate_mipmap,=20 GL_SGIS_pixel_texture, GL_SGIS_texture_border_clamp,=20 GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture,= =20 GL_SGIX_pixel_texture, GL_SGIX_shadow, GL_SGIX_shadow_ambient,=20 GL_SUN_multi_draw_arrays |
From: Ian R. <id...@us...> - 2004-02-03 23:56:37
|
Andreas Stenglein wrote: > after setting LIBGL_ALWAYS_INDIRECT=1 > glxinfo shows > OpenGL version string: 1.5 Mesa 6.0 > but doesnt show all extensions necessary for OpenGL 1.5 > > An application only checking for GL_VERSION 1.5 would probably fail. > > Any idea what would happen with libGL.so / libGLcore.a from different versions > of XFree86 / DRI and/or different vendors (nvidia) on the client/server machines? That's *bad*. It is currently *impossible* to have GL 1.5 with indirect rendering because some of the GLX protocol (for ARB_occlusion_query & ARB_vertex_buffer_objects) was never completely defined. Looking back at it, we can't even advertise 1.3 or 1.4 with indirect rendering becuase the protocol for ARB_texture_compression isn't supported (on either end). Please submit a bug for this on XFree86. Something should be done for this for the 4.4.0 release. http://bugs.xfree86.org/ Does anyone know if either the ATI or Nvidia closed-source drivers support ARB_texture_compression for indirect rendering? If one of them does, that would give us a test bed for the client-side protocol support. When that support is added, we can change the library version to 1.4 (i.e., change from libGL.so.1.2 to libGL.so.1.4, with extra .1.2 and .1.3 symlinks). |
From: Michel <mi...@da...> - 2004-02-04 00:21:49
|
On Wed, 2004-02-04 at 00:56, Ian Romanick wrote: > > Does anyone know if either the ATI or Nvidia closed-source drivers > support ARB_texture_compression for indirect rendering? If one of them > does, that would give us a test bed for the client-side protocol > support. When that support is added, we can change the library version > to 1.4 (i.e., change from libGL.so.1.2 to libGL.so.1.4, with extra .1.2 > and .1.3 symlinks). Are those symlinks really necessary? Apps should only care about libGL.so.1 . While we're at it: is there a reason for libGL not having a patchlevel, e.g. libGL.so.1.2.0? This can cause unpleasant surprises because ldconfig will consider something like libGL.so.1.2.bak as the higher patchlevel and change libGL.so.1 to point to that instead of libGL.so.1.2 . -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Ian R. <id...@us...> - 2004-02-04 17:47:25
|
Michel D=C3=A4nzer wrote: > On Wed, 2004-02-04 at 00:56, Ian Romanick wrote: >=20 >>Does anyone know if either the ATI or Nvidia closed-source drivers=20 >>support ARB_texture_compression for indirect rendering? If one of them= =20 >>does, that would give us a test bed for the client-side protocol=20 >>support. When that support is added, we can change the library version= =20 >>to 1.4 (i.e., change from libGL.so.1.2 to libGL.so.1.4, with extra .1.2= =20 >>and .1.3 symlinks). >=20 > Are those symlinks really necessary? Apps should only care about > libGL.so.1 .=20 It's a debatable point. If an app explicitly links against=20 libGL.so.1.5, then it can expect symbols to statically exist that may=20 not be in libGL.so.1.2. So an app that links against libGL.so.1.5=20 wouldn't have to use glXGetProcAddress for glBindBuffer or glBeginQuery,=20 but an app linking to a lower version would. Do we want to encourage that? That's the debatable part. :) > While we're at it: is there a reason for libGL not having a patchlevel, > e.g. libGL.so.1.2.0? This can cause unpleasant surprises because > ldconfig will consider something like libGL.so.1.2.bak as the higher > patchlevel and change libGL.so.1 to point to that instead of > libGL.so.1.2 . That's a good idea. I've been bitten by that before, but my sollution=20 was to make it libGL.bak.so.1.2 or something similar. |
From: Brian P. <bri...@tu...> - 2004-02-04 19:55:27
|
Ian Romanick wrote: > Michel D=C3=A4nzer wrote: >=20 >> On Wed, 2004-02-04 at 00:56, Ian Romanick wrote: >> >>> Does anyone know if either the ATI or Nvidia closed-source drivers=20 >>> support ARB_texture_compression for indirect rendering? If one of=20 >>> them does, that would give us a test bed for the client-side protocol= =20 >>> support. When that support is added, we can change the library=20 >>> version to 1.4 (i.e., change from libGL.so.1.2 to libGL.so.1.4, with=20 >>> extra .1.2 and .1.3 symlinks). >> >> >> Are those symlinks really necessary? Apps should only care about >> libGL.so.1 .=20 >=20 >=20 > It's a debatable point. If an app explicitly links against=20 > libGL.so.1.5, then it can expect symbols to statically exist that may=20 > not be in libGL.so.1.2. So an app that links against libGL.so.1.5=20 > wouldn't have to use glXGetProcAddress for glBindBuffer or glBeginQuery= ,=20 > but an app linking to a lower version would. Since libGL is usually built with DT_SONAME (aka -soname) set to=20 "libGL.so.1", the minor version number isn't really significant. I.e. I may have originally linked my application with libGL.so.1.5 but=20 at runtime the loader will be satisfied with libGL.so.1.2 > Do we want to encourage that? That's the debatable part. :) >=20 >> While we're at it: is there a reason for libGL not having a patchlevel= , >> e.g. libGL.so.1.2.0? This can cause unpleasant surprises because >> ldconfig will consider something like libGL.so.1.2.bak as the higher >> patchlevel and change libGL.so.1 to point to that instead of >> libGL.so.1.2 . >=20 >=20 > That's a good idea. I've been bitten by that before, but my sollution=20 > was to make it libGL.bak.so.1.2 or something similar. -Brian |
From: Brian P. <bri...@tu...> - 2004-02-04 15:29:33
|
Ian Romanick wrote: > Andreas Stenglein wrote: > >> after setting LIBGL_ALWAYS_INDIRECT=1 >> glxinfo shows >> OpenGL version string: 1.5 Mesa 6.0 >> but doesnt show all extensions necessary for OpenGL 1.5 >> >> An application only checking for GL_VERSION 1.5 would probably fail. >> >> Any idea what would happen with libGL.so / libGLcore.a from different >> versions >> of XFree86 / DRI and/or different vendors (nvidia) on the >> client/server machines? > > > That's *bad*. It is currently *impossible* to have GL 1.5 with indirect > rendering because some of the GLX protocol (for ARB_occlusion_query & > ARB_vertex_buffer_objects) was never completely defined. Looking back > at it, we can't even advertise 1.3 or 1.4 with indirect rendering > becuase the protocol for ARB_texture_compression isn't supported (on > either end). Ian, it seems to me that xc/lib/GL/glx/single2.c's glGetString() function should catch queries for GL_VERSION (as it does for GL_EXTENSIONS) and compute the minimum of the renderer's glGetString(GL_VERSION) and what the client/server GLX modules can support. That would solve this, right? > Please submit a bug for this on XFree86. Something should be done for > this for the 4.4.0 release. > > http://bugs.xfree86.org/ > > Does anyone know if either the ATI or Nvidia closed-source drivers > support ARB_texture_compression for indirect rendering? If one of them > does, that would give us a test bed for the client-side protocol > support. When that support is added, we can change the library version > to 1.4 (i.e., change from libGL.so.1.2 to libGL.so.1.4, with extra .1.2 > and .1.3 symlinks). I don't have the latest NVIDIA drivers on my machines, but glxinfo reports: direct rendering: No server glx vendor string: NVIDIA Corporation server glx version string: 1.3 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_ARB_multisample 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_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_NV_float_buffer GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_ARB_multisample, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce3/AGP/SSE2 OpenGL version string: 1.4.0 NVIDIA 44.96 OpenGL extensions: GL_EXT_blend_minmax, GL_EXT_texture_object, GL_EXT_draw_range_elements, GL_EXT_texture3D, GL_EXT_secondary_color, GL_ARB_multitexture, GL_EXT_multi_draw_arrays, GL_ARB_point_parameters, GL_EXT_fog_coord, GL_ARB_imaging, GL_EXT_vertex_array, GL_EXT_paletted_texture, GL_ARB_window_pos, GL_EXT_blend_color glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess So, it appears that GL_ARB_texture_compression is not supported, but the GL_VERSION is reported as 1.4.0 Hmmm. -Brian |
From: Ian R. <id...@us...> - 2004-02-04 18:12:32
|
Brian Paul wrote: > Ian Romanick wrote: > >> That's *bad*. It is currently *impossible* to have GL 1.5 with >> indirect rendering because some of the GLX protocol (for >> ARB_occlusion_query & ARB_vertex_buffer_objects) was never completely >> defined. Looking back at it, we can't even advertise 1.3 or 1.4 with >> indirect rendering becuase the protocol for ARB_texture_compression >> isn't supported (on either end). > > Ian, it seems to me that xc/lib/GL/glx/single2.c's glGetString() > function should catch queries for GL_VERSION (as it does for > GL_EXTENSIONS) and compute the minimum of the renderer's > glGetString(GL_VERSION) and what the client/server GLX modules can support. > > That would solve this, right? Making that change and changing the server-side to not advertise a core version that it can't take protocol for would fix the bug for 4.4.0. Do you think anything should be done to preserve text after the version? That is, if a server sends us "1.4.20040108 Foobar, Inc. Fancypants GL", should we return "1.2" or something more elaborate? I thought about it some last night, and I think there's some longer term work to be done on the client-side. Basically, we need a mechanism for GL extensions that matches what we have for GLX extensions. There are a few extensions that are essentially client-side only. We should be able to expose those without expecting the server-side to list them. In fact, the server-side should not list them. Extensions like EXT_draw_range_elements, EXT_multi_draw_arrays, and a few others fall into this category. It should be fairly easy to generalize the code for GLX extensions so that it can be used for both. As a side bonus, that would eliminate the compiler warning in glxcmds.c about the __glXGLClientExtensions string being too long. :) >> Does anyone know if either the ATI or Nvidia closed-source drivers >> support ARB_texture_compression for indirect rendering? If one of >> them does, that would give us a test bed for the client-side protocol >> support. When that support is added, we can change the library >> version to 1.4 (i.e., change from libGL.so.1.2 to libGL.so.1.4, with >> extra .1.2 and .1.3 symlinks). [big snip] > OpenGL vendor string: NVIDIA Corporation > OpenGL renderer string: GeForce3/AGP/SSE2 > OpenGL version string: 1.4.0 NVIDIA 44.96 > OpenGL extensions: > GL_EXT_blend_minmax, GL_EXT_texture_object, GL_EXT_draw_range_elements, > GL_EXT_texture3D, GL_EXT_secondary_color, GL_ARB_multitexture, > GL_EXT_multi_draw_arrays, GL_ARB_point_parameters, GL_EXT_fog_coord, > GL_ARB_imaging, GL_EXT_vertex_array, GL_EXT_paletted_texture, > GL_ARB_window_pos, GL_EXT_blend_color > glu version: 1.3 > glu extensions: > GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess > > > So, it appears that GL_ARB_texture_compression is not supported, but the > GL_VERSION is reported as 1.4.0 Hmmm. Okay, that's just weird. Normally the Nvidia extension string is about 3 pages long. |
From: Brian P. <bri...@tu...> - 2004-02-04 19:58:30
|
Ian Romanick wrote: > Brian Paul wrote: > >> Ian Romanick wrote: >> >>> That's *bad*. It is currently *impossible* to have GL 1.5 with >>> indirect rendering because some of the GLX protocol (for >>> ARB_occlusion_query & ARB_vertex_buffer_objects) was never completely >>> defined. Looking back at it, we can't even advertise 1.3 or 1.4 with >>> indirect rendering becuase the protocol for ARB_texture_compression >>> isn't supported (on either end). >> >> >> Ian, it seems to me that xc/lib/GL/glx/single2.c's glGetString() >> function should catch queries for GL_VERSION (as it does for >> GL_EXTENSIONS) and compute the minimum of the renderer's >> glGetString(GL_VERSION) and what the client/server GLX modules can >> support. >> >> That would solve this, right? > > > Making that change and changing the server-side to not advertise a core > version that it can't take protocol for would fix the bug for 4.4.0. Do > you think anything should be done to preserve text after the version? > That is, if a server sends us "1.4.20040108 Foobar, Inc. Fancypants GL", > should we return "1.2" or something more elaborate? It would be nice to preserve the extra text, but it's not essential. > I thought about it some last night, and I think there's some longer term > work to be done on the client-side. Basically, we need a mechanism for > GL extensions that matches what we have for GLX extensions. There are a > few extensions that are essentially client-side only. We should be able > to expose those without expecting the server-side to list them. In > fact, the server-side should not list them. Extensions like > EXT_draw_range_elements, EXT_multi_draw_arrays, and a few others fall > into this category. It should be fairly easy to generalize the code for > GLX extensions so that it can be used for both. Sounds reasonable. > As a side bonus, that would eliminate the compiler warning in glxcmds.c > about the __glXGLClientExtensions string being too long. :) > >>> Does anyone know if either the ATI or Nvidia closed-source drivers >>> support ARB_texture_compression for indirect rendering? If one of >>> them does, that would give us a test bed for the client-side protocol >>> support. When that support is added, we can change the library >>> version to 1.4 (i.e., change from libGL.so.1.2 to libGL.so.1.4, with >>> extra .1.2 and .1.3 symlinks). > > > [big snip] > >> OpenGL vendor string: NVIDIA Corporation >> OpenGL renderer string: GeForce3/AGP/SSE2 >> OpenGL version string: 1.4.0 NVIDIA 44.96 >> OpenGL extensions: >> GL_EXT_blend_minmax, GL_EXT_texture_object, >> GL_EXT_draw_range_elements, >> GL_EXT_texture3D, GL_EXT_secondary_color, GL_ARB_multitexture, >> GL_EXT_multi_draw_arrays, GL_ARB_point_parameters, GL_EXT_fog_coord, >> GL_ARB_imaging, GL_EXT_vertex_array, GL_EXT_paletted_texture, >> GL_ARB_window_pos, GL_EXT_blend_color >> glu version: 1.3 >> glu extensions: >> GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess >> >> >> So, it appears that GL_ARB_texture_compression is not supported, but >> the GL_VERSION is reported as 1.4.0 Hmmm. > > > Okay, that's just weird. Normally the Nvidia extension string is about > 3 pages long. I guess they just aren't bothering to support many extensions via indirect rendering. -Brian |
From: Andreas S. <A.S...@gm...> - 2004-02-04 23:02:48
|
Am 2004.02.04 21:00:14 +0100 schrieb(en) Brian Paul: > Ian Romanick wrote: [snip] > > Making that change and changing the server-side to not advertise a core= =20 > > version that it can't take protocol for would fix the bug for 4.4.0. D= o=20 > > you think anything should be done to preserve text after the version?= =20 > > That is, if a server sends us "1.4.20040108 Foobar, Inc. Fancypants GL"= ,=20 > > should we return "1.2" or something more elaborate? >=20 > It would be nice to preserve the extra text, but it's not essential. why not just add the "1.2 " before the original text? 1.2 1.4.20040108 Foobar, Inc. Fancypants GL so you would see that the renderer could support 1.4 if GLX could do it. @Ian: its bug #1147 http://bugs.xfree86.org/show_bug.cgi?id=3D1147 best regards Andreas |
From: Brian P. <bri...@tu...> - 2004-02-05 21:03:48
|
Andreas Stenglein wrote: > Am 2004.02.04 21:00:14 +0100 schrieb(en) Brian Paul: > >>Ian Romanick wrote: > > [snip] > >>>Making that change and changing the server-side to not advertise a core >>>version that it can't take protocol for would fix the bug for 4.4.0. Do >>>you think anything should be done to preserve text after the version? >>>That is, if a server sends us "1.4.20040108 Foobar, Inc. Fancypants GL", >>> should we return "1.2" or something more elaborate? >> >>It would be nice to preserve the extra text, but it's not essential. > > > why not just add the "1.2 " before the original text? > 1.2 1.4.20040108 Foobar, Inc. Fancypants GL > so you would see that the renderer could support 1.4 if GLX could do it. Yeah, I guess that could be done. -Brian |
From: Ian R. <id...@us...> - 2004-02-07 08:44:57
|
Andreas Stenglein wrote: > Am 2004.02.04 21:00:14 +0100 schrieb(en) Brian Paul: >>Ian Romanick wrote: > >>>Making that change and changing the server-side to not advertise a core >>>version that it can't take protocol for would fix the bug for 4.4.0. Do >>>you think anything should be done to preserve text after the version? >>>That is, if a server sends us "1.4.20040108 Foobar, Inc. Fancypants GL", >>> should we return "1.2" or something more elaborate? >> >>It would be nice to preserve the extra text, but it's not essential. > > why not just add the "1.2 " before the original text? > 1.2 1.4.20040108 Foobar, Inc. Fancypants GL > so you would see that the renderer could support 1.4 if GLX could do it. I like it. :) It looks a little weird to me like that, but I think doing "1.2 (1.4.20040108 Foobar, Inc. Fancypants GL)" should work just as well. I'll try to have a patch tomorrow. The server-side of things is...ugly. The deeper I dig into the server-side GLX code, the more I think it needs the Ultimate Refactor...'rm -rf programs/Xserver/GL' |
From: Andreas S. <A.S...@gm...> - 2004-02-08 18:07:15
|
Am 2004.02.07 09:44:39 +0100 schrieb(en) Ian Romanick: [...] > as well. I'll try to have a patch tomorrow. The server-side of things= =20 Looks like its fixed in DRI CVS with/since your patch. I have to admit that I only tried with the new libGL.so and old Xserver/libs, not with old libGL and new Xserver. OpenGL version string: 1.2 (1.5 Mesa 6.1) [...] > think it needs the Ultimate Refactor...'rm -rf programs/Xserver/GL' =2E.. and I was told 'rm -rf' means "read mail, really fast!" ;) greetings, Andreas |
From: Jon L. <xl...@od...> - 2004-02-08 08:09:30
|
On Sat, Feb 07, 2004 at 12:44:39AM -0800, Ian Romanick wrote: > I like it. :) It looks a little weird to me like that, but I think > doing "1.2 (1.4.20040108 Foobar, Inc. Fancypants GL)" should work just > as well. I would want to be very sure that there are no apps parsing that string before making such a change. Granted it's more likely they'll be looking at the RENDERER string. Jon Leech SGI |
From: Allen A. <ak...@po...> - 2004-02-04 20:30:09
|
On Wed, Feb 04, 2004 at 10:12:19AM -0800, Ian Romanick wrote: | | Okay, that's just weird. Normally the Nvidia extension string is about | 3 pages long. Just for reference, here's the direct-rendering version (table of Visuals omitted): name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.3 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_ARB_multisample 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_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_NV_float_buffer GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_ARB_multisample, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce4 Ti 4200/AGP/SSE2 OpenGL version string: 1.4.1 NVIDIA 53.28 OpenGL extensions: GL_ARB_depth_texture, 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_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, GL_S3_s3tc, GL_EXT_texture_env_add, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, 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_object, GL_EXT_vertex_array, GL_HP_occlusion_test, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_copy_depth_to_color, GL_NV_depth_clamp, GL_NV_fence, GL_NV_fog_distance, GL_NV_light_max_exponent, GL_NV_multisample_filter_hint, GL_NV_occlusion_query, GL_NV_packed_depth_stencil, GL_NV_pixel_data_range, GL_NV_point_sprite, GL_NV_register_combiners, GL_NV_register_combiners2, GL_NV_texgen_reflection, GL_NV_texture_compression_vtc, GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_NV_texture_shader, GL_NV_texture_shader2, GL_NV_texture_shader3, GL_NV_vertex_array_range, GL_NV_vertex_array_range2, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_NVX_ycrcb, GL_SGIS_generate_mipmap, GL_SGIS_multitexture, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SUN_slice_accum glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess Allen |