On Wed, Dec 04, 2002 at 01:23:26 -0800, Ian Romanick wrote: > On Wed, Dec 04, 2002 at 02:35:39PM -0500, Leif Delgass wrote: > > On Tue, 3 Dec 2002, Ian Romanick wrote: > > > > > Unless there are any objections, I'm going to commit a merge from the trunk > > > to the texmem-0-0-1 branch tomorrow (Wednesday). I've tested the merge on > > > the R100, and I'll test it on an M6 and a G400 before I commit it. > > > > That's fine by me. FYI, I've started trying to debug r128 in the texmem > > branch. I've found some problems, but am still experiencing texture > > corruption. The first problem I found is in the switch/case at > > r128_texmem.c:281 (r128UploadTexImages()). Since the uploading of > > textures was moved from r128EmitHwStateLocked() to functions called from > > r128UpdateTextureState(), a texture isn't marked as bound until _after_ > > it's uploaded, so the default case was being hit (with t->base.bound == > > 0). > > I've actually moved it again, too. I moved it to enable_tex_2d to match the > R100 / R200 drivers. > > > Another problem I found is that r128DDBindTexture no longer sets the > > R128_NEW_TEXTURE flag, and this prevents the texture state from being > > updated when an app switches textures. For example: running tunnel, I get > > the floor texture on the walls, but if I set R128_NEW_TEXTURE in > > r128DDBindTexture, the wall textures and floor textures appear in the > > right places. How do the radeon/r200 drivers work without setting the > > NEW_TEXTURE flag there? Also, shouldn't it unbind the texture currently > > bound to that texture unit? > > Ah-ha! The R128 driver tracks changes to texture state on its own, but the > R100 / R200 drivers just let Mesa do it. When the state changes, Mesa calls > the drivers UpdateState function (r128DDInvalidateState & > radeonInvalidateState) and passes it new_state. If texture state has been > called, _NEW_TEXTURE will be set in new_state. The changes that I'm going to > commit today are: > > - Remove all usage of R128_NEW_TEXTURE. > - Modify r128UpdateHwState to test _NEW_TEXTURE in NewGLState > > I suspect that will fix the texture problems. Somebody (that actually has > Rage128 hardware!) should go through and eliminate the new_state field from > r128_context altogether. I will make similar changes to the MGA driver. It > would be nice to have fundamental things, like tracking state changes, as > similar as possible across the various drivers. It makes it easier to move > from driver-to-driver to fix bugs and make enhancements.
I'm using an R128 for some work I'm doing at the moment. I'll take a look when the trunk merge is done. Alan. ------------------------------------------------------- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
