On Monday, July 11, 2016 1:19:34 PM PDT Samuel Iglesias Gonsálvez wrote: > > On 06/07/16 22:32, Kenneth Graunke wrote: > > On Wednesday, July 6, 2016 12:09:58 PM PDT Samuel Iglesias Gonsálvez wrote: > >> From: Iago Toral Quiroga <ito...@igalia.com> > >> > >> --- > >> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 6 +++--- > >> 1 file changed, 3 insertions(+), 3 deletions(-) > >> > >> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > >> b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > >> index 268c847..d805d95 100644 > >> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > >> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp > >> @@ -832,7 +832,7 @@ fs_visitor::nir_emit_alu(const fs_builder &bld, > >> nir_alu_instr *instr) > >> * a register and compare with that. > >> */ > >> fs_reg tmp = vgrf(glsl_type::double_type); > >> - bld.MOV(tmp, brw_imm_df(0.0)); > >> + bld.MOV(tmp, setup_imm_df(0.0)); > > > > Does this need to be splatted out to a full SIMD-width? > > Why not just do: > > > > fs_reg tmp = setup_imm_df(0.0); > > > > and let the CMP compare against the stride 0 register? > > > > I have just noticed this is not right. > > CMP will use the 64-bit immediate as one of the sources of the CMP, > which is not valid in gen8+. According to BDW+'s PRMs, an 64-bit > immediate is only valid in source values for instructions with single > source operands. > > I am going to keep the original patch. > > Sam
Ah, right, I missed that on Gen8+ setup_imm_df returns an actual immediate, rather than a GRF register with the immediate loaded into it. Feel free to ignore that suggestion.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
