Olivier Galibert <galib...@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.
pgp2BRFPESEft.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
