On 5 December 2011 15:14, Paul Berry <span dir="ltr">&lt;<a href="mailto:stereotype441@gmail.com" target="_blank">stereotype441@gmail.com</a>&gt;</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 5 December 2011 14:53, Eric Anholt <span dir="ltr">&lt;<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>&gt;</span> wrote:<br></div><div class="gmail_quote"><br><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<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>
</blockquote></div></div><br>Yeah, me too.  I&#39;ll write a follow-up patch that fixes that.<br>
</blockquote></div><br>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?  Then we would be certain that computing the VUE map wasn&#39;t impacting drawing performance, because it would be outside the state atoms.  Also, we could stop keeping track of state changes that might affect the VUE map (e.g. currently gen6_sf_state has a non-obvious dependency on _NEW_TRANSFORM because ctx-&gt;Transform contains ClipPlanesEnabled, and that affects the VUE map).  Besides, link time just seems like the &quot;right&quot; time to compute the VUE map, since assigning locations to inputs and outputs is supposed to be part of what linking is all about. <br>
<br>The disadvantage would be that we would have to remove one optimization that&#39;s currently present in the code: currently, when user clipping is disabled, we save space in the VUE by repurposing the 2 clip distance slots as general-purpose vertex attributes.  I suspect it would be ok to lose this optimization because we currently waste 4 VUE slots on gen5, and to my knowledge we&#39;ve never identified that as a performance bottleneck.<br>
<br>Another argument in favor of this approach is that when we implement geometry shaders, we&#39;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&#39;s responsible for binding VS outputs to GS inputs, and GS outputs to FS inputs.<br>
<br>What do you think?<br>