Direct Rendering Infrastructure

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

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

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

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.

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.

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

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

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

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

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

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'

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

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