Re: [Dri-devel] Trunk-to-texmem merge
Keith Whitwell wrote: 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. This dates from Mesa 3.x where the mesa state tracking mechanism was designed around the software rasterizer useless for anything else. Hmm that sounds kindof negative. Lets rephase: Yes, in the olden days, it was necessary for the driver to implement a parallel set of state flags to Mesa's. Since then Mesa's has been made a lot more robust and is now sufficiently good that drivers no longer need to do this. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Trunk-to-texmem merge
Ian Romanick wrote: On Tue, Dec 03, 2002 at 05:05:26PM -0800, 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. I am in the process of commiting the merge. By the time this messages gets to most people, it should be done. I have tested on r100, M6, and G400 hardware. The r200 r128 drivers pass the it compiles test. Merging in the r200 changes causes some changes in other parts of the code. I modified the routines in texmem.c to calculate mipmap size limits for 3D textures, cube maps, and texture rectangles. Right now the r200 is the only driver that supports these texture types, so I have not tested this code thoroughly. I would greatly appreciate it if somebody could compare the output of 'glxinfo -l' (from a recent Mesa build) on r200 from the trunk and the branch. A slightly different calculation method is used, so the results may not be exactly the same, but they should be close. I made some additional changes to the locking, texture upload, and state tracking in the r128 driver. This was done to make it more like the r100 and r200 drivers. I believe that it is correct, but I may have inadvertently introduced errors. Could somebody with the appropriate documentation add the missing #defines to radeon_reg.h to support texture rectangles, 3D textures, and cubic textures? It should be pretty trivial to back-port support for these features from the r200 driver once the registers are known. I've added the cube map and NPOT registers. Couldn't find anything for 3D textures (Q-axis clamp, filter, size). -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Trunk-to-texmem merge
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). 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? One other thing I noticed is that R128_NEW_TEXTURE is being set in disable_tex() and update_tex_common() in r128_texstate.c. This shouldn't be necessary, in fact it causes the texture state to be repeatedly updated when there haven't been any actual state changes (I saw that happening in multiarb, e.g.). Marking the context and texture registers for upload should be enough. Only the texture functions in r128_tex.c (texture image, env mode, parameter, etc. changes) and enabling/disabling of texturing in r128_state.c need to cause an update of the texture state. I'll keep digging... -- Leif Delgass http://www.retinalburn.net --- 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
Re: [Dri-devel] Trunk-to-texmem merge
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
Re: [Dri-devel] Trunk-to-texmem merge
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
Re: [Dri-devel] Trunk-to-texmem merge
On Tue, Dec 03, 2002 at 05:05:26PM -0800, 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. I am in the process of commiting the merge. By the time this messages gets to most people, it should be done. I have tested on r100, M6, and G400 hardware. The r200 r128 drivers pass the it compiles test. Merging in the r200 changes causes some changes in other parts of the code. I modified the routines in texmem.c to calculate mipmap size limits for 3D textures, cube maps, and texture rectangles. Right now the r200 is the only driver that supports these texture types, so I have not tested this code thoroughly. I would greatly appreciate it if somebody could compare the output of 'glxinfo -l' (from a recent Mesa build) on r200 from the trunk and the branch. A slightly different calculation method is used, so the results may not be exactly the same, but they should be close. I made some additional changes to the locking, texture upload, and state tracking in the r128 driver. This was done to make it more like the r100 and r200 drivers. I believe that it is correct, but I may have inadvertently introduced errors. Could somebody with the appropriate documentation add the missing #defines to radeon_reg.h to support texture rectangles, 3D textures, and cubic textures? It should be pretty trivial to back-port support for these features from the r200 driver once the registers are known. -- 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
Re: [Dri-devel] Trunk-to-texmem merge
On Wed, Dec 04, 2002 at 02:30:03PM -0800, Ian Romanick wrote: On Tue, Dec 03, 2002 at 05:05:26PM -0800, 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. I am in the process of commiting the merge. By the time this messages gets to most people, it should be done. I have tested on r100, M6, and G400 hardware. The r200 r128 drivers pass the it compiles test. Scratch that. CVS died mid-commit. I am now waiting for idr's lock in Grr! I'll try again in the morning. I'll send out e-mail when the commit is actually done. Sigh... -- 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
Re: [Dri-devel] Trunk-to-texmem merge
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. This dates from Mesa 3.x where the mesa state tracking mechanism was designed around the software rasterizer useless for anything else. Keith --- 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
Re: [Dri-devel] Trunk-to-texmem merge
On Wed, 4 Dec 2002, Ian Romanick wrote: On Wed, Dec 04, 2002 at 02:30:03PM -0800, Ian Romanick wrote: On Tue, Dec 03, 2002 at 05:05:26PM -0800, 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. I am in the process of commiting the merge. By the time this messages gets to most people, it should be done. I have tested on r100, M6, and G400 hardware. The r200 r128 drivers pass the it compiles test. Scratch that. CVS died mid-commit. I am now waiting for idr's lock in Grr! I'll try again in the morning. I'll send out e-mail when the commit is actually done. Sigh... That sucks. You'll probably need to submit a support request to sf.net to get the lock removed. Better luck on the next attempt... -- Leif Delgass http://www.retinalburn.net --- 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
