Bug 61090 - X refuses to run with DRI beyond 1024x768 on 16Mb tdfx cards
X refuses to run with DRI beyond 1024x768 on 16Mb tdfx cards
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: FutureFeature
: 62344 64723 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-13 09:36 EST by Need Real Name
Modified: 2007-04-18 12:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-05-10 02:07:14 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 with 1600x1200 res. and DRI specified (1.59 KB, text/plain)
2002-03-14 03:51 EST, Need Real Name
no flags Details
log file from XFree86-4.2.0-6.24 (the last version that works okay) (23.95 KB, text/plain)
2002-03-14 03:53 EST, Need Real Name
no flags Details
log file from XFree86-4.2.0-6.45 (23.34 KB, text/plain)
2002-03-14 03:55 EST, Need Real Name
no flags Details

  None (edit)
Description Need Real Name 2002-03-13 09:36:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020308

Description of problem:
XFree86 4.2.0 versions >6.24 refuse to run with tdfx DRI in 1600x1200

Version-Release number of selected component (if applicable):
XFree86-4.2.0-6.45

How reproducible:
Always

Steps to Reproduce:
1. specify both the DRI module and a resolution of 1600x1200 in /etc/X11/XF86Config
2. restart X

Actual Results:  version 6.32 crashed
version 6.45 logs this into /var/log/XFree86.0.log:
>(WW) TDFX(0): [dri] To use DRI, with a 16Mb Voodoo 3 or Banshee card, you must
>        invoke the server using a maximum resolution of 1024x768 or lower.

Expected Results:  versions 6.24 and lower (even 4.1.0-x and 4.0.0-x) used to
work just fine with both 1600x1200 resolution _and_ DRI.

Additional info:

Since GL is very slow without acceleration, I'd like to continue using X with
DRI enabled. And I didn't buy a 19" monitor to use it with a resolution as low
as 1024x768.
So, please add an option to re-enable DRI in 1600x1200 on tdfx cards.
Comment 1 Mike A. Harris 2002-03-13 23:45:32 EST
It is possible there is a glitch in the driver.  Please attach your
X server log, and your X config file using the file attachment link
below.
Comment 2 Need Real Name 2002-03-14 03:51:47 EST
Created attachment 48464 [details]
XF86Config with 1600x1200 res. and DRI specified
Comment 3 Need Real Name 2002-03-14 03:53:37 EST
Created attachment 48465 [details]
log file from XFree86-4.2.0-6.24 (the last version that works okay)
Comment 4 Need Real Name 2002-03-14 03:55:03 EST
Created attachment 48466 [details]
log file from XFree86-4.2.0-6.45
Comment 5 Mike A. Harris 2002-03-14 07:43:17 EST
Ah, ok.  I thought perhaps you had a Voodoo 4 or Voodoo 5, and the
detection logic had failed somehow, but it is working correctly.

The 3dfx driver did not previously check how much memory was on the
card prior to enabling DRI.  This caused a condition in which users
would enable DRI acceleration and high resolution at the same time,
then run 3D games or other OpenGL applications which use texture
mapping, which would fail because there was not enough memory
available on the video card to store textures, etc properly.

This causes the X server to crash in the least case scenario, and
in the worst case scenario it causes the machine to lock up.

The problem is that DRI requires a fairly large amount of video
memory to be available for textures and vertices, etc. however
high resolution video modes also use a lot of video memory.  So
if you use the two in combination, the memory allocated by the X
server uses a lot of memory, and DRI does not have enough memory
to work properly.

Depending on the 3D application being used, it may work for a while
in the the cases of very simple and trivial OpenGL applications,
such as a few of the supplied OpenGL screen savers, however with
the more complex screen savers, some of the Mesa demo programs,
and most 3D video games, what occurs is either an immediate lock up,
or the app runs for a period of time, and eventually locks up the
system.

This problem has been present in the 3dfx driver for a long time, and
has been frustrating to find the root cause.  It does not occur on most
other 16Mb AGP video cards because most AGP cards implement full AGP, which
includes using AGP textures.  The 3dfx cards do not, and are thus limited
to the 16Mb of RAM on the card itself.

The solution to this, is to have the DRI driver detect the combination
of DRI being used with video modes that cannot properly support it, and
disable DRI in those cases.  This is the warning message which you are
seeing above.

You claim above that this combination used to work fine for you, which
I can only conclude means that you did not run anything other than
trivial OpenGL programs.  Running a game such as Quake 3, or some other
intensive application will certainly trigger the lockup behaviour which
I described above.

