<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 8, 2017 at 4:56 PM, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> writes:<br>
<br>
> When NIR was first created, we were a bit lazy about numbers of components.<br>
> The rule was that a source couldn't consume more components than the thing<br>
> it was reading from.  However, this leads to a lot of confusion because you<br>
> now have a thing sourcing from a vec4 but only reading two of the<br>
> components.<br>
><br>
> The solution to this is to disallow that case and require that the number<br>
> of components always match.  The one exception is ALU instructions because<br>
> they're designed to naturally swizzle things around like mad.  We already<br>
> require this restriction for phi instructions.  This series adds it for<br>
> intrinsics, texture instructions, and deref indirects.<br>
><br>
> Cc: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>><br>
> Cc: Connor Abbott <<a href="mailto:cwabbott0@gmaial.com">cwabbott0@gmaial.com</a>><br>
<br>
</span>Other than the comments I gave, and needing to land the lowering patch,<br>
this series is:<br>
<br>
Reviewed-by: Eric Anholt <<a href="mailto:eric@anholt.net">eric@anholt.net</a>><br>
</blockquote></div><br></div><div class="gmail_extra">Thanks!<br></div></div>