On 27 November 2015 at 18:33, Jason Ekstrand <ja...@jlekstrand.net> wrote:
>
> On Nov 27, 2015 10:21 AM, "Emil Velikov" <emil.l.veli...@gmail.com> wrote:
>>
>> On 27 November 2015 at 18:00, Jason Ekstrand <ja...@jlekstrand.net> wrote:
>> >
>> > On Nov 25, 2015 1:27 PM, "Emil Velikov" <emil.l.veli...@gmail.com>
>> > wrote:
>> >>
>> >> From: Emil Velikov <emil.veli...@collabora.com>
>> >>
>> >> ... alongside its C++ brethren. On the flip side the files are called
>> >> nir_types.{cpp,h} just because...
>> >
>> > It does do one NIR-specific thing: if you call glsl_get_length on a
>> > matrix,
>> > it gives you the number of columns. This probably isn't a huge deal
>> > though.
>> >
>> By "NIR-specific" I believe you mean "used solely by NIR" or am I
>> missing something ?
>
> I mean that GLSL IR and NIR treat matrices differently. NIR has no concept
> of a matrix but rather treats them as an array of vectors. GLSL IR treats
> matrices and vectors more-or-less the same; matrices just have more than one
> column. However, almost all C code that works with glsl_type is working with
> NIR so this shouldn't be a problem.
Ouch, this sounds like a nice subtlety which might need to keep an eye
for when doing the IR re-factoring/cleanups.
Thanks for that I wasn't aware of it.
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
