On Aug 8, 2016 9:18 AM, "Eric Anholt" <<a href="mailto:eric@anholt.net">eric@anholt.net</a>> wrote: > > Timothy Arceri <<a href="mailto:timothy.arceri@collabora.com">timothy.arceri@collabora.com</a>> 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 > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> >