Bug 30994 - direct rendering on r128 - not exactly
direct rendering on r128 - not exactly
Status: CLOSED CURRENTRELEASE
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86 (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-07 16:08 EST by Michal Jaegermann
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-14 11:54:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
XF86Config file used with ATI R128 card (2.04 KB, text/plain)
2001-03-08 13:10 EST, Michal Jaegermann
no flags Details
Log file for ATI R128 - 24 depth run (27.16 KB, text/plain)
2001-03-08 13:14 EST, Michal Jaegermann
no flags Details
Diffs from X log files in 24-bit depth and 16-bit depth (3.06 KB, patch)
2001-03-13 13:37 EST, Michal Jaegermann
no flags Details | Diff

  None (edit)
Description Michal Jaegermann 2001-03-07 16:08:40 EST
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@harddata.com
Comment 1 Bill Nottingham 2001-03-07 16:12:32 EST
What kernel?
Comment 2 Michal Jaegermann 2001-03-07 16:16:02 EST
Oops! 2.4.2-0.1.19 from RC2
Comment 3 Bill Nottingham 2001-03-07 16:21:23 EST
Oh, rereading, it works fine in 16bpp, but not 24.
Comment 4 Michal Jaegermann 2001-03-07 18:38:47 EST
"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.
Comment 5 Mike A. Harris 2001-03-08 04:47:27 EST
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..
Comment 6 Michal Jaegermann 2001-03-08 13:09:05 EST
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.
Comment 7 Michal Jaegermann 2001-03-08 13:10:34 EST
Created attachment 12102 [details]
XF86Config file used with ATI R128 card
Comment 8 Michal Jaegermann 2001-03-08 13:14:07 EST
Created attachment 12103 [details]
Log file for ATI R128 - 24 depth run
Comment 9 Mike A. Harris 2001-03-12 23:00:27 EST
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?
Comment 10 Michal Jaegermann 2001-03-13 13:36:01 EST
> 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.
Comment 11 Michal Jaegermann 2001-03-13 13:37:27 EST
Created attachment 12622 [details]
Diffs from X log files in 24-bit depth and 16-bit depth
Comment 12 Michal Jaegermann 2001-04-10 13:34:11 EDT
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.
Comment 13 Mike A. Harris 2001-05-15 00:20:36 EDT
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?

Comment 14 Mike A. Harris 2001-05-15 00:27:40 EDT
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?
Comment 15 Michal Jaegermann 2001-05-15 12:42:36 EDT
> 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.

Comment 16 Mike A. Harris 2001-05-22 07:11:43 EDT
Waiting for test results..
Comment 17 Mike A. Harris 2001-08-14 03:01:16 EDT
Have you tested this yet, with any newer releases of X including
Rawhide 4.1.0?
Comment 18 Michal Jaegermann 2001-08-14 11:53:58 EDT
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.
Comment 19 Mike A. Harris 2001-10-04 07:47:05 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.