[Bug 10097] New: cataclysmic system failure with git i915tex and Warsow video game.
http://bugs.freedesktop.org/show_bug.cgi?id=10097 Summary: cataclysmic system failure with git i915tex and Warsow video game. Product: Mesa Version: CVS Platform: x86 (IA32) OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Serious crash. The screen goes all psychedelic plaid on me. Bright flashing colors with vertical and horizontal lines all moving about rapidly. Static noise comes out the speaker and the system is instantly unresponsive. Hard lock up. Total system failure. Have to reboot and fsck corrects the file system. etc etc. I am using Debian Sid with all up to date packages. Default kernel 2.6.18-4-686 System is using a Asus 945g motherboard with Pentium-D 930. Running dual core. Using Git versions of: drm linux-agp-compat mesa xf86-video-intel The thing is is that the system has been stable for me running mostly any sort of OpenGL application. I've played a little of: Torcs, Flight Gear, gl-117, wolfenstein, enemy-territory/truecombat, tremulous, nexuiz. the only game that wouldn't work was Tremulous, which had some weird graphic glitches at the beginning and ran so badly I couldn't make it past the first screen. However Warsow is the game that is causing the severe crash. Before I ran it under using the 915_dri.so driver supplied by Debian and that ran fine, but it didn't have the performance I wanted. So I tried the i915_dri.so and drm stuff from git and that provided good enough performance, but it crashed X after a while. Then i figure I'll try to give the git version of i810 a try since the problem could be X related, maybe. So to do that then it automaticly started choosing the i915tex driver (which I originally didn't compile, but built it to see what happened). So now instead of just taking X out it is crashing the whole system very badly. I'll try to get some information for you while using the i915 driver... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10097] cataclysmic system failure with git i915tex and Warsow video game.
http://bugs.freedesktop.org/show_bug.cgi?id=10097 --- Comment #1 from [EMAIL PROTECTED] 2007-02-26 03:34 --- Created an attachment (id=8851) -- (http://bugs.freedesktop.org/attachment.cgi?id=8851action=view) xorg.log from i915_dri.so crash. xorg.log from i915_dri.so crash. Log for i915tex_dri.so crash leading to system meltdown unfortunately gets cut off. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10097] cataclysmic system failure with git i915tex and Warsow video game.
http://bugs.freedesktop.org/show_bug.cgi?id=10097 --- Comment #2 from [EMAIL PROTECTED] 2007-02-26 03:35 --- Created an attachment (id=8852) -- (http://bugs.freedesktop.org/attachment.cgi?id=8852action=view) warsow crash log with i915_dri.so warsow rand with export LIBGL_DEBUG=verbose with i915_dri.so driver. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10097] cataclysmic system failure with git i915tex and Warsow video game.
http://bugs.freedesktop.org/show_bug.cgi?id=10097 --- Comment #3 from [EMAIL PROTECTED] 2007-02-26 03:36 --- I was able to reproduce the crash with the i915_dri.so by reinstalling the xserver-xorg-video-i810 package that came with Debian. Note that this i915_dri.so is from the same git-based build as the i915tex_dri.so It didn't crash the machine, it only locked up X so I was able to safely reboot by hitting the button on the front of my machine. (which triggers a shutdown command via acpi or something like that) Also tremulous ran perfectly well also, no bugs, visual issues or slowness. If there is anything else that I can supply you let me know. Here is the X.org logs for that... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10097] cataclysmic system failure with git i915tex and Warsow video game.
http://bugs.freedesktop.org/show_bug.cgi?id=10097 --- Comment #4 from [EMAIL PROTECTED] 2007-02-26 03:38 --- BTW the game can be obtained at: http://www.warsow.net/ And tremulous I installed using the packages provided by Debian, but if your not running Debian you can find the game at: http://tremulous.net/ -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] R300 early Z cleanup
Attached is a mini-patch to add the address of early Z to r300_reg.h and
use it.
Jerome Glisse helped me with this patch. Thanks. :-)
diff --git a/src/mesa/drivers/dri/r300/r300_reg.h b/src/mesa/drivers/dri/r300/r300_reg.h
index 9f636ec..5dfd1fb 100644
--- a/src/mesa/drivers/dri/r300/r300_reg.h
+++ b/src/mesa/drivers/dri/r300/r300_reg.h
@@ -1378,6 +1378,10 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
/* 16 bit format or some aditional bit ? */
# define R300_DEPTH_FORMAT_UNK32 (32 0)
+#define R300_RB3D_EARLY_Z 0x4F14
+# define R300_EARLY_Z_DISABLE 0
+# define R300_EARLY_Z_ENABLE 1
+
/* gap */
#define R300_RB3D_DEPTHOFFSET 0x4F20
diff --git a/src/mesa/drivers/dri/r300/r300_state.c b/src/mesa/drivers/dri/r300/r300_state.c
index b30ece1..0e33e51 100644
--- a/src/mesa/drivers/dri/r300/r300_state.c
+++ b/src/mesa/drivers/dri/r300/r300_state.c
@@ -328,24 +328,24 @@ static void r300UpdateCulling(GLcontext* ctx)
static void update_early_z(GLcontext *ctx)
{
- /* updates register 0x4f14
- if depth test is not enabled it should be 0x
- if depth is enabled and alpha not it should be 0x0001
- if depth and alpha is enabled it should be 0x
+ /* updates register R300_RB3D_EARLY_Z (0x4F14)
+ if depth test is not enabled it should be R300_EARLY_Z_DISABLE
+ if depth is enabled and alpha not it should be R300_EARLY_Z_ENABLE
+ if depth and alpha is enabled it should be R300_EARLY_Z_DISABLE
*/
r300ContextPtr r300 = R300_CONTEXT(ctx);
R300_STATECHANGE(r300, unk4F10);
if (ctx-Color.AlphaEnabled ctx-Color.AlphaFunc != GL_ALWAYS)
/* disable early Z */
- r300-hw.unk4F10.cmd[2] = 0x;
+ r300-hw.unk4F10.cmd[2] = R300_EARLY_Z_DISABLE;
else {
if (ctx-Depth.Test ctx-Depth.Func != GL_NEVER)
/* enable early Z */
- r300-hw.unk4F10.cmd[2] = 0x0001;
+ r300-hw.unk4F10.cmd[2] = R300_EARLY_Z_ENABLE;
else
/* disable early Z */
- r300-hw.unk4F10.cmd[2] = 0x;
+ r300-hw.unk4F10.cmd[2] = R300_EARLY_Z_DISABLE;
}
}
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] R300 early Z cleanup
Attached is a revised patch with few comments (because of missing bit
shifts) from agd5f in #dri-devel. Thanks!
diff --git a/src/mesa/drivers/dri/r300/r300_reg.h b/src/mesa/drivers/dri/r300/r300_reg.h
index 9f636ec..6abcfa4 100644
--- a/src/mesa/drivers/dri/r300/r300_reg.h
+++ b/src/mesa/drivers/dri/r300/r300_reg.h
@@ -1378,6 +1378,10 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
/* 16 bit format or some aditional bit ? */
# define R300_DEPTH_FORMAT_UNK32 (32 0)
+#define R300_RB3D_EARLY_Z 0x4F14
+# define R300_EARLY_Z_DISABLE (0 0)
+# define R300_EARLY_Z_ENABLE (1 0)
+
/* gap */
#define R300_RB3D_DEPTHOFFSET 0x4F20
diff --git a/src/mesa/drivers/dri/r300/r300_state.c b/src/mesa/drivers/dri/r300/r300_state.c
index b30ece1..0e33e51 100644
--- a/src/mesa/drivers/dri/r300/r300_state.c
+++ b/src/mesa/drivers/dri/r300/r300_state.c
@@ -328,24 +328,24 @@ static void r300UpdateCulling(GLcontext* ctx)
static void update_early_z(GLcontext *ctx)
{
- /* updates register 0x4f14
- if depth test is not enabled it should be 0x
- if depth is enabled and alpha not it should be 0x0001
- if depth and alpha is enabled it should be 0x
+ /* updates register R300_RB3D_EARLY_Z (0x4F14)
+ if depth test is not enabled it should be R300_EARLY_Z_DISABLE
+ if depth is enabled and alpha not it should be R300_EARLY_Z_ENABLE
+ if depth and alpha is enabled it should be R300_EARLY_Z_DISABLE
*/
r300ContextPtr r300 = R300_CONTEXT(ctx);
R300_STATECHANGE(r300, unk4F10);
if (ctx-Color.AlphaEnabled ctx-Color.AlphaFunc != GL_ALWAYS)
/* disable early Z */
- r300-hw.unk4F10.cmd[2] = 0x;
+ r300-hw.unk4F10.cmd[2] = R300_EARLY_Z_DISABLE;
else {
if (ctx-Depth.Test ctx-Depth.Func != GL_NEVER)
/* enable early Z */
- r300-hw.unk4F10.cmd[2] = 0x0001;
+ r300-hw.unk4F10.cmd[2] = R300_EARLY_Z_ENABLE;
else
/* disable early Z */
- r300-hw.unk4F10.cmd[2] = 0x;
+ r300-hw.unk4F10.cmd[2] = R300_EARLY_Z_DISABLE;
}
}
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] R300 early Z cleanup
Christoph Brill wrote: Attached is a mini-patch to add the address of early Z to r300_reg.h and use it. Jerome Glisse helped me with this patch. Thanks. :-) Not really related directly to the patch itself, but it seems to me that the conditions when to enable early-z are a bit wrong. First, I'd think you need to disable early-z when writing to the depth output (or use texkill) in fragment programs. Second, why disable early-z specifically if the depth function is gl_never? Is that some workaround because stencil updates don't work otherwise (in that case should certainly rather check for that) or something similar? Roland - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10085] doesn't build against 2.6.21-rc1
http://bugs.freedesktop.org/show_bug.cgi?id=10085 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from [EMAIL PROTECTED] 2007-02-26 09:20 --- Fixed in git HEAD. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] R300 early Z cleanup
On 2/26/07, Roland Scheidegger [EMAIL PROTECTED] wrote: Christoph Brill wrote: Attached is a mini-patch to add the address of early Z to r300_reg.h and use it. Jerome Glisse helped me with this patch. Thanks. :-) Not really related directly to the patch itself, but it seems to me that the conditions when to enable early-z are a bit wrong. First, I'd think you need to disable early-z when writing to the depth output (or use texkill) in fragment programs. Second, why disable early-z specifically if the depth function is gl_never? Is that some workaround because stencil updates don't work otherwise (in that case should certainly rather check for that) or something similar? Roland Yes we need to disable early z when the fragment program write to z buffer, so far there isn't real support for depth writing in the driver (it's in the todo list). I fail to see why we should disable early z when there is texkill instruction (and stencil disabled), if we disable early z then if the fragment doesn't pass the test in the early pass it won't after texkill so will be killed anyway (and better kill early then at the end). And i believe that stencil update doesn't work if early z is enabled (the fragment is killed before any stencil operation are performed), thus we should disable early in case of stencil is enabled; but as you said checking for that would be nice (maybe some one already looked at that). best, Jerome Glisse - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] R300 early Z cleanup
Jerome Glisse wrote: On 2/26/07, Roland Scheidegger [EMAIL PROTECTED] wrote: Christoph Brill wrote: Attached is a mini-patch to add the address of early Z to r300_reg.h and use it. Jerome Glisse helped me with this patch. Thanks. :-) Not really related directly to the patch itself, but it seems to me that the conditions when to enable early-z are a bit wrong. First, I'd think you need to disable early-z when writing to the depth output (or use texkill) in fragment programs. Second, why disable early-z specifically if the depth function is gl_never? Is that some workaround because stencil updates don't work otherwise (in that case should certainly rather check for that) or something similar? Roland Yes we need to disable early z when the fragment program write to z buffer, so far there isn't real support for depth writing in the driver (it's in the todo list). I fail to see why we should disable early z when there is texkill instruction (and stencil disabled), if we disable early z then if the fragment doesn't pass the test in the early pass it won't after texkill so will be killed anyway (and better kill early then at the end). If you don't disable early z, you can end up writing values to the depth buffer for fragments that are later killed. Keith - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10024] R300 fragment.position viewport transformation is incorrect
http://bugs.freedesktop.org/show_bug.cgi?id=10024
--- Comment #37 from [EMAIL PROTECTED] 2007-02-26 11:50 PST ---
I would still like you to confirm the X Y values.
Do something like:
MUL result.color.xy, fragment.color.xy, {0.005}.x;
If you could send me a screenshot from r300 blog, so I can compare
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCHES] Misc R300 cleanup towards a better r300_reg.h
Attached are two patches that: - define 0x4f18 as R300_RB3D_UNKOWN_4F18 - copy over 1 define from r200 as R300_VAP_CNTL - rename R300_VAP_CNTL to R300_VAP_CNTL_STATUS to be the same as r200 (both unused in r300 code) On #dri-devel there was discussion about similarities in the lower register numbers (up to 0x2200 iirc). Can someone tell if these thoughts might be correct? Also there was discussion on getting information about the blob from tracing the win32 driver. Anyone got some information on how to do so? diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_ioctl.c ./r300_ioctl.c --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_ioctl.c 2007-02-26 16:48:38.0 +0100 +++ ./r300_ioctl.c 2007-02-26 16:53:22.0 +0100 @@ -227,7 +227,7 @@ e32(0); R300_STATECHANGE(r300, unk221C); - reg_start(0x221C, 0); + reg_start(R300_VAP_UNKNOWN_221C, 0); e32(R300_221C_CLEAR); R300_STATECHANGE(r300, ps); diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_reg.h ./r300_reg.h --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_reg.h 2007-02-26 16:48:40.0 +0100 +++ ./r300_reg.h 2007-02-26 17:46:22.0 +0100 @@ -63,6 +63,12 @@ #define R300_SE_VPORT_ZOFFSET 0x1DAC +/* + * Vertex Array Processing (VAP) Control + * Stolen from r200 code from Christoph Brill (It's a guess!) + */ +#define R300_VAP_CNTL 0x2080 + /* This register is written directly and also starts data section * in many 3d CP_PACKET3's */ @@ -135,7 +141,7 @@ /* gap */ -#define R300_VAP_CNTL 0x2140 +#define R300_VAP_CNTL_STATUS 0x2140 # define R300_VC_NO_SWAP (0 0) # define R300_VC_16BIT_SWAP (1 0) # define R300_VC_32BIT_SWAP (2 0) diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/radeon_mm.c ./radeon_mm.c --- /usr/src/mesa/src/mesa/drivers/dri/r300/radeon_mm.c 2007-01-20 21:07:09.0 +0100 +++ ./radeon_mm.c 2007-02-26 16:57:56.0 +0100 @@ -283,7 +283,7 @@ size -= cp_size; } - reg_start(0x4e4c,0); + reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0); e32(0x000a); reg_start(0x342c,0); diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_ioctl.c ./r300_ioctl.c --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_ioctl.c 2007-02-26 10:55:02.0 +0100 +++ ./r300_ioctl.c 2007-02-26 16:41:10.0 +0100 @@ -163,9 +163,8 @@ reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0); e32(0x000a); - - reg_start(0x4f18,0); + reg_start(R300_RB3D_UNKOWN_4F18,0); e32(0x0003); cp_wait(rmesa, R300_WAIT_3D | R300_WAIT_3D_CLEAN); } diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_reg.h ./r300_reg.h --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_reg.h 2007-02-26 16:44:19.0 +0100 +++ ./r300_reg.h 2007-02-26 16:40:41.0 +0100 @@ -1309,7 +1309,7 @@ /* gap */ /* Guess by Vladimir. - * Set to 0A before 3D operations, set to 02 afterwards. + * Set to 0A before 3D operations, set to 0A (was 02) afterwards. */ #define R300_RB3D_DSTCACHE_CTLSTAT 0x4E4C # define R300_RB3D_DSTCACHE_02 0x0002 @@ -1382,6 +1382,12 @@ # define R300_EARLY_Z_DISABLE (0 0) # define R300_EARLY_Z_ENABLE (1 0) +/* + * Set to 03 before 3D operations, set to 03 (was 01) afterwards. + */ +#define R300_RB3D_UNKOWN_4F18 0x4F18 + + /* gap */ #define R300_RB3D_DEPTHOFFSET 0x4F20 diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_render.c ./r300_render.c --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_render.c 2007-02-26 10:55:02.0 +0100 +++ ./r300_render.c 2007-02-26 16:39:03.0 +0100 @@ -346,7 +346,7 @@ reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0); e32(0x000a); - reg_start(0x4f18,0); + reg_start(R300_RB3D_UNKOWN_4F18,0); e32(0x0003); r300EmitState(rmesa); @@ -362,7 +362,7 @@ reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0); e32(0x000a/*0x2*/); - reg_start(0x4f18,0); + reg_start(R300_RB3D_UNKOWN_4F18,0); e32(0x0003/*0x1*/); #ifdef USER_BUFFERS - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] R300 early Z cleanup
On 2/26/07, Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On 2/26/07, Roland Scheidegger [EMAIL PROTECTED] wrote: Christoph Brill wrote: Attached is a mini-patch to add the address of early Z to r300_reg.h and use it. Jerome Glisse helped me with this patch. Thanks. :-) Not really related directly to the patch itself, but it seems to me that the conditions when to enable early-z are a bit wrong. First, I'd think you need to disable early-z when writing to the depth output (or use texkill) in fragment programs. Second, why disable early-z specifically if the depth function is gl_never? Is that some workaround because stencil updates don't work otherwise (in that case should certainly rather check for that) or something similar? Roland Yes we need to disable early z when the fragment program write to z buffer, so far there isn't real support for depth writing in the driver (it's in the todo list). I fail to see why we should disable early z when there is texkill instruction (and stencil disabled), if we disable early z then if the fragment doesn't pass the test in the early pass it won't after texkill so will be killed anyway (and better kill early then at the end). If you don't disable early z, you can end up writing values to the depth buffer for fragments that are later killed. Keith Doesn't early z only discard fragment that fail z test and doesn't write z value, differing the write after fragment operation ? best, Jerome Glisse - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] R300 early Z cleanup
Jerome Glisse wrote: On 2/26/07, Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On 2/26/07, Roland Scheidegger [EMAIL PROTECTED] wrote: Christoph Brill wrote: Attached is a mini-patch to add the address of early Z to r300_reg.h and use it. Jerome Glisse helped me with this patch. Thanks. :-) Not really related directly to the patch itself, but it seems to me that the conditions when to enable early-z are a bit wrong. First, I'd think you need to disable early-z when writing to the depth output (or use texkill) in fragment programs. Second, why disable early-z specifically if the depth function is gl_never? Is that some workaround because stencil updates don't work otherwise (in that case should certainly rather check for that) or something similar? Roland Yes we need to disable early z when the fragment program write to z buffer, so far there isn't real support for depth writing in the driver (it's in the todo list). I fail to see why we should disable early z when there is texkill instruction (and stencil disabled), if we disable early z then if the fragment doesn't pass the test in the early pass it won't after texkill so will be killed anyway (and better kill early then at the end). If you don't disable early z, you can end up writing values to the depth buffer for fragments that are later killed. Keith Doesn't early z only discard fragment that fail z test and doesn't write z value, differing the write after fragment operation ? I guess it depends on the hardware - at least some do both the test and write early. You'd have to test somehow. If it does do the writeback early, you need to also look at disabling when alphatest is enabled. Keith - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] Use constants during reset
Attached is a patch to use some more constants in r300ResetHwState() or r300_state.c. Maybe some of the unk registers in r300_hw_state of r300_context.h should be renamed, too. diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_cmdbuf.c ./r300_cmdbuf.c --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_cmdbuf.c 2007-02-26 21:18:39.0 +0100 +++ ./r300_cmdbuf.c 2007-02-26 21:38:28.0 +0100 @@ -292,13 +292,13 @@ ALLOC_STATE( vpt, always, R300_VPT_CMDSIZE, vpt, 0 ); r300-hw.vpt.cmd[R300_VPT_CMD_0] = cmdpacket0(R300_SE_VPORT_XSCALE, 6); ALLOC_STATE( unk2080, always, 2, unk2080, 0 ); - r300-hw.unk2080.cmd[0] = cmdpacket0(0x2080, 1); + r300-hw.unk2080.cmd[0] = cmdpacket0(R300_VAP_CNTL, 1); ALLOC_STATE( vte, always, 3, vte, 0 ); r300-hw.vte.cmd[0] = cmdpacket0(R300_SE_VTE_CNTL, 2); ALLOC_STATE( unk2134, always, 3, unk2134, 0 ); r300-hw.unk2134.cmd[0] = cmdpacket0(0x2134, 2); ALLOC_STATE( unk2140, always, 2, unk2140, 0 ); - r300-hw.unk2140.cmd[0] = cmdpacket0(0x2140, 1); + r300-hw.unk2140.cmd[0] = cmdpacket0(R300_VAP_CNTL_STATUS, 1); ALLOC_STATE( vir[0], variable, R300_VIR_CMDSIZE, vir/0, 0 ); r300-hw.vir[0].cmd[R300_VIR_CMD_0] = cmdpacket0(R300_VAP_INPUT_ROUTE_0_0, 1); ALLOC_STATE( vir[1], variable, R300_VIR_CMDSIZE, vir/1, 1 ); @@ -308,11 +308,11 @@ ALLOC_STATE( unk21DC, always, 2, unk21DC, 0 ); r300-hw.unk21DC.cmd[0] = cmdpacket0(0x21DC, 1); ALLOC_STATE( unk221C, always, 2, unk221C, 0 ); - r300-hw.unk221C.cmd[0] = cmdpacket0(0x221C, 1); + r300-hw.unk221C.cmd[0] = cmdpacket0(R300_VAP_UNKNOWN_221C, 1); ALLOC_STATE( unk2220, always, 5, unk2220, 0 ); r300-hw.unk2220.cmd[0] = cmdpacket0(0x2220, 4); ALLOC_STATE( unk2288, always, 2, unk2288, 0 ); - r300-hw.unk2288.cmd[0] = cmdpacket0(0x2288, 1); + r300-hw.unk2288.cmd[0] = cmdpacket0(R300_VAP_UNKNOWN_2288, 1); ALLOC_STATE( vof, always, R300_VOF_CMDSIZE, vof, 0 ); r300-hw.vof.cmd[R300_VOF_CMD_0] = cmdpacket0(R300_VAP_OUTPUT_VTX_FMT_0, 2); ALLOC_STATE( pvs, always, R300_PVS_CMDSIZE, pvs, 0 ); @@ -336,9 +336,9 @@ ALLOC_STATE( unk4260, always, 4, unk4260, 0 ); r300-hw.unk4260.cmd[0] = cmdpacket0(0x4260, 3); ALLOC_STATE( unk4274, always, 5, unk4274, 0 ); - r300-hw.unk4274.cmd[0] = cmdpacket0(0x4274, 4); + r300-hw.unk4274.cmd[0] = cmdpacket0(R300_RE_SHADE, 4); ALLOC_STATE( unk4288, always, 4, unk4288, 0 ); - r300-hw.unk4288.cmd[0] = cmdpacket0(0x4288, 3); + r300-hw.unk4288.cmd[0] = cmdpacket0(R300_RE_POLYGON_MODE, 3); ALLOC_STATE( fogp, always, 3, fogp, 0 ); r300-hw.fogp.cmd[0] = cmdpacket0(R300_RE_FOG_SCALE, 2); ALLOC_STATE( unk42A0, always, 2, unk42A0, 0 ); @@ -346,7 +346,7 @@ ALLOC_STATE( zbs, always, R300_ZBS_CMDSIZE, zbs, 0 ); r300-hw.zbs.cmd[R300_ZBS_CMD_0] = cmdpacket0(R300_RE_ZBIAS_T_FACTOR, 4); ALLOC_STATE( unk42B4, always, 2, unk42B4, 0 ); - r300-hw.unk42B4.cmd[0] = cmdpacket0(0x42B4, 1); + r300-hw.unk42B4.cmd[0] = cmdpacket0(R300_RE_OCCLUSION_CNTL, 1); ALLOC_STATE( cul, always, R300_CUL_CMDSIZE, cul, 0 ); r300-hw.cul.cmd[R300_CUL_CMD_0] = cmdpacket0(R300_RE_CULL_CNTL, 1); ALLOC_STATE( unk42C0, always, 3, unk42C0, 0 ); @@ -393,7 +393,7 @@ ALLOC_STATE( cmk, always, R300_CMK_CMDSIZE, cmk, 0 ); r300-hw.cmk.cmd[R300_CMK_CMD_0] = cmdpacket0(R300_RB3D_COLORMASK, 1); ALLOC_STATE( unk4E10, always, 4, unk4E10, 0 ); - r300-hw.unk4E10.cmd[0] = cmdpacket0(0x4E10, 3); + r300-hw.unk4E10.cmd[0] = cmdpacket0(R300_RB3D_BLEND_COLOR, 3); ALLOC_STATE( cb, always, R300_CB_CMDSIZE, cb, 0 ); r300-hw.cb.cmd[R300_CB_CMD_0] = cmdpacket0(R300_RB3D_COLOROFFSET0, 1); r300-hw.cb.cmd[R300_CB_CMD_1] = cmdpacket0(R300_RB3D_COLORPITCH0, 1); @@ -406,7 +406,7 @@ ALLOC_STATE( zs, always, R300_ZS_CMDSIZE, zstencil, 0 ); r300-hw.zs.cmd[R300_ZS_CMD_0] = cmdpacket0(R300_RB3D_ZSTENCIL_CNTL_0, 3); ALLOC_STATE( unk4F10, always, 5, unk4F10, 0 ); - r300-hw.unk4F10.cmd[0] = cmdpacket0(0x4F10, 4); + r300-hw.unk4F10.cmd[0] = cmdpacket0(R300_RB3D_ZSTENCIL_FORMAT, 4); ALLOC_STATE( zb, always, R300_ZB_CMDSIZE, zb, 0 ); r300-hw.zb.cmd[R300_ZB_CMD_0] = cmdpacket0(R300_RB3D_DEPTHOFFSET, 2); ALLOC_STATE( unk4F28, always, 2, unk4F28, 0 ); diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_reg.h ./r300_reg.h --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_reg.h 2007-02-26 21:18:37.0 +0100 +++ ./r300_reg.h 2007-02-26 21:36:43.0 +0100 @@ -544,6 +544,9 @@ /* Some sort of scale or clamp value for texcoordless textures. */ #define R300_RE_UNK4238 0x4238 +/* Something shade related */ +#define R300_RE_SHADE 0x4274 + #define R300_RE_SHADE_MODEL 0x4278 # define R300_RE_SHADE_MODEL_SMOOTH 0x3 # define R300_RE_SHADE_MODEL_FLAT 0x39595 @@ -1279,6 +1282,7 @@ # define R300_BLEND_MASK (63) # define R300_SRC_BLEND_SHIFT (16) # define R300_DST_BLEND_SHIFT (24) +#define R300_RB3D_BLEND_COLOR 0x4E10
Re: [PATCH] R300 early Z cleanup
Keith Whitwell wrote: Jerome Glisse wrote: On 2/26/07, Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On 2/26/07, Roland Scheidegger [EMAIL PROTECTED] wrote: Christoph Brill wrote: Attached is a mini-patch to add the address of early Z to r300_reg.h and use it. Jerome Glisse helped me with this patch. Thanks. :-) Not really related directly to the patch itself, but it seems to me that the conditions when to enable early-z are a bit wrong. First, I'd think you need to disable early-z when writing to the depth output (or use texkill) in fragment programs. Second, why disable early-z specifically if the depth function is gl_never? Is that some workaround because stencil updates don't work otherwise (in that case should certainly rather check for that) or something similar? Roland Yes we need to disable early z when the fragment program write to z buffer, so far there isn't real support for depth writing in the driver (it's in the todo list). I fail to see why we should disable early z when there is texkill instruction (and stencil disabled), if we disable early z then if the fragment doesn't pass the test in the early pass it won't after texkill so will be killed anyway (and better kill early then at the end). If you don't disable early z, you can end up writing values to the depth buffer for fragments that are later killed. Keith Doesn't early z only discard fragment that fail z test and doesn't write z value, differing the write after fragment operation ? I guess it depends on the hardware - at least some do both the test and write early. You'd have to test somehow. If it does do the writeback early, you need to also look at disabling when alphatest is enabled. Indeed the driver already does that, r300 chips apparently do early z write (http://ati.amd.com/developer/gpups/index.html mentions Force Alpha Test Enable Can identify problems related to early Z test). As for stencil, I'm actually not sure that stencil isn't performed (that was just a guess for that disabling of early z when gl_never z test is used, since in that case you're probably updating stencil, what's the point of doing rendering at all otherwise) - since it's a shared stencil/depth buffer it would make sense for the hardware to perform stencil test at the same time and thus it would still work with early z. IIRC I think there was some talk about some differences there between r300 and r400, can't remember though. Test apps should easily reveal if it works. Roland - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10024] R300 fragment.position viewport transformation is incorrect
http://bugs.freedesktop.org/show_bug.cgi?id=10024
--- Comment #38 from [EMAIL PROTECTED] 2007-02-26 19:35 PST ---
I assume you mean MUL result.color.xy, fragment.position.xy, {0.005}.x; and
not fragment.color. I'm testing with MUL result.color.xy,
fragment.position.xy, {0.005}.x; now, and I'll post the attach the screenshots
after I'm done.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10024] R300 fragment.position viewport transformation is incorrect
http://bugs.freedesktop.org/show_bug.cgi?id=10024
--- Comment #39 from [EMAIL PROTECTED] 2007-02-26 19:42 PST ---
Created an attachment (id=8865)
-- (http://bugs.freedesktop.org/attachment.cgi?id=8865action=view)
R300 fragment.position.xy
I had to use MUL result.color.xy, fragment.position, {0.005}.x; for the
program to successfully load (removed the .xy mask on fragment.position) but
this shouldn't make a difference since result.color is masked for .xy anyway.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10024] R300 fragment.position viewport transformation is incorrect
http://bugs.freedesktop.org/show_bug.cgi?id=10024 --- Comment #40 from [EMAIL PROTECTED] 2007-02-26 19:53 PST --- Created an attachment (id=8866) -- (http://bugs.freedesktop.org/attachment.cgi?id=8866action=view) Blob fragment.position.xy Ditto -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10024] R300 fragment.position viewport transformation is incorrect
http://bugs.freedesktop.org/show_bug.cgi?id=10024 --- Comment #41 from [EMAIL PROTECTED] 2007-02-26 19:59 PST --- I forgot to mention that the R300 screenshot is with your patch to calculate the WPOS in the fragment program. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 9252] complete lockups with radeon 9600 XT
http://bugs.freedesktop.org/show_bug.cgi?id=9252 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #13 from [EMAIL PROTECTED] 2007-02-26 20:06 PST --- I think that I have a similar problem; actually, I get a couple of different lock up types, but this is one of them. I also haven't been able to get anything to disk yet, but I'm going try with a kernel serial console that should (hopefully) get all the DRM messages. I'm also going to try with the R300 ring buffer debug patch, originally posted at http://marc.theaimsgroup.com/?l=dri-develm=111736048825917w=2 I modified it slightly so it applies cleanly to Git master. http://z3ro.name/r300_ring_buffer.patch Just some random ideas that may or may not help you. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10090] Google Earth rendering trouble with Unichrome IGP
http://bugs.freedesktop.org/show_bug.cgi?id=10090 --- Comment #5 from [EMAIL PROTECTED] 2007-02-26 21:32 PST --- Created an attachment (id=8867) -- (http://bugs.freedesktop.org/attachment.cgi?id=8867action=view) fix hardware clipping I have a patch for you to test :) this depends on the other fix for the viewport, but you should already have that one. Have fun with google earth, i know i am. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
