From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [Intel-gfx] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE. Date: Mon, 30 Jul 2012 10:30:57 -0700 Message-ID: <87mx2hxijy.fsf@eliezer.anholt.net> References: <1341082215-22933-1-git-send-email-galibert@pobox.com> <1341082215-22933-2-git-send-email-galibert@pobox.com> <20120717085757.GB360@dspnet.fr> <20120729170037.GA3431@dspnet.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1489128909==" Return-path: In-Reply-To: <20120729170037.GA3431@dspnet.fr> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mesa-dev-bounces+gcvmd-mesa3d-493=gmane.org@lists.freedesktop.org Errors-To: mesa-dev-bounces+gcvmd-mesa3d-493=gmane.org@lists.freedesktop.org To: Olivier Galibert , Paul Berry Cc: mesa-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1489128909== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Olivier Galibert 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 situat= ion >> 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.=20 > > 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? >>=20 >> 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 =3D 0;" into the shader. This will guarantee that whenev= er >> gl_BackColor is written, gl_FrontColor is too. >>=20 >> 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. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlAWxNEACgkQHUdvYGzw6vdICwCZAX5Lxb2rn2CDRNPxqGAsK5QH yq0AoITu9IHFnUlsWOpvnBcCiLJz/JMS =hIWP -----END PGP SIGNATURE----- --=-=-=-- --===============1489128909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev --===============1489128909==--