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

Paul Berry stereotype441 at gmail.com
Tue Dec 6 09:19:15 PST 2011


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?  Then we would be certain that computing the VUE map wasn't
impacting drawing performance, because it would be outside the state
atoms.  Also, we could stop keeping track of state changes that might
affect the VUE map (e.g. currently gen6_sf_state has a non-obvious
dependency on _NEW_TRANSFORM because ctx->Transform contains
ClipPlanesEnabled, and that affects the VUE map).  Besides, link time just
seems like the "right" time to compute the VUE map, since assigning
locations to inputs and outputs is supposed to be part of what linking is
all about.

The disadvantage would be that we would have to remove one optimization
that's currently present in the code: currently, when user clipping is
disabled, we save space in the VUE by repurposing the 2 clip distance slots
as general-purpose vertex attributes.  I suspect it would be ok to lose
this optimization because we currently waste 4 VUE slots on gen5, and to my
knowledge we've never identified that as a performance bottleneck.

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.

What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111206/a71585df/attachment.htm>


More information about the mesa-dev mailing list