strange "GLX_EXT_texture_from_pixmap is missing" e

[ioannis]

Once again I run into the famous "compiz: GLX_EXT_texture_from_pixmap is missing" error. The problem is I can't figure out what's wrong.

I use fedora core 6 on an athlon XP with an ati RV250 and the radeon open-source drivers

running compiz reports:
$ LIBGL_DEBUG=verbose compiz --replace --use-cow --strict-binding gconf
libGL: XF86DRIGetClientDriverName: 5.2.0 r200 (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri//r200_dri.so
drmOpenByBusid: Searching for BusID pci:0000:01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
libGL warning: 3D driver claims to not support visual 0x4b
libGL error:
Can't open configuration file /home/ioannis/.drirc: No such file or directory.
compiz: GLX_EXT_texture_from_pixmap is missing
compiz: Failed to manage screen: 0
compiz: No manageable screens found on display :0

but running glxinfo says:
$ glxinfo | grep GLX_EXT_texture_from_pixmap
libGL warning: 3D driver claims to not support visual 0x4b
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap

which suggests that the extensions is there!

The follwoing might be useful to know as well
$ glxinfo | grep direct
libGL warning: 3D driver claims to not support visual 0x4b
direct rendering: Yes

$ dmesg | grep drm
[drm] Initialized drm 1.0.1 20051102
[drm] Initialized radeon 1.25.0 20060524 on minor 0
[drm] Setting GART location based on new memory map
[drm] Loading R200 Microcode
[drm] writeback test succeeded in 1 usecs

$ grep AIGLX /var/log/Xorg.0.log
(**) Option "AIGLX" "true"
(**) AIGLX enabled
(WW) AIGLX: 3D driver claims to not support visual 0x23
(WW) AIGLX: 3D driver claims to not support visual 0x24
(WW) AIGLX: 3D driver claims to not support visual 0x25
(WW) AIGLX: 3D driver claims to not support visual 0x26
(WW) AIGLX: 3D driver claims to not support visual 0x27
(WW) AIGLX: 3D driver claims to not support visual 0x28
(WW) AIGLX: 3D driver claims to not support visual 0x29
(WW) AIGLX: 3D driver claims to not support visual 0x2a
(WW) AIGLX: 3D driver claims to not support visual 0x2b
(WW) AIGLX: 3D driver claims to not support visual 0x2c
(WW) AIGLX: 3D driver claims to not support visual 0x2d
(WW) AIGLX: 3D driver claims to not support visual 0x2e
(WW) AIGLX: 3D driver claims to not support visual 0x2f
(WW) AIGLX: 3D driver claims to not support visual 0x30
(WW) AIGLX: 3D driver claims to not support visual 0x31
(WW) AIGLX: 3D driver claims to not support visual 0x32
(II) AIGLX: Loaded and initialized /usr/lib/dri/r200_dri.so

$ grep DRI /var/log/Xorg.0.log
(II) Loading extension XFree86-DRI
(II) RADEON(0): [dri] Found DRI library version 1.2.0 and kernel module version 1.25.0
(**) RADEON(0): DRI New memory map param
(**) RADEON(0): DRI Finishing init !
(II) RADEON(0): [DRI] installation complete
(WW) RADEON(0): DRI init changed memory map, adjusting ...
(II) GLX: Initialized DRI GL provider for screen 0

Here comes the most weird thing of all. I noticed that AIGLX loads "/usr/lib/dri/r200_dri.so" while compiz tries to use "/usr/X11R6/lib/modules/dri//r200_dri.so", the latter being a symbolic link of the former.

If I remove the symbolic link then compiz works, but I get the following:
$ LIBGL_DEBUG=verbose compiz --replace --use-cow --strict-binding gconf
libGL: XF86DRIGetClientDriverName: 5.2.0 r200 (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri//r200_dri.so
libGL error: dlopen /usr/X11R6/lib/modules/dri//r200_dri.so failed (/usr/X11R6/lib/modules/dri//r200_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: r200_dri.so

glxinfo report that there is no "direct rendering". Compiz works fairly ok, although anything that uses lots of CPU makes compiz have hiccups (slows down significantly and all effects are "jumpy") and scrolling is slow in general.

Any ideas ?

[fab]

Well i think i know the reason :

try glxinfo without grep .
You should find three entries for GLX_ext_texture_from_pixmap :

One in server glx extensions, one in client glx extensions and one in GLX extensions.

If it is not present in GLX extensions you will have the problem of extension not found.

If it is not present in GLX extensions but both in server and clients one then it is a bug in xorg ( because GLX extensions is the intersect between server and client extension ).

I have this problem on laptop with an i945gm card. To solve the problem i compile my own package commenting the line for the test in src/screen.c and it is working flawlessly.

This bug is a known one and corrected in xorg. We just need a new release for it ( 7.2 or 7.1.2 ).

Have a good evening

[ioannis]

Indeed you are right!

when the symbolic link to r200_dri.so is present, the GLX_EXT_texture_from_pixmap appears only on at the server and client glx extension but not in the GLX extensions section. On the other hand, removing the symbolic link to the dri driver I get the 3 instances of the extension.

If I get this right, we need a newer libglx.so. i.e. get the latest xorg server. So this is not a driver or Mesa issue, right?

thanks

[ioannis]

I've updated xserver and the open-source ati driver from fedora's development repositories, but these exhibit the same behaviour. The server version is 7.1.1 though.
I've tried to compile my own server but failed due to dependencies nightmare.

As someone from the compiz mailing list suggested, using
LIBGL_ALWAYS_INDIRECT=1 brings back the extension in the GLX extensions section.
thus invoking compiz like this:
$ LIBGL_ALWAYS_INDIRECT=1 compiz --replace --use-cow --strict-binding gconf

works, but transparencies don't work, shadows are black.

if I don't use --strict-binding the server crashes. The same happens if I use --indirect-rendering. If I don't use --use-cow the display is not updated.

[ioannis]

I wonder why each of the glx section has a different version. My glxinfo reports

direct rendering: Yes
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_EXT_texture_from_pixmap, GLX_OML_swap_method,
GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,
GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
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_allocate_memory,
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_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R200 20060602 AGP 1x x86/MMX+/3DNow!+/SSE TCL
OpenGL version string: 1.3 Mesa 6.5.2
OpenGL extensions:....

the server is 1.2, the client 1.4 and the the third one 1.2. Even the two with the same glx version have different mixture of extensions. What does each of those three sections corresponds to? I know the "server glx extensions" are those provided by the X server (and if I'm not mistaken this is the well known libglx.so object). Is the client glx the driver? and if so, what's the third one?

I also noticed that the client has "pbuffer" support. GLX 1.3 introduces, among other, pbuffer drawables. Is there a 1.3 version for the server available (and for the mysterious third "GLX extensions" field)?

also the GLX_EXT_texture_from_pixmap doesn't seem to be part of any specific GLX spec. I only found that it requires at least 1.2 and the GLX_SGIX_fbconfig.

oh! boy, I'm confused ! :)

[ioannis]

Ok, let me add here what I've learned so far about this subject. These are from discussions in the Xorg and compiz mailing list.

First of all, GLX_EXT_texture_from_pixmap (otherwise known as TFP), is only supported, at the moment, via indirect rendering with AIGLX. There is a plan to add support of the extension in direct rendering, which is now possible since an important prerequisite, the Translation Table Maps(TTM), which has been recently add to the Direct Rendering Manager (DRM), is now in place.[1]

thus, to run compiz using the open-source radeon drivers one needs to force indirect rendering by using the LIBGL_ALWAYS_INDIRECT=1 variable. e.g.

$ LIBGL_ALWAYS_INDIRECT=1 compiz --replace --use-cow gconf

that works well, but because the server doesn't support pbuffers yet, any 3d app will not map to the windows. Same applies for video.

And as for my question about the difference between server, client and general GLX extension fields in glxinfo, these are:

server: "There's a server-side GLX module that decodes incoming GLX commands and dispatches them to the rendering core, which is Mesa (or NVIDIA's driver if using NVIDIA hardware, for example)"[2]

client: "Client-side is the libGL.so library which takes GL commands and converts them to GLX commands, or dispatches them to the local direct-rendering driver"[2]

general: and that's the resulting supported GLX extensions, depending what the server and client sides support.
"Most GLX extensions have both client and server-side requirements and only are available for use when both ends support the extension."[2]


[1] Michel Dänzer
[2] Brian Paul