[Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.

[Dave Airlie]

On Mon, Dec 19, 2011 at 5:39 PM, Brian Paul <brianp at vmware.com> wrote:
> On 12/19/2011 09:29 AM, Dave Airlie wrote:
>>
>> From: Dave Airlie<airlied at redhat.com>
>>
>> In the case where a front and back output are specified, the draw code
>> will
>> copy the back output into the front color slot and everything is happy.
>>
>> However if no front is specified then the draw code will do a bad copy
>> (separate patch), but also the frag shader won't pick up the color as there
>> there is
>> no write to COLOR from the vertex shader just BCOLOR.
>>
>> This patch fixes that problem so if it can't find a vertex shader output
>> for the front color slot, it will go and lookup and use one for the back
>> color
>> slot.
>>
>> Signed-off-by: Dave Airlie<airlied at redhat.com>
>> ---
>>  src/gallium/drivers/softpipe/sp_state_derived.c |    5 +++++
>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c
>> b/src/gallium/drivers/softpipe/sp_state_derived.c
>> index f89d23c..5685997 100644
>> --- a/src/gallium/drivers/softpipe/sp_state_derived.c
>> +++ b/src/gallium/drivers/softpipe/sp_state_derived.c
>> @@ -121,6 +121,11 @@ softpipe_get_vertex_info(struct softpipe_context
>> *softpipe)
>>           src = draw_find_shader_output(softpipe->draw,
>>                                         fsInfo->input_semantic_name[i],
>>                                         fsInfo->input_semantic_index[i]);
>> +        if (fsInfo->input_semantic_name[i] == TGSI_SEMANTIC_COLOR&&  src
>> == 0)
>>
>> +          /* try and find a bcolor */
>> +          src = draw_find_shader_output(softpipe->draw,
>> +                                        TGSI_SEMANTIC_BCOLOR,
>> fsInfo->input_semantic_index[i]);
>> +
>>           draw_emit_vertex_attr(vinfo, EMIT_4F, interp, src);
>>        }
>>
>
> And if the VS emits neither a front color or back color, what happens?

Well the same as happens now, which from what I can see is undefined.
Since if the
VS emits no colors and the FS expects a color, you have a problem, I'm
not sure if the
linker deals with this.

> It seems to me that if the VS doesn't emit a front color and the polygon
> ends up being front-facing, the polygon color is undefined.

Yes the test seems to not care about the value in the front in this case at all,
but maybe Ian or someone with more spec can say what the chapter/verse is.

Dave.