On Sat, Sep 20, 2014 at 10:23 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 24
> +++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
> index f3f6ef4..f0b118f 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
> @@ -472,6 +472,30 @@ fs_visitor::assign_regs(bool allow_spilling)
> if (brw->gen >= 7)
> setup_mrf_hack_interference(g, first_mrf_hack_node);
>
> + if (dispatch_width > 8) {
> + /* In 16-wide dispatch we have an issue where a compressed
> + * instruction is actually two instructions executed simultaneiously.
simultaneously
> + * It's actually ok to have the source and destination registers be
> + * the same. In this case, each instruction over-writes its own
> + * source and there's no problem. The real problem here is if the
> + * source and destination registers are off by one. Then you can end
> + * up in a scenario where the first instruction over-writes the
> + * source of the second instruction. Since the compiler doesn't know
> + * about this level of granularity, we simply make the source and
> + * destination interfere.
> + */
> + foreach_in_list(fs_inst, inst, &instructions) {
Pending review of a pair of patches, my cfg series is going to remove
the ability to do a foreach_in_list of the instructions. You'll have
to change this to
foreach_block_and_inst(block, fs_inst, inst, cfg)
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
