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. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html ------------------------------------------------------- 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
