I've reworked the patch a bit again to try and make the endianness issues more explicit. It also attempts to fix r128 but I can't test that.
http://penguinppc.org/~daenzer/DRI/endianness.diff I'm going to commit this now, will the Mesa changes propagate to the Mesa tree or do I have to take care of that as well? On Sun, 2002-05-26 at 20:17, Michel D�nzer wrote: [ various rendering problems with the radeon driver ] > > I'm going to try the TCL branch to see if those are still there. > > Well, glxgears hangs with that both on an Athlon box at work with a VE > and on this TiBook with an M6. And on a Cube with a QD (which actually > has a TCL unit), the X server doesn't even start. Looks like there's > more porting work to do. :/ After completing the merge of the above patch to the TCL branch, I have it working on a PowerBook with an M7. All problems seem to be gone there, except that morph3d only seems to draw about half the polygons, and there are other new problems, but those may be arch specific again. :/ Also, the framerate seems to drop very quickly as the polygon count rises, e.g. with the XScreenSaver lament hack, it drops from around 250 fps when it's a single cube to around 25 (!) fps when it decomposes into several parts. Most 'real' apps are significantly slower than with the trunk code. 2D crawls when a 3D client is running. Any hints for debugging that appreciated. Last, but not least, I can't seem to get it to use pageflipping. Do I have to do anything other than setting the X server option? -- Earthling Michel D�nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
