There was talk in the DRI weekly meating about tdfx. There is definatly interested non-DRI developers, however motivation is the biggest thing holding tdfx back. Alan Cox has reportedly been working on the voodoo 1&2 series drivers. If there is consumer intrest then programers might be more likely to acctualy do the work. I know I get a jolt when sombody says tuxnes is the best emulator thay could find.
--- "Mike A. Harris" <[EMAIL PROTECTED]> wrote: > On Mon, 1 Mar 2004, Michel [ISO-8859-1] Dänzer wrote: > > >> > It looks to me like the error message you're complaining of was not > >> > added in 4.3.0. > >> > >> I don't see anything that is obviously causing this to be triggered. > >> However, I am unsure about how this code fits in the wider > implementation. > > > >This is due to the patch > 035_tdfx_disable_dri_on_16mb_with_highres.diff, > >which contains the comment: > > > > /* Disable DRI if using a 16Mb card with virtual resolution higher > >than > > * 1024x768 because DRI does not have enough memory available for > >textures > > * at higher resolutions, and will not operate correctly. > > */ > > > >See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=38717 . > > > >Now, this is an odd explanation; 16 MB should be plenty enough for the > >DRI at say 1280x1024x16. Mike, do you have a better explanation for > this > >limit? > > It's been quite a long time now since I created that patch. I > was receiving bug reports of DRI enabled tdfx configurations > crashing randomly when running 3D software, usually video games. > The problem didn't usually occur instantly, but would occur over > a short period of time, and usually only with rather 3D intensive > games like Quake III and the like. > > When the games were played at a lower resolution, the problems > went away. Research into the problem, discovered that it was due > to the majority of the video memory being given to the > framebuffer, and starving texture memory. I do not remember the > gory details, but it should be in dri-devel archives from 1.5-2 > years ago. > > At the time, people proposed that the problem could be solved by > modifying the tdfx code to work better in low memory (read as > high-resolution) situations. I don't believe anyone ever cared > enough about the problem to do that work though, or if it did get > done, it certainly has slipped past me unnoticed. ;o) > > For our (Red Hat) purposes however, I was more concerned with > desktop stability than the ability of 3Dfx hardware users to play > Quake III at high resolution and crash their machine. My > solution was to patch our driver to disable configurations known > to cause crashes or other instabilities in certain circumstances, > and to remove the patch should the real problem ever be fixed in > upstream sources down the line. The patch remains in my current > rpm packages for 4.3.0, and I believe many other distributions > have borrowed the patch also to prevent the instability problems. > > Has the tdfx driver been fixed so that memory starvation isn't an > issue any more? If so, it's probably a good idea to drop this > patch nowadays. I don't have time to do a runtime test > personally and bash the driver with some intense 3D. Could > someone else do that perhaps? > > > -- > Mike A. Harris > > > __________________________________ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com
