Bug#234388: xserver-xfree86: [tdfx] X server refuses to use DRI at 1280x960 resolution
On Mon, 1 Mar 2004, Michel [ISO-8859-1] D�er 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
Reply to: