[Intel-gfx] [Mesa-dev] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE.
Eric Anholt
eric at anholt.net
Mon Jul 30 19:30:57 CEST 2012
Olivier Galibert <galibert at pobox.com> writes:
> 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 :/
I'm perfectly fine with the VUE containing slots for both when the app
has gone out of its way to ask for deprecated two-sided color
rendering.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120730/0711425c/attachment.sig>
More information about the Intel-gfx
mailing list