Bug 61090
Summary: | X refuses to run with DRI beyond 1024x768 on 16Mb tdfx cards | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <kimiko> | ||||||||
Component: | XFree86 | Assignee: | Mike A. Harris <mharris> | ||||||||
Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 7.3 | CC: | billc | ||||||||
Target Milestone: | --- | Keywords: | FutureFeature | ||||||||
Target Release: | --- | ||||||||||
Hardware: | i386 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Enhancement | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2002-05-10 06:07:14 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
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. 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 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. 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 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. 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. *** Bug 64723 has been marked as a duplicate of this bug. *** |
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.