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

[Eric Anholt]

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 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160808/6c2705fa/attachment.sig>