> I've skipped 21 and 28 because I wanted to give a deeper look at the
> originals.
OK. Patches 21 and 28 are
Reviewed-by: Caio Marcelo de Oliveira Filho
Patch 12 seems a candidate to get in early. (It is R-B'ed in my
previous mail).
Thanks,
Caio
_
On Mon, Apr 9, 2018 at 6:20 PM, Jason Ekstrand wrote:
> On Mon, Apr 9, 2018 at 4:58 PM, Caio Marcelo de Oliveira Filho <
> caio.olive...@intel.com> wrote:
>
>> Hi,
>>
>> Given the fixes you already made based on my comments. Patches 1-20,
>> 22-27, 29-43, and 61 (multiview!) are
>>
>> Reviewed-by
On Mon, Apr 9, 2018 at 4:58 PM, Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> Hi,
>
> Given the fixes you already made based on my comments. Patches 1-20,
> 22-27, 29-43, and 61 (multiview!) are
>
> Reviewed-by: Caio Marcelo de Oliveira Filho
>
> Patches 46-47 and 49 seem to
Hi,
Given the fixes you already made based on my comments. Patches 1-20,
22-27, 29-43, and 61 (multiview!) are
Reviewed-by: Caio Marcelo de Oliveira Filho
Patches 46-47 and 49 seem to be valid regardless the rest of the code,
so I'd consider getting them in independently. They are also R-b'ed.
On Tue, Apr 3, 2018 at 2:32 PM, Jason Ekstrand wrote:
> This is something that Connor and I have been talking about for some time
> now. The basic idea is to replace the current singly linked nir_deref list
> with deref instructions. This is similar to what LLVM does and it offers
> quite a bit
I ran shader-db on the whole series and this is what I got on KBL:
total instructions in shared programs: 15201981 -> 15231264 (0.19%)
instructions in affected programs: 315139 -> 344422 (9.29%)
helped: 33
HURT: 1253
This should by and large be a no-op but clearly something is amiss. I'll
take a
This is something that Connor and I have been talking about for some time
now. The basic idea is to replace the current singly linked nir_deref list
with deref instructions. This is similar to what LLVM does and it offers
quite a bit more freedom when we start getting more realistic pointers from
