#444 Strange behavior of the TCL branch


I have an ATI Radeon LE (which is pretty much the same
card as the ATI Radeon DDR but only with 32megs of DDR
ram not 64).

Linux misato 2.4.19-pre10 #1 Tue Jun 4 04:44:29 EDT
2002 i686 unknown


XFree86 Version 4.2.0 (DRI trunk) / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 18 January 2002

checked out with:
cvs -z3 -d
co -rtcl-0-0-branch xc

my pci list:
00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host
Bridge and Memory Controller Hub (rev 04)
00:01.0 PCI bridge: Intel Corp.: Unknown device 1131
(rev 04)
00:1e.0 PCI bridge: Intel Corp. 82820 820 (Camino 2)
Chipset PCI (rev 11)
00:1f.0 ISA bridge: Intel Corp. 82820 820 (Camino 2)
Chipset ISA Bridge (ICH2) (rev 11)
00:1f.1 IDE interface: Intel Corp. 82820 820 (Camino 2)
Chipset IDE U100 (rev 11)
00:1f.2 USB Controller: Intel Corp. 82820 820 (Camino
2) Chipset USB (Hub A) (rev 11)
00:1f.3 SMBus: Intel Corp. 82820 820 (Camino 2) Chipset
SMBus (rev 11)
00:1f.4 USB Controller: Intel Corp. 82820 820 (Camino
2) Chipset USB (Hub B) (rev 11)
01:00.0 VGA compatible controller: ATI Technologies Inc
Radeon QD
02:01.0 Multimedia audio controller: Ensoniq 5880
AudioPCI (rev 02)
02:02.0 Ethernet controller: Digital Equipment
Corporation DECchip 21041 [Tulip Pass 3] (rev 21)
02:03.0 Ethernet controller: 3Com Corporation
3c900B-TPO [Etherlink XL TPO] (rev 04)
02:04.0 Multimedia video controller: Brooktree
Corporation Bt878 (rev 02)
02:04.1 Multimedia controller: Brooktree Corporation
Bt878 (rev 02)

name of display: :0.0
radeonUpdatePageFlipping allow 0 current 0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating,
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating,
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI Radeon 20020309 AGP 4x
OpenGL version string: 1.2 Mesa 4.0.1
OpenGL extensions:
GL_ARB_imaging, GL_ARB_multitexture,
GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra,
GL_EXT_blend_logic_op, GL_EXT_blend_minmax,
GL_EXT_clip_volume_hint, GL_EXT_convolution,
GL_EXT_histogram, GL_EXT_packed_pixels,
GL_EXT_rescale_normal, GL_EXT_secondary_color,
GL_EXT_texture_env_add, GL_EXT_texture_env_combine,
GL_EXT_texture_object, GL_EXT_texture_lod_bias,
GL_IBM_rasterpos_clip, GL_MESA_window_pos,
GL_SGI_color_matrix, GL_SGI_color_table
glu version: 1.2 Mesa 3.3 beta
glu extensions:


When I run any OpenGL game like say , RTCW or Q3 or
even something with Wine (like JD2) I get rather poor

While playing any of the OGL games the frame rates
aren't stable, approximtly once a second the game
pauses for a small amount of time and then resumes...
Even if I were to stay in the same place (i.e. not
cause the game to texture swap by looking at a wall for
example) the frame rate still drops to 0 every second
(the game pauses the FPS counter drops and then counts
back up).

This happens in any opengl prog that i've tried, it
looks like the driver is doing something at one second
intervals that causes the software to wait.

Now, the intesting part. I normally run overclocked
(this bug report was produced for NON-OVERCLOCKED
runs)... at 121MHZ FSB (with PCI divider of 3), my
computer is very stable like that, I have multi-month
uptimes with high load, however, the behaviour of this
problems differs with bus speed. If I run the BUS at
100mhz (i.e. giving PCI normal 33mhz speed) this
problem is a bit less noticebale because the "pause"
appears to be shorter (however still present and still
very noticeable). The higher the BUS speed becomes
(for example 121mhz FSB with a PCI speed of 40mhz) the
more noticeable the pauses are and more jerky the game

There were no such problems with the normal XF 4.2.0
release and an MGAG450... (at any bus speed)

If any one is interested in more feedback or has
questions of any kind I will be glad to help to the
best of my ability (my email hackie@misato.prohost.org).


  • Michel Dänzer

    Michel Dänzer - 2002-06-16
    • assigned_to: nobody --> mdaenzer
    • status: open --> closed-fixed
  • Michel Dänzer

    Michel Dänzer - 2002-06-16

    Logged In: YES

    This is fixed on the trunk.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks