[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
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
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
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
