This one should bee a little better. The last one did dent set the reg
correct for COL0 if wee don't have one.
Tommy Schultz Lassen skrev:
> :-) Nov with patch :-)
>
> Oliver McFadden skrev:
>
>> Uhh... did you forget to attach the patch?
>>
>>
>> On 7/13/07, Tommy Schultz Lassen <[EMAIL PROTECTED]> wrote:
>>
>>> Could you trey this patch.
>>>
>>> It makes a couple of changes/fixes i found via dumps of COL0, COL1,
>>> BFC0, BFC1 in some different combinations. I also disablet PSIZ for the
>>> moment. I don't know how to set it correctly but i am quit cirten it is
>>> wrong at the moment.
>>>
>>> Is it possible for you to send me a example that dose the flickering. I
>>> would like to fix it but it would bee esier if i where able to see the
>>> problem.
>>>
>>>
>>> Oliver McFadden skrev:
>>>
>>>> Oh, just realized I already sent you that one. I forgot I did that.
>>>>
>>>>
>>>> On 7/13/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> I have a patch that will work around the flickering by restoring
>>>>>
>>> the old
>>>
>>>>> output
>>>>> handling in r300_vertprog.c.
>>>>>
>>>>> On 7/13/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> I've reverted the off-by-one commit, but your patch doesn't fix my
>>>>>> flickering
>>>>>> problems... I'm not sure why that is happening.
>>>>>>
>>>>>>
>>>>>> On 7/13/07, Tommy Schultz Lassen <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>> 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
>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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_emit.c b/src/mesa/drivers/dri/r300/r300_emit.c
index 424bf44..98a5c87 100644
--- a/src/mesa/drivers/dri/r300/r300_emit.c
+++ b/src/mesa/drivers/dri/r300/r300_emit.c
@@ -293,8 +293,7 @@ GLuint r300VAPOutputCntl0(GLcontext * ctx, GLuint OutputsWritten)
if (OutputsWritten & (1 << VERT_RESULT_HPOS))
ret |= R300_VAP_OUTPUT_VTX_FMT_0__POS_PRESENT;
- if (OutputsWritten & (1 << VERT_RESULT_COL0))
- ret |= R300_VAP_OUTPUT_VTX_FMT_0__COLOR_PRESENT;
+ ret |= R300_VAP_OUTPUT_VTX_FMT_0__COLOR_PRESENT; // Wee always have color0 enabled.
if (OutputsWritten & (1 << VERT_RESULT_COL1))
ret |= R300_VAP_OUTPUT_VTX_FMT_0__COLOR_1_PRESENT;
@@ -308,10 +307,10 @@ GLuint r300VAPOutputCntl0(GLcontext * ctx, GLuint OutputsWritten)
#if 0
if (OutputsWritten & (1 << VERT_RESULT_FOGC)) ;
-#endif
if (OutputsWritten & (1 << VERT_RESULT_PSIZ))
ret |= R300_VAP_OUTPUT_VTX_FMT_0__PT_SIZE_PRESENT;
+#endif
return ret;
}
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
@@ -1471,13 +1471,10 @@ static void r300SetupRSUnit(GLcontext * ctx)
}
if (InputsRead & FRAG_BIT_COL0) {
- if (R300_OUTPUTS_WRITTEN_TEST(OutputsWritten, VERT_RESULT_COL0, _TNL_ATTRIB_COLOR0)) {
- r300->hw.rr.cmd[R300_RR_ROUTE_0] |= 0 | R300_RS_ROUTE_0_COLOR | (fp_reg++ << R300_RS_ROUTE_0_COLOR_DEST_SHIFT);
- InputsRead &= ~FRAG_BIT_COL0;
- col_interp_nr++;
- } else {
- WARN_ONCE("fragprog wants col0, vp doesn't provide it\n");
- }
+ // Wee always have COL0 in vertex program output.
+ r300->hw.rr.cmd[R300_RR_ROUTE_0] |= 0 | R300_RS_ROUTE_0_COLOR | (fp_reg++ << R300_RS_ROUTE_0_COLOR_DEST_SHIFT);
+ InputsRead &= ~FRAG_BIT_COL0;
+ col_interp_nr++;
}
if (InputsRead & FRAG_BIT_COL1) {
@@ -1498,9 +1495,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);
diff --git a/src/mesa/drivers/dri/r300/r300_vertprog.c b/src/mesa/drivers/dri/r300/r300_vertprog.c
index 60f151c..356ab02 100644
--- a/src/mesa/drivers/dri/r300/r300_vertprog.c
+++ b/src/mesa/drivers/dri/r300/r300_vertprog.c
@@ -455,7 +455,7 @@ static void r300TranslateVertexShader(struct r300_vertex_program *vp,
if (vp->key.OutputsWritten & (1 << VERT_RESULT_BFC0)) {
vp->outputs[VERT_RESULT_BFC0] = 3;
- cur_reg = 4;
+ cur_reg = 5; // (It seems tat the engien only sees if back coloring is enabled or not. 5 if enabled else 2 og 3)
}
if (vp->key.OutputsWritten & (1 << VERT_RESULT_BFC1)) {
@@ -465,10 +465,10 @@ static void r300TranslateVertexShader(struct r300_vertex_program *vp,
#if 0 /* Not supported yet */
if (vp->key.OutputsWritten & (1 << VERT_RESULT_FOGC))
vp->outputs[VERT_RESULT_FOGC] = cur_reg++;
-#endif
if (vp->key.OutputsWritten & (1 << VERT_RESULT_PSIZ))
vp->outputs[VERT_RESULT_PSIZ] = cur_reg++;
+#endif
for (i = VERT_RESULT_TEX0; i <= VERT_RESULT_TEX7; i++)
if (vp->key.OutputsWritten & (1 << i)) {
@@ -1054,6 +1054,22 @@ static void r300TranslateVertexShader(struct r300_vertex_program *vp,
}
next:;
}
+ if (!(vp->key.OutputsWritten & (1 << VERT_RESULT_COL0))) {
+ src[2].File = PROGRAM_TEMPORARY;
+ src[2].Index = u_temp_i;
+ src[2].RelAddr = 0;
+ u_temp_i--;
+ // Wee need COL0 in vertex program output
+ o_inst->op =
+ MAKE_VSF_OP(R300_VPI_OUT_OP_ADD, u_temp_i,
+ VSF_FLAG_ALL,
+ VSF_OUT_CLASS_TMP);
+
+ o_inst->src[0] = ZERO_SRC_2;
+ o_inst->src[1] = ZERO_SRC_2;
+ o_inst->src[2] = ZERO_SRC_2;
+ o_inst++;
+ }
/* Will most likely segfault before we get here... fix later. */
if (o_inst - vp->program.body.i >= VSF_MAX_FRAGMENT_LENGTH / 4) {
-------------------------------------------------------------------------
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
