On Tue, 6 Dec 2011 09:19:15 -0800, Paul Berry <stereotype...@gmail.com> wrote: > On 5 December 2011 15:14, Paul Berry <stereotype...@gmail.com> wrote: > > > On 5 December 2011 14:53, Eric Anholt <e...@anholt.net> wrote: > > > > > >> What I really want is to compute the vue map at the top of the pipeline > >> and reuse it from the various places that want it. > >> > > > > Yeah, me too. I'll write a follow-up patch that fixes that. > > > > This morning I had an idea that I think I like even better: What if we > compute the VUE map at *link* time and store it with the compiled vertex > shader?
> Another argument in favor of this approach is that when we implement > geometry shaders, we're going to have to keep track of two separate VUE > layouts: one for data flowing from VS to GS, and another for the data > flowing from GS to the rest of the pipeline. The linker seems like the > right place to do that, since it's responsible for binding VS outputs to GS > inputs, and GS outputs to FS inputs. I like the general idea! The link-time plan is going to be tricky to handle today because we still have the fixed function VS and VP/FP, so we don't actually have linking happening on all the programs used for rendering. We could even keep the same userclip optimization and still do your idea to avoid vue_map per draw by just storing the two variants of VUE map in the VP. (I never eliminated the unused userclip SF slots on Ironlake because while I was experimenting with it I was also trying to fix the vertex flashing bug, and I meant to revisit that once I fixed it and never did. Sigh.)
pgpJ6T1ZoiQOY.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
