Browse Source

st/mesa: 'fix' point coord semantic info

This fixes the progs/glsl/pointcoord.c demo.  But this isn't a proper fix.
We really need a TGSI_SEMANTIC_POINT_COORD label so that the draw module
can determine which fragment input / vertex output slot needs to be set
up with the point coordinate info.  We've been using generic slot 0 so far.

This would also require telling the draw module about fragment shaders
(something it doesn't have at this time).
tags/7.8-rc1
Brian Paul 15 years ago
parent
commit
f1d544d6a6
1 changed files with 10 additions and 1 deletions
  1. 10
    1
      src/mesa/state_tracker/st_program.c

+ 10
- 1
src/mesa/state_tracker/st_program.c View File

@@ -325,6 +325,16 @@ st_translate_fragment_program(struct st_context *st,
stfp->input_semantic_index[slot] = 0;
interpMode[slot] = TGSI_INTERPOLATE_CONSTANT;
break;
case FRAG_ATTRIB_PNTC:
/* This is a hack. We really need a new semantic label for
* point coord. The draw module needs to know which fragment
* shader input is the point coord attribute so that it can set
* up the right vertex attribute values.
*/
stfp->input_semantic_name[slot] = TGSI_SEMANTIC_GENERIC;
stfp->input_semantic_index[slot] = 0;
interpMode[slot] = TGSI_INTERPOLATE_PERSPECTIVE;
break;

/* In most cases, there is nothing special about these
* inputs, so adopt a convention to use the generic
@@ -349,7 +359,6 @@ st_translate_fragment_program(struct st_context *st,
case FRAG_ATTRIB_TEX5:
case FRAG_ATTRIB_TEX6:
case FRAG_ATTRIB_TEX7:
case FRAG_ATTRIB_PNTC:
case FRAG_ATTRIB_VAR0:
default:
/* Actually, let's try and zero-base this just for

Loading…
Cancel
Save