Michael wrote: > > Looking at the tdfx driver texture stuff > > tdfxTMFindOldestObject > does an assert ( t->range[0] ) which afaict is bogus, that's the > point where it fails here running q3 with hardcoded 1mb of > texture space. > > a) afaict assert()ing will crash/hang the X server regardless as > locks are held in the texture functions? Certainly running > remotely the program assert()s and exits with signal 6, the > machine in the other room appears locked but a ctrl-c remotely > and everything carries on. > > b) Changing the assert to an if ( ! range[0] ) tdfxTMDumpTexMem shows lots > of textures allocated to unit 1 with range[0] == null - this > surely isn't a bug, is it? If it isn't, the asserts are wrong and > probably just need removing (or at least some logic to tidy up > and exit cleanly) > > c) Removing the assert() altogether and I've had q3 running with > 1mb texture mem for a couple of hours. It probably makes sense > to change the 2d driver to disable DRI if there's less than 256 > * 256 * (2 or num tmus) * (2 or cpp?) as it probably does make > sense to disable if you can't allocate at least > 1 texture to each tmu though.
The texture memory management code in the tdfx driver is dark & mysterious. I don't know if anyone understands it any more... It's completely different to the other drivers and it's not really clear why. If you're getting a grip on it, you are ahead of just about anyone else... Keith _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
