Hi, I as well would prefer to bee more certain.
I still need to confirm R300_VAP_OUTPUT_VTX_FMT_0__PT_SIZE_PRESENT. When i have some more time i while cook up some code to exercise thees outputs. But if someone already has some code it would bee nice. Some testing on other ati cards than my X700 PCIE with some different apps would bee nice. Oliver McFadden skrev: > Hi, > > I would prefer if we could confirm the R300_VAP_OUTPUT_VTX_FMT_0 bits > before > merging this patch... > > Although r300_reg.h does mark many of the bits as guesses, so I'm not > apposed to > committing this patch now and figuring out all the bits later. As long > as you > have confirmed that the bits you have changed are correct. > > > On 6/10/07, Tommy Schultz Lassen <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Here is a new version of Back face color. It also enables FOGC out. >> >> VERT_RESULT_BFC1 >> VERT_RESULT_PSIZ >> VERT_RESULT_COL1 >> >> is pure guess work. If some one has a example that exercise some of >> those that wot help mi. >> >> VERT_RESULT_BFC0 >> >> That is the only value where i can get Back faced to work for the >> moment. >> >> VERT_RESULT_FOGC >> >> That is the value where it seems to work for the moment. I have some >> indications that it is actually dependent on the the index used in >> r300_vertprog.c t_dst_index. >> >> Cut it bee that r300VAPOutputCntl0 and r300VAPOutputCntl1 depends on the >> values set in r300_vertprog.c t_dst_index? >> >> >> >> >> >> Oliver McFadden skrev: >> > Hi, >> > >> > I think something is wrong with the >> > R300_VAP_OUTPUT_VTX_FMT_0__COLOR_2_PRESENT >> > change you made. You changed this to (1 << 16) however this would >> > correspond to >> > the R300_VAP_OUTPUT_VTX_FMT_0__PT_SIZE_PRESENT define. >> > >> > So either your change is incorrect, or the defines for >> > R300_VAP_OUTPUT_VTX_FMT_0 >> > are incorrect. It wouldn't surprise me if some of the bits for this >> > register are >> > not correct; as far as I know the driver hasn't previously supported >> > back-facing >> > color, so these bits may have been guessed based on the standard color >> > bit. >> > >> > I don't think it would be hard to write some OpenGL code for revenge >> > (my reverse >> > engineering tool) to test these bits, though. >> > >> > >> > On 6/8/07, Tommy Schultz Lassen <[EMAIL PROTECTED]> wrote: >> >> Hi Oliver >> >> >> >> I got the checker board shown in wave :). The problem seems to bee >> >> missing VERT_RESULT_BFC0. >> >> >> >> I have attached a patch that gets VERT_RESULT_BFC0 a step closer. >> >> >> >> There is a couple of problems: >> >> >> >> 1) This patch makes the driver do state changes allot. >> >> >> >> 2) I fink there is something more basic wrong wit how wee handle >> >> VERT_RESULT. >> >> >> >> How do the chip now that the reg wee set in r300TranslateVertexShader >> >> with code like: >> >> >> >> vp->outputs[VERT_RESULT_BFC0] = cur_reg++; >> >> >> >> is for VERT_RESULT_BFC0. >> >> >> >> >> >> Any insights? >> >> >> >> >> >> The patch makes the tube in fog look read instead of green. NWN >> looks as >> >> it has for some time. OK but with weird colors on cloaks an some >> >> monsters. >> >> >> >> I am going to keep looking. >> >> >> >> /Tommy >> >> >> >> ------------------------------------------------------------------------- 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/ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
