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):
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.
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
So, please add an option to re-enable DRI in 1600x1200 on tdfx cards.
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
Created attachment 48464 [details]
XF86Config with 1600x1200 res. and DRI specified
Created attachment 48465 [details]
log file from XFree86-4.2.0-6.24 (the last version that works okay)
Created attachment 48466 [details]
log file from XFree86-4.2.0-6.45
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
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
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.
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.
*** Bug 62344 has been marked as a duplicate of this bug. ***
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.
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.
- 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.
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
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.
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:
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.
*** Bug 64723 has been marked as a duplicate of this bug. ***