On Mon, Dec 19, 2011 at 5:49 PM, Dave Airlie <airl...@gmail.com> wrote: > On Mon, Dec 19, 2011 at 5:39 PM, Brian Paul <bri...@vmware.com> wrote: >> On 12/19/2011 09:29 AM, Dave Airlie wrote: >>> >>> From: Dave Airlie<airl...@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<airl...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev