Bug 33581 - the best of anaconda is the worst for DRI acceleration. Memory!
Summary: the best of anaconda is the worst for DRI acceleration. Memory!
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: Xconfigurator   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-28 08:07 UTC by Alexei Podtelezhnikov
Modified: 2007-03-27 03:42 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-07-27 23:16:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Alexei Podtelezhnikov 2001-03-28 08:07:14 UTC
Anaconda (and Xconfigurator for that matter) offer 24 bpp as their berst 
color resolution. This resolution, however, is officially unsupported by 
DRI. This leads to unpredictable lock-ups using 3d-accelerated 
xscreensavers. I was able to get my ATI All-in-Wonder 128 pro working only
with 16 bpp.

I suggest adding a little disclaimer concerning this particular 
disadvantage of choosing 24 bpp. DRI officially suports 16 bpp and 32 bpp, 
Unfortunately, neither anaconda, nor Xconfigurator give 32 bpp option for 
sonme reason.

Please, advise users against choosing 24 bpp if they want to use 3d-
accelerated stuff.

Comment 1 Michael Fulbright 2001-03-28 15:47:27 UTC
Preston, Bill, or Trond:

  What is the answer to this so we can get it in the GUI X configuration?

Comment 2 Trond Eivind Glomsrxd 2001-03-28 16:03:10 UTC
24 bpp is the same mode as 32 bpp.

Another factor to consider is that Matrox cards only have working DRI in 16 bpp.

Comment 3 Bill Nottingham 2001-03-28 16:23:13 UTC
Yes; while DRI will try and start in 24/32bpp, I'm not sure it actually
*works* at that depth on any of the cards.

Comment 4 Jeremy Katz 2001-03-28 18:56:55 UTC
I'm pretty sure that the r128 and ati only really work with DRI in 16bpp right
now, especially when you consider that a lot of these chips out there are in
laptops which don't have the video ram you need to support 32bpp and DRI.

Comment 5 Alexei Podtelezhnikov 2001-03-28 19:43:37 UTC
The problem is not r128 specific, see bug 33368 about G400/G450. Nor is it
specific to laptops.

I guess anaconda (and Xconfigurator) should just be more careful enabling DRI
conditionally only for supported color depths! Right now it makes no
distinction, which is wrong. 

Installer should also explicitly warn against 24 bpp, and give the choice of
full 32 bpp.

Comment 6 Trond Eivind Glomsrxd 2001-03-28 19:50:38 UTC
Enabling DRI in usupported bit depths has no harm, 3D is just very slow (not

As for 24 vs. 32 bit, XFree 4 doesn't handle 32 bit so this is not an option.
The current way is not doing anything wrong, but having 16 bpp as default for
Matrox and possibly r128 would give more people accelerated 3D.

Comment 7 Alexei Podtelezhnikov 2001-03-28 20:00:43 UTC
Please see bug 25920 and bug 28987 , they describe how harmful enabling of DRI
on wrong colordepth is. In short, it causes X lock-ups on my Rage 128 PF.

Comment 8 Trond Eivind Glomsrxd 2001-03-28 20:03:31 UTC
These were fixed in the kernel - there was bug there which made the R128s very

Comment 9 Alexei Podtelezhnikov 2001-03-28 21:05:52 UTC
Gareth Hughes's fixes to kernel's drm module probably fixed some cases but they
never helped me. I can lock up X server in no time firing up Morph3D, Gears, or
Atlantis with 24 bpp depth and DRI enabled! True, they slowly worked at this
color depth and DRI disabled. First time I saw these screensavers properly
working was yesterday when I reduced the colordepth to 16 bpp. I do have recent
kernel and X from rawhide.

Comment 10 Alexei Podtelezhnikov 2001-03-30 04:06:00 UTC
It's all about memory. 16 Mb card is supposed to work at 1280x1024x24bpp as 
long as it's not 3d accelerated. 3d stuff locks up X server because DRI 
requires 3-4 times more memory. I tried reducing to 1024x768x24bpp - 3d stuff 
works again! 1280x1024x16bpp works even better.

Thus, anaconda and Xconfigurator should enable DRI only when there is enuf 
memory for it. Top 2d resolution is definately an overshot for DRI.

Sorry for initially erroneous bug report. Anaconda and Xconf stell need fixing 

Comment 11 Mike A. Harris 2001-05-22 10:56:57 UTC
Really the bug is in XFree86 because it should not allow stupid combinations
of options like enabling DRI in high res on unsupported depths on cards with
low memory constraints.

Unfortunately X does allow these dumb configurations.  So, it will definitely
be looked into in the future for X configuration.  I'm changing this from
Anaconda to Xconfigurator.

Comment 12 Mike A. Harris 2002-03-11 02:36:27 UTC
I have fixed a similar problem in the tdfx driver.  A similar fix might
work ok in the r128 driver, but the r128 is significantly different since
there are a lot more different r128 chips to cover, so it might take some
fiddling to get just right.  Not a high priority though since such problem
is rarely reported on ATI hardware.

The proper fix is twofold.

1) Fixing the driver to not allow unsensible combinations at runtime
2) Fixing the config tools to not allow nonsensical configuration.

#2 will come first likely

Deferring for future.

Comment 13 Mike A. Harris 2002-07-27 23:19:19 UTC
Through the last few releases I have not heard of any problems from any
users with DRI being enabled on ATI hardware in bit depths that are
unsupported.  Any stability issues seem to be fixed now.  I'm closing
this out as I don't see it as a relevant issue any more.

If someone experiences a problem similar to this using our latest distro
release, please reopen a new bug report in bugzilla, and we can
try to fix the root cause of the problem, rather than kludging it over
in configuration tools.  The driver source is the proper place to either
fix a bug, or provide detection/workaround of a problem combination of

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