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 side-effects. Michal michal
What kernel?
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 any difference): 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_SGIS_pixel_texture GL_SGIS_texture_edge_clamp GL_RENDERER: Mesa DRI Rage128 20001215 AGP 2x x86/3DNow! GL_VENDOR: VA Linux Systems, Inc. GLU_VERSION: 1.1 Mesa 3.4.1 GLU_EXTENSIONS: GL_EXT_abgr GLUT_API_VERSION: 3 GLUT_XLIB_IMPLEMENTATION: 15 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 detected." > 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 Rawhide 4.1.0?
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.