With ATI Technologies Inc Rage 128 RF card XFree86-4.0.2-11.4.0 claims
to support direct rendering in 24-bit depth. This is actually a
relevant fragment of a log file:
(0): X context handle = 0x00000001
(0): [drm] installed DRM signal handler
(0): [DRI] installation complete
(II) R128(0): [drm] Added 128 16384 byte vertex/indirect buffers
(II) R128(0): [drm] Mapped 128 vertex/indirect buffers
(II) R128(0): Direct rendering enabled
But an attempt to run any of Mesa-demos, like 'gears' or 'bounce'
produces only a window with a black background and a keyboad focus
is not returned even if this demo is started in a background.
Luckily enough one can log over a network and kill an offending
program (most of the time :-).
In depth 16 most of demos works - more or less; with small exceptions
like 'clearspd', 'double' or 'gltestperf' which may have nasty
Oops! 2.4.2-0.1.19 from RC2
Oh, rereading, it works fine in 16bpp, but not 24.
"Works fine" is maybe tad too optimistic in places, :-) but in principle
it does work in depth 16. 'gears' benchmarks reports there numbers in
620 fps range.
Depth 32 is not supported in this driver and in depth 8 there is no
direct rendering. The later depth is ridiculous on that hardware anyway.
Ok, this is a new one for me. I don't have any other info to corelate
with. Can you attach full config file and server log please? I can't
currently reproduce this yet..
There is not much info. Log files look remarkably similar both for 16
and 24 bit depths. The only difference is that one works, more or less,
and the other does not.
This is what 'glinfo' has to say (24-bit depth but this does not make
GL_VERSION: 1.2 Mesa 3.4
GL_EXTENSIONS: GL_ARB_multitexture GL_ARB_tranpose_matrix GL_EXT_abgr
GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array GL_EXT_histogram GL_EXT_packed_pixels
GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_stencil_wrap
GL_EXT_texture3D GL_EXT_texture_env_add GL_EXT_texture_object
GL_EXT_texture_lod_bias GL_EXT_vertex_array GL_MESA_window_pos
GL_MESA_resize_buffers GL_NV_texgen_reflection GL_PGI_misc_hints
GL_RENDERER: Mesa DRI Rage128 20001215 AGP 2x x86/3DNow!
GL_VENDOR: VA Linux Systems, Inc.
GLU_VERSION: 1.1 Mesa 3.4.1
Requested files attached.
Created attachment 12102 [details]
XF86Config file used with ATI R128 card
Created attachment 12103 [details]
Log file for ATI R128 - 24 depth run
You're using the framebuffer driver. Please try X without the
framebuffer, and make sure you're using 4.0.2-11.4.0, and Mesa 3.4-11
as well as the latest rawhide kernel. Does this fix it for you?
> You're using the framebuffer driver.
Oh, really? So how did you perform this feat of a deduction if only
differences between XFree logs from a failing run (24-bits) and a
working one (16-bits, fps from 'gears' in 625 range) are as attached?
> Please try X without the framebuffer,
Could you tell me, please, how outside of specifying in my XFree86-4
config 'Device "ATI Rage 128"' in my Screen section? Especially that
with 'Device "Linux Frame Buffer"' there I see "(EE) No devices
> and make sure you're using 4.0.2-11.4.0, and Mesa 3.4-11
> as well as the latest rawhide kernel. Does this fix it for you?
I have right now Mesa 3.4-11, kernel-2.4.2-0.1.25 and
XFree86-4.0.2-12.1. Nothing changed in the reported behaviour.
Created attachment 12622 [details]
Diffs from X log files in 24-bit depth and 16-bit depth
Recently I had an opportunity to try "graphics intensive graphical hardware
accelaration tester", a.k.a. 'tuxracer', on a machine with ATI r128 and
with XFree86-4.0.3-5 server. It was running just fine when depth was 16
bits. Attempts to run it in 24 bits were consistenly bringing a totally
black window, with a music playing in a background, and all keyboard and mouse
gone. The only way out was to reboot machine remotely - it it happened
to be connected over a network. Even killing X server was of no help.
A keyboard was back but the whole video was crashed and it was no way to
see what one was typing on a screen full of vertical stripes.
Oh, a kernel used in these experiments was 2.4.2-0.1.49. Nothing unusual
in XFree log files.
Some 3D hardware supports 3D acceleration only in 16 bit fbbpp, some
hardware also supports 32bit depth. To do DRI you must use one of the
modes supported by the hardware, and also by XFree86. This bug is old
and likely been fixed in our latest stuff, with the r128 kernel fixes
as well as the stuff in -15 build of XFree86. Can you try my -15 release
along with the r128 kernel patch, and let me know if it works now?
Just noticed also, you have 16Mb of RAM.
1280*1024*4 = 5242880
DRI needs a *LOT* of memory to do 3D. Plus you need more memory for textures,
and pixmaps and other stuff. Looks like your card is not made to do 3D at
this high a resolution. Does it work in 640x480 with depth24?
> Can you try my -15 release
> along with the r128 kernel patch, and let me know if it works now?
I am afraid that this would be difficult as I do not even have an
access to the machine in question right now. Maybe in a month, or so.
Waiting for test results..
Have you tested this yet, with any newer releases of X including
I am afraid that I do not have now any hardware of that sort. Quite
a few of these things is only passing for a short while through my hands.
All of my r128 cards work with the current XFree86 4.1.0-3 release of
XFree86, so I'm closing the bug CURRENTRELEASE. Please reopen if you
reattain hardware access and continue to have this problem.
4.1.0 DRI is much improved to boot.