interpreting glxinfo's output

[andrew rader]

On Wed, Mar 26, 2008 at 5:03 PM, Adam K Kirchhoff <adamk at voicenet.com> wrote:
>
> On Wednesday 26 March 2008 19:37:07 andrew rader wrote:
> > Hi all,
> >
> > I've been toying with the idea of creating a small compositing window
> > manager for a while, and I've started looking at the sourcecode of
> > compiz, xcompmgr, etc and I have a quick question. I'm currently using
> > a laptop with the intel gm965 chipset (aka X3100) and I've been
> > bothered by the output of glxinfo regarding the texture_from_pixmap
> > extension.
> >
> > My app is using the glXQueryExtensionsString function to check for the
> > existence of the GLX_EXT_texture_from_pixmap extension, without
> > success. The output of this function is the following string:
> >
> > "GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_import_context
> > GLX_EXT_visual_info GLX_EXT_visual_rating GLX_MESA_copy_sub_buffer
> > GLX_MESA_swap_control GLX_MESA_swap_frame_usage GLX_OML_swap_method
> > GLX_SGI_make_current_read GLX_SGI_swap_control GLX_SGI_video_sync
> > GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_visual_select_group "
> >
> > The above clearly does not contain the texture_from_pixmap extension,
> > but when I run glxinfo I get the following (snipped for brevity):
> >
> > 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_make_current_read,
> > 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_copy_sub_buffer,
> >    GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
> >    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
> >    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
> > OpenGL vendor string: Tungsten Graphics, Inc
> > OpenGL renderer string: Mesa DRI Intel(R) 965GM 4.1.3002
> > OpenGL version string: 1.4 Mesa 7.0.2
> > OpenGL extensions: <snip>
> >
> > So my question: what is the difference between "server glx
> > extensions", "client glx extensions", and "GLX extensions"? It appears
> > the the first two list "GLX_EXT_texture_from_pixmap" as supported, but
> > the "GLX extensions" list does not.
> >
> > Is this a configuration issue? a driver issue? any ideas would be
> > appreciated
>
> I'm probably not the best person to explain the difference between those
> extensions.  However, GLX_EXT_texture_from_pixmap won't show up under GLX
> extensions unless you run glxinfo after setting LIBGL_ALWAYS_INDIRECT=1.  TFP
> is only supported as a GLX extension via AIGLX on the open source intel and
> radeon drivers (well, except for the experimental intel DRI2 driver, I
> believe).
>
> Adam
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>

thanks for the reply :)

I've seen people mention the LIBGL_ALWAYS_INDIRECT=1 trick, and that
it works for setting up compiz, but wouldn't this then revert to
"slower" rendering? I've also been unable to find _why_ that is needed
and why it works... does it mean the DRI drivers don't support TFP?

I think my basic source of confusion here, is who has to support TFP
for this to work in the "intended" (read: direct) way?

-Andy