[Mesa-dev] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE.

[Olivier Galibert]

On Tue, Jul 17, 2012 at 07:37:43AM -0700, Paul Berry wrote:
> If possible, I would still like to think of a way to address this situation
> that (a) doesn't require modifying both fragment shader back-ends and the
> SF program, and (b) helps all Mesa drivers, not just Intel Gen4-5.
> Especially because I suspect we may have bugs in Gen6-7 related to this
> situation. 

You don't :-) It's correctly handled in
gen6_sf_state.c::get_attr_override with similar semantics too.

> Would you be happy with one of the following two alternatives?
> 
> 1. In the GLSL front-end, if we detect that a vertex shader writes to
> gl_BackColor but not gl_FrontColor, then automatically insert
> "gl_FrontColor = 0;" into the shader.  This will guarantee that whenever
> gl_BackColor is written, gl_FrontColor is too.
> 
> 2. In the function brw_compute_vue_map(), assign a VUE slot for
> VERT_RESULT_COL0 whenever *either* VERT_RESULT_COL0 or VERT_RESULT_BFC0 is
> used.  This will guarantee that we always have a VUE slot available for
> front color, so we don't have to be as tricky in the FS and SF code.

With both methods the SF code is not really simplified.  Doing the mov
without testing would require writing to/reserving a slot for
gl_BackColor if gl_FrontColor is written to, which wouldn't be
acceptable.  And to write to/reserve a slot for the two of them if
gl_Color is read in any case.  Probably unacceptable.  So the need_*
stuff is going to stay in any case :/

So the only simplification would be in the fs/wm and I'm somewhat
afraid of having a vue slot that's not in outputs_written of the
previous stage.  They seem to be expected equivalent.

> This morning I'll try to ask some other Intel folks for their opinion on
> the subject.

Did they have an opinion?

Best,

  OG.