[Mesa-dev] [PATCH 02/10] i965 gs: Reduce information in key to avoid unnecessary recompiles.

[Paul Berry]

On 6 December 2011 11:43, Eric Anholt <eric at anholt.net> wrote:

> On Tue, 6 Dec 2011 09:19:15 -0800, Paul Berry <stereotype441 at gmail.com>
> wrote:
> > On 5 December 2011 15:14, Paul Berry <stereotype441 at gmail.com> wrote:
> >
> > > On 5 December 2011 14:53, Eric Anholt <eric at anholt.net> wrote:
> > >
> > >
> > >> What I really want is to compute the vue map at the top of the
> pipeline
> > >> and reuse it from the various places that want it.
> > >>
> > >
> > > Yeah, me too.  I'll write a follow-up patch that fixes that.
> > >
> >
> > 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?
>
> > Another argument in favor of this approach is that when we implement
> > geometry shaders, we'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's responsible for binding VS outputs to
> GS
> > inputs, and GS outputs to FS inputs.
>
> I like the general idea!
>
> The link-time plan is going to be tricky to handle today because we
> still have the fixed function VS and VP/FP, so we don't actually have
> linking happening on all the programs used for rendering.
>
>
Ugh.  Yeah, that's going to be tricky.


> We could even keep the same userclip optimization and still do your idea
> to avoid vue_map per draw by just storing the two variants of VUE map in
> the VP.
>
>
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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111206/3050b2b4/attachment.html>