On Mon, 5 Dec 2011 20:01:52 -0800, Paul Berry <stereotype...@gmail.com> wrote: > 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?
Yeah, I just wanted to clarify what is generally true for thinking about performance in the driver: key setup is called many thousands of times more frequently than compile. (If compile happens after the first frame, something is usually broken).
pgpu6UZAVBMq0.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
