Kenneth Graunke <kenn...@whitecape.org> writes: > On 03/20/2013 05:36 PM, Eric Anholt wrote: >> For sampler messages, it depends on the target gen, and on gen4 >> SIMD16-sampler-on-SIMD8-execution we were returning 4 instead of 8 like we >> should. >> >> NOTE: This is a candidate for the 9.1 branch. >> --- >> src/mesa/drivers/dri/i965/brw_fs.cpp | 29 >> +++++++------------- >> src/mesa/drivers/dri/i965/brw_fs.h | 2 +- >> src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 6 ++-- >> .../drivers/dri/i965/brw_fs_live_variables.cpp | 2 +- >> src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 8 +++--- >> .../dri/i965/brw_fs_schedule_instructions.cpp | 6 ++-- >> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 7 +++-- >> 7 files changed, 27 insertions(+), 33 deletions(-) > > Ugh...I'm not a huge fan of this, but I think it's better than the > alternative (which is passing "intel" into random functions to handle > the case you mentioned.) > > The reason I'm concerned is that we sometimes change the opcode of > instructions, and we'll need to make sure to update this too. But > that's probably fine. For CSE, you emit new instructions, rather than > editing it, so that works.
Yeah, I think it'll be safe because while we do sometimes change an opcode, it's hard to even imagine doing so in a way that would change the output size.
pgpUIdFRG5FyF.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
