On 5 December 2011 18:42, Eric Anholt <e...@anholt.net> wrote: > On Mon, 5 Dec 2011 15:14:13 -0800, Paul Berry <stereotype...@gmail.com> > wrote: > > On 5 December 2011 14:53, Eric Anholt <e...@anholt.net> wrote: > > > > > On Mon, 5 Dec 2011 09:40:45 -0800, Paul Berry < > stereotype...@gmail.com> > > > wrote: > > > > Previously, the geometry shader program key was storing all the > > > > information necessary to compute the exact structure of the VUE map > > > > (attrs and userclip_active). However, the GS program doesn't depend > > > > on the exact structure of the VUE map; only on the size (in 256-bit > > > > registers) of the VUE. So we were recompiling the GS program > > > > unnecessarily when the VUE map changed in structure but not in size. > > > > > > > > This patch changes the key to store just the size of the VUE map, not > > > > its structure. > > > > > > Hmm. I'm betting that brw_compute_vue_map() is way more expensive than > > > the extra couple bytes of key data to compare. > > > > > > > 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. > > That still happens a limited number of times, while key setup is per > drawing operation. And if you've got the same program code, you should > even end up associating the same instructions with the identical copies. >
So am I correct in assuming you're ok with this patch, provided that I do a follow-on patch that computes the vue map at the top of the pipeline, as previously discussed?
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
