On Mon, Apr 9, 2012 at 9:13 PM, Eric Anholt <e...@anholt.net> wrote: > On Tue, 3 Apr 2012 14:16:52 +0100, Dave Airlie <airl...@gmail.com> wrote: >> From: Dave Airlie <airl...@redhat.com> >> >> This adds index support to the GLSL compiler. >> >> I'm not 100% sure of my approach here, esp without how output ordering >> happens wrt location, index pairs, in the "mark" function. >> >> Since current hw doesn't ever have a location > 0 with an index > 0, >> we don't have to work out if the output ordering the hw requires is >> location, index, location, index or location, location, index, index. >> But we have no hw to know, so punt on it for now. >> >> v2: index requires layout - catch and error >> setup explicit index properly. > > I don't like this magic 4 that's unexplained. It seems like the second > fragment output should have a totally separate ir_variable->location > assigned. Whether that's in a separate space like FRAG_RESULT_DUALSRC_0 > that comes after all the FRAG_RESULT_DATAn, or whether it's just > FRAG_RESULT_DATA1 since we're not anticipating dual source max buffers > going beyond 1, 4 doesn't seem like the right number.
Yeah the reason I left it all configurable was I wasn't sure how flexible we should leave the GLSL compiler. But I personally don't see hw with index > 1 and location > 0 unless index gets re-purposed for something else. I'll resend a smaller patch that just puts index after location. Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev