[Mesa-dev] [PATCH 08/14] i965/fs: Initialize a builder explicitly in the gen4 send dependency work-arounds.

2015-07-28 Thread Francisco Jerez
Instead of relying on the default one. This shouldn't lead to any functional changes because DEP_RESOLVE_MOV overrides the execution controls of the instruction anyway. --- src/mesa/drivers/dri/i965/brw_fs.cpp | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/mes

Re: [Mesa-dev] [PATCH 08/14] i965/fs: Initialize a builder explicitly in the gen4 send dependency work-arounds.

2015-07-28 Thread Jason Ekstrand
On Tue, Jul 28, 2015 at 1:23 AM, Francisco Jerez wrote: > Instead of relying on the default one. This shouldn't lead to any > functional changes because DEP_RESOLVE_MOV overrides the execution > controls of the instruction anyway. Actually, DEP_RESOLVE_MOV calls half() on the builder which doesn

Re: [Mesa-dev] [PATCH 08/14] i965/fs: Initialize a builder explicitly in the gen4 send dependency work-arounds.

2015-07-29 Thread Francisco Jerez
Jason Ekstrand writes: > On Tue, Jul 28, 2015 at 1:23 AM, Francisco Jerez > wrote: >> Instead of relying on the default one. This shouldn't lead to any >> functional changes because DEP_RESOLVE_MOV overrides the execution >> controls of the instruction anyway. > > Actually, DEP_RESOLVE_MOV cal

Re: [Mesa-dev] [PATCH 08/14] i965/fs: Initialize a builder explicitly in the gen4 send dependency work-arounds.

2015-07-29 Thread Jason Ekstrand
On Jul 29, 2015 3:12 AM, "Francisco Jerez" wrote: > > Jason Ekstrand writes: > > > On Tue, Jul 28, 2015 at 1:23 AM, Francisco Jerez wrote: > >> Instead of relying on the default one. This shouldn't lead to any > >> functional changes because DEP_RESOLVE_MOV overrides the execution > >> controls

Re: [Mesa-dev] [PATCH 08/14] i965/fs: Initialize a builder explicitly in the gen4 send dependency work-arounds.

2015-07-29 Thread Francisco Jerez
Jason Ekstrand writes: > On Jul 29, 2015 3:12 AM, "Francisco Jerez" wrote: >> >> Jason Ekstrand writes: >> >> > On Tue, Jul 28, 2015 at 1:23 AM, Francisco Jerez > wrote: >> >> Instead of relying on the default one. This shouldn't lead to any >> >> functional changes because DEP_RESOLVE_MOV ov