I agree that this is a good idea. For the series:
Reviewed-by: Connor Abbott
On Fri, Mar 3, 2017 at 8:12 PM, Jason Ekstrand wrote:
> When NIR was first created, we were a bit lazy about numbers of components.
> The rule was that a source couldn't consume more components than the thing
> it was
On Friday, March 3, 2017 5:12:24 PM PST Jason Ekstrand wrote:
> When NIR was first created, we were a bit lazy about numbers of components.
> The rule was that a source couldn't consume more components than the thing
> it was reading from. However, this leads to a lot of confusion because you
> no
On Wed, Mar 8, 2017 at 4:56 PM, Eric Anholt wrote:
> Jason Ekstrand writes:
>
> > When NIR was first created, we were a bit lazy about numbers of
> components.
> > The rule was that a source couldn't consume more components than the
> thing
> > it was reading from. However, this leads to a lot
Jason Ekstrand writes:
> When NIR was first created, we were a bit lazy about numbers of components.
> The rule was that a source couldn't consume more components than the thing
> it was reading from. However, this leads to a lot of confusion because you
> now have a thing sourcing from a vec4 b
+correct connor
On Fri, Mar 3, 2017 at 5:12 PM, Jason Ekstrand wrote:
> When NIR was first created, we were a bit lazy about numbers of components.
> The rule was that a source couldn't consume more components than the thing
> it was reading from. However, this leads to a lot of confusion becau
When NIR was first created, we were a bit lazy about numbers of components.
The rule was that a source couldn't consume more components than the thing
it was reading from. However, this leads to a lot of confusion because you
now have a thing sourcing from a vec4 but only reading two of the
compon
