Re: r300 + NWN
Adam K Kirchhoff schrieb: > I'm sure this confirms what are already known issues with the r300 > driver, but felt it'd be worth posting anyway. There's definitely > something bizarre going on with textures. They're much crisper with the > fglrx driver. To me it looks like the fglrx driver does linear filtering, while r300 does nearest filtering. Philipp --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + NWN
Philipp Klaus Krause wrote: Adam K Kirchhoff schrieb: I'm sure this confirms what are already known issues with the r300 driver, but felt it'd be worth posting anyway. There's definitely something bizarre going on with textures. They're much crisper with the fglrx driver. To me it looks like the fglrx driver does linear filtering, while r300 does nearest filtering. It could be the mipmap selection offset that fglrx applies to textures. There's a setting for this reg on r200 (see the R200_EMIT_PP_TRI_PERF_CNTL reg), it probably applies to r300 too. Stephane --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + NWN
Stephane Marchesin wrote: Philipp Klaus Krause wrote: Adam K Kirchhoff schrieb: I'm sure this confirms what are already known issues with the r300 driver, but felt it'd be worth posting anyway. There's definitely something bizarre going on with textures. They're much crisper with the fglrx driver. To me it looks like the fglrx driver does linear filtering, while r300 does nearest filtering. It could be the mipmap selection offset that fglrx applies to textures. There's a setting for this reg on r200 (see the R200_EMIT_PP_TRI_PERF_CNTL reg), it probably applies to r300 too. That setting doesn't affect mipmap selection - just how the transition area from one to another mipmap looks like. You'd only get banding as the worst thing possible. Looks like nearest filtering to me too, and/or no mipmaps (so yes mipmap selection offset (LOD setting?) could be an issue there but if so it would be ways off). No idea what's wrong with the inventory there - some issue with transparent textures? Strange that not the whole inventory gets affected exactly the same way though. Roland --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + NWN
Roland Scheidegger wrote: Stephane Marchesin wrote: Philipp Klaus Krause wrote: Adam K Kirchhoff schrieb: I'm sure this confirms what are already known issues with the r300 driver, but felt it'd be worth posting anyway. There's definitely something bizarre going on with textures. They're much crisper with the fglrx driver. To me it looks like the fglrx driver does linear filtering, while r300 does nearest filtering. It could be the mipmap selection offset that fglrx applies to textures. There's a setting for this reg on r200 (see the R200_EMIT_PP_TRI_PERF_CNTL reg), it probably applies to r300 too. That setting doesn't affect mipmap selection - just how the transition area from one to another mipmap looks like. You'd only get banding as the worst thing possible. Looks like nearest filtering to me too, and/or no mipmaps (so yes mipmap selection offset (LOD setting?) could be an issue there but if so it would be ways off). No idea what's wrong with the inventory there - some issue with transparent textures? Strange that not the whole inventory gets affected exactly the same way though. Roland Hello all. I've narrowed down this problem to something that changed in Mesa between the 5th of December and the 11th, when I first noticed this problem. I have a system at work with a 9800. I started up NWN (after first initializing the card with the fglrx driver, of course), and the textures looked just fine (though the fog problem still existed). The drivers were built from CVS on the 5th. I upgraded it to what's currently in CVS, started up NWN, and had the same texture problem. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + NWN
Adam K Kirchhoff wrote:
I've narrowed down this problem to something that changed in Mesa
between the 5th of December and the 11th, when I first noticed this
problem. I have a system at work with a 9800. I started up NWN (after
first initializing the card with the fglrx driver, of course), and the
textures looked just fine (though the fog problem still existed). The
drivers were built from CVS on the 5th. I upgraded it to what's
currently in CVS, started up NWN, and had the same texture problem.
On a quick glance (though I'm not familiar with that driver), it looks
to me like introducing texture rectangle caused mipmaps to be disabled
for compressed textures.
Roland
Index: r300_texstate.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_texstate.c,v
retrieving revision 1.35
diff -u -r1.35 r300_texstate.c
--- r300_texstate.c 5 Dec 2005 09:30:58 - 1.35
+++ r300_texstate.c 13 Dec 2005 14:33:29 -
@@ -370,9 +370,11 @@
* requires 64-byte aligned pitches, and we may/may not need the
* blitter. NPOT only!
*/
- if (baseImage->IsCompressed)
+ if (baseImage->IsCompressed) {
t->pitch =
(tObj->Image[0][t->base.firstLevel]->Width + 63) & ~(63);
+ t->size |=
((log2Width>log2Height)?log2Width:log2Height)pitch = ((tObj->Image[0][t->base.firstLevel]->Width *
Re: r300 + NWN
Roland Scheidegger wrote: Adam K Kirchhoff wrote: I've narrowed down this problem to something that changed in Mesa between the 5th of December and the 11th, when I first noticed this problem. I have a system at work with a 9800. I started up NWN (after first initializing the card with the fglrx driver, of course), and the textures looked just fine (though the fog problem still existed). The drivers were built from CVS on the 5th. I upgraded it to what's currently in CVS, started up NWN, and had the same texture problem. On a quick glance (though I'm not familiar with that driver), it looks to me like introducing texture rectangle caused mipmaps to be disabled for compressed textures. Roland I'll give it a shot over lunch, hopefully. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + NWN
Roland Scheidegger wrote: Adam K Kirchhoff wrote: I've narrowed down this problem to something that changed in Mesa between the 5th of December and the 11th, when I first noticed this problem. I have a system at work with a 9800. I started up NWN (after first initializing the card with the fglrx driver, of course), and the textures looked just fine (though the fog problem still existed). The drivers were built from CVS on the 5th. I upgraded it to what's currently in CVS, started up NWN, and had the same texture problem. On a quick glance (though I'm not familiar with that driver), it looks to me like introducing texture rectangle caused mipmaps to be disabled for compressed textures. Roland Your patch seems to have solved the texture problem with NWN. Thanks! Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + NWN
> On a quick glance (though I'm not familiar with that driver), it looks to me > like introducing texture rectangle caused mipmaps to be disabled for > compressed textures. oops, my bad.. I've checked in the fix.. thanks, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
"enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Hi, Found the cause the patch: "enable hw vertex programs by default". The only fix I've found is to disable it (attached patch). I am willing to test better solutions, but until then can it be disabled by default? Rune Petersen Rune Petersen wrote: Hi, I've been out of it lately, and I have been unable to track down the change that caused it. I am only able one map of NWN, when loading the second map (2D -> 3D transition ) it locks up. Is the driver forgetting to clean up. Any ideas as to the cause of this? Rune Petersen Setup: Radeon X800XT (JK) Mesa CVS HEAD drm CVS HEAD Xorg (CVS HEAD) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel Index: r300_context.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.c,v retrieving revision 1.46 diff -u -r1.46 r300_context.c --- r300_context.c 27 Jan 2006 14:35:24 - 1.46 +++ r300_context.c 27 Feb 2006 18:41:00 - @@ -68,8 +68,8 @@ #include "xmlpool.h" /* for symbolic values of enum-type options */ /* hw_tcl_on derives from future_hw_tcl_on when its safe to change it. */ -int future_hw_tcl_on=1; -int hw_tcl_on=1; +int future_hw_tcl_on=0; +int hw_tcl_on=0; #define need_GL_ARB_multisample #define need_GL_ARB_texture_compression
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Mon, 27 Feb 2006 19:47:35 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: > Hi, > > Found the cause the patch: > "enable hw vertex programs by default". > > The only fix I've found is to disable it (attached patch). > > I am willing to test better solutions, but until then can it be disabled > by default? Try with these two patches applied: http://rasterburn.org/~aet/r300_lit.diff http://rasterburn.org/~aet/r300_no_fog.diff I was able to get a trace on the vertex program behind one nwn lock but I cannot make it lock my box any more. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Appears to fix it, thank you. The r300_lit.diff by the way is broken. Rune Petersen Aapo Tahkola wrote: On Mon, 27 Feb 2006 19:47:35 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: Hi, Found the cause the patch: "enable hw vertex programs by default". The only fix I've found is to disable it (attached patch). I am willing to test better solutions, but until then can it be disabled by default? Try with these two patches applied: http://rasterburn.org/~aet/r300_lit.diff http://rasterburn.org/~aet/r300_no_fog.diff I was able to get a trace on the vertex program behind one nwn lock but I cannot make it lock my box any more. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
This also fixes the lockup I've been having in Quake3 map0. There is still corruption which spreads to include the menu, and is persistent even when restarting the game. But hay it's an improvement. Rune Petersen Rune Petersen wrote: Appears to fix it, thank you. The r300_lit.diff by the way is broken. Rune Petersen Aapo Tahkola wrote: On Mon, 27 Feb 2006 19:47:35 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: Hi, Found the cause the patch: "enable hw vertex programs by default". The only fix I've found is to disable it (attached patch). I am willing to test better solutions, but until then can it be disabled by default? Try with these two patches applied: http://rasterburn.org/~aet/r300_lit.diff http://rasterburn.org/~aet/r300_no_fog.diff I was able to get a trace on the vertex program behind one nwn lock but I cannot make it lock my box any more. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Tue, 28 Feb 2006 22:04:49 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: > This also fixes the lockup I've been having in Quake3 map0. There is > still corruption which spreads to include the menu, and is persistent > even when restarting the game. But hay it's an improvement. Can you get a screenshot of it? -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
I made a mistake, and did not use clean Mesa source. sorry about the noise. with: int future_hw_tcl_on=1; int hw_tcl_on=1; nwn: Texture corruption (random changing garbage) on some items/doors. this corruption will bleed into other games started after nwn is closed (like Quake3). This is an improvement over the lockup I get without the patch.( it did lockup once) Quake3: No corruption. the mirror and teleport is still partly broken, but no corruption. with: int future_hw_tcl_on=0; int hw_tcl_on=0; nwn: No corruption. Quake3: map0: Texture corruption (random changing garbage). this corruption will bleed into other games started after Quake3 is closed. http://megahurts.dk/rune/stuff/shot0003.jpg Rune Petersen Aapo Tahkola wrote: On Tue, 28 Feb 2006 22:04:49 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: This also fixes the lockup I've been having in Quake3 map0. There is still corruption which spreads to include the menu, and is persistent even when restarting the game. But hay it's an improvement. Can you get a screenshot of it? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Wed, 01 Mar 2006 20:58:49 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: > I made a mistake, and did not use clean Mesa source. > > sorry about the noise. > > with: > int future_hw_tcl_on=1; > int hw_tcl_on=1; > > nwn: > Texture corruption (random changing garbage) on some > items/doors. this > corruption will bleed into other games started after nwn is closed (like > Quake3). > This is an improvement over the lockup I get without the > patch.( it > did lockup once) > > Quake3: > No corruption. the mirror and teleport is still partly broken, > but no > corruption. > > with: > int future_hw_tcl_on=0; > int hw_tcl_on=0; > > nwn: > No corruption. > > Quake3: > map0: Texture corruption (random changing garbage). this > corruption > will bleed into other games started after Quake3 is closed. > http://megahurts.dk/rune/stuff/shot0003.jpg I dont see anything wrong with that shot. Does it change if you look from different angle? If it changes all the time, id say you have gart overlapping with fb. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
I didn't get the best shot, but I didn't want to risk a lockup at the time. Try looking closer at the bot. When I exited to the menu most of the background was corrupted. Rune Petersen Aapo Tahkola wrote: Quake3: map0: Texture corruption (random changing garbage). this corruption will bleed into other games started after Quake3 is closed. http://megahurts.dk/rune/stuff/shot0003.jpg I dont see anything wrong with that shot. Does it change if you look from different angle? If it changes all the time, id say you have gart overlapping with fb. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
This looks somewhat familiar. I saw this on a Radeon 7500 where AGP writes from the card to system memory did not work reliably. So uploading textures to AGP memory (through DMA) was corrupting textures. Reducing the AGP speed to 2x solved the problem on that card. The problem only occurred after a while of heavy texture usage, when it started using the AGP texture heap. After that it kept using the AGP heap and I saw texture corruption in other games too. The same card also suffered from soft lockups due to AGP status writeback that was affected by the same unreliability. I solved it locally be disabling status writeback in the kernel module before I figured out that reducing the AGP speed helped as well. YMMV. Regards, Felix Am Donnerstag, den 02.03.2006, 18:48 +0100 schrieb Rune Petersen: > I didn't get the best shot, but I didn't want to risk a lockup at the time. > Try looking closer at the bot. > > When I exited to the menu most of the background was corrupted. > > > Rune Petersen > > Aapo Tahkola wrote: > >> > >>Quake3: > >>map0: Texture corruption (random changing garbage). this > >> corruption > >>will bleed into other games started after Quake3 is closed. > >>http://megahurts.dk/rune/stuff/shot0003.jpg > > > > > > I dont see anything wrong with that shot. > > > > Does it change if you look from different angle? > > If it changes all the time, id say you have gart overlapping with fb. > > > > > > --- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
I doubt it since it is triggered by disabling hw tcl in the driver. Rune Petersen Felix Kühling wrote: This looks somewhat familiar. I saw this on a Radeon 7500 where AGP writes from the card to system memory did not work reliably. So uploading textures to AGP memory (through DMA) was corrupting textures. Reducing the AGP speed to 2x solved the problem on that card. The problem only occurred after a while of heavy texture usage, when it started using the AGP texture heap. After that it kept using the AGP heap and I saw texture corruption in other games too. The same card also suffered from soft lockups due to AGP status writeback that was affected by the same unreliability. I solved it locally be disabling status writeback in the kernel module before I figured out that reducing the AGP speed helped as well. YMMV. Regards, Felix Am Donnerstag, den 02.03.2006, 18:48 +0100 schrieb Rune Petersen: I didn't get the best shot, but I didn't want to risk a lockup at the time. Try looking closer at the bot. When I exited to the menu most of the background was corrupted. Rune Petersen Aapo Tahkola wrote: Quake3: map0: Texture corruption (random changing garbage). this corruption will bleed into other games started after Quake3 is closed. http://megahurts.dk/rune/stuff/shot0003.jpg I dont see anything wrong with that shot. Does it change if you look from different angle? If it changes all the time, id say you have gart overlapping with fb. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Update: The "Free temps when possible" patch makes NWN lockup again. It would appear that hw tcl is very fragile on some cards. Rune Petersen Rune Petersen wrote: I made a mistake, and did not use clean Mesa source. sorry about the noise. with: int future_hw_tcl_on=1; int hw_tcl_on=1; nwn: Texture corruption (random changing garbage) on some items/doors. this corruption will bleed into other games started after nwn is closed (like Quake3). This is an improvement over the lockup I get without the patch.( it did lockup once) Quake3: No corruption. the mirror and teleport is still partly broken, but no corruption. with: int future_hw_tcl_on=0; int hw_tcl_on=0; nwn: No corruption. Quake3: map0: Texture corruption (random changing garbage). this corruption will bleed into other games started after Quake3 is closed. http://megahurts.dk/rune/stuff/shot0003.jpg Rune Petersen Aapo Tahkola wrote: On Tue, 28 Feb 2006 22:04:49 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: This also fixes the lockup I've been having in Quake3 map0. There is still corruption which spreads to include the menu, and is persistent even when restarting the game. But hay it's an improvement. Can you get a screenshot of it? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Sat, 04 Mar 2006 20:55:50 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: > Update: > The "Free temps when possible" patch makes NWN lockup again. > > It would appear that hw tcl is very fragile on some cards. Sorry, I missed your mail. I just added option that will initialize all temps in vertex programs when enabled. This does not cover initializing outputs so it is still possible that something goes wrong there. You can use it by exporting R300_VP_SAFETY in your env. You should see WARN_ONCE when its enabled but keep in mind that nwn repipes stderr to /dev/null so you wont see it. I'm hoping to fix this after GLSL support has been added so I don't have to rewrite it twice. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Aapo Tahkola wrote: On Sat, 04 Mar 2006 20:55:50 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: Update: The "Free temps when possible" patch makes NWN lockup again. It would appear that hw tcl is very fragile on some cards. Sorry, I missed your mail. I just added option that will initialize all temps in vertex programs when enabled. This does not cover initializing outputs so it is still possible that something goes wrong there. You can use it by exporting R300_VP_SAFETY in your env. You should see WARN_ONCE when its enabled but keep in mind that nwn repipes stderr to /dev/null so you wont see it. I tried it, it had no effect, I don't think its the temp registers. I suspect there is something broken with the vp code or it triggers a bug somewhere else. Also I'm am able to see corruption in the nwn loading/splash screen. The corruption seams structured, and it gradually changes from left to right, top to bottom. Is there any way to capture this? (without using a camera) I'm hoping to fix this after GLSL support has been added so I don't have to rewrite it twice. great, I'm just trying to make sure everything is thought of. avoiding another rewrite. Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Fri, 10 Mar 2006 18:27:51 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: > Aapo Tahkola wrote: > > On Sat, 04 Mar 2006 20:55:50 +0100 > > Rune Petersen <[EMAIL PROTECTED]> wrote: > > > > > >>Update: > >>The "Free temps when possible" patch makes NWN lockup again. > >> > >>It would appear that hw tcl is very fragile on some cards. > > > > > > Sorry, I missed your mail. > > > > > I just added option that will initialize all temps in vertex programs when > > enabled. This does not cover initializing outputs so it is still possible > > that something goes wrong there. > > You can use it by exporting R300_VP_SAFETY in your env. > > You should see WARN_ONCE when its enabled but keep in mind that nwn repipes > > stderr to /dev/null so you wont see it. > > I tried it, it had no effect, I don't think its the temp registers. I > suspect there is something broken with the vp code or it triggers a bug > somewhere else. Do I recall correctly that you have had this problem with textures before hw vps were enabled too? > Also I'm am able to see corruption in the nwn loading/splash screen. The > corruption seams structured, and it gradually changes from left to > right, top to bottom. > Is there any way to capture this? (without using a camera) I dont think iv seen anything like that but seeing it on a flat surface might set off some ideas. You can enter console and write: sleep 10 && DISPLAY=:0 xwd -root | xwdtopnm | pnmtopng > foo.png or: DISPLAY=:0 scrot -d 10 foo.png and switch back to X. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Aapo Tahkola wrote: On Fri, 10 Mar 2006 18:27:51 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: I tried it, it had no effect, I don't think its the temp registers. I suspect there is something broken with the vp code or it triggers a bug somewhere else. Do I recall correctly that you have had this problem with textures before hw vps were enabled too? Yes I did but a different kind, flashing "tiles" of colors on the texture. was fix with clear cache patch ( this was also reported by others). Also I'm am able to see corruption in the nwn loading/splash screen. The corruption seams structured, and it gradually changes from left to right, top to bottom. Is there any way to capture this? (without using a camera) I dont think iv seen anything like that but seeing it on a flat surface might set off some ideas. The best images this time were in the menu (grows upwards this time): http://megahurts.dk/rune/stuff/nwn_menu_1.png http://megahurts.dk/rune/stuff/nwn_menu_2.png http://megahurts.dk/rune/stuff/nwn_menu_3.png Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Fri, 10 Mar 2006 21:58:50 +0100, Rune Petersen <[EMAIL PROTECTED]> wrote: Aapo Tahkola wrote: On Fri, 10 Mar 2006 18:27:51 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: I tried it, it had no effect, I don't think its the temp registers. I suspect there is something broken with the vp code or it triggers a bug somewhere else. Do I recall correctly that you have had this problem with textures before hw vps were enabled too? Yes I did but a different kind, flashing "tiles" of colors on the texture. was fix with clear cache patch ( this was also reported by others). Also I'm am able to see corruption in the nwn loading/splash screen. The corruption seams structured, and it gradually changes from left to right, top to bottom. Is there any way to capture this? (without using a camera) I dont think iv seen anything like that but seeing it on a flat surface might set off some ideas. The best images this time were in the menu (grows upwards this time): http://megahurts.dk/rune/stuff/nwn_menu_1.png http://megahurts.dk/rune/stuff/nwn_menu_2.png http://megahurts.dk/rune/stuff/nwn_menu_3.png hmm, iv'e seen that on fglrx drivers atleast on the top of the screen once or thrice.. I *think* it occured when i killed the x-server and started it up again; The driver crashed at the same time too. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Fri, 10 Mar 2006 21:58:50 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: > Aapo Tahkola wrote: > > On Fri, 10 Mar 2006 18:27:51 +0100 > > Rune Petersen <[EMAIL PROTECTED]> wrote: > > > >>I tried it, it had no effect, I don't think its the temp registers. I > >>suspect there is something broken with the vp code or it triggers a bug > >>somewhere else. > > > > > > Do I recall correctly that you have had this problem with textures before > > hw vps were enabled too? > Yes I did but a different kind, flashing "tiles" of colors on the > texture. was fix with clear cache patch ( this was also reported by others). > > > > > >>Also I'm am able to see corruption in the nwn loading/splash screen. The > >>corruption seams structured, and it gradually changes from left to > >>right, top to bottom. > >>Is there any way to capture this? (without using a camera) > > > > > > I dont think iv seen anything like that but seeing it on a flat surface > > might set off some ideas. > > > The best images this time were in the menu (grows upwards this time): > http://megahurts.dk/rune/stuff/nwn_menu_1.png > http://megahurts.dk/rune/stuff/nwn_menu_2.png > http://megahurts.dk/rune/stuff/nwn_menu_3.png Get xf86-video-ati and drm with Ben's fixes and try again. You might see it go upwards or downwards depending on how they are rending. nwn background image is made up of four textures sized 512x512, 512x88, 288x512, 288x88. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Aapo Tahkola wrote: On Fri, 10 Mar 2006 21:58:50 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: The best images this time were in the menu (grows upwards this time): http://megahurts.dk/rune/stuff/nwn_menu_1.png http://megahurts.dk/rune/stuff/nwn_menu_2.png http://megahurts.dk/rune/stuff/nwn_menu_3.png Get xf86-video-ati and drm with Ben's fixes and try again. You might see it go upwards or downwards depending on how they are rending. nwn background image is made up of four textures sized 512x512, 512x88, 288x512, 288x88. I assumed I had a snapshot with all Ben's changes, I was wrong. updating xf86-video-ati cured the corruption then starting nwn the second time. As for the in-game corruption its a little different now. the second map loaded still have corrupted textures (slightly more then before). if I return to the first map and enter the second map again there is no corruption apart for some green on the weapons. all subsequent maps load with no trouble. there might still be trouble with maps that needs textures not already loaded. Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Sat, 11 Mar 2006 22:48:49 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: > Aapo Tahkola wrote: > > On Fri, 10 Mar 2006 21:58:50 +0100 > > Rune Petersen <[EMAIL PROTECTED]> wrote: > >> > >>The best images this time were in the menu (grows upwards this time): > >>http://megahurts.dk/rune/stuff/nwn_menu_1.png > >>http://megahurts.dk/rune/stuff/nwn_menu_2.png > >>http://megahurts.dk/rune/stuff/nwn_menu_3.png > > > > > > Get xf86-video-ati and drm with Ben's fixes and try again. > > You might see it go upwards or downwards depending on how they are rending. > > nwn background image is made up of four textures sized 512x512, 512x88, > > 288x512, 288x88. > > > > I assumed I had a snapshot with all Ben's changes, I was wrong. updating > xf86-video-ati cured the corruption then starting nwn the second time. > > As for the in-game corruption its a little different now. the second map > loaded still have corrupted textures (slightly more then before). if I > return to the first map and enter the second map again there is no > corruption apart for some green on the weapons. all subsequent maps load > with no trouble. > > there might still be trouble with maps that needs textures not already > loaded. All this is just a symptom of dri tex heap manager. nwn will reload textures but they will be given different locations on vram. You can print out t->offset at around line 506 of r300_texmem.c if you are interested in seeing how it behaves. But if you do keep in mind that you need to do it after UNLOCK_HARDWARE or else bad things will happen. You should check that Ben's fix is kicking in by looking for message saying: "Setting GART location based on new memory map" in dmesg. If you still see problems with it enabled you can confirm GART overlapping by loading drm.ko with DEBUG=1 (AFAIK) and compairing dev_priv->gart_vm_start against dev_priv->fb_location and dev_priv->fb_size . DRM doesnt print these values but you can calculated it based on Xorg log. Find line that says: (II) RADEON(0): Will use x kb for textures at offset x and compaire upper bound of that against dev_priv->gart_vm_start. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Aapo Tahkola wrote: On Sat, 11 Mar 2006 22:48:49 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: All this is just a symptom of dri tex heap manager. nwn will reload textures but they will be given different locations on vram. You can print out t->offset at around line 506 of r300_texmem.c if you are interested in seeing how it behaves. But if you do keep in mind that you need to do it after UNLOCK_HARDWARE or else bad things will happen. You should check that Ben's fix is kicking in by looking for message saying: "Setting GART location based on new memory map" in dmesg. If you still see problems with it enabled you can confirm GART overlapping by loading drm.ko with DEBUG=1 (AFAIK) and compairing dev_priv->gart_vm_start against dev_priv->fb_location and dev_priv->fb_size . DRM doesnt print these values but you can calculated it based on Xorg log. Find line that says: (II) RADEON(0): Will use x kb for textures at offset x and compaire upper bound of that against dev_priv->gart_vm_start. Me stupid, there is a module-path in xorg.conf and I forgot to change i to the new path. Now nwn looks nice, and all games works (ut2k? still have corruption(?) on some textures). I really sorry about this. Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Aapo Tahkola wrote: On Sun, 12 Mar 2006 17:51:16 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: Aapo Tahkola wrote: On Sat, 11 Mar 2006 22:48:49 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: All this is just a symptom of dri tex heap manager. nwn will reload textures but they will be given different locations on vram. You can print out t->offset at around line 506 of r300_texmem.c if you are interested in seeing how it behaves. But if you do keep in mind that you need to do it after UNLOCK_HARDWARE or else bad things will happen. You should check that Ben's fix is kicking in by looking for message saying: "Setting GART location based on new memory map" in dmesg. If you still see problems with it enabled you can confirm GART overlapping by loading drm.ko with DEBUG=1 (AFAIK) and compairing dev_priv->gart_vm_start against dev_priv->fb_location and dev_priv->fb_size . DRM doesnt print these values but you can calculated it based on Xorg log. Find line that says: (II) RADEON(0): Will use x kb for textures at offset x and compaire upper bound of that against dev_priv->gart_vm_start. Me stupid, there is a module-path in xorg.conf and I forgot to change i to the new path. Now nwn looks nice, and all games works (ut2k? still have corruption(?) on some textures). Nice to hear it works now :) I'v checked in a fix that should make nearly all ut2k4 texturing problems disappear. s3tc multitexturing and 8x8 cubic maps are still broken so try to avoid them. Does nwn still lock? No, not with limited amount I've been playing, but it usually crashed on the first or second map. I've something else that locks up :) progs/demos/clearspd it lockups after a few seconds. Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Sun, 12 Mar 2006 17:51:16 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: > Aapo Tahkola wrote: > > On Sat, 11 Mar 2006 22:48:49 +0100 > > Rune Petersen <[EMAIL PROTECTED]> wrote: > > > > All this is just a symptom of dri tex heap manager. nwn will reload > > textures but they will be given different locations on vram. > > You can print out t->offset at around line 506 of r300_texmem.c if you are > > interested in seeing how it behaves. > > But if you do keep in mind that you need to do it after UNLOCK_HARDWARE or > > else bad things will happen. > > > > You should check that Ben's fix is kicking in by looking for message > > saying: "Setting GART location based on new memory map" in dmesg. > > > > If you still see problems with it enabled you can confirm GART overlapping > > by loading drm.ko with DEBUG=1 (AFAIK) and compairing > > dev_priv->gart_vm_start against dev_priv->fb_location and dev_priv->fb_size > > . > > DRM doesnt print these values but you can calculated it based on Xorg log. > > > > Find line that says: > > (II) RADEON(0): Will use x kb for textures at offset x > > and compaire upper bound of that against dev_priv->gart_vm_start. > > Me stupid, there is a module-path in xorg.conf and I forgot to change i > to the new path. > Now nwn looks nice, and all games works (ut2k? still have corruption(?) > on some textures). Nice to hear it works now :) I'v checked in a fix that should make nearly all ut2k4 texturing problems disappear. s3tc multitexturing and 8x8 cubic maps are still broken so try to avoid them. Does nwn still lock? -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Mon, 13 Mar 2006 20:23:29 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: > Aapo Tahkola wrote: > > On Sun, 12 Mar 2006 17:51:16 +0100 > > Rune Petersen <[EMAIL PROTECTED]> wrote: > > > > > >>Aapo Tahkola wrote: > >> > >>>On Sat, 11 Mar 2006 22:48:49 +0100 > >>>Rune Petersen <[EMAIL PROTECTED]> wrote: > >>> > >>>All this is just a symptom of dri tex heap manager. nwn will reload > >>>textures but they will be given different locations on vram. > >>>You can print out t->offset at around line 506 of r300_texmem.c if you are > >>>interested in seeing how it behaves. > >>>But if you do keep in mind that you need to do it after UNLOCK_HARDWARE or > >>>else bad things will happen. > >>> > >>>You should check that Ben's fix is kicking in by looking for message > >>>saying: "Setting GART location based on new memory map" in dmesg. > >>> > >>>If you still see problems with it enabled you can confirm GART overlapping > >>>by loading drm.ko with DEBUG=1 (AFAIK) and compairing > >>>dev_priv->gart_vm_start against dev_priv->fb_location and > >>>dev_priv->fb_size . > >>>DRM doesnt print these values but you can calculated it based on Xorg log. > >>> > >>>Find line that says: > >>>(II) RADEON(0): Will use x kb for textures at offset x > >>>and compaire upper bound of that against dev_priv->gart_vm_start. > >> > >>Me stupid, there is a module-path in xorg.conf and I forgot to change i > >>to the new path. > >>Now nwn looks nice, and all games works (ut2k? still have corruption(?) > >>on some textures). > > > > > > Nice to hear it works now :) > > I'v checked in a fix that should make nearly all ut2k4 texturing problems > > disappear. > > s3tc multitexturing and 8x8 cubic maps are still broken so try to avoid > > them. > > > > Does nwn still lock? > > No, not with limited amount I've been playing, but it usually crashed on > the first or second map. > > I've something else that locks up :) > progs/demos/clearspd > it lockups after a few seconds. You can try commenting r300_context.h:#define CB_DPATH . If that doesnt help, one could write a simple app that does same as clearspd but renders quads instead. Based on that, we could then put the blame on buffer clear code or high fillrate. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
> Me stupid, there is a module-path in xorg.conf and I forgot to change i > to the new path. > Now nwn looks nice, and all games works (ut2k? still have corruption(?) > on some textures). I've seen heavy desktop & texture corruption when using mergedfb with dri too which makes me suspect we might still have unresolved "issues" with texture memory management... Ben. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
