On 10 May 2002, Mike wrote: >>As a general guideline of what is realistically possible with >>such hardware, one might try Windows, and see what 3D video >>modes are available on these cards in Windows while running a 3D >>game. Whatever windows can do with the 3Dfx drivers, it is >>theoretically possible that X can do also. However in addition >>to the problems in the current driver, there is an additional >>problem that XFree86 can't reclaim video memory used by 2D. >>Unless this has changed and slipped by me recently. >> >>I think if someone were to fix the drivers, that 1280x1024 might >>be possible, but I doubt much beyond that could run stable in >>3D. > >So youre saying that Windows is better than Xfree86 and us >Voodoo 3 owners should go back to using it to get the most from >our cards?
No, that is not what I have said at all. What I have said, is to go into Windows, and see what video modes the Windows 3Dfx drivers can do for desktop 2D, and then run popular modern 3D games, and see what 3D resolutions are available in those games under Windows. WRite all this down on paper. Whatever the Windows drivers _cant_ do, you probably wont find XFree86 doing either. XFree86 is more likely going to have limitations over what the Windows drivers can do. By "looking" at Windows, you get an idea of what the limitations are in Windows, and can guage what can be done with the hardware. That does not mean that X will _do_ what the Windows drivers do, however it provides a "we're not here yet" milestone which someone can aim for who is interested in working on the X driver. In other words, if one runs a 1600x1200 desktop in Windows, and runs a 3D game, and the maximum resolution that game presents to you as available to use, is 1024x768 - or 1280x960 - or whatever, then don't expect XFree86 to work in 1024x768 without hacking on the code. Windows can be used to guage what is realistically possible on the hardware. I do not have a windows machine handy that I can shove a 16Mb Voodoo 3 into to see what the max 3D resolution is. >I would only say that the Voodoo 3 is 2 generations old if you >look at from a memory timing/core clock speed point of view >rather than an Nvidia new chip with not widely used features and >larger heatsink every 6 months point of view. I'll test my card >out with Quake 3 and Unreal Tournament this weekend to see how >it fares. People can debate how old the cards are, and how to label them as obsolete or not, but such labels wont change the level of software support available for the cards in XFree86 right now, nor is it likely to cause any existing developers who have touched the driver in the past to prioritize working on the tdfx driver code in the future. In short, the driver is basically abandoned, and left to the community to maintain, as is Glide3. Very small enhancement patches and bugfixes continue to trickle in occasionally (I just submitted a few myself), however it is in "sit there and gain bitrot" mode right now. If the term "obsolete" offends someone, then I retract that term, and call it instead "ultra low priority" instead. At any rate, I've now offered an explanation why I've patched the driver for stability, and why that was required. I've provided a few scenarios for people whom are interested in finding a better fix to explore, and I've offered my help in steering people towards the information and resources they'd need, including providing links to the Voodoo specs. I've illustrated why I think it is important that the driver defaults to disallowing configurations that have caused crashes on existing systems, and why it doesn't matter if it appears to work for one user ok if it does not work for another user ok. I think I've pretty much covered all the points I wanted to make, and don't see much point in further debate about the issue. I've made my decision for our packages, and that isn't changing, and it's up to the DRI guys to decide if they'd like to make the same change or not for upstream stability as well. It's up to someone who has a personal interest in the code to massage it into properly supporting the hardware the way they'd like now. Worst case, lets please let this thread die, unless it changes into developers seeking to fix the real problems. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
