[Mesa-dev] [PATCH] nir: Add an IO scalarizing pass using the intrinsic's first_component.

[Jason Ekstrand]

On Aug 8, 2016 9:18 AM, "Eric Anholt" <eric at anholt.net> wrote:
>
> Timothy Arceri <timothy.arceri at collabora.com> writes:
>
> > On Sat, 2016-08-06 at 10:15 +1000, Timothy Arceri wrote:
> >> On Fri, 2016-08-05 at 16:27 -0700, Eric Anholt wrote:
> >> > vc4 wants to have per-scalar IO load/stores so that dead code
> >> > elimination
> >> > can happen on a more granular basis,
> >
> > Out of interest what is it exactly that you are doing in the backend?
>
> Given that all of my IO is done as indidivual moves of scalars (with the
> exception of the color output, which is weird but is lowered by vc4 code
> anyway), I'd like to see all the scalar ops for setting up
> undefined/unused scalar slots get dropped.  I don't see much change from
> this, because dead code is easy to eliminate, but I think there were
> small diffs.  It also makes the output more readable by cutting the
> pointless vector ops.
>
> However, doing my IO as scalar has been a bit of a pain for other
> passes: The UCP and twoside lowering want a single load/store for the
> vector.  Because of this, I've also wondered if using the write_mask and
> extending nir_opt_dce() for per-channel liveness would be a better way
> to go.

I would very much like to see dead code extended to channels anyway. :-)

> > I was looking at brw_do_vector_splitting() and it seems to me that
> > moving that out of the Intel backend and making it also work on
> > varyings could be benefical to all drivers as we could extend it to
> > work across stages which would hopefully also improve varying packing.
> >
> > Currently it says:
> >
> > "This skips vectors in uniforms and varyings, which need to be
> > accessible as vectors for their access by the GL."
> >
> > But that really only applies to vs inputs and the outward facing stages
> > of SSOs.
>
> Yeah, I think that comment is stale at this point.  But we have a lot of
> that pass in NIR already (ALU, const, io), and instead of extending the
> GLSL IR pass I'd rather see a NIR cross-linking pass.
>
> On the topic of cross-linking: Back in the day, i965 would look at the
> VS outputs and propagate constants into the FS inputs.  This was really
> painful, slow code to maintain, and we eventually just dropped it.
> However, if we know that a VS/FS pair are non-SSO, it seems like with
> NIR we could do that propagation really easily at link time.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160808/ef135211/attachment-0001.html>