On Tue, May 17, 2016 at 12:24 PM, Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > On Mon, May 16, 2016 at 9:22 PM, Francisco Jerez
> > wrote:
> >
> >> This seems cleaner than exposing an implementation detail of
> >> brw_fs_reg_allocate.cpp to the world, and will give the caller control
>
Jason Ekstrand writes:
> On Mon, May 16, 2016 at 9:22 PM, Francisco Jerez
> wrote:
>
>> This seems cleaner than exposing an implementation detail of
>> brw_fs_reg_allocate.cpp to the world, and will give the caller control
>> over the instruction execution flags (e.g. force_writemask_all) that
>
On Mon, May 16, 2016 at 9:22 PM, Francisco Jerez
wrote:
> This seems cleaner than exposing an implementation detail of
> brw_fs_reg_allocate.cpp to the world, and will give the caller control
> over the instruction execution flags (e.g. force_writemask_all) that
> are applied to the scratch read
This seems cleaner than exposing an implementation detail of
brw_fs_reg_allocate.cpp to the world, and will give the caller control
over the instruction execution flags (e.g. force_writemask_all) that
are applied to the scratch read and write instructions.
---
src/mesa/drivers/dri/i965/brw_fs.h
