On 6 December 2011 11:43, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>On Tue, 6 Dec 2011 09:19:15 -0800, Paul Berry <<a href="mailto:stereotype441@gmail.com" target="_blank">stereotype441@gmail.com</a>> wrote:<br> > On 5 December 2011 15:14, Paul Berry <<a href="mailto:stereotype441@gmail.com" target="_blank">stereotype441@gmail.com</a>> wrote:<br> ><br> > > On 5 December 2011 14:53, Eric Anholt <<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>> wrote:<br> > ><br> > ><br> > >> What I really want is to compute the vue map at the top of the pipeline<br> > >> and reuse it from the various places that want it.<br> > >><br> > ><br> > > Yeah, me too. I'll write a follow-up patch that fixes that.<br> > ><br> ><br> > This morning I had an idea that I think I like even better: What if we<br> > compute the VUE map at *link* time and store it with the compiled vertex<br> > shader?<br> <br> </div><div>> Another argument in favor of this approach is that when we implement<br> > geometry shaders, we're going to have to keep track of two separate VUE<br> > layouts: one for data flowing from VS to GS, and another for the data<br> > flowing from GS to the rest of the pipeline. The linker seems like the<br> > right place to do that, since it's responsible for binding VS outputs to GS<br> > inputs, and GS outputs to FS inputs.<br> <br> </div>I like the general idea!<br> <br> The link-time plan is going to be tricky to handle today because we<br> still have the fixed function VS and VP/FP, so we don't actually have<br> linking happening on all the programs used for rendering.<br> <br></blockquote><div><br>Ugh. Yeah, that's going to be tricky.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> We could even keep the same userclip optimization and still do your idea<br> to avoid vue_map per draw by just storing the two variants of VUE map in<br> the VP.<br> <br></blockquote><div><br>Yeah, I thought about that too, although it feels like a lot of unnecessary complexity to preserve an optimization that was probably never necessary in the first place. <br><br>On further reflection, I guess any time we compute the VUE map for the purposes of generating code is ok (e.g. for generating a VS, GS, clip, or SF program) because the cache will ensure that we don't waste time computing it every frame. In point of fact, those uses of the VUE map wouldn't benefit much from computing it ahead of time, since they still need to have everything the VUE map depends on in their cache keys. So the only real problem (before this patch) is in gen{6,7}_sf_state.c, where we compute the VUE map every time we emit a _3DSTATE_SF batch.<br> <br>At this point I'm tempted to drop this patch entirely (and the idea of precomputing the VUE map), and instead have brw_vs_prog store the VUE map in brw->vs.prog_data, where gen{6,7}_sf_state.c can examine it later. This would be safe, since for obvious reasons gen{6,7}_sf_state already depends on CACHE_NEW_VS_PROG. That would neatly address all the concerns we've been talking about in this thread.<br> </div></div>