I sent this to the freebsd-current mailing list yesterday, but haven't
heard back from anyone. And, since I'm not sure if this is an AGP issue
or a DRM specific issue, I thought I'd mention it here as well:
When I boot up, the agp driver is loaded properly:
agp0: <ATI RS100 AGP bridge> on hostb0
When I launch X, the drm and radeon modules are loaded:
drm0: <ATI Radeon RS100 Mobility U1> on vgapci0
info: [drm] AGP at 0xd4000000 64MB
info: [drm] Initialized radeon 1.19.0 20050911
According to the X server, Direct Rendering is enabled:
(II) RADEON(0): [drm] DRM interface version 1.2
(II) RADEON(0): [drm] created "radeon" driver at busid "pci:0000:01:05.0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xc3ce7000
(II) RADEON(0): [drm] mapped SAREA 0xc3ce7000 to 0x283d3000
(II) RADEON(0): [drm] framebuffer handle = 0xe0000000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(II) RADEON(0): [agp] Mode 0x0f000207 [AGP 0x0000/0x0000; Card
0x1002/0x4336]
(II) RADEON(0): [agp] 32768 kB allocated with handle 0xc381f700
(II) RADEON(0): [agp] ring handle = 0xd4000000
(II) RADEON(0): [agp] Ring mapped at 0x2c433000
(II) RADEON(0): [agp] ring read ptr handle = 0xd4101000
(II) RADEON(0): [agp] Ring read ptr mapped at 0x282df000
(II) RADEON(0): [agp] vertex/indirect buffers handle = 0xd4102000
(II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x2c534000
(II) RADEON(0): [agp] GART texture map handle = 0xd4302000
(II) RADEON(0): [agp] GART Texture map mapped at 0x2c734000
(II) RADEON(0): [drm] register handle = 0xd0100000
(II) RADEON(0): [dri] Visual configs initialized
(II) RADEON(0): CP in BM mode
(II) RADEON(0): Using 32 MB GART aperture
(II) RADEON(0): Using 1 MB for the ring buffer
(II) RADEON(0): Using 2 MB for vertex/indirect buffers
(II) RADEON(0): Using 29 MB for GART textures
<snip>
(II) RADEON(0): [drm] installed DRM signal handler
(II) RADEON(0): [DRI] installation complete
(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers
(II) RADEON(0): [drm] dma control initialized, using IRQ 9
(II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416
(II) RADEON(0): Direct rendering enabled
According to glxgears, the DRI driver is being used:
name of display: scroll.netops.dci.lan:0.0
display: scroll.netops.dci.lan: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_visual_info, GLX_EXT_visual_rating,
GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read,
GLX_SGIS_multisample, GLX_SGIX_fbconfig
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_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 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_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI Radeon 20051013 AGP 4x NO-TCL
OpenGL version string: 1.3 Mesa 6.5
However, glxgears is only giving me about 1 FPS. Most other GL
applications (gltext, for example, from the xscreensaver package) are
even slower. Software Mesa is even faster.
The DRM driver is giving the following error message:
error: [drm:pid51336:drm_alloc_resource] *ERROR* Couldn't find resource 0x0
The PID changes, of course, depending on the PID of the X server, but
the rest of the error stays the same.
What's really bizarre, however, is that if I set hw.dri.0.debug to 1,
glxgears gets roughly 200 FPS, faster than software Mesa, but slower
than it can get (undoubtedly due to the massive amounts of debugging
information that the kernel is logging).
I tried a few more GL programs, all from the xscreensaver package.
glforestfire also appear to display less than a frame per second. Same
with flip-flop and flyingtoasters. flurry, on the other hand, is quite
smooth and the FPS meter shows roughly 30 fps.
Any ideas? Thanks!
Adam
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
