Can't get accelerated 3D on R300, can't build from source

David D. Hagood wowbagger at sktc.net
Thu May 4 05:00:53 PDT 2006


I cannot get accelerated 3D on the R300 to work using the binary 
distribution supplied by Fedora Core Rawhide, nor can I build modular X 
from source.

As per the instructions, I pulled down Mesa from CVS, built the 
linux-dri-x86 target, and installed it into /usr[...] (i.e. NOT into 
/usr/local/[...]).

At that point, this is the output from glxinfo:

glxinfo
name of display: :0.0
Mesa: CPU vendor: AuthenticAMD
Mesa: CPU name: AMD Athlon(tm)
Mesa: MMX cpu detected.
Mesa: 3DNow! cpu detected.
Mesa: SSE cpu detected.
Mesa: Testing OS support for SSE...
Mesa: Yes
Mesa: Testing OS support for SSE unmasked exceptions...
Mesa: Yes.
Mesa: Tests of OS support for SSE passed.
display: :0  screen: 0
direct rendering: No
server glx vendor string: Brian Paul
server glx version string: 1.4 Mesa 6.5.1
server glx extensions:
     GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
     GLX_MESA_release_buffers, GLX_ARB_get_proc_address, 
GLX_EXT_visual_info,
     GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig,
     GLX_SGIX_pbuffer
client glx vendor string: Brian Paul
client glx version string: 1.4 Mesa 6.5.1
client glx extensions:
     GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
     GLX_MESA_release_buffers, GLX_ARB_get_proc_address, 
GLX_EXT_visual_info,
     GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig,
     GLX_SGIX_pbuffer
GLX version: 1.4
GLX extensions:
     GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
     GLX_MESA_release_buffers, GLX_ARB_get_proc_address, 
GLX_EXT_visual_info,
     GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig,
     GLX_SGIX_pbuffer
OpenGL vendor string: Brian Paul
OpenGL renderer string: Mesa X11
OpenGL version string: 1.5 Mesa 6.5.1
OpenGL extensions:
     GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program,
<snip>
     GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays
glu version: 1.3
glu extensions:
     GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

In my /var/log/Xorg.0.log, I see the following:

drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 11, (OK)
drmOpenByBusid: Searching for BusID pci:0000:02:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 11, (OK)
drmOpenByBusid: drmOpenMinor returns 11
drmOpenByBusid: drmGetBusid reports pci:0000:02:00.0
(EE) AIGLX error: Calling driver entry point failed(EE) AIGLX: reverting 
to software rendering

So it would seem that this is the reason that DRI is not working. Now, 
as to *why* AIGLX is not able to call the entry point I do not know - 
I've been unable to find any references that explain this online (hence 
this message). I have created 
https://bugs.freedesktop.org/show_bug.cgi?id=6816 for this problem.

OK, so the next step was to try to pull the modular xc from CVS and 
build it. However, I ran into the following errors:

1) In /usr/include/linux/input.h there is an error wherein struct 
input_device_id uses the kernel_ulong_t typedef, which is only defined 
when compiling the kernel proper, and thus fails. This is a bug in the 
header - so I protected the struct input_device_id definition with a 
#ifdef __KERNEL__, and this allowed compilation to continue.

For a bit.

2) After that change, I get errors later trying to build the drivers:

  gcc -DHAVE_CONFIG_H -I. -I. -I.. -DXFree86Server -DIN_MODULE 
-DXFree86Module
-DXFree86LOADER -I/tmp/modular/include/xorg -I/tmp/modular/include
-march=athlon-xp -mfpmath=sse,387 -O3 -MT ast_vgatool.lo -MD -MP -MF
.deps/ast_vgatool.Tpo -c ast_vgatool.c  -fPIC -DPIC -o .libs/ast_vgatool.o
In file included from ast.h:23,
                  from ast_vgatool.c:58:
/usr/include/string.h:293: error: conflicting types for 'xf86memmove'
/usr/include/string.h:44: error: previous declaration of 'xf86memmove' 
was here
/usr/include/string.h:296: error: conflicting types for 'xf86bzero'
/tmp/modular/include/xorg/xf86_ansic.h:295: error: previous declaration of
'xf86bzero' was here
In file included from /usr/include/stdlib.h:438,
                  from ast.h:24,
                  from ast_vgatool.c:58:
/usr/include/sys/types.h:62: error: conflicting types for 'xf86dev_t'
/tmp/modular/include/xorg/xf86_libc.h:87: error: previous declaration of
'xf86dev_t' was here
/usr/include/sys/types.h:110: error: conflicting types for 'xf86ssize_t'
/tmp/modular/include/xorg/xf86_libc.h:86: error: previous declaration of
'xf86ssize_t' was here
In file included from /usr/include/stdlib.h:438,
                  from ast.h:24,
                  from ast_vgatool.c:58:
/usr/include/sys/types.h:151: error: duplicate 'unsigned'
In file included from ast.h:24,
                  from ast_vgatool.c:58:
/usr/include/stdlib.h:445:29: error: macro "random" passed 1 arguments, but
takes just 0
/usr/include/stdlib.h:628:24: error: macro "abort" passed 1 arguments, 
but takes
just 0
make[2]: *** [ast_vgatool.lo] Error 1
make[2]: Leaving directory 
`/home/wowbaggr/src/xorg/driver/xf86-video-ast/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/wowbaggr/src/xorg/driver/xf86-video-ast'
make: *** [all] Error 2

It would seem that X is aliasing "memmove" and friends to be 
"xf86memmove" and this is confusing the standard headers.

I have created https://bugs.freedesktop.org/show_bug.cgi?id=6815 in 
reference to this.

So, at this point I am dead in the water.

Now, I know others are seeing the "AIGLX" problem, but I have not seen 
any fixes for that.

I cannot imagine a compile problem like I am seeing not going unnoticed, 
but I cannot see what I could be doing to cause it at my end. So, any 
suggestions?



More information about the xorg mailing list