[Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.
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); } -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.
On 12/19/2011 09:29 AM, Dave Airlie wrote: From: Dave Airlieairl...@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 Airlieairl...@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? 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. Off-hand I don't recall what the GL/GLSL specs say about this. What is the piglit test expecting? -Brain ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.
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 Airlieairl...@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 Airlieairl...@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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.
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 Airlieairl...@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 Airlieairl...@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
