[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:49 PM, Dave Airlie <airlied at gmail.com> wrote:
> 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.
>

GLSL 1.30 7.6 says

"The following built-in vertex output variables are available. A
particular one should be written to if any
functionality in a corresponding fragment shader or fixed pipeline
uses it or state derived from it.
Otherwise, behavior is undefined."

where it defines the front/back builtins.

Dave.