From 1ad914575a89f3fdbfa5bce863e14f8d4679ed3b Mon Sep 17 00:00:00 2001 From: Jerome Glisse Date: Tue, 4 Jul 2006 20:50:49 +0000 Subject: Add R300_VAP_CNTL 0x2140 and cosmetic cleanup. --- src/mesa/drivers/dri/r300/r300_reg.h | 893 +++++++++++++++++++---------------- 1 file changed, 498 insertions(+), 395 deletions(-) diff --git a/src/mesa/drivers/dri/r300/r300_reg.h b/src/mesa/drivers/dri/r300/r300_reg.h index b2fe46979f..f7cdfbe3c4 100644 --- a/src/mesa/drivers/dri/r300/r300_reg.h +++ b/src/mesa/drivers/dri/r300/r300_reg.h @@ -48,12 +48,12 @@ USE OR OTHER DEALINGS IN THE SOFTWARE. # define R300_MC_MISC__MC_GLOBW_FULL_LAT_SHIFT 28 /* -This file contains registers and constants for the R300. They have been -found mostly by examining command buffers captured using glxtest, as well -as by extrapolating some known registers and constants from the R200. - -I am fairly certain that they are correct unless stated otherwise in comments. -*/ + * This file contains registers and constants for the R300. They have been + * found mostly by examining command buffers captured using glxtest, as well + * as by extrapolating some known registers and constants from the R200. + * I am fairly certain that they are correct unless stated otherwise + * in comments. + */ #define R300_SE_VPORT_XSCALE 0x1D98 #define R300_SE_VPORT_XOFFSET 0x1D9C @@ -63,46 +63,48 @@ I am fairly certain that they are correct unless stated otherwise in comments. #define R300_SE_VPORT_ZOFFSET 0x1DAC -/* This register is written directly and also starts data section in many 3d CP_PACKET3's */ +/* This register is written directly and also starts data section + * in many 3d CP_PACKET3's + */ #define R300_VAP_VF_CNTL 0x2084 - -# define R300_VAP_VF_CNTL__PRIM_TYPE__SHIFT 0 -# define R300_VAP_VF_CNTL__PRIM_NONE (0<<0) -# define R300_VAP_VF_CNTL__PRIM_POINTS (1<<0) -# define R300_VAP_VF_CNTL__PRIM_LINES (2<<0) -# define R300_VAP_VF_CNTL__PRIM_LINE_STRIP (3<<0) -# define R300_VAP_VF_CNTL__PRIM_TRIANGLES (4<<0) -# define R300_VAP_VF_CNTL__PRIM_TRIANGLE_FAN (5<<0) -# define R300_VAP_VF_CNTL__PRIM_TRIANGLE_STRIP (6<<0) -# define R300_VAP_VF_CNTL__PRIM_LINE_LOOP (12<<0) -# define R300_VAP_VF_CNTL__PRIM_QUADS (13<<0) -# define R300_VAP_VF_CNTL__PRIM_QUAD_STRIP (14<<0) -# define R300_VAP_VF_CNTL__PRIM_POLYGON (15<<0) - -# define R300_VAP_VF_CNTL__PRIM_WALK__SHIFT 4 - /* State based - direct writes to registers trigger vertex generation */ -# define R300_VAP_VF_CNTL__PRIM_WALK_STATE_BASED (0<<4) -# define R300_VAP_VF_CNTL__PRIM_WALK_INDICES (1<<4) -# define R300_VAP_VF_CNTL__PRIM_WALK_VERTEX_LIST (2<<4) -# define R300_VAP_VF_CNTL__PRIM_WALK_VERTEX_EMBEDDED (3<<4) - - /* I don't think I saw these three used.. */ -# define R300_VAP_VF_CNTL__COLOR_ORDER__SHIFT 6 -# define R300_VAP_VF_CNTL__TCL_OUTPUT_CTL_ENA__SHIFT 9 -# define R300_VAP_VF_CNTL__PROG_STREAM_ENA__SHIFT 10 - - /* index size - when not set the indices are assumed to be 16 bit */ -# define R300_VAP_VF_CNTL__INDEX_SIZE_32bit (1<<11) - /* number of vertices */ -# define R300_VAP_VF_CNTL__NUM_VERTICES__SHIFT 16 +# define R300_VAP_VF_CNTL__PRIM_TYPE__SHIFT 0 +# define R300_VAP_VF_CNTL__PRIM_NONE (0<<0) +# define R300_VAP_VF_CNTL__PRIM_POINTS (1<<0) +# define R300_VAP_VF_CNTL__PRIM_LINES (2<<0) +# define R300_VAP_VF_CNTL__PRIM_LINE_STRIP (3<<0) +# define R300_VAP_VF_CNTL__PRIM_TRIANGLES (4<<0) +# define R300_VAP_VF_CNTL__PRIM_TRIANGLE_FAN (5<<0) +# define R300_VAP_VF_CNTL__PRIM_TRIANGLE_STRIP (6<<0) +# define R300_VAP_VF_CNTL__PRIM_LINE_LOOP (12<<0) +# define R300_VAP_VF_CNTL__PRIM_QUADS (13<<0) +# define R300_VAP_VF_CNTL__PRIM_QUAD_STRIP (14<<0) +# define R300_VAP_VF_CNTL__PRIM_POLYGON (15<<0) + +# define R300_VAP_VF_CNTL__PRIM_WALK__SHIFT 4 + /* State based - direct writes to registers trigger vertex + generation */ +# define R300_VAP_VF_CNTL__PRIM_WALK_STATE_BASED (0<<4) +# define R300_VAP_VF_CNTL__PRIM_WALK_INDICES (1<<4) +# define R300_VAP_VF_CNTL__PRIM_WALK_VERTEX_LIST (2<<4) +# define R300_VAP_VF_CNTL__PRIM_WALK_VERTEX_EMBEDDED (3<<4) + + /* I don't think I saw these three used.. */ +# define R300_VAP_VF_CNTL__COLOR_ORDER__SHIFT 6 +# define R300_VAP_VF_CNTL__TCL_OUTPUT_CTL_ENA__SHIFT 9 +# define R300_VAP_VF_CNTL__PROG_STREAM_ENA__SHIFT 10 + + /* index size - when not set the indices are assumed to be 16 bit */ +# define R300_VAP_VF_CNTL__INDEX_SIZE_32bit (1<<11) + /* number of vertices */ +# define R300_VAP_VF_CNTL__NUM_VERTICES__SHIFT 16 /* BEGIN: Wild guesses */ #define R300_VAP_OUTPUT_VTX_FMT_0 0x2090 # define R300_VAP_OUTPUT_VTX_FMT_0__POS_PRESENT (1<<0) # define R300_VAP_OUTPUT_VTX_FMT_0__COLOR_PRESENT (1<<1) -# define R300_VAP_OUTPUT_VTX_FMT_0__COLOR_1_PRESENT (1<<2) /* GUESS */ -# define R300_VAP_OUTPUT_VTX_FMT_0__COLOR_2_PRESENT (1<<3) /* GUESS */ -# define R300_VAP_OUTPUT_VTX_FMT_0__COLOR_3_PRESENT (1<<4) /* GUESS */ +# define R300_VAP_OUTPUT_VTX_FMT_0__COLOR_1_PRESENT (1<<2) /* GUESS */ +# define R300_VAP_OUTPUT_VTX_FMT_0__COLOR_2_PRESENT (1<<3) /* GUESS */ +# define R300_VAP_OUTPUT_VTX_FMT_0__COLOR_3_PRESENT (1<<4) /* GUESS */ # define R300_VAP_OUTPUT_VTX_FMT_0__PT_SIZE_PRESENT (1<<16) /* GUESS */ #define R300_VAP_OUTPUT_VTX_FMT_1 0x2094 @@ -114,7 +116,7 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_VAP_OUTPUT_VTX_FMT_1__TEX_5_COMP_CNT_SHIFT 15 # define R300_VAP_OUTPUT_VTX_FMT_1__TEX_6_COMP_CNT_SHIFT 18 # define R300_VAP_OUTPUT_VTX_FMT_1__TEX_7_COMP_CNT_SHIFT 21 -/* END */ +/* END: Wild guesses */ #define R300_SE_VTE_CNTL 0x20b0 # define R300_VPORT_X_SCALE_ENA 0x00000001 @@ -130,29 +132,39 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_VTX_ST_DENORMALIZED 0x00001000 /* BEGIN: Vertex data assembly - lots of uncertainties */ + /* gap */ + +#define R300_VAP_CNTL 0x2140 +# define R300_VC_NO_SWAP (0 << 0) +# define R300_VC_16BIT_SWAP (1 << 0) +# define R300_VC_32BIT_SWAP (2 << 0) + +/* gap */ + /* Where do we get our vertex data? -// -// Vertex data either comes either from immediate mode registers or from -// vertex arrays. -// There appears to be no mixed mode (though we can force the pitch of -// vertex arrays to 0, effectively reusing the same element over and over -// again). -// -// Immediate mode is controlled by the INPUT_CNTL registers. I am not sure -// if these registers influence vertex array processing. -// -// Vertex arrays are controlled via the 3D_LOAD_VBPNTR packet3. -// -// In both cases, vertex attributes are then passed through INPUT_ROUTE. - -// Beginning with INPUT_ROUTE_0_0 is a list of WORDs that route vertex data -// into the vertex processor's input registers. -// The first word routes the first input, the second word the second, etc. -// The corresponding input is routed into the register with the given index. -// The list is ended by a word with INPUT_ROUTE_END set. -// -// Always set COMPONENTS_4 in immediate mode. */ + * + * Vertex data either comes either from immediate mode registers or from + * vertex arrays. + * There appears to be no mixed mode (though we can force the pitch of + * vertex arrays to 0, effectively reusing the same element over and over + * again). + * + * Immediate mode is controlled by the INPUT_CNTL registers. I am not sure + * if these registers influence vertex array processing. + * + * Vertex arrays are controlled via the 3D_LOAD_VBPNTR packet3. + * + * In both cases, vertex attributes are then passed through INPUT_ROUTE. + * + * Beginning with INPUT_ROUTE_0_0 is a list of WORDs that route vertex data + * into the vertex processor's input registers. + * The first word routes the first input, the second word the second, etc. + * The corresponding input is routed into the register with the given index. + * The list is ended by a word with INPUT_ROUTE_END set. + * + * Always set COMPONENTS_4 in immediate mode. + */ #define R300_VAP_INPUT_ROUTE_0_0 0x2150 # define R300_INPUT_ROUTE_COMPONENTS_1 (0 << 0) @@ -176,10 +188,12 @@ I am fairly certain that they are correct unless stated otherwise in comments. #define R300_VAP_INPUT_ROUTE_0_7 0x216C /* gap */ + /* Notes: -// - always set up to produce at least two attributes: -// if vertex program uses only position, fglrx will set normal, too -// - INPUT_CNTL_0_COLOR and INPUT_CNTL_COLOR bits are always equal */ + * - always set up to produce at least two attributes: + * if vertex program uses only position, fglrx will set normal, too + * - INPUT_CNTL_0_COLOR and INPUT_CNTL_COLOR bits are always equal. + */ #define R300_VAP_INPUT_CNTL_0 0x2180 # define R300_INPUT_CNTL_0_COLOR 0x00000001 #define R300_VAP_INPUT_CNTL_1 0x2184 @@ -196,12 +210,14 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_INPUT_CNTL_TC7 0x00020000 /* GUESS */ /* gap */ + /* Words parallel to INPUT_ROUTE_0; All words that are active in INPUT_ROUTE_0 -// are set to a swizzling bit pattern, other words are 0. -// -// In immediate mode, the pattern is always set to xyzw. In vertex array -// mode, the swizzling pattern is e.g. used to set zw components in texture -// coordinates with only tweo components. */ + * are set to a swizzling bit pattern, other words are 0. + * + * In immediate mode, the pattern is always set to xyzw. In vertex array + * mode, the swizzling pattern is e.g. used to set zw components in texture + * coordinates with only tweo components. + */ #define R300_VAP_INPUT_ROUTE_1_0 0x21E0 # define R300_INPUT_ROUTE_SELECT_X 0 # define R300_INPUT_ROUTE_SELECT_Y 1 @@ -210,11 +226,11 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_INPUT_ROUTE_SELECT_ZERO 4 # define R300_INPUT_ROUTE_SELECT_ONE 5 # define R300_INPUT_ROUTE_SELECT_MASK 7 -# define R300_INPUT_ROUTE_X_SHIFT 0 -# define R300_INPUT_ROUTE_Y_SHIFT 3 -# define R300_INPUT_ROUTE_Z_SHIFT 6 -# define R300_INPUT_ROUTE_W_SHIFT 9 -# define R300_INPUT_ROUTE_ENABLE (15 << 12) +# define R300_INPUT_ROUTE_X_SHIFT 0 +# define R300_INPUT_ROUTE_Y_SHIFT 3 +# define R300_INPUT_ROUTE_Z_SHIFT 6 +# define R300_INPUT_ROUTE_W_SHIFT 9 +# define R300_INPUT_ROUTE_ENABLE (15 << 12) #define R300_VAP_INPUT_ROUTE_1_1 0x21E4 #define R300_VAP_INPUT_ROUTE_1_2 0x21E8 #define R300_VAP_INPUT_ROUTE_1_3 0x21EC @@ -223,53 +239,64 @@ I am fairly certain that they are correct unless stated otherwise in comments. #define R300_VAP_INPUT_ROUTE_1_6 0x21F8 #define R300_VAP_INPUT_ROUTE_1_7 0x21FC -/* END */ +/* END: Vertex data assembly */ /* gap */ -/* BEGIN: Upload vertex program and data -// The programmable vertex shader unit has a memory bank of unknown size -// that can be written to in 16 byte units by writing the address into -// UPLOAD_ADDRESS, followed by data in UPLOAD_DATA (multiples of 4 DWORDs). -// -// Pointers into the memory bank are always in multiples of 16 bytes. -// -// The memory bank is divided into areas with fixed meaning. -// -// Starting at address UPLOAD_PROGRAM: Vertex program instructions. -// Native limits reported by drivers from ATI suggest size 256 (i.e. 4KB), -// whereas the difference between known addresses suggests size 512. -// -// Starting at address UPLOAD_PARAMETERS: Vertex program parameters. -// Native reported limits and the VPI layout suggest size 256, whereas -// difference between known addresses suggests size 512. -// -// At address UPLOAD_POINTSIZE is a vector (0, 0, ps, 0), where ps is the -// floating point pointsize. The exact purpose of this state is uncertain, -// as there is also the R300_RE_POINTSIZE register. -// -// Multiple vertex programs and parameter sets can be loaded at once, -// which could explain the size discrepancy. */ + +/* BEGIN: Upload vertex program and data */ + +/* + * The programmable vertex shader unit has a memory bank of unknown size + * that can be written to in 16 byte units by writing the address into + * UPLOAD_ADDRESS, followed by data in UPLOAD_DATA (multiples of 4 DWORDs). + * + * Pointers into the memory bank are always in multiples of 16 bytes. + * + * The memory bank is divided into areas with fixed meaning. + * + * Starting at address UPLOAD_PROGRAM: Vertex program instructions. + * Native limits reported by drivers from ATI suggest size 256 (i.e. 4KB), + * whereas the difference between known addresses suggests size 512. + * + * Starting at address UPLOAD_PARAMETERS: Vertex program parameters. + * Native reported limits and the VPI layout suggest size 256, whereas + * difference between known addresses suggests size 512. + * + * At address UPLOAD_POINTSIZE is a vector (0, 0, ps, 0), where ps is the + * floating point pointsize. The exact purpose of this state is uncertain, + * as there is also the R300_RE_POINTSIZE register. + * + * Multiple vertex programs and parameter sets can be loaded at once, + * which could explain the size discrepancy. + */ #define R300_VAP_PVS_UPLOAD_ADDRESS 0x2200 # define R300_PVS_UPLOAD_PROGRAM 0x00000000 # define R300_PVS_UPLOAD_PARAMETERS 0x00000200 # define R300_PVS_UPLOAD_POINTSIZE 0x00000406 + /* gap */ + #define R300_VAP_PVS_UPLOAD_DATA 0x2208 -/* END */ + +/* END: Upload vertex program and data */ /* gap */ + /* I do not know the purpose of this register. However, I do know that -// it is set to 221C_CLEAR for clear operations and to 221C_NORMAL -// for normal rendering. */ + * it is set to 221C_CLEAR for clear operations and to 221C_NORMAL + * for normal rendering. + */ #define R300_VAP_UNKNOWN_221C 0x221C # define R300_221C_NORMAL 0x00000000 # define R300_221C_CLEAR 0x0001C000 /* gap */ + /* Sometimes, END_OF_PKT and 0x2284=0 are the only commands sent between -// rendering commands and overwriting vertex program parameters. -// Therefore, I suspect writing zero to 0x2284 synchronizes the engine and -// avoids bugs caused by still running shaders reading bad data from memory. */ + * rendering commands and overwriting vertex program parameters. + * Therefore, I suspect writing zero to 0x2284 synchronizes the engine and + * avoids bugs caused by still running shaders reading bad data from memory. + */ #define R300_VAP_PVS_WAITIDLE 0x2284 /* GUESS */ /* Absolutely no clue what this register is about. */ @@ -278,19 +305,22 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_2288_RV350 0x0000FFFF /* -- Vladimir */ /* gap */ + /* Addresses are relative to the vertex program instruction area of the -// memory bank. PROGRAM_END points to the last instruction of the active -// program -// -// The meaning of the two UNKNOWN fields is obviously not known. However, -// experiments so far have shown that both *must* point to an instruction -// inside the vertex program, otherwise the GPU locks up. -// fglrx usually sets CNTL_3_UNKNOWN to the end of the program and -// CNTL_1_UNKNOWN points to instruction where last write to position takes place. -// Most likely this is used to ignore rest of the program in cases where group of verts arent visible. -// For some reason this "section" is sometimes accepted other instruction that have -// no relationship with position calculations. -*/ + * memory bank. PROGRAM_END points to the last instruction of the active + * program + * + * The meaning of the two UNKNOWN fields is obviously not known. However, + * experiments so far have shown that both *must* point to an instruction + * inside the vertex program, otherwise the GPU locks up. + * fglrx usually sets CNTL_3_UNKNOWN to the end of the program and + * CNTL_1_UNKNOWN points to instruction where last write to position takes + * place. + * Most likely this is used to ignore rest of the program in cases + * where group of verts arent visible. For some reason this "section" + * is sometimes accepted other instruction that have no relationship with + *position calculations. + */ #define R300_VAP_PVS_CNTL_1 0x22D0 # define R300_PVS_CNTL_1_PROGRAM_START_SHIFT 0 # define R300_PVS_CNTL_1_POS_END_SHIFT 10 @@ -304,7 +334,8 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_PVS_CNTL_3_PROGRAM_UNKNOWN2_SHIFT 0 /* The entire range from 0x2300 to 0x2AC inclusive seems to be used for -// immediate vertices */ + * immediate vertices + */ #define R300_VAP_VTX_COLOR_R 0x2464 #define R300_VAP_VTX_COLOR_G 0x2468 #define R300_VAP_VTX_COLOR_B 0x246C @@ -314,13 +345,15 @@ I am fairly certain that they are correct unless stated otherwise in comments. #define R300_VAP_VTX_POS_0_X_2 0x24A0 /* used for glVertex3*() */ #define R300_VAP_VTX_POS_0_Y_2 0x24A4 #define R300_VAP_VTX_POS_0_Z_2 0x24A8 -#define R300_VAP_VTX_END_OF_PKT 0x24AC /* write 0 to indicate end of packet? */ +/* write 0 to indicate end of packet? */ +#define R300_VAP_VTX_END_OF_PKT 0x24AC /* gap */ /* These are values from r300_reg/r300_reg.h - they are known to be correct - and are here so we can use one register file instead of several - - Vladimir */ + * and are here so we can use one register file instead of several + * - Vladimir + */ #define R300_GB_VAP_RASTER_VTX_FMT_0 0x4000 # define R300_GB_VAP_RASTER_VTX_FMT_0__POS_PRESENT (1<<0) # define R300_GB_VAP_RASTER_VTX_FMT_0__COLOR_0_PRESENT (1<<1) @@ -343,8 +376,10 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_GB_VAP_RASTER_VTX_FMT_1__TEX_7_COMP_CNT_SHIFT 21 /* UNK30 seems to enables point to quad transformation on textures - (or something closely related to that). - This bit is rather fatal at the time being due to lackings at pixel shader side */ + * (or something closely related to that). + * This bit is rather fatal at the time being due to lackings at pixel + * shader side + */ #define R300_GB_ENABLE 0x4008 # define R300_GB_POINT_STUFF_ENABLE (1<<0) # define R300_GB_LINE_STUFF_ENABLE (1<<1) @@ -452,9 +487,8 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_AA_SUBSAMPLES_4 (2<<1) # define R300_AA_SUBSAMPLES_6 (3<<1) -/* END */ - /* gap */ + /* Zero to flush caches. */ #define R300_TX_CNTL 0x4100 @@ -478,8 +512,9 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_TX_ENABLE_15 (1 << 15) /* The pointsize is given in multiples of 6. The pointsize can be -// enormous: Clear() renders a single point that fills the entire -// framebuffer. */ + * enormous: Clear() renders a single point that fills the entire + * framebuffer. + */ #define R300_RE_POINTSIZE 0x421C # define R300_POINTSIZE_Y_SHIFT 0 # define R300_POINTSIZE_Y_MASK (0xFFFF << 0) /* GUESS */ @@ -488,11 +523,11 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_POINTSIZE_MAX (R300_POINTSIZE_Y_MASK / 6) /* The line width is given in multiples of 6. - In default mode lines are classified as vertical lines. - HO: horizontal - VE: vertical or horizontal - HO & VE: no classification -*/ + * In default mode lines are classified as vertical lines. + * HO: horizontal + * VE: vertical or horizontal + * HO & VE: no classification + */ #define R300_RE_LINE_CNT 0x4234 # define R300_LINESIZE_SHIFT 0 # define R300_LINESIZE_MASK (0xFFFF << 0) /* GUESS */ @@ -522,23 +557,25 @@ I am fairly certain that they are correct unless stated otherwise in comments. #define R300_RE_FOG_START 0x4298 /* Not sure why there are duplicate of factor and constant values. - My best guess so far is that there are seperate zbiases for test and write. - Ordering might be wrong. - Some of the tests indicate that fgl has a fallback implementation of zbias - via pixel shaders. */ + * My best guess so far is that there are seperate zbiases for test and write. + * Ordering might be wrong. + * Some of the tests indicate that fgl has a fallback implementation of zbias + * via pixel shaders. + */ #define R300_RE_ZBIAS_T_FACTOR 0x42A4 #define R300_RE_ZBIAS_T_CONSTANT 0x42A8 #define R300_RE_ZBIAS_W_FACTOR 0x42AC #define R300_RE_ZBIAS_W_CONSTANT 0x42B0 /* This register needs to be set to (1<<1) for RV350 to correctly - perform depth test (see --vb-triangles in r300_demo) - Don't know about other chips. - Vladimir - This is set to 3 when GL_POLYGON_OFFSET_FILL is on. - My guess is that there are two bits for each zbias primitive (FILL, LINE, POINT). - One to enable depth test and one for depth write. - Yet this doesnt explain why depth writes work ... - */ + * perform depth test (see --vb-triangles in r300_demo) + * Don't know about other chips. - Vladimir + * This is set to 3 when GL_POLYGON_OFFSET_FILL is on. + * My guess is that there are two bits for each zbias primitive + * (FILL, LINE, POINT). + * One to enable depth test and one for depth write. + * Yet this doesnt explain why depth writes work ... + */ #define R300_RE_OCCLUSION_CNTL 0x42B4 # define R300_OCCLUSION_ON (1<<1) @@ -549,30 +586,37 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_FRONT_FACE_CW (1 << 2) -/* BEGIN: Rasterization / Interpolators - many guesses -// 0_UNKNOWN_18 has always been set except for clear operations. -// TC_CNT is the number of incoming texture coordinate sets (i.e. it depends -// on the vertex program, *not* the fragment program) */ +/* BEGIN: Rasterization / Interpolators - many guesses */ + +/* 0_UNKNOWN_18 has always been set except for clear operations. + * TC_CNT is the number of incoming texture coordinate sets (i.e. it depends + * on the vertex program, *not* the fragment program) + */ #define R300_RS_CNTL_0 0x4300 # define R300_RS_CNTL_TC_CNT_SHIFT 2 # define R300_RS_CNTL_TC_CNT_MASK (7 << 2) -# define R300_RS_CNTL_CI_CNT_SHIFT 7 /* number of color interpolators used */ + /* number of color interpolators used */ +# define R300_RS_CNTL_CI_CNT_SHIFT 7 # define R300_RS_CNTL_0_UNKNOWN_18 (1 << 18) -/* Guess: RS_CNTL_1 holds the index of the highest used RS_ROUTE_n register. */ + /* Guess: RS_CNTL_1 holds the index of the highest used RS_ROUTE_n + register. */ #define R300_RS_CNTL_1 0x4304 /* gap */ + /* Only used for texture coordinates. -// Use the source field to route texture coordinate input from the vertex program -// to the desired interpolator. Note that the source field is relative to the -// outputs the vertex program *actually* writes. If a vertex program only writes -// texcoord[1], this will be source index 0. -// Set INTERP_USED on all interpolators that produce data used by the -// fragment program. INTERP_USED looks like a swizzling mask, but -// I haven't seen it used that way. -// -// Note: The _UNKNOWN constants are always set in their respective register. -// I don't know if this is necessary. */ + * Use the source field to route texture coordinate input from the + * vertex program to the desired interpolator. Note that the source + * field is relative to the outputs the vertex program *actually* + * writes. If a vertex program only writes texcoord[1], this will + * be source index 0. + * Set INTERP_USED on all interpolators that produce data used by + * the fragment program. INTERP_USED looks like a swizzling mask, + * but I haven't seen it used that way. + * + * Note: The _UNKNOWN constants are always set in their respective + * register. I don't know if this is necessary. + */ #define R300_RS_INTERP_0 0x4310 #define R300_RS_INTERP_1 0x4314 # define R300_RS_INTERP_1_UNKNOWN 0x40 @@ -589,7 +633,8 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_RS_INTERP_USED 0x00D10000 /* These DWORDs control how vertex data is routed into fragment program -// registers, after interpolators. */ + * registers, after interpolators. + */ #define R300_RS_ROUTE_0 0x4330 #define R300_RS_ROUTE_1 0x4334 #define R300_RS_ROUTE_2 0x4338 @@ -611,8 +656,9 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_RS_ROUTE_DEST_MASK (31 << 6) /* GUESS */ /* Special handling for color: When the fragment program uses color, -// the ROUTE_0_COLOR bit is set and ROUTE_0_COLOR_DEST contains the -// color register index. */ + * the ROUTE_0_COLOR bit is set and ROUTE_0_COLOR_DEST contains the + * color register index. + */ # define R300_RS_ROUTE_0_COLOR (1 << 14) # define R300_RS_ROUTE_0_COLOR_DEST_SHIFT 17 # define R300_RS_ROUTE_0_COLOR_DEST_MASK (31 << 17) /* GUESS */ @@ -621,22 +667,24 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_RS_ROUTE_1_COLOR1_DEST_SHIFT 17 # define R300_RS_ROUTE_1_COLOR1_DEST_MASK (31 << 17) # define R300_RS_ROUTE_1_UNKNOWN11 (1 << 11) -/* END */ - -/* BEGIN: Scissors and cliprects -// There are four clipping rectangles. Their corner coordinates are inclusive. -// Every pixel is assigned a number from 0 and 15 by setting bits 0-3 depending -// on whether the pixel is inside cliprects 0-3, respectively. For example, -// if a pixel is inside cliprects 0 and 1, but outside 2 and 3, it is assigned -// the number 3 (binary 0011). -// Iff the bit corresponding to the pixel's number in RE_CLIPRECT_CNTL is set, -// the pixel is rasterized. -// -// In addition to this, there is a scissors rectangle. Only pixels inside the -// scissors rectangle are drawn. (coordinates are inclusive) -// -// For some reason, the top-left corner of the framebuffer is at (1440, 1440) -// for the purpose of clipping and scissors. */ +/* END: Rasterization / Interpolators - many guesses */ + +/* BEGIN: Scissors and cliprects */ + +/* There are four clipping rectangles. Their corner coordinates are inclusive. + * Every pixel is assigned a number from 0 and 15 by setting bits 0-3 depending + * on whether the pixel is inside cliprects 0-3, respectively. For example, + * if a pixel is inside cliprects 0 and 1, but outside 2 and 3, it is assigned + * the number 3 (binary 0011). + * Iff the bit corresponding to the pixel's number in RE_CLIPRECT_CNTL is set, + * the pixel is rasterized. + * + * In addition to this, there is a scissors rectangle. Only pixels inside the + * scissors rectangle are drawn. (coordinates are inclusive) + * + * For some reason, the top-left corner of the framebuffer is at (1440, 1440) + * for the purpose of clipping and scissors. + */ #define R300_RE_CLIPRECT_TL_0 0x43B0 #define R300_RE_CLIPRECT_BR_0 0x43B4 #define R300_RE_CLIPRECT_TL_1 0x43B8 @@ -670,6 +718,7 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_CLIP_3210 (1 << 15) /* gap */ + #define R300_RE_SCISSORS_TL 0x43E0 #define R300_RE_SCISSORS_BR 0x43E4 # define R300_SCISSORS_OFFSET 1440 @@ -677,12 +726,15 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_SCISSORS_X_MASK (0x1FFF << 0) # define R300_SCISSORS_Y_SHIFT 13 # define R300_SCISSORS_Y_MASK (0x1FFF << 13) -/* END */ +/* END: Scissors and cliprects */ -/* BEGIN: Texture specification -// The texture specification dwords are grouped by meaning and not by texture unit. -// This means that e.g. the offset for texture image unit N is found in register -// TX_OFFSET_0 + (4*N) */ +/* BEGIN: Texture specification */ + +/* + * The texture specification dwords are grouped by meaning and not by texture + * unit. This means that e.g. the offset for texture image unit N is found in + * register TX_OFFSET_0 + (4*N) + */ #define R300_TX_FILTER_0 0x4400 # define R300_TX_REPEAT 0 # define R300_TX_MIRRORED 1 @@ -706,13 +758,14 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_TX_MIN_FILTER_LINEAR_MIP_LINEAR (10 << 11) /* NOTE: NEAREST doesnt seem to exist. - Im not seting MAG_FILTER_MASK and (3 << 11) on for all - anisotropy modes because that would void selected mag filter */ -# define R300_TX_MIN_FILTER_ANISO_NEAREST ((0 << 13) /*|R300_TX_MAG_FILTER_MASK|(3<<11)*/) -# define R300_TX_MIN_FILTER_ANISO_LINEAR ((0 << 13) /*|R300_TX_MAG_FILTER_MASK|(3<<11)*/) -# define R300_TX_MIN_FILTER_ANISO_NEAREST_MIP_NEAREST ((1 << 13) /*|R300_TX_MAG_FILTER_MASK|(3<<11)*/) -# define R300_TX_MIN_FILTER_ANISO_NEAREST_MIP_LINEAR ((2 << 13) /*|R300_TX_MAG_FILTER_MASK|(3<<11)*/) -# define R300_TX_MIN_FILTER_MASK ( (15 << 11) | (3 << 13) ) + * Im not seting MAG_FILTER_MASK and (3 << 11) on for all + * anisotropy modes because that would void selected mag filter + */ +# define R300_TX_MIN_FILTER_ANISO_NEAREST (0 << 13) +# define R300_TX_MIN_FILTER_ANISO_LINEAR (0 << 13) +# define R300_TX_MIN_FILTER_ANISO_NEAREST_MIP_NEAREST (1 << 13) +# define R300_TX_MIN_FILTER_ANISO_NEAREST_MIP_LINEAR (2 << 13) +# define R300_TX_MIN_FILTER_MASK ( (15 << 11) | (3 << 13) ) # define R300_TX_MAX_ANISO_1_TO_1 (0 << 21) # define R300_TX_MAX_ANISO_2_TO_1 (2 << 21) # define R300_TX_MAX_ANISO_4_TO_1 (4 << 21) @@ -745,8 +798,8 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_TX_UNK23 (1 << 23) # define R300_TX_MAX_MIP_LEVEL_SHIFT 26 # define R300_TX_MAX_MIP_LEVEL_MASK (0xf << 26) -# define R300_TX_SIZE_PROJECTED (1<<30) -# define R300_TX_SIZE_TXPITCH_EN (1<<31) +# define R300_TX_SIZE_PROJECTED (1<<30) +# define R300_TX_SIZE_TXPITCH_EN (1<<31) #define R300_TX_FORMAT_0 0x44C0 /* The interpretation of the format word by Wladimir van der Laan */ /* The X, Y, Z and W refer to the layout of the components. @@ -774,7 +827,7 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_TX_FORMAT_A8R8G8B8 0x13 /* no swizzle */ # define R300_TX_FORMAT_B8G8_B8G8 0x14 /* no swizzle */ # define R300_TX_FORMAT_G8R8_G8B8 0x15 /* no swizzle */ - /* 0x16 - some 16 bit green format.. ?? */ + /* 0x16 - some 16 bit green format.. ?? */ # define R300_TX_FORMAT_UNK25 (1 << 25) /* no swizzle */ # define R300_TX_FORMAT_CUBIC_MAP (1 << 26) @@ -802,23 +855,26 @@ I am fairly certain that they are correct unless stated otherwise in comments. # define R300_TX_FORMAT_W 3 # define R300_TX_FORMAT_ZERO 4 # define R300_TX_FORMAT_ONE 5 -# define R300_TX_FORMAT_CUT_Z 6 /* 2.0*Z, everything above 1.0 is set to 0.0 */ -# define R300_TX_FORMAT_CUT_W 7 /* 2.0*W, everything above 1.0 is set to 0.0 */ + /* 2.0*Z, everything above 1.0 is set to 0.0 */ +# define R300_TX_FORMAT_CUT_Z 6 + /* 2.0*W, everything above 1.0 is set to 0.0 */ +# define R300_TX_FORMAT_CUT_W 7 # define R300_TX_FORMAT_B_SHIFT 18 # define R300_TX_FORMAT_G_SHIFT 15 # define R300_TX_FORMAT_R_SHIFT 12 # define R300_TX_FORMAT_A_SHIFT 9 /* Convenience macro to take care of layout and swizzling */ -# define R300_EASY_TX_FORMAT(B, G, R, A, FMT) (\ - ((R300_TX_FORMAT_##B)<