Re: [Mesa3d-dev] Figuring out R300_VAP_CNTL
Not sure if you are still collecting ... but here you go 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R300 ND [Radeon 9700 Pro] (prog-if 00 [VGA]) Subsystem: Elsa AG Unknown device 0c90 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop+ ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 255 (2000ns min), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at d800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at c000 [size=256] Region 2: Memory at e900 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at e800 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ Rate=x4 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 01:00.1 Display controller: ATI Technologies Inc Radeon R300 [Radeon 9700 Pro] (Secondary) Subsystem: Elsa AG Unknown device 0c91 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (2000ns min), Cache Line Size: 32 bytes Region 0: Memory at e000 (32-bit, prefetchable) [size=128M] Region 1: Memory at e901 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- RADEON_DAC_CNTL 0102 RADEON_DAC_EXT_CNTL RADEON_DAC_MACRO_CNTL 0808 RADEON_DAC_CNTL2 RADEON_TV_DAC_CNTL 07800142 RADEON_DISP_OUTPUT_CNTL 3408 RADEON_CONFIG_MEMSIZE 0800 RADEON_AUX_SC_CNTL RADEON_CRTC_EXT_CNTL11008000 RADEON_CRTC_GEN_CNTL03208600 RADEON_CRTC2_GEN_CNTL 0410 RADEON_DEVICE_ID00a74e44 RADEON_DISP_MISC_CNTL 5b300600 RADEON_GPIO_MONID RADEON_GPIO_MONIDB RADEON_GPIO_CRT2_DDC RADEON_GPIO_DVI_DDC 0300 RADEON_GPIO_VGA_DDC 0300 RADEON_LVDS_GEN_CNTL0808 RADEON_FP_GEN_CNTL 0202 RADEON_FP2_GEN_CNTL 01000208 RADEON_PIXCLKS_CNTL a010 R300_VAP_CNTL 00240455 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r200] minor minor minor cleanups
Hi list, attached are few fixes for issues I found while browsing through the r200 DRI code. Bye, Christoph 0001-r200-Drop-CVS-header-from-files.patch Description: application/mbox 0002-r200-reenable-debug-output.patch Description: application/mbox 0003-r200-set-anisotropy-filtering-to-1-instead-of-16-fo.patch Description: application/mbox - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R200 minor cleanups
Hi, find attached some minor cleanups I did while comparing r200 and r300 code. Most of them are indention and cosmetical changes. Only real changes are that I replaced som if (0) with if (R200_DEBUG DEBUG_TEXTURE) It generally reduces the diff between r200 and r300. That's it. Review and commit please, Christoph Brill r200-updates.tar.bz2 Description: application/bzip-compressed-tar - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 minor cleanups
Am Montag, den 14.05.2007, 22:53 +0200 schrieb Roland Scheidegger: Christoph Brill wrote: Hi, find attached some minor cleanups I did while comparing r200 and r300 code. Most of them are indention and cosmetical changes. Only real changes are that I replaced som if (0) with if (R200_DEBUG DEBUG_TEXTURE) It generally reduces the diff between r200 and r300. That's it. Review and commit please, Christoph Brill Hmm, personally I'm not too happy with kernel-style indentation (and worse, some parts of the driver but not others converted to it). But maybe that's just me. If you're truely going to unify the drivers, there is obviously no way around that (though you could just convert r300 to use style of radeon/r200...) but if the files are still separate anyway I don't see much point. Other opinions? Roland I don't really have an opinion on that. The only thing I dislike in the r200 code is that it uses spaces for indents. But that's only my opinion. We can choose whatever indention you like. Note: I'm not 100% sure if merging r300 and r200 code is usefull or even possible. I generally think there is a high amount of redundancy that could be unified. But I need to check that against radeon first before I really continue to do so. I'd rather say to keep my patches out of git for now until a decision for indention was made. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] minor cleanups
Hi list, I've been browsing through the code to get more in touch with it. On my way I added few doxygen comments and removed the use of a unnecessary function. The removal was agreed by Jerome Glisse. Please check and push these. Thanks in advance, Christoph Brill 0001-Add-few-doxygen-comments-to-r300_context.h.patch Description: application/mbox 0002-Few-doxgen-comments.patch Description: application/mbox - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 cleanup questions
I reviewed the cleanup done by Olliver McFadden and had the following
questions:
-int r300_get_num_verts(r300ContextPtr rmesa, int num_verts, int prim)
+static int r300NumVerts(r300ContextPtr rmesa, int num_verts, int prim)
Is it necessary/usefull that the function is static?
-/* Immediate implementation has been removed from CVS. */
-
-/* vertex buffer implementation */
-
-static void inline fire_EB(r300ContextPtr rmesa, unsigned long addr
+static void inline r300FireEB(r300ContextPtr rmesa, unsigned long addr
Why move all the comments to the head of the file. IMO the method should
have a doxygen comment that states it is the vertex buffer
implementation of fire_EB, right?
-if (num_verts 65535) { /* not implemented yet */
+if (num_verts 65535) {
Comments like this should be kept. Otherwise it looks like a hardware
limitation while the limitation can be worked around or the limitation
does not exist.
Last but not least is
r300_foo_bar
preferred or
r300FooBar
Which is the one mesa uses?
Otherwise thumbs up for starting to cleanup code... on of the most
unthankfull jobs :-)
Regards,
Christoph Brill
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[ANNOUNCE] TiRDC #4
Hi list, I proudly present the 4th issue of The irregular Radeon Development Companion. This is an aggregation of the DRI development events happening on IRC, on the mailing lists and on blogs. It is mainly focused on R300, but also sums up other parts of DRM/DRI and sometimes even DDX. Feel free to read what happened lately and give feedback about what you think of TiRDC. The current issue is at: http://dri.freedesktop.org/wiki/Radeon_20Companion_204 and older versions can be found at http://dri.freedesktop.org/wiki/R300 Thanks for reading, Christoph Brill (TiRDC author) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ 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
[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
[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: R300 status
Am Mittwoch, den 10.01.2007, 15:54 +0100 schrieb Paul Heldens: http://dri.freedesktop.org/wiki/R300_20Portal I think it's a good idea but it's really hidden. And lacks content ... a bit ;-) But it's a good start. I'm willing to fill it with more information... is it available in an aggregated form, or do I have to gather things from watch git? What about a monthly Git changes for R300 on that page? Regards, Christoph - 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: r500 - where to start?
Might it be an idea to collect these tools on a single page? Definitely! So I hacked it up at: http://dri.freedesktop.org/wiki/ReverseEngineering Maybe everything is wrong. Maybe it helps. I have no idea. I never used with any of these. Regards, Christoph Brill - 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: r300 code cleanup
Am Dienstag, den 04.07.2006, 18:35 +0200 schrieb Jerome Glisse: On 7/4/06, Tilman Sauerbeck [EMAIL PROTECTED] wrote: Jerome Glisse [2006-07-03 23:49]: For indenting rules i personnaly use the linux kernel ones, iirc this was the original indenting choosed by Nicolai. Anyway, we can use another if people prefer another one (as long as the indenting you propose is not severly broken). Shouldn't we stick to the Mesa indentation rules? http://www.mesa3d.org/devinfo.html You could find rules for Mesa there, duno if there are the actual one :) If no one object i will go with this one. For function name i think that r300DoSomething is for function called by mesa and r300_do_otherthings is for internal driver function at leat this is my guess from looking at i915 driver :) I'd prefer not to mix up CamelCase and snake_case. Do you think the benefit it provides is good enough to make up for the inconsistency? I think this is good enough, thus you can easily spot which function are called by mesa and which one could only be called inside the driver. There is little explanation for that here : http://www.mesa3d.org/devinfo.html Btw what about doxygen comment ? Might help people looking at the driver and might help refreshing memory when you get back on old code :) I personally dislike using doxygen. It bloats the code without having a real benefint. Most developers don't comment oder don't comment very well. Without a Guide on documenting code it's pretty useless from my experience. And I think especially in hardware development (when you're happy when you are done ;-) ) the special tricks necessary to get it working will in best cases be found in a normal comment and not the Doxygen one. But I like doxygen to create call graphs. This is pretty helpfull whe I try to trace function calls to understand what is happening (like pressing F3 in Eclipse when developing Java). But I really recommend documenting the code in whatever way is the best :-) Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] Lockups
Hi list, I'm still seeing lots of lockups with my r300 (Radeon 9700Pro) with current drm/mesa/xf86-video-ati cvs. I think I found a reproducable lockup. It happens when I use Wings3d[1] (a free modeller). Wings has a grid for orientation when I move around the camera it works fine. But as soon as the grid hits the borders of the window, my system locks up. I'm not 100% sure so if anyone else can reproduce this it would be great. Thanks, Christoph Brill [1] http://www.wings3d.com --- 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=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRI snapshots built from modular Xorg
Felix Kühling wrote: Hi, I just uploaded the first set of snapshots built from the modular Xorg tree (20060226). This now has the latest and greatest changes in Xorg CVS that the monolithic tree did not have. Among other things this means that i915 should now work again, with rotation support. It also has Benjamin Herrenschmidt's memory mapping changes that should solve lockup problems on many Radeons. Please let me know if there are any new problems with installing these snapshots. Regards, Felix Thanks for the work! BTW: Someone should redirect www.freedesktop.org/*dri*/*snapshots*/ to http://dri.freedesktop.org/snapshots/ ... it's listed first on google when search for dri snapshot and it's quite dead :) --- 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=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
