On 06/09/2014 05:34 PM, Robert Bragg wrote:
> Hey Tapani,
>
> I came across this issue the other day too and can at least confirm
> that I wrote an almost identical patch.
>
> I was a bit unsure whether this was the best place to fix this issue
> since it seems a bit unobvious, in isolation, why we
On Mon, Jun 9, 2014 at 2:30 AM, Tapani Pälli wrote:
> Commit 07af0ab changed fs_inst to have 0 sources for texture opcodes
> in emit_texture_gen5 (Ironlake, Sandybrige) while fs_generator still
> uses a single source from brw_reg struct. Patch sets src as reg_undef
> which matches the behavior bef
Hey Tapani,
I came across this issue the other day too and can at least confirm
that I wrote an almost identical patch.
I was a bit unsure whether this was the best place to fix this issue
since it seems a bit unobvious, in isolation, why we emit these
texture ops with a place holder register, bu
On Mon, Jun 09, 2014 at 12:30:55PM +0300, Tapani P?lli wrote:
> Commit 07af0ab changed fs_inst to have 0 sources for texture opcodes
> in emit_texture_gen5 (Ironlake, Sandybrige) while fs_generator still
> uses a single source from brw_reg struct. Patch sets src as reg_undef
> which matches the beh
Commit 07af0ab changed fs_inst to have 0 sources for texture opcodes
in emit_texture_gen5 (Ironlake, Sandybrige) while fs_generator still
uses a single source from brw_reg struct. Patch sets src as reg_undef
which matches the behavior before the constructor got changed.
Signed-off-by: Tapani Pälli
