I fink i have found the problem. The binary drivers sets R300_RS_CNTL_0
to 0x40100 in stead of 0x40080.

Here is a patch that fixes that.

Your comit 07ac2386f5c0ab9c2432d4b5e3490b1e13d033fc seems to bee wrong(I
had it set the same way at first). When backface coloring is enabled the
start reg for tex needs to bee 5. There is problems with textures in
sample/logo and wave with that commit.

NB: Du you know what R300_VAP_PVS_CNTL_1 is used for. The binary drivers
sets it to 0x500c00. Instead of 0x400c00.


Oliver McFadden skrev:
> Actually perhaps a more accurate description is random flickering of the
> triangles. They seem to flicker white for a second.
>
> I checked the old code against the new code, too.
>
> old = 0x000003f1 new = 0x000003f3
>
> So the new code sets an extra bit.
>
>
> On 7/12/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
>> I just found that there seem to be some bugs with output routing
>> now... With
>> my
>> engine I would see some random colors appear on the rendered tris.
>>
>> I've made a patch to restore the old behaviour but this would break
>> BFC so
>> we
>> should really fix it properly. It probably affects other OpenGL programs
>> too.
>>
>> On 7/11/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
>> > I did some more testing and removing any one of the PRESENT bits
>> breaks
>> the
>> > wave
>> > and fog demos.
>> >
>> > I assume that those demos don't actually use all 3 colors but
>> rather the
>> > hardware must enable all or none...
>> >
>> > So assuming this is correct, fixing BFC1 should be pretty easy... just
>> > enable
>> > all 3 bits like for BFC0.
>> >
>> > Let me know if you find out anything more. :-)
>> >
>> >
>> > On 7/11/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
>> > > I just looked at the R300_VAP_OUTPUT_VTX_FMT_0 bits some more and
>> found
>> > the
>> > > following:
>> > >
>> > > (7 << 2) == R300_VAP_OUTPUT_VTX_FMT_0__COLOR_1_PRESENT |
>> > >             R300_VAP_OUTPUT_VTX_FMT_0__COLOR_2_PRESENT |
>> > >             R300_VAP_OUTPUT_VTX_FMT_0__COLOR_3_PRESENT;
>> > >
>> > > So maybe for back facing color we must enable all those bits at
>> once;
>> the
>> > > hardware might not allow them to be set individually?
>> > >
>> > > I'll do some more testing on this now.
>> > >
>> > >
>> > > On 7/11/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
>> > > > Okay. I'll push the current changes now and I can commit further
>> changes
>> > > > when
>> > > > you find the bits for BFC1 and FOGC. :-) I verified that
>> > progs/samples/fog
>> > > > and
>> > > > wave are working now.
>> > > >
>> > > > I'm glad to hear that Revenge is being useful, and great work
>> on these
>> > > > patches
>> > > > btw. :-)
>> > > >
>> > > >
>> > > > On 7/11/07, Tommy Schultz Lassen <[EMAIL PROTECTED]> wrote:
>> > > > > Hi,
>> > > > >
>> > > > > I would guess that as well. But i am not cirtan.
>> > > > >
>> > > > > I am going to trey to make some more dumps to try to figure out
>> COL1,
>> > > > > BFC1 and FOGC.
>> > > > >
>> > > > > Mvh Tommy
>> > > > >
>> > > > > Oliver McFadden skrev:
>> > > > > > Hi,
>> > > > > >
>> > > > > > The patch looks good to me. :-) I'll commit it to my local
>> tree
>> and
>> > do
>> > > > > > some
>> > > > > > testing.
>> > > > > >
>> > > > > > Btw, I see in r300_emit.c:r300VAPOutputCntl0 you've changed
>> the
>> bits
>> > > > > > for BFC0
>> > > > > > but I wonder if we should change BFC1, too. I would guess
>> based on
>> > > > > > BFC0 that
>> > > > > > BFC1 should be (8 << 2)?
>> > > > > >
>> > > > > >
>> > > > > > On 7/11/07, Tommy Schultz Lassen <[EMAIL PROTECTED]> wrote:
>> > > > > >> Hi,
>> > > > > >>
>> > > > > >> Here is a new patch for enabling Back face coloring.
>> > > > > >>
>> > > > > >> It is parts information from revenge dumps and parts
>> guesswork.
>> > > > > >>
>> > > > > >> It also fixes a bug in r300FrontFace or rather
>> r300UpdateCulling.
>> > It
>> > > > > >> would only set GL_CW og GL_CCW if wee set some culling.
>> > > > > >>
>> > > > > >> This patch gets wave and fog forking for me.
>> > > > > >>
>> > > > > >> /Tommy
>> > > > > >>
>> > > > > >> Tommy Schultz Lassen skrev:
>> > > > > >> > 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
>> > > > > >> >
>> > > > > >>
>> > > > > >>
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>


diff --git a/src/mesa/drivers/dri/r300/r300_state.c b/src/mesa/drivers/dri/r300/r300_state.c
index 48d92da..6dde941 100644
--- a/src/mesa/drivers/dri/r300/r300_state.c
+++ b/src/mesa/drivers/dri/r300/r300_state.c
@@ -1498,9 +1498,16 @@ static void r300SetupRSUnit(GLcontext * ctx)
 		col_interp_nr++;
 	}
 
-	r300->hw.rc.cmd[1] = 0 | (in_texcoords << R300_RS_CNTL_TC_CNT_SHIFT)
-	    | (col_interp_nr << R300_RS_CNTL_CI_CNT_SHIFT)
-	    | R300_RS_CNTL_0_UNKNOWN_18;
+	if(R300_OUTPUTS_WRITTEN_TEST(OutputsWritten, VERT_RESULT_BFC0, -1) ||
+	   R300_OUTPUTS_WRITTEN_TEST(OutputsWritten, VERT_RESULT_BFC1, -1)){
+		r300->hw.rc.cmd[1] = 0 | (in_texcoords << R300_RS_CNTL_TC_CNT_SHIFT)
+		    | (col_interp_nr << (R300_RS_CNTL_CI_CNT_SHIFT+1))
+		    | R300_RS_CNTL_0_UNKNOWN_18;
+	}else{
+		r300->hw.rc.cmd[1] = 0 | (in_texcoords << R300_RS_CNTL_TC_CNT_SHIFT)
+		    | (col_interp_nr << R300_RS_CNTL_CI_CNT_SHIFT)
+		    | R300_RS_CNTL_0_UNKNOWN_18;
+	}
 
 	assert(high_rr >= 0);
 	r300->hw.rr.cmd[R300_RR_CMD_0] = cmdpacket0(R300_RS_ROUTE_0, high_rr + 1);

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

Reply via email to