On 5 December 2011 14:53, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net">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 class="im">On Mon, 5 Dec 2011 09:40:45 -0800, Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> wrote:<br>
> Previously, the geometry shader program key was storing all the<br>
> information necessary to compute the exact structure of the VUE map<br>
> (attrs and userclip_active). However, the GS program doesn't depend<br>
> on the exact structure of the VUE map; only on the size (in 256-bit<br>
> registers) of the VUE. So we were recompiling the GS program<br>
> unnecessarily when the VUE map changed in structure but not in size.<br>
><br>
> This patch changes the key to store just the size of the VUE map, not<br>
> its structure.<br>
<br>
</div>Hmm. I'm betting that brw_compute_vue_map() is way more expensive than<br>
the extra couple bytes of key data to compare.<br></blockquote><div><br>True, but it's way less expensive than unnecessarily compiling (and uploading to the GPU) a brand new GS program that is identical to the one that's already there. That's what this patch is avoiding.<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><br>Yeah, me too. I'll write a follow-up patch that fixes that.<br>