[Mesa-dev] [PATCH 02/10] i965 gs: Reduce information in key to avoid unnecessary recompiles.
Eric Anholt
eric at anholt.net
Tue Dec 6 11:43:35 PST 2011
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.
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.
(I never eliminated the unused userclip SF slots on Ironlake because
while I was experimenting with it I was also trying to fix the vertex
flashing bug, and I meant to revisit that once I fixed it and never did.
Sigh.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111206/ed807a93/attachment.pgp>
More information about the mesa-dev
mailing list