This change was made for stability of the 3dfx driver due to the volume
of bug reports received from gamers and other people who did not realize
and/or understand the limitations of their hardware.  The driver as is,
without this bug fix is not supportable.

The alternate solution, is for someone with a deep knowledge of the 3dfx
driver, and the tdfx DRI driver, and Glide3 to make the driver work
better in situations of low 3D memory availability instead of crashing,
however that is beyond our expertise and our level of support.

I might possibly consider adding a user configureable option such as:

Option "IWantBrokenDRI"  or Option "DisableDRISanityTestForHighRes".

possibly that allows users to disable this sanity check, knowing their
configuration is unsupported and may crash.



Comment 6 Need Real Name 2002-03-14 13:54:46 EST
Yes, please add an option like that. For screensavers, games light on 3D
resources, like chromium, and many other programs that use OpenGL, 16 mb is
enough. I'd like to be able to use XFree86 versions greater than 4.2.0-6.24.
Comment 7 Mike A. Harris 2002-03-31 07:18:55 EST
*** Bug 62344 has been marked as a duplicate of this bug. ***
Comment 8 Mike A. Harris 2002-04-01 13:37:24 EST
Not sure if I will have the time to work on this anytime soon as it is
not a high priority item, but I'll keep it open for now.  If someone
else whom is interested also decides to implement a user configureable
option patch, I may include it sooner however.
Comment 9 Alexei Podtelezhnikov 2002-04-01 18:27:37 EST
This discussion arrived to somewhat different conclusions from DRI user guide.
http://dri.sourceforge.net/doc/DRIuserguide.html clearly states that 

"Using the 3D features of a graphics card requires more memory than when it's
just used as a 2D device. Double buffering, depth buffering, stencil buffers,
textures, etc. all require extra graphics memory. These features may require
four times the memory used for a simple 2D display."

Thus, using textures is just one of many memory eaters. 16Mb card cannot
possibly accomodate DRI at 1600x1200 even at 16bit color (pushing 4 Mb). 
BTW, you are trying 24bit colors - not a good idea on your card.

As for your argument about expensive 19 inch monitor... Why not invest in 32 Mb
card then? and my 21 inch at 1280x1024 works just fine.
Comment 10 Need Real Name 2002-04-02 03:01:26 EST
- The conclusion was that it works just fine as long as you don't try any of the
heavy stuff, like Quake. I know I shouldn't try that with this card. I don't
want to anyway. I don't like such violence.
- Also, I'm running 16bit, not 24bit, because 24bit has always been unaccelerated.
- 1280x1024 looks grainy on my 19" monitor. I wouldn't use it on a 21" one at all.
- Buying new hardware is not anywhere near the top of my priority list these days.
- This is not a bug report anymore, it's a feature request now.
Comment 11 Mike A. Harris 2002-04-03 09:39:29 EST
Banshee and Voodoo 3 only support 3D acceleration in hardware at 16 bit
depth anyway, so it is not possible to run them in 24bit depth ever with
3D acceleration.

As stated above, I dont have the time to implement such an option any
time soon, however I will defer it for now, and consider doing so in
a future release.
Comment 12 Mike A. Harris 2002-05-10 02:05:32 EDT
I've decided that adding this option only would decrease the motivation
for someone to fix the driver correctly.  I wont add such an option,
however I plan on changing the error message that comes up, so that
it informs people more clearly of why this is not supported.

Stability trumps any "it works for me" type comments people may make,
and the driver has proven to be  unstable at high resolutions on enough
systems including every board I've got, that it isn't sensible or
responsible to allow the driver to crash people's systems randomly,
merely because nobody is interested in fixing this obsolete driver.

If someone is interested in hacking on the driver and making it operate
stable at higher resolutions with zero crash problems, then this
workaround can go away.  Until that however, as far as I'm concerned,
the driver is broken (and the DRI team agrees with me on this, and
they wrote the driver), and is not likely to be fixed unless someone
with a personal itch to scratch in the community cares to fix it.

As an aide to any enterprising individuals interested in solving this
problem, here is a URL which has downloadable PDF datasheets for all
of the 3Dfx Voodoo and Banshee hardware up to the Voodoo 3:

http://www.medex.hu/~danthe/tdfx

The dri-devel mailing list on sourceforge will prove helpful in
working on this project as well.  DRI meetings are also held on Monday's
at 4pm EST on #dri-devel on irc.openprojects.net

Hope this helps.
Comment 13 Mike A. Harris 2002-05-10 02:09:46 EDT
*** Bug 64723 has been marked as a duplicate of this bug. ***

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