fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2025-12-22 13:30:12 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
mesa/src/intel/compiler/test_opt_cmod_propagation.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2307 lines
65 KiB
C++
Raw Normal View History

i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
/*
* Copyright © 2015 Intel Corporation
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
* SPDX-License-Identifier: MIT
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
#include "test_helpers.h"
intel/brw: Rename brw_fs_builder.h to brw_builder.h Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33076>
2025-01-15 08:20:46 -08:00
#include "brw_builder.h"
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
class cmod_propagation_test : public brw_shader_pass_test {
intel/compiler: Prefer ctor/dtors in some Google Tests Per Google Test FAQ recommendation, prefer consutrctors and destructors unless there's a need to use SetUp/TearDown. We will take advantage of this later to initialize an fs_builder. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26301>
2023-11-20 22:51:03 -08:00
protected:
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
void test_mov_prop(enum brw_conditional_mod cmod,
enum brw_reg_type add_type,
enum brw_reg_type mov_dst_type,
bool expected_cmod_prop_progress);
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
void test_saturate_prop(enum brw_conditional_mod before,
enum opcode op,
enum brw_reg_type add_type,
enum brw_reg_type op_type,
bool expected_cmod_prop_progress);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
};
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
TEST_F(cmod_propagation_test, basic)
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0.0f);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
i965/fs: Migrate test_fs_cmod_propagation to the IR builder. v2: Use set_predicate/condmod. Use fs_builder::OPCODE instead of ::emit. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-06-03 18:16:30 +03:00
bld.ADD(dest, src0, src1);
bld.CMP(bld.null_reg_f(), dest, zero, BRW_CONDITIONAL_GE);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest, src0, src1)->conditional_mod = BRW_CONDITIONAL_GE;
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
}
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
TEST_F(cmod_propagation_test, basic_other_flag)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0.0f);
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
bld.ADD(dest, src0, src1);
bld.CMP(bld.null_reg_f(), dest, zero, BRW_CONDITIONAL_GE)
->flag_subreg = 1;
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_inst *add = exp.ADD(dest, src0, src1);
add->conditional_mod = BRW_CONDITIONAL_GE;
add->flag_subreg = 1;
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
}
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
TEST_F(cmod_propagation_test, cmp_nonzero)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg src1 = bld.vgrf(BRW_TYPE_F);
brw_reg nonzero(brw_imm_f(1.0f));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
i965/fs: Migrate test_fs_cmod_propagation to the IR builder. v2: Use set_predicate/condmod. Use fs_builder::OPCODE instead of ::emit. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-06-03 18:16:30 +03:00
bld.ADD(dest, src0, src1);
bld.CMP(bld.null_reg_f(), dest, nonzero, BRW_CONDITIONAL_GE);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
}
TEST_F(cmod_propagation_test, non_cmod_instruction)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_UD);
brw_reg src0 = bld.vgrf(BRW_TYPE_UD);
brw_reg zero(brw_imm_ud(0u));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
i965/fs: Migrate test_fs_cmod_propagation to the IR builder. v2: Use set_predicate/condmod. Use fs_builder::OPCODE instead of ::emit. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-06-03 18:16:30 +03:00
bld.FBL(dest, src0);
bld.CMP(bld.null_reg_ud(), dest, zero, BRW_CONDITIONAL_GE);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
}
intel/fs: Fix a cmod prop bug when cmod is set to inst that doesn't support it Fixes dEQP-VK.reconvergence.*nesting* tests. There are cases when cmod is set to an instruction that cannot have conditional modifier. E.g. following: find_live_channel(32) vgrf166:UD, NoMask cmp.z.f0.0(32) null:D, vgrf166+0.0<0>:D, 0d is optimized to: find_live_channel.z.f0.0(32) vgrf166:UD, NoMask v2: - Add unit test to check cmod is not set to 'find_live_channel' (Matt Turner) - Update flag_subreg when conditonal_mod is updated (Ian Romanick) Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5431 Fixes: 32b7ba66b01 ("intel/compiler: fix cmod propagation optimisations") Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13268>
2021-10-21 23:06:29 +03:00
TEST_F(cmod_propagation_test, non_cmod_livechannel)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 32);
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_UD);
brw_reg zero(brw_imm_d(0));
intel/fs: Fix a cmod prop bug when cmod is set to inst that doesn't support it Fixes dEQP-VK.reconvergence.*nesting* tests. There are cases when cmod is set to an instruction that cannot have conditional modifier. E.g. following: find_live_channel(32) vgrf166:UD, NoMask cmp.z.f0.0(32) null:D, vgrf166+0.0<0>:D, 0d is optimized to: find_live_channel.z.f0.0(32) vgrf166:UD, NoMask v2: - Add unit test to check cmod is not set to 'find_live_channel' (Matt Turner) - Update flag_subreg when conditonal_mod is updated (Ian Romanick) Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5431 Fixes: 32b7ba66b01 ("intel/compiler: fix cmod propagation optimisations") Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13268>
2021-10-21 23:06:29 +03:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
bld.emit(SHADER_OPCODE_FIND_LIVE_CHANNEL, dest);
bld.CMP(bld.null_reg_d(), dest, zero, BRW_CONDITIONAL_Z);
intel/fs: Fix a cmod prop bug when cmod is set to inst that doesn't support it Fixes dEQP-VK.reconvergence.*nesting* tests. There are cases when cmod is set to an instruction that cannot have conditional modifier. E.g. following: find_live_channel(32) vgrf166:UD, NoMask cmp.z.f0.0(32) null:D, vgrf166+0.0<0>:D, 0d is optimized to: find_live_channel.z.f0.0(32) vgrf166:UD, NoMask v2: - Add unit test to check cmod is not set to 'find_live_channel' (Matt Turner) - Update flag_subreg when conditonal_mod is updated (Ian Romanick) Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5431 Fixes: 32b7ba66b01 ("intel/compiler: fix cmod propagation optimisations") Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13268>
2021-10-21 23:06:29 +03:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Fix a cmod prop bug when cmod is set to inst that doesn't support it Fixes dEQP-VK.reconvergence.*nesting* tests. There are cases when cmod is set to an instruction that cannot have conditional modifier. E.g. following: find_live_channel(32) vgrf166:UD, NoMask cmp.z.f0.0(32) null:D, vgrf166+0.0<0>:D, 0d is optimized to: find_live_channel.z.f0.0(32) vgrf166:UD, NoMask v2: - Add unit test to check cmod is not set to 'find_live_channel' (Matt Turner) - Update flag_subreg when conditonal_mod is updated (Ian Romanick) Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5431 Fixes: 32b7ba66b01 ("intel/compiler: fix cmod propagation optimisations") Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13268>
2021-10-21 23:06:29 +03:00
}
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
TEST_F(cmod_propagation_test, intervening_flag_write)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg src1 = bld.vgrf(BRW_TYPE_F);
brw_reg src2 = bld.vgrf(BRW_TYPE_F);
brw_reg zero(brw_imm_f(0.0f));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
i965/fs: Migrate test_fs_cmod_propagation to the IR builder. v2: Use set_predicate/condmod. Use fs_builder::OPCODE instead of ::emit. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-06-03 18:16:30 +03:00
bld.ADD(dest, src0, src1);
bld.CMP(bld.null_reg_f(), src2, zero, BRW_CONDITIONAL_GE);
bld.CMP(bld.null_reg_f(), dest, zero, BRW_CONDITIONAL_GE);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
}
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
TEST_F(cmod_propagation_test, intervening_mismatch_flag_write)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src2 = vgrf(bld, exp, BRW_TYPE_F);
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg zero(brw_imm_f(0.0f));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
bld.ADD(dest, src0, src1);
bld.CMP(bld.null_reg_f(), src2, zero, BRW_CONDITIONAL_GE)
->flag_subreg = 1;
bld.CMP(bld.null_reg_f(), dest, zero, BRW_CONDITIONAL_GE);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest, src0, src1)->conditional_mod = BRW_CONDITIONAL_GE;
exp.CMP(bld.null_reg_f(), src2, zero, BRW_CONDITIONAL_GE)
->flag_subreg = 1;
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
}
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
TEST_F(cmod_propagation_test, intervening_flag_read)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest0 = bld.vgrf(BRW_TYPE_F);
brw_reg dest1 = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg src1 = bld.vgrf(BRW_TYPE_F);
brw_reg src2 = bld.vgrf(BRW_TYPE_F);
brw_reg zero(brw_imm_f(0.0f));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
i965/fs: Migrate test_fs_cmod_propagation to the IR builder. v2: Use set_predicate/condmod. Use fs_builder::OPCODE instead of ::emit. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-06-03 18:16:30 +03:00
bld.ADD(dest0, src0, src1);
set_predicate(BRW_PREDICATE_NORMAL, bld.SEL(dest1, src2, zero));
bld.CMP(bld.null_reg_f(), dest0, zero, BRW_CONDITIONAL_GE);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
}
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
TEST_F(cmod_propagation_test, intervening_mismatch_flag_read)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg dest1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src2 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0.0f);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
bld.ADD(dest0, src0, src1);
set_predicate(BRW_PREDICATE_NORMAL, bld.SEL(dest1, src2, zero))
->flag_subreg = 1;
bld.CMP(bld.null_reg_f(), dest0, zero, BRW_CONDITIONAL_GE);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest0, src0, src1)->conditional_mod = BRW_CONDITIONAL_GE;
set_predicate(BRW_PREDICATE_NORMAL, exp.SEL(dest1, src2, zero))
->flag_subreg = 1;
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
}
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
TEST_F(cmod_propagation_test, intervening_dest_write)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_F, 4);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg src1 = bld.vgrf(BRW_TYPE_F);
brw_reg src2 = bld.vgrf(BRW_TYPE_F, 2);
brw_reg zero(brw_imm_f(0.0f));
intel/brw: Change unit tests to use TEX_LOGICAL instead of TEX We're not really doing any fancy texturing here, just emitting a TEX instruction that writes multiple destination registers. I plan to remove the non-logical TEX instruction in the next commit, so we swap these over to use the logical version instead. It should work just as well for the purposes of the test. Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27908>
2024-02-28 23:34:28 -08:00
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg tex_srcs[TEX_LOGICAL_NUM_SRCS];
intel/brw: Change unit tests to use TEX_LOGICAL instead of TEX We're not really doing any fancy texturing here, just emitting a TEX instruction that writes multiple destination registers. I plan to remove the non-logical TEX instruction in the next commit, so we swap these over to use the logical version instead. It should work just as well for the purposes of the test. Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27908>
2024-02-28 23:34:28 -08:00
tex_srcs[TEX_LOGICAL_SRC_COORDINATE] = src2;
tex_srcs[TEX_LOGICAL_SRC_SURFACE] = brw_imm_ud(0);
tex_srcs[TEX_LOGICAL_SRC_COORD_COMPONENTS] = brw_imm_ud(2);
tex_srcs[TEX_LOGICAL_SRC_GRAD_COMPONENTS] = brw_imm_ud(0);
tex_srcs[TEX_LOGICAL_SRC_RESIDENCY] = brw_imm_ud(0);
i965/fs: Add a builder argument to offset() Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Acked-by: Francisco Jerez <currojerez@riseup.net>
2015-06-18 12:07:27 -07:00
bld.ADD(offset(dest, bld, 2), src0, src1);
intel/brw: Change unit tests to use TEX_LOGICAL instead of TEX We're not really doing any fancy texturing here, just emitting a TEX instruction that writes multiple destination registers. I plan to remove the non-logical TEX instruction in the next commit, so we swap these over to use the logical version instead. It should work just as well for the purposes of the test. Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27908>
2024-02-28 23:34:28 -08:00
bld.emit(SHADER_OPCODE_TEX_LOGICAL, dest, tex_srcs, TEX_LOGICAL_NUM_SRCS)
i965/fs: Replace fs_inst::regs_written with ::size_written field in bytes. The previous regs_written field can be recovered by rewriting each rvalue reference of regs_written like 'x = i.regs_written' to 'x = DIV_ROUND_UP(i.size_written, reg_unit)', and each lvalue reference like 'i.regs_written = x' to 'i.size_written = x * reg_unit'. For the same reason as in the previous patches, this doesn't attempt to be particularly clever about simplifying the result in the interest of keeping the rather lengthy patch as obvious as possible. I'll come back later to clean up any ugliness introduced here. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
2016-09-07 13:38:20 -07:00
->size_written = 4 * REG_SIZE;
i965/fs: Add a builder argument to offset() Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Acked-by: Francisco Jerez <currojerez@riseup.net>
2015-06-18 12:07:27 -07:00
bld.CMP(bld.null_reg_f(), offset(dest, bld, 2), zero, BRW_CONDITIONAL_GE);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Add unit tests for cmod propagation pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-05 16:13:59 -08:00
}
i965/fs: Propagate cmod across flag read if it contains the same value. total instructions in shared programs: 5959463 -> 5958900 (-0.01%) instructions in affected programs: 70031 -> 69468 (-0.80%) Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-01-03 12:18:15 -08:00
TEST_F(cmod_propagation_test, intervening_flag_read_same_value)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg dest1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src2 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0.0f);
set_condmod(BRW_CONDITIONAL_GE, bld.ADD(dest0, src0, src1));
i965/fs: Migrate test_fs_cmod_propagation to the IR builder. v2: Use set_predicate/condmod. Use fs_builder::OPCODE instead of ::emit. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-06-03 18:16:30 +03:00
set_predicate(BRW_PREDICATE_NORMAL, bld.SEL(dest1, src2, zero));
bld.CMP(bld.null_reg_f(), dest0, zero, BRW_CONDITIONAL_GE);
i965/fs: Propagate cmod across flag read if it contains the same value. total instructions in shared programs: 5959463 -> 5958900 (-0.01%) instructions in affected programs: 70031 -> 69468 (-0.80%) Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-01-03 12:18:15 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Propagate cmod across flag read if it contains the same value. total instructions in shared programs: 5959463 -> 5958900 (-0.01%) instructions in affected programs: 70031 -> 69468 (-0.80%) Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-01-03 12:18:15 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
set_condmod(BRW_CONDITIONAL_GE, exp.ADD(dest0, src0, src1));
set_predicate(BRW_PREDICATE_NORMAL, exp.SEL(dest1, src2, zero));
i965/fs: Propagate cmod across flag read if it contains the same value. total instructions in shared programs: 5959463 -> 5958900 (-0.01%) instructions in affected programs: 70031 -> 69468 (-0.80%) Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-01-03 12:18:15 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
i965/fs: Propagate cmod across flag read if it contains the same value. total instructions in shared programs: 5959463 -> 5958900 (-0.01%) instructions in affected programs: 70031 -> 69468 (-0.80%) Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-01-03 12:18:15 -08:00
}
i965/fs: Allow flipping cond mod for negated arguments. This allows us to apply the optimization in cases where the CMP's argument is negated, by flipping the conditional mod. For example, it allows us to optimize this: add(8) temp a b cmp.l.f0(8) null -temp 0.0 into add.g.f0(8) temp a b total instructions in shared programs: 5958360 -> 5955701 (-0.04%) instructions in affected programs: 466880 -> 464221 (-0.57%) GAINED: 0 LOST: 1 Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 12:18:57 -08:00
TEST_F(cmod_propagation_test, negate)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
i965/fs: Allow flipping cond mod for negated arguments. This allows us to apply the optimization in cases where the CMP's argument is negated, by flipping the conditional mod. For example, it allows us to optimize this: add(8) temp a b cmp.l.f0(8) null -temp 0.0 into add.g.f0(8) temp a b total instructions in shared programs: 5958360 -> 5955701 (-0.04%) instructions in affected programs: 466880 -> 464221 (-0.57%) GAINED: 0 LOST: 1 Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 12:18:57 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0.0f);
i965/fs: Allow flipping cond mod for negated arguments. This allows us to apply the optimization in cases where the CMP's argument is negated, by flipping the conditional mod. For example, it allows us to optimize this: add(8) temp a b cmp.l.f0(8) null -temp 0.0 into add.g.f0(8) temp a b total instructions in shared programs: 5958360 -> 5955701 (-0.04%) instructions in affected programs: 466880 -> 464221 (-0.57%) GAINED: 0 LOST: 1 Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 12:18:57 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
bld.ADD(dest, src0, src1);
bld.CMP(bld.null_reg_f(), negate(dest), zero, BRW_CONDITIONAL_GE);
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Allow flipping cond mod for negated arguments. This allows us to apply the optimization in cases where the CMP's argument is negated, by flipping the conditional mod. For example, it allows us to optimize this: add(8) temp a b cmp.l.f0(8) null -temp 0.0 into add.g.f0(8) temp a b total instructions in shared programs: 5958360 -> 5955701 (-0.04%) instructions in affected programs: 466880 -> 464221 (-0.57%) GAINED: 0 LOST: 1 Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 12:18:57 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest, src0, src1)->conditional_mod = BRW_CONDITIONAL_LE;
i965/fs: Allow flipping cond mod for negated arguments. This allows us to apply the optimization in cases where the CMP's argument is negated, by flipping the conditional mod. For example, it allows us to optimize this: add(8) temp a b cmp.l.f0(8) null -temp 0.0 into add.g.f0(8) temp a b total instructions in shared programs: 5958360 -> 5955701 (-0.04%) instructions in affected programs: 466880 -> 464221 (-0.57%) GAINED: 0 LOST: 1 Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 12:18:57 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
i965/fs: Allow flipping cond mod for negated arguments. This allows us to apply the optimization in cases where the CMP's argument is negated, by flipping the conditional mod. For example, it allows us to optimize this: add(8) temp a b cmp.l.f0(8) null -temp 0.0 into add.g.f0(8) temp a b total instructions in shared programs: 5958360 -> 5955701 (-0.04%) instructions in affected programs: 466880 -> 464221 (-0.57%) GAINED: 0 LOST: 1 Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 12:18:57 -08:00
}
i965/fs: Add support for removing MOV.NZ instructions. For some reason, we occasionally write the flag register with a MOV.NZ instruction: add(8) g25<1>F -g6<0,1,0>F g15<8,8,1>F cmp.l.f0(8) g26<1>D g25<8,8,1>F 0F mov.nz.f0(8) null g26<8,8,1>D A MOV.NZ instruction on the result of a CMP is like comparing for equality with true in C. It's useless. Removing it allows us to generate: add.l.f0(8) null -g6<0,1,0>F g15<8,8,1>F total instructions in shared programs: 5955701 -> 5951657 (-0.07%) instructions in affected programs: 302910 -> 298866 (-1.34%) GAINED: 1 LOST: 0 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 17:19:41 -08:00
TEST_F(cmod_propagation_test, movnz)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
i965/fs: Add support for removing MOV.NZ instructions. For some reason, we occasionally write the flag register with a MOV.NZ instruction: add(8) g25<1>F -g6<0,1,0>F g15<8,8,1>F cmp.l.f0(8) g26<1>D g25<8,8,1>F 0F mov.nz.f0(8) null g26<8,8,1>D A MOV.NZ instruction on the result of a CMP is like comparing for equality with true in C. It's useless. Removing it allows us to generate: add.l.f0(8) null -g6<0,1,0>F g15<8,8,1>F total instructions in shared programs: 5955701 -> 5951657 (-0.07%) instructions in affected programs: 302910 -> 298866 (-1.34%) GAINED: 1 LOST: 0 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 17:19:41 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
i965/fs: Add support for removing MOV.NZ instructions. For some reason, we occasionally write the flag register with a MOV.NZ instruction: add(8) g25<1>F -g6<0,1,0>F g15<8,8,1>F cmp.l.f0(8) g26<1>D g25<8,8,1>F 0F mov.nz.f0(8) null g26<8,8,1>D A MOV.NZ instruction on the result of a CMP is like comparing for equality with true in C. It's useless. Removing it allows us to generate: add.l.f0(8) null -g6<0,1,0>F g15<8,8,1>F total instructions in shared programs: 5955701 -> 5951657 (-0.07%) instructions in affected programs: 302910 -> 298866 (-1.34%) GAINED: 1 LOST: 0 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 17:19:41 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
bld.CMP(dest, src0, src1, BRW_CONDITIONAL_GE);
bld.MOV(bld.null_reg_f(), dest)->conditional_mod = BRW_CONDITIONAL_NZ;
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Add support for removing MOV.NZ instructions. For some reason, we occasionally write the flag register with a MOV.NZ instruction: add(8) g25<1>F -g6<0,1,0>F g15<8,8,1>F cmp.l.f0(8) g26<1>D g25<8,8,1>F 0F mov.nz.f0(8) null g26<8,8,1>D A MOV.NZ instruction on the result of a CMP is like comparing for equality with true in C. It's useless. Removing it allows us to generate: add.l.f0(8) null -g6<0,1,0>F g15<8,8,1>F total instructions in shared programs: 5955701 -> 5951657 (-0.07%) instructions in affected programs: 302910 -> 298866 (-1.34%) GAINED: 1 LOST: 0 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 17:19:41 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.CMP(dest, src0, src1, BRW_CONDITIONAL_GE);
i965/fs: Add support for removing MOV.NZ instructions. For some reason, we occasionally write the flag register with a MOV.NZ instruction: add(8) g25<1>F -g6<0,1,0>F g15<8,8,1>F cmp.l.f0(8) g26<1>D g25<8,8,1>F 0F mov.nz.f0(8) null g26<8,8,1>D A MOV.NZ instruction on the result of a CMP is like comparing for equality with true in C. It's useless. Removing it allows us to generate: add.l.f0(8) null -g6<0,1,0>F g15<8,8,1>F total instructions in shared programs: 5955701 -> 5951657 (-0.07%) instructions in affected programs: 302910 -> 298866 (-1.34%) GAINED: 1 LOST: 0 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 17:19:41 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
i965/fs: Add support for removing MOV.NZ instructions. For some reason, we occasionally write the flag register with a MOV.NZ instruction: add(8) g25<1>F -g6<0,1,0>F g15<8,8,1>F cmp.l.f0(8) g26<1>D g25<8,8,1>F 0F mov.nz.f0(8) null g26<8,8,1>D A MOV.NZ instruction on the result of a CMP is like comparing for equality with true in C. It's useless. Removing it allows us to generate: add.l.f0(8) null -g6<0,1,0>F g15<8,8,1>F total instructions in shared programs: 5955701 -> 5951657 (-0.07%) instructions in affected programs: 302910 -> 298866 (-1.34%) GAINED: 1 LOST: 0 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 17:19:41 -08:00
}
i965/fs: Don't propagate cmod to inst with different type. Cc: 10.5 <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89317 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-02-27 10:22:21 -08:00
TEST_F(cmod_propagation_test, different_types_cmod_with_zero)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_D);
brw_reg src0 = bld.vgrf(BRW_TYPE_D);
brw_reg src1 = bld.vgrf(BRW_TYPE_D);
brw_reg zero(brw_imm_f(0.0f));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
i965/fs: Migrate test_fs_cmod_propagation to the IR builder. v2: Use set_predicate/condmod. Use fs_builder::OPCODE instead of ::emit. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-06-03 18:16:30 +03:00
bld.ADD(dest, src0, src1);
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
bld.CMP(bld.null_reg_f(), retype(dest, BRW_TYPE_F), zero,
i965/fs: Migrate test_fs_cmod_propagation to the IR builder. v2: Use set_predicate/condmod. Use fs_builder::OPCODE instead of ::emit. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-06-03 18:16:30 +03:00
BRW_CONDITIONAL_GE);
i965/fs: Don't propagate cmod to inst with different type. Cc: 10.5 <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89317 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-02-27 10:22:21 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Don't propagate cmod to inst with different type. Cc: 10.5 <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89317 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-02-27 10:22:21 -08:00
}
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
TEST_F(cmod_propagation_test, andnz_one)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_reg dest = vgrf(bld, exp, BRW_TYPE_D);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0.0f);
brw_reg one = brw_imm_d(1);
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
bld.CMP(retype(dest, BRW_TYPE_F), src0, zero, BRW_CONDITIONAL_L);
bld.AND(bld.null_reg_d(), dest, one)->conditional_mod = BRW_CONDITIONAL_NZ;
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.CMP(retype(dest, BRW_TYPE_F), src0, zero, BRW_CONDITIONAL_L);
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
}
TEST_F(cmod_propagation_test, andnz_non_one)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_D);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg zero(brw_imm_f(0.0f));
brw_reg nonone(brw_imm_d(38));
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
bld.CMP(retype(dest, BRW_TYPE_F), src0, zero, BRW_CONDITIONAL_L);
i965/fs: Migrate test_fs_cmod_propagation to the IR builder. v2: Use set_predicate/condmod. Use fs_builder::OPCODE instead of ::emit. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-06-03 18:16:30 +03:00
set_condmod(BRW_CONDITIONAL_NZ,
bld.AND(bld.null_reg_d(), dest, nonone));
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
}
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
TEST_F(cmod_propagation_test, cmp_cmpnz)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
bld.CMP(dst0, src0, zero, BRW_CONDITIONAL_NZ);
bld.CMP(bld.null_reg_f(), dst0, zero, BRW_CONDITIONAL_NZ);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.CMP(dst0, src0, zero, BRW_CONDITIONAL_NZ);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
}
TEST_F(cmod_propagation_test, cmp_cmpg)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dst0 = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg zero(brw_imm_f(0));
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
bld.CMP(dst0, src0, zero, BRW_CONDITIONAL_NZ);
bld.CMP(bld.null_reg_f(), dst0, zero, BRW_CONDITIONAL_G);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
}
TEST_F(cmod_propagation_test, plnnz_cmpnz)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0);
bld.PLN(dst0, src0, zero)->conditional_mod = BRW_CONDITIONAL_NZ;
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
bld.CMP(bld.null_reg_f(), dst0, zero, BRW_CONDITIONAL_NZ);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.PLN(dst0, src0, zero)->conditional_mod = BRW_CONDITIONAL_NZ;
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
}
TEST_F(cmod_propagation_test, plnnz_cmpz)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0);
bld.PLN(dst0, src0, zero)->conditional_mod = BRW_CONDITIONAL_NZ;
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
bld.CMP(bld.null_reg_f(), dst0, zero, BRW_CONDITIONAL_Z);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.PLN(dst0, src0, zero)->conditional_mod = BRW_CONDITIONAL_Z;
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
}
TEST_F(cmod_propagation_test, plnnz_sel_cmpz)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dst0 = bld.vgrf(BRW_TYPE_F);
brw_reg dst1 = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg zero(brw_imm_f(0));
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
set_condmod(BRW_CONDITIONAL_NZ, bld.PLN(dst0, src0, zero));
set_predicate(BRW_PREDICATE_NORMAL, bld.SEL(dst1, src0, zero));
bld.CMP(bld.null_reg_f(), dst0, zero, BRW_CONDITIONAL_Z);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
}
TEST_F(cmod_propagation_test, cmp_cmpg_D)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dst0 = bld.vgrf(BRW_TYPE_D);
brw_reg src0 = bld.vgrf(BRW_TYPE_D);
brw_reg zero(brw_imm_d(0));
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
bld.CMP(dst0, src0, zero, BRW_CONDITIONAL_NZ);
bld.CMP(bld.null_reg_d(), dst0, zero, BRW_CONDITIONAL_G);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
}
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
TEST_F(cmod_propagation_test, cmp_cmpg_UD)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg zero = brw_imm_ud(0);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
bld.CMP(dst0, src0, zero, BRW_CONDITIONAL_NZ);
bld.CMP(bld.null_reg_ud(), dst0, zero, BRW_CONDITIONAL_G);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.CMP(dst0, src0, zero, BRW_CONDITIONAL_NZ);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
}
TEST_F(cmod_propagation_test, cmp_cmpl_D)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_D);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_D);
brw_reg zero = brw_imm_d(0);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
bld.CMP(dst0, src0, zero, BRW_CONDITIONAL_NZ);
bld.CMP(bld.null_reg_d(), dst0, zero, BRW_CONDITIONAL_L);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.CMP(dst0, src0, zero, BRW_CONDITIONAL_NZ);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
}
TEST_F(cmod_propagation_test, cmp_cmpl_UD)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dst0 = bld.vgrf(BRW_TYPE_UD);
brw_reg src0 = bld.vgrf(BRW_TYPE_UD);
brw_reg zero(brw_imm_ud(0));
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
bld.CMP(dst0, src0, zero, BRW_CONDITIONAL_NZ);
bld.CMP(bld.null_reg_ud(), dst0, zero, BRW_CONDITIONAL_L);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/compiler: fix cmod propagation optimisations Knowing following: - CMP writes to flag register the result of applying cmod to the `src0 - src1`. After that it stores the same value to dst. Other instructions first store their result to dst, and then store cmod(dst) to the flag register. - inst is either CMP or MOV - inst->dst is null - inst->src[0] overlaps with scan_inst->dst - inst->src[1] is zero - scan_inst wrote to a flag register There can be three possible paths: - scan_inst is CMP: Considering that src0 is either 0x0 (false), or 0xffffffff (true), and src1 is 0x0: - If inst's cmod is NZ, we can always remove scan_inst: NZ is invariant for false and true. This holds even if src0 is NaN: .nz is the only cmod, that returns true for NaN. - .g is invariant if src0 has a UD type - .l is invariant if src0 has a D type - scan_inst and inst have the same cmod: If scan_inst is anything than CMP, it already wrote the appropriate value to the flag register. - else: We can change cmod of scan_inst to that of inst, and remove inst. It is valid as long as we make sure that no instruction uses the flag register between scan_inst and inst. Nine new cmod_propagation unit tests: - cmp_cmpnz - cmp_cmpg - plnnz_cmpnz - plnnz_cmpz (*) - plnnz_sel_cmpz - cmp_cmpg_D - cmp_cmpg_UD (*) - cmp_cmpl_D (*) - cmp_cmpl_UD (*) this would fail without changes to brw_fs_cmod_propagation. This fixes optimisation that used to be illegal (see issue #2154) = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F Now it is optimised as such (note change of cmod in line 0): = Before = 0: linterp.z.f0.0(8) vgrf0:F, g2:F, attr0<0>:F 1: cmp.nz.f0.0(8) null:F, vgrf0:F, 0f = After = 0: linterp.nz.f0.0(8) vgrf0:F, g2:F, attr0<0>:F No shaderdb changes Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2154 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3348>
2020-01-03 16:37:00 +02:00
}
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
TEST_F(cmod_propagation_test, andz_one)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_D);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg zero(brw_imm_f(0.0f));
brw_reg one(brw_imm_d(1));
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
bld.CMP(retype(dest, BRW_TYPE_F), src0, zero, BRW_CONDITIONAL_L);
i965/fs: Migrate test_fs_cmod_propagation to the IR builder. v2: Use set_predicate/condmod. Use fs_builder::OPCODE instead of ::emit. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-06-03 18:16:30 +03:00
set_condmod(BRW_CONDITIONAL_Z,
bld.AND(bld.null_reg_d(), dest, one));
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
}
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
TEST_F(cmod_propagation_test, add_not_merge_with_compare)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg src1 = bld.vgrf(BRW_TYPE_F);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
bld.ADD(dest, src0, src1);
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
}
TEST_F(cmod_propagation_test, subtract_merge_with_compare)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
bld.ADD(dest, src0, negate(src1));
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest, src0, negate(src1))->conditional_mod = BRW_CONDITIONAL_L;
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
}
TEST_F(cmod_propagation_test, subtract_immediate_merge_with_compare)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg one = brw_imm_f(1.0f);
brw_reg negative_one = brw_imm_f(-1.0f);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
bld.ADD(dest, src0, negative_one);
bld.CMP(bld.null_reg_f(), src0, one, BRW_CONDITIONAL_NZ);
/* = Before =
* 0: add(8) dest:F src0:F -1.0f
* 1: cmp.nz.f0(8) null:F src0:F 1.0f
*
* = After =
* 0: add.nz.f0(8) dest:F src0:F -1.0f
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest, src0, negative_one)->conditional_mod = BRW_CONDITIONAL_NZ;
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
}
TEST_F(cmod_propagation_test, subtract_merge_with_compare_intervening_add)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg dest1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
bld.ADD(dest0, src0, negate(src1));
bld.ADD(dest1, src0, src1);
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest0, src0, negate(src1))->conditional_mod = BRW_CONDITIONAL_L;
exp.ADD(dest1, src0, src1);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
}
TEST_F(cmod_propagation_test, subtract_not_merge_with_compare_intervening_partial_write)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest0 = bld.vgrf(BRW_TYPE_F);
brw_reg dest1 = bld.vgrf(BRW_TYPE_F);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg src1 = bld.vgrf(BRW_TYPE_F);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
bld.ADD(dest0, src0, negate(src1));
set_predicate(BRW_PREDICATE_NORMAL, bld.ADD(dest1, src0, negate(src1)));
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
}
TEST_F(cmod_propagation_test, subtract_not_merge_with_compare_intervening_add)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest0 = bld.vgrf(BRW_TYPE_F);
brw_reg dest1 = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg src1 = bld.vgrf(BRW_TYPE_F);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
bld.ADD(dest0, src0, negate(src1));
set_condmod(BRW_CONDITIONAL_EQ, bld.ADD(dest1, src0, src1));
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
}
TEST_F(cmod_propagation_test, add_merge_with_compare)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
bld.ADD(dest, src0, src1);
bld.CMP(bld.null_reg_f(), src0, negate(src1), BRW_CONDITIONAL_L);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest, src0, src1)->conditional_mod = BRW_CONDITIONAL_L;
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
}
TEST_F(cmod_propagation_test, negative_subtract_merge_with_compare)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
bld.ADD(dest, src1, negate(src0));
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
/* The result of the subtract is the negatiion of the result of the
* implicit subtract in the compare, so the condition must change.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest, src1, negate(src0))->conditional_mod = BRW_CONDITIONAL_G;
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
}
TEST_F(cmod_propagation_test, subtract_delete_compare)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg dest1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src2 = vgrf(bld, exp, BRW_TYPE_F);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
set_condmod(BRW_CONDITIONAL_L, bld.ADD(dest, src0, negate(src1)));
set_predicate(BRW_PREDICATE_NORMAL, bld.MOV(dest1, src2));
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L);
/* = Before =
* 0: add.l.f0(8) dest0:F src0:F -src1:F
* 1: (+f0) mov(0) dest1:F src2:F
* 2: cmp.l.f0(8) null:F src0:F src1:F
*
* = After =
* 0: add.l.f0(8) dest:F src0:F -src1:F
* 1: (+f0) mov(0) dest1:F src2:F
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
set_condmod(BRW_CONDITIONAL_L, exp.ADD(dest, src0, negate(src1)));
set_predicate(BRW_PREDICATE_NORMAL, exp.MOV(dest1, src2));
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
}
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
TEST_F(cmod_propagation_test, subtract_delete_compare_other_flag)
{
/* This test is the same as subtract_delete_compare but it explicitly used
* flag f0.1 for the subtraction and the comparison.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg dest1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src2 = vgrf(bld, exp, BRW_TYPE_F);
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
set_condmod(BRW_CONDITIONAL_L, bld.ADD(dest, src0, negate(src1)))
->flag_subreg = 1;
set_predicate(BRW_PREDICATE_NORMAL, bld.MOV(dest1, src2));
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L)
->flag_subreg = 1;
/* = Before =
* 0: add.l.f0.1(8) dest0:F src0:F -src1:F
* 1: (+f0) mov(0) dest1:F src2:F
* 2: cmp.l.f0.1(8) null:F src0:F src1:F
*
* = After =
* 0: add.l.f0.1(8) dest:F src0:F -src1:F
* 1: (+f0) mov(0) dest1:F src2:F
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
set_condmod(BRW_CONDITIONAL_L, exp.ADD(dest, src0, negate(src1)))
->flag_subreg = 1;
set_predicate(BRW_PREDICATE_NORMAL, exp.MOV(dest1, src2));
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
}
TEST_F(cmod_propagation_test, subtract_to_mismatch_flag)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg src1 = bld.vgrf(BRW_TYPE_F);
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
set_condmod(BRW_CONDITIONAL_L, bld.ADD(dest, src0, negate(src1)));
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L)
->flag_subreg = 1;
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
}
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
TEST_F(cmod_propagation_test,
subtract_merge_with_compare_intervening_mismatch_flag_write)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
bld.ADD(dest0, src0, negate(src1));
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L)
->flag_subreg = 1;
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L);
/* = Before =
* 0: add(8) dest0:F src0:F -src1:F
* 1: cmp.l.f0.1(8) null:F src0:F src1:F
* 2: cmp.l.f0(8) null:F src0:F src1:F
*
* = After =
* 0: add.l.f0(8) dest0:F src0:F -src1:F
* 1: cmp.l.f0.1(8) null:F src0:F src1:F
*
* NOTE: Another perfectly valid after sequence would be:
*
* 0: add.f0.1(8) dest0:F src0:F -src1:F
* 1: cmp.l.f0(8) null:F src0:F src1:F
*
* However, the optimization pass starts at the end of the basic block.
* Because of this, the cmp.l.f0 will always be chosen. If the pass
* changes its strategy, this test will also need to change.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest0, src0, negate(src1))->conditional_mod = BRW_CONDITIONAL_L;
exp.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L)
->flag_subreg = 1;
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
}
TEST_F(cmod_propagation_test,
subtract_merge_with_compare_intervening_mismatch_flag_read)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg dest1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src2 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0.0f);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
bld.ADD(dest0, src0, negate(src1));
set_predicate(BRW_PREDICATE_NORMAL, bld.SEL(dest1, src2, zero))
->flag_subreg = 1;
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L);
/* = Before =
* 0: add(8) dest0:F src0:F -src1:F
* 1: (+f0.1) sel(8) dest1 src2 0.0f
* 2: cmp.l.f0(8) null:F src0:F src1:F
*
* = After =
* 0: add.l.f0(8) dest0:F src0:F -src1:F
* 1: (+f0.1) sel(8) dest1 src2 0.0f
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest0, src0, negate(src1))->conditional_mod = BRW_CONDITIONAL_L;
set_predicate(BRW_PREDICATE_NORMAL, exp.SEL(dest1, src2, zero))
->flag_subreg = 1;
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
}
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
TEST_F(cmod_propagation_test, subtract_delete_compare_derp)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg dest1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
set_condmod(BRW_CONDITIONAL_L, bld.ADD(dest0, src0, negate(src1)));
set_predicate(BRW_PREDICATE_NORMAL, bld.ADD(dest1, negate(src0), src1));
bld.CMP(bld.null_reg_f(), src0, src1, BRW_CONDITIONAL_L);
/* = Before =
* 0: add.l.f0(8) dest0:F src0:F -src1:F
* 1: (+f0) add(0) dest1:F -src0:F src1:F
* 2: cmp.l.f0(8) null:F src0:F src1:F
*
* = After =
* 0: add.l.f0(8) dest0:F src0:F -src1:F
* 1: (+f0) add(0) dest1:F -src0:F src1:F
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
set_condmod(BRW_CONDITIONAL_L, exp.ADD(dest0, src0, negate(src1)));
set_predicate(BRW_PREDICATE_NORMAL, exp.ADD(dest1, negate(src0), src1));
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
i965/fs: Propagate conditional modifiers from compares to adds The math inside the add and the cmp in this instruction sequence is the same. We can utilize this to eliminate the compare. add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This is reduced to: add.z.f0(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; This optimization pass could do even better. The nature of converting vectorized code from the GLSL front end to scalar code in NIR results in sequences like: add(8) g7<1>F g4<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g6<1>F g3<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; add(8) g5<1>F g2<8,8,1>F g64.5<0,1,0>F { align1 1Q compacted }; cmp.z.f0(8) null<1>F g2<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g8<1>F (abs)g5<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g3<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g10<1>F (abs)g6<8,8,1>F 3e-37F { align1 1Q }; cmp.z.f0(8) null<1>F g4<8,8,1>F -g64.5<0,1,0>F { align1 1Q switch }; (-f0) sel(8) g12<1>F (abs)g7<8,8,1>F 3e-37F { align1 1Q }; In this sequence, only the first cmp.z is removed. With different scheduling, all 3 could get removed. Skylake total instructions in shared programs: 14407009 -> 14400173 (-0.05%) instructions in affected programs: 1307274 -> 1300438 (-0.52%) helped: 4880 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.40 x̃: 1 helped stats (rel) min: 0.03% max: 8.70% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.45 -1.35 95% mean confidence interval for instructions %-change: -0.72% -0.69% Instructions are helped. total cycles in shared programs: 532943169 -> 532923528 (<.01%) cycles in affected programs: 14065798 -> 14046157 (-0.14%) helped: 2703 HURT: 339 helped stats (abs) min: 1 max: 1062 x̄: 12.27 x̃: 2 helped stats (rel) min: <.01% max: 28.72% x̄: 0.38% x̃: 0.21% HURT stats (abs) min: 1 max: 739 x̄: 39.86 x̃: 12 HURT stats (rel) min: 0.02% max: 27.69% x̄: 1.38% x̃: 0.41% 95% mean confidence interval for cycles value: -8.66 -4.26 95% mean confidence interval for cycles %-change: -0.24% -0.14% Cycles are helped. LOST: 0 GAINED: 1 Broadwell total instructions in shared programs: 14719636 -> 14712949 (-0.05%) instructions in affected programs: 1288188 -> 1281501 (-0.52%) helped: 4845 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.38 x̃: 1 helped stats (rel) min: 0.03% max: 8.00% x̄: 0.70% x̃: 0.52% 95% mean confidence interval for instructions value: -1.43 -1.33 95% mean confidence interval for instructions %-change: -0.72% -0.68% Instructions are helped. total cycles in shared programs: 559599253 -> 559581699 (<.01%) cycles in affected programs: 13315565 -> 13298011 (-0.13%) helped: 2600 HURT: 269 helped stats (abs) min: 1 max: 2128 x̄: 12.24 x̃: 2 helped stats (rel) min: <.01% max: 23.95% x̄: 0.41% x̃: 0.20% HURT stats (abs) min: 1 max: 790 x̄: 53.07 x̃: 20 HURT stats (rel) min: 0.02% max: 15.96% x̄: 1.55% x̃: 0.75% 95% mean confidence interval for cycles value: -8.47 -3.77 95% mean confidence interval for cycles %-change: -0.27% -0.18% Cycles are helped. LOST: 0 GAINED: 8 Haswell total instructions in shared programs: 12978609 -> 12973483 (-0.04%) instructions in affected programs: 932921 -> 927795 (-0.55%) helped: 3480 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.47 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.78% x̃: 0.58% 95% mean confidence interval for instructions value: -1.53 -1.42 95% mean confidence interval for instructions %-change: -0.80% -0.75% Instructions are helped. total cycles in shared programs: 410270788 -> 410250531 (<.01%) cycles in affected programs: 10986161 -> 10965904 (-0.18%) helped: 2087 HURT: 254 helped stats (abs) min: 1 max: 2672 x̄: 14.63 x̃: 4 helped stats (rel) min: <.01% max: 39.61% x̄: 0.42% x̃: 0.21% HURT stats (abs) min: 1 max: 519 x̄: 40.49 x̃: 16 HURT stats (rel) min: 0.01% max: 12.83% x̄: 1.20% x̃: 0.47% 95% mean confidence interval for cycles value: -12.82 -4.49 95% mean confidence interval for cycles %-change: -0.31% -0.18% Cycles are helped. LOST: 0 GAINED: 5 Ivy Bridge total instructions in shared programs: 11686082 -> 11681548 (-0.04%) instructions in affected programs: 937696 -> 933162 (-0.48%) helped: 3150 HURT: 0 helped stats (abs) min: 1 max: 33 x̄: 1.44 x̃: 1 helped stats (rel) min: 0.03% max: 7.84% x̄: 0.69% x̃: 0.49% 95% mean confidence interval for instructions value: -1.49 -1.38 95% mean confidence interval for instructions %-change: -0.71% -0.67% Instructions are helped. total cycles in shared programs: 257514962 -> 257492471 (<.01%) cycles in affected programs: 11524149 -> 11501658 (-0.20%) helped: 1970 HURT: 239 helped stats (abs) min: 1 max: 3525 x̄: 17.48 x̃: 3 helped stats (rel) min: <.01% max: 49.60% x̄: 0.46% x̃: 0.17% HURT stats (abs) min: 1 max: 1358 x̄: 50.00 x̃: 15 HURT stats (rel) min: 0.02% max: 59.88% x̄: 1.84% x̃: 0.65% 95% mean confidence interval for cycles value: -17.01 -3.35 95% mean confidence interval for cycles %-change: -0.33% -0.08% Cycles are helped. LOST: 9 GAINED: 1 Sandy Bridge total instructions in shared programs: 10432841 -> 10429893 (-0.03%) instructions in affected programs: 685071 -> 682123 (-0.43%) helped: 2453 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.20 x̃: 1 helped stats (rel) min: 0.02% max: 7.55% x̄: 0.64% x̃: 0.46% 95% mean confidence interval for instructions value: -1.23 -1.17 95% mean confidence interval for instructions %-change: -0.67% -0.62% Instructions are helped. total cycles in shared programs: 146133660 -> 146134195 (<.01%) cycles in affected programs: 3991634 -> 3992169 (0.01%) helped: 1237 HURT: 153 helped stats (abs) min: 1 max: 2853 x̄: 6.93 x̃: 2 helped stats (rel) min: <.01% max: 29.00% x̄: 0.24% x̃: 0.14% HURT stats (abs) min: 1 max: 1740 x̄: 59.56 x̃: 12 HURT stats (rel) min: 0.03% max: 78.98% x̄: 1.96% x̃: 0.42% 95% mean confidence interval for cycles value: -5.13 5.90 95% mean confidence interval for cycles %-change: -0.17% 0.16% Inconclusive result (value mean confidence interval includes 0). LOST: 0 GAINED: 1 GM45 and Iron Lake had similar results (GM45 shown): total instructions in shared programs: 4800332 -> 4798380 (-0.04%) instructions in affected programs: 565995 -> 564043 (-0.34%) helped: 1451 HURT: 0 helped stats (abs) min: 1 max: 20 x̄: 1.35 x̃: 1 helped stats (rel) min: 0.05% max: 5.26% x̄: 0.47% x̃: 0.31% 95% mean confidence interval for instructions value: -1.40 -1.29 95% mean confidence interval for instructions %-change: -0.50% -0.45% Instructions are helped. total cycles in shared programs: 122032318 -> 122027798 (<.01%) cycles in affected programs: 8334868 -> 8330348 (-0.05%) helped: 1029 HURT: 1 helped stats (abs) min: 2 max: 40 x̄: 4.43 x̃: 2 helped stats (rel) min: <.01% max: 1.83% x̄: 0.09% x̃: 0.04% HURT stats (abs) min: 38 max: 38 x̄: 38.00 x̃: 38 HURT stats (rel) min: 0.25% max: 0.25% x̄: 0.25% x̃: 0.25% 95% mean confidence interval for cycles value: -4.70 -4.08 95% mean confidence interval for cycles %-change: -0.09% -0.08% Cycles are helped. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2018-03-09 13:45:01 -08:00
}
intel/compiler/test: Add unit test for mismatched signedness comparison v2 (idr): Move adding the test to after adding the fix. Reordering the two commits prevents possible headaches for git-bisect with scripts that always do 'ninja check'. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109404 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2019-02-11 13:41:32 -08:00
TEST_F(cmod_propagation_test, signed_unsigned_comparison_mismatch)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest0 = bld.vgrf(BRW_TYPE_D);
brw_reg src0 = bld.vgrf(BRW_TYPE_D);
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
src0.type = BRW_TYPE_W;
intel/compiler/test: Add unit test for mismatched signedness comparison v2 (idr): Move adding the test to after adding the fix. Reordering the two commits prevents possible headaches for git-bisect with scripts that always do 'ninja check'. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109404 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2019-02-11 13:41:32 -08:00
bld.ASR(dest0, negate(src0), brw_imm_d(15));
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
bld.CMP(bld.null_reg_ud(), retype(dest0, BRW_TYPE_UD),
intel/compiler/test: Add unit test for mismatched signedness comparison v2 (idr): Move adding the test to after adding the fix. Reordering the two commits prevents possible headaches for git-bisect with scripts that always do 'ninja check'. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109404 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2019-02-11 13:41:32 -08:00
brw_imm_ud(0u), BRW_CONDITIONAL_LE);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/compiler/test: Add unit test for mismatched signedness comparison v2 (idr): Move adding the test to after adding the fix. Reordering the two commits prevents possible headaches for git-bisect with scripts that always do 'ninja check'. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109404 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2019-02-11 13:41:32 -08:00
}
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
intel/fs: Fix a cmod prop bug when the source type of a mov doesn't match the dest type of scan_inst We were previously operating with the mindset "a MOV is just a compare with zero." As a result, we were trying to share as much code between the MOV path and the CMP path as possible. However, MOV instructions can perform type conversions that affect the result of the comparison. There was some code added to better handle this for cases like and(16) g31<1>UD g20<8,8,1>UD g22<8,8,1>UD mov.nz.f0(16) null<1>F g31<8,8,1>D The flaw in these changed special cases is that it allowed things like or(8) dest:D src0:D src1:D mov.nz(8) null:D dest:F Because both destinations were integer types, the propagation was allowed. The source type of the MOV and the destination type of the OR do not match, so type conversion rules have to be accounted for. My solution was to just split the MOV and non-MOV paths with completely separate checks. The "else" path in this commit is basically the old code with the BRW_OPCODE_MOV special case removed. The new MOV code further splits into "destination of scan_inst is float" and "destination of scan_inst is integer" paths. For each case I enumerate the rules that I belive apply. For the integer path, only the "Z or NZ" rules are listed as only NZ is currently allowed (hence the conditional_mod assertion in that path). A later commit relaxes this and adds the rule. The new rules slightly relax one of the previous rules. Previously the sizes of the MOV destination and the MOV source had to be the same. In some cases now the sizes can be different by the following conditions: - Floating point to integer conversion are not allowed. - If the conversion is integer to floating point, the size of the floating point value does not matter as it will not affect the comparison result. - If the conversion is float to float, the size of the destination must be greater than or equal to the size of the source. - If the conversion is integer to integer, the size of the destination must be greater than or equal to the size of the source. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 17:15:03 -07:00
TEST_F(cmod_propagation_test, ior_f2i_nz)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_D);
brw_reg src0 = bld.vgrf(BRW_TYPE_D);
brw_reg src1 = bld.vgrf(BRW_TYPE_D);
intel/fs: Fix a cmod prop bug when the source type of a mov doesn't match the dest type of scan_inst We were previously operating with the mindset "a MOV is just a compare with zero." As a result, we were trying to share as much code between the MOV path and the CMP path as possible. However, MOV instructions can perform type conversions that affect the result of the comparison. There was some code added to better handle this for cases like and(16) g31<1>UD g20<8,8,1>UD g22<8,8,1>UD mov.nz.f0(16) null<1>F g31<8,8,1>D The flaw in these changed special cases is that it allowed things like or(8) dest:D src0:D src1:D mov.nz(8) null:D dest:F Because both destinations were integer types, the propagation was allowed. The source type of the MOV and the destination type of the OR do not match, so type conversion rules have to be accounted for. My solution was to just split the MOV and non-MOV paths with completely separate checks. The "else" path in this commit is basically the old code with the BRW_OPCODE_MOV special case removed. The new MOV code further splits into "destination of scan_inst is float" and "destination of scan_inst is integer" paths. For each case I enumerate the rules that I belive apply. For the integer path, only the "Z or NZ" rules are listed as only NZ is currently allowed (hence the conditional_mod assertion in that path). A later commit relaxes this and adds the rule. The new rules slightly relax one of the previous rules. Previously the sizes of the MOV destination and the MOV source had to be the same. In some cases now the sizes can be different by the following conditions: - Floating point to integer conversion are not allowed. - If the conversion is integer to floating point, the size of the floating point value does not matter as it will not affect the comparison result. - If the conversion is float to float, the size of the destination must be greater than or equal to the size of the source. - If the conversion is integer to integer, the size of the destination must be greater than or equal to the size of the source. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 17:15:03 -07:00
bld.OR(dest, src0, src1);
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
bld.MOV(bld.null_reg_d(), retype(dest, BRW_TYPE_F))
intel/fs: Fix a cmod prop bug when the source type of a mov doesn't match the dest type of scan_inst We were previously operating with the mindset "a MOV is just a compare with zero." As a result, we were trying to share as much code between the MOV path and the CMP path as possible. However, MOV instructions can perform type conversions that affect the result of the comparison. There was some code added to better handle this for cases like and(16) g31<1>UD g20<8,8,1>UD g22<8,8,1>UD mov.nz.f0(16) null<1>F g31<8,8,1>D The flaw in these changed special cases is that it allowed things like or(8) dest:D src0:D src1:D mov.nz(8) null:D dest:F Because both destinations were integer types, the propagation was allowed. The source type of the MOV and the destination type of the OR do not match, so type conversion rules have to be accounted for. My solution was to just split the MOV and non-MOV paths with completely separate checks. The "else" path in this commit is basically the old code with the BRW_OPCODE_MOV special case removed. The new MOV code further splits into "destination of scan_inst is float" and "destination of scan_inst is integer" paths. For each case I enumerate the rules that I belive apply. For the integer path, only the "Z or NZ" rules are listed as only NZ is currently allowed (hence the conditional_mod assertion in that path). A later commit relaxes this and adds the rule. The new rules slightly relax one of the previous rules. Previously the sizes of the MOV destination and the MOV source had to be the same. In some cases now the sizes can be different by the following conditions: - Floating point to integer conversion are not allowed. - If the conversion is integer to floating point, the size of the floating point value does not matter as it will not affect the comparison result. - If the conversion is float to float, the size of the destination must be greater than or equal to the size of the source. - If the conversion is integer to integer, the size of the destination must be greater than or equal to the size of the source. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 17:15:03 -07:00
->conditional_mod = BRW_CONDITIONAL_NZ;
/* = Before =
* 0: or(8) dest:D src0:D src1:D
* 1: mov.nz(8) null:D dest:F
*
* = After =
* No changes.
*
* If src0 = 0x30000000 and src1 = 0x0f000000, then the value stored in
* dest, interpreted as floating point, is 0.5. This bit pattern is not
* zero, but after the float-to-integer conversion, the value is zero.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Fix a cmod prop bug when the source type of a mov doesn't match the dest type of scan_inst We were previously operating with the mindset "a MOV is just a compare with zero." As a result, we were trying to share as much code between the MOV path and the CMP path as possible. However, MOV instructions can perform type conversions that affect the result of the comparison. There was some code added to better handle this for cases like and(16) g31<1>UD g20<8,8,1>UD g22<8,8,1>UD mov.nz.f0(16) null<1>F g31<8,8,1>D The flaw in these changed special cases is that it allowed things like or(8) dest:D src0:D src1:D mov.nz(8) null:D dest:F Because both destinations were integer types, the propagation was allowed. The source type of the MOV and the destination type of the OR do not match, so type conversion rules have to be accounted for. My solution was to just split the MOV and non-MOV paths with completely separate checks. The "else" path in this commit is basically the old code with the BRW_OPCODE_MOV special case removed. The new MOV code further splits into "destination of scan_inst is float" and "destination of scan_inst is integer" paths. For each case I enumerate the rules that I belive apply. For the integer path, only the "Z or NZ" rules are listed as only NZ is currently allowed (hence the conditional_mod assertion in that path). A later commit relaxes this and adds the rule. The new rules slightly relax one of the previous rules. Previously the sizes of the MOV destination and the MOV source had to be the same. In some cases now the sizes can be different by the following conditions: - Floating point to integer conversion are not allowed. - If the conversion is integer to floating point, the size of the floating point value does not matter as it will not affect the comparison result. - If the conversion is float to float, the size of the destination must be greater than or equal to the size of the source. - If the conversion is integer to integer, the size of the destination must be greater than or equal to the size of the source. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 17:15:03 -07:00
}
brw: Fix mov cmod propagation when there's int signedness mismatch If there's difference between scan_inst dest type and inst src type we should be more careful, because difference in signedness can cause incorrect results after the propagation. Updated ror-default.trace hash, as the change fixes misrendering there. Fixes: b23432c5 ("intel/fs: Fix a cmod prop bug when the source type of a mov doesn't match the dest type of scan_inst") Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30998>
2024-09-03 14:48:07 +03:00
TEST_F(cmod_propagation_test, uand_b2f_g)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw: Fix mov cmod propagation when there's int signedness mismatch If there's difference between scan_inst dest type and inst src type we should be more careful, because difference in signedness can cause incorrect results after the propagation. Updated ror-default.trace hash, as the change fixes misrendering there. Fixes: b23432c5 ("intel/fs: Fix a cmod prop bug when the source type of a mov doesn't match the dest type of scan_inst") Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30998>
2024-09-03 14:48:07 +03:00
brw_reg dest = bld.vgrf(BRW_TYPE_UD);
brw_reg src0 = bld.vgrf(BRW_TYPE_UD);
brw_reg src1 = bld.vgrf(BRW_TYPE_UD);
bld.AND(dest, src0, src1);
bld.MOV(bld.null_reg_f(), negate(retype(dest, BRW_TYPE_D)))
->conditional_mod = BRW_CONDITIONAL_G;
/* = Before =
* 0: and(8) dest:UD src0:UD src1:UD
* 1: mov.g(8) null:F -dest:D
*
* = After =
* No changes.
*
* If src0 and src1 are 0xffffffff, then dest:D will be interpreted as -1,
* and -dest:D will be 1, which is > 0.
* If the cmod was propagated (and.l(8) dest:UD src0:UD src1:UD),
* dest:UD can never be < 0.
*
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
brw: Fix mov cmod propagation when there's int signedness mismatch If there's difference between scan_inst dest type and inst src type we should be more careful, because difference in signedness can cause incorrect results after the propagation. Updated ror-default.trace hash, as the change fixes misrendering there. Fixes: b23432c5 ("intel/fs: Fix a cmod prop bug when the source type of a mov doesn't match the dest type of scan_inst") Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30998>
2024-09-03 14:48:07 +03:00
}
intel/fs: Fix a cmod prop bug when the source type of a mov doesn't match the dest type of scan_inst We were previously operating with the mindset "a MOV is just a compare with zero." As a result, we were trying to share as much code between the MOV path and the CMP path as possible. However, MOV instructions can perform type conversions that affect the result of the comparison. There was some code added to better handle this for cases like and(16) g31<1>UD g20<8,8,1>UD g22<8,8,1>UD mov.nz.f0(16) null<1>F g31<8,8,1>D The flaw in these changed special cases is that it allowed things like or(8) dest:D src0:D src1:D mov.nz(8) null:D dest:F Because both destinations were integer types, the propagation was allowed. The source type of the MOV and the destination type of the OR do not match, so type conversion rules have to be accounted for. My solution was to just split the MOV and non-MOV paths with completely separate checks. The "else" path in this commit is basically the old code with the BRW_OPCODE_MOV special case removed. The new MOV code further splits into "destination of scan_inst is float" and "destination of scan_inst is integer" paths. For each case I enumerate the rules that I belive apply. For the integer path, only the "Z or NZ" rules are listed as only NZ is currently allowed (hence the conditional_mod assertion in that path). A later commit relaxes this and adds the rule. The new rules slightly relax one of the previous rules. Previously the sizes of the MOV destination and the MOV source had to be the same. In some cases now the sizes can be different by the following conditions: - Floating point to integer conversion are not allowed. - If the conversion is integer to floating point, the size of the floating point value does not matter as it will not affect the comparison result. - If the conversion is float to float, the size of the destination must be greater than or equal to the size of the source. - If the conversion is integer to integer, the size of the destination must be greater than or equal to the size of the source. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 17:15:03 -07:00
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
void
cmod_propagation_test::test_mov_prop(enum brw_conditional_mod cmod,
enum brw_reg_type add_type,
enum brw_reg_type mov_dst_type,
bool expected_cmod_prop_progress)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, add_type);
brw_reg src0 = vgrf(bld, exp, add_type);
brw_reg src1 = vgrf(bld, exp, add_type);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
bld.ADD(dest, src0, src1);
bld.MOV(retype(bld.null_reg_ud(), mov_dst_type), dest)
->conditional_mod = cmod;
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS_RESULT(expected_cmod_prop_progress,
brw_opt_cmod_propagation, bld);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
if (expected_cmod_prop_progress) {
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest, src0, src1)->conditional_mod = cmod;
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
}
}
TEST_F(cmod_propagation_test, fadd_fmov_nz)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.nz(8) null:F dest:F
*
* = After =
* 0: add.nz(8) dest:F src0:F src1:F
*/
test_mov_prop(BRW_CONDITIONAL_NZ,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_F,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
true);
}
TEST_F(cmod_propagation_test, fadd_fmov_z)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.z(8) null:F dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* 0: add.z(8) dest:F src0:F src1:F
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*/
test_mov_prop(BRW_CONDITIONAL_Z,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_F,
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
true);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
}
TEST_F(cmod_propagation_test, fadd_fmov_l)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.l(8) null:F dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* 0: add.l(8) dest:F src0:F src1:F
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*/
test_mov_prop(BRW_CONDITIONAL_L,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_F,
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
true);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
}
TEST_F(cmod_propagation_test, fadd_fmov_g)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.g(8) null:F dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* 0: add.g(8) dest:F src0:F src1:F
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*/
test_mov_prop(BRW_CONDITIONAL_G,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_F,
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
true);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
}
TEST_F(cmod_propagation_test, fadd_fmov_le)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.le(8) null:F dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* 0: add.le(8) dest:F src0:F src1:F
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*/
test_mov_prop(BRW_CONDITIONAL_LE,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_F,
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
true);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
}
TEST_F(cmod_propagation_test, fadd_fmov_ge)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.ge(8) null:F dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* 0: add.ge(8) dest:F src0:F src1:F
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*/
test_mov_prop(BRW_CONDITIONAL_GE,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_F,
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
true);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
}
TEST_F(cmod_propagation_test, iadd_imov_nz)
{
/* = Before =
* 0: add(8) dest:D src0:D src1:D
* 1: mov.nz(8) null:D dest:D
*
* = After =
* 0: add.nz(8) dest:D src0:D src1:D
*/
test_mov_prop(BRW_CONDITIONAL_NZ,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D,
BRW_TYPE_D,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
true);
}
TEST_F(cmod_propagation_test, iadd_imov_z)
{
/* = Before =
* 0: add(8) dest:D src0:D src1:D
* 1: mov.z(8) null:D dest:D
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* 0: add.z(8) dest:D src0:D src1:D
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*/
test_mov_prop(BRW_CONDITIONAL_Z,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D,
BRW_TYPE_D,
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
true);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
}
TEST_F(cmod_propagation_test, iadd_imov_l)
{
/* = Before =
* 0: add(8) dest:D src0:D src1:D
* 1: mov.l(8) null:D dest:D
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* 0: add.l(8) dest:D src0:D src1:D
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*/
test_mov_prop(BRW_CONDITIONAL_L,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D,
BRW_TYPE_D,
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
true);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
}
TEST_F(cmod_propagation_test, iadd_imov_g)
{
/* = Before =
* 0: add(8) dest:D src0:D src1:D
* 1: mov.g(8) null:D dest:D
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* 0: add.g(8) dest:D src0:D src1:D
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*/
test_mov_prop(BRW_CONDITIONAL_G,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D,
BRW_TYPE_D,
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
true);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
}
TEST_F(cmod_propagation_test, iadd_imov_le)
{
/* = Before =
* 0: add(8) dest:D src0:D src1:D
* 1: mov.le(8) null:D dest:D
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* 0: add.le(8) dest:D src0:D src1:D
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*/
test_mov_prop(BRW_CONDITIONAL_LE,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D,
BRW_TYPE_D,
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
true);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
}
TEST_F(cmod_propagation_test, iadd_imov_ge)
{
/* = Before =
* 0: add(8) dest:D src0:D src1:D
* 1: mov.ge(8) null:D dest:D
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* 0: add.ge(8) dest:D src0:D src1:D
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*/
test_mov_prop(BRW_CONDITIONAL_GE,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D,
BRW_TYPE_D,
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
true);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
}
TEST_F(cmod_propagation_test, iadd_umov_nz)
{
/* = Before =
* 0: add(8) dest:D src0:D src1:D
* 1: mov.nz(8) null:UD dest:D
*
* = After =
* 0: add.nz(8) dest:D src0:D src1:D
*/
test_mov_prop(BRW_CONDITIONAL_NZ,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D,
BRW_TYPE_UD,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
true);
}
TEST_F(cmod_propagation_test, iadd_umov_z)
{
/* = Before =
* 0: add(8) dest:D src0:D src1:D
* 1: mov.z(8) null:UD dest:D
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* 0: add.z(8) dest:D src0:D src1:D
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*/
test_mov_prop(BRW_CONDITIONAL_Z,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D,
BRW_TYPE_UD,
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
true);
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
}
TEST_F(cmod_propagation_test, iadd_umov_l)
{
/* = Before =
* 0: add(8) dest:D src0:D src1:D
* 1: mov.l(8) null:UD dest:D
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* Due to the signed-to-usigned type conversion, the conditional modifier
* cannot be propagated to the ADD without changing at least the
* destination type of the add.
*
* This particular tests is a little silly. Unsigned less than zero is a
* contradiction, and earlier optimization passes should have eliminated
* it.
*/
test_mov_prop(BRW_CONDITIONAL_L,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D,
BRW_TYPE_UD,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, iadd_umov_g)
{
/* = Before =
* 0: add(8) dest:D src0:D src1:D
* 1: mov.g(8) null:UD dest:D
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* In spite of the type conversion, this could be made to work by
* propagating NZ instead of G to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_G,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D,
BRW_TYPE_UD,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, iadd_umov_le)
{
/* = Before =
* 0: add(8) dest:D src0:D src1:D
* 1: mov.le(8) null:UD dest:D
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* In spite of the type conversion, this could be made to work by
* propagating Z instead of LE to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_LE,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D,
BRW_TYPE_UD,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, iadd_umov_ge)
{
/* = Before =
* 0: add(8) dest:D src0:D src1:D
* 1: mov.ge(8) null:UD dest:D
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* Due to the signed-to-usigned type conversion, the conditional modifier
* cannot be propagated to the ADD without changing at least the
* destination type of the add.
*
* This particular tests is a little silly. Unsigned greater than or equal
* to zero is a tautology, and earlier optimization passes should have
* eliminated it.
*/
test_mov_prop(BRW_CONDITIONAL_GE,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D,
BRW_TYPE_UD,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, fadd_f2u_nz)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.nz(8) null:UD dest:F
*
* = After =
* No changes. The MOV changes the type from float to unsigned integer.
* If dest is in the range [-Inf, 1), the conversion will clamp it to zero.
* If dest is NaN, the conversion will also clamp it to zero. It is not
* safe to propagate the NZ back to the ADD.
*
* It's tempting to try to propagate G to the ADD in place of the NZ. This
* fails for values (0, 1). For example, if dest is 0.5, add.g would set
* the flag, but mov.nz would not because the 0.5 would get rounded down to
* zero.
*/
test_mov_prop(BRW_CONDITIONAL_NZ,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_UD,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, fadd_f2u_z)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.z(8) null:UD dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* The MOV changes the type from float to unsigned integer. If dest is in
* the range [-Inf, 1), the conversion will clamp it to zero. If dest is
* NaN, the conversion will also clamp it to zero. It is not safe to
* propagate the Z back to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_Z,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_UD,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, fadd_f2u_l)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.l(8) null:UD dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* The MOV changes the type from float to unsigned integer. If dest is in
* the range [-Inf, 1), the conversion will clamp it to zero. If dest is
* NaN, the conversion will also clamp it to zero. It is not safe to
* propagate the L back to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_L,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_UD,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, fadd_f2u_g)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.g(8) null:UD dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* The MOV changes the type from float to unsigned integer. If dest is in
* the range [-Inf, 1), the conversion will clamp it to zero. If dest is
* NaN, the conversion will also clamp it to zero. It is not safe to
* propagate the G back to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_G,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_UD,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, fadd_f2u_le)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.le(8) null:UD dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* The MOV changes the type from float to unsigned integer. If dest is in
* the range [-Inf, 1), the conversion will clamp it to zero. If dest is
* NaN, the conversion will also clamp it to zero. It is not safe to
* propagate the LE back to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_LE,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_UD,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, fadd_f2u_ge)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.ge(8) null:UD dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* The MOV changes the type from float to unsigned integer. If dest is in
* the range [-Inf, 1), the conversion will clamp it to zero. If dest is
* NaN, the conversion will also clamp it to zero. It is not safe to
* propagate the GE back to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_GE,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_UD,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, fadd_f2i_nz)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.nz(8) null:D dest:F
*
* = After =
* No changes. The MOV changes the type from float to signed integer. If
* dest is in the range (-1, 1), the conversion will clamp it to zero. If
* dest is NaN, the conversion will also clamp it to zero. It is not safe
* to propagate the NZ back to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_NZ,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_D,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, fadd_f2i_z)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.z(8) null:D dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* The MOV changes the type from float to signed integer. If dest is in
* the range (-1, 1), the conversion will clamp it to zero. If dest is
* NaN, the conversion will also clamp it to zero. It is not safe to
* propagate the Z back to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_Z,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_D,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, fadd_f2i_l)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.l(8) null:D dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* The MOV changes the type from float to signed integer. If dest is in
* the range (-1, 1), the conversion will clamp it to zero. If dest is
* NaN, the conversion will also clamp it to zero. It is not safe to
* propagate the L back to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_L,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_D,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, fadd_f2i_g)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.g(8) null:D dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* The MOV changes the type from float to signed integer. If dest is in
* the range (-1, 1), the conversion will clamp it to zero. If dest is
* NaN, the conversion will also clamp it to zero. It is not safe to
* propagate the G back to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_G,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_D,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, fadd_f2i_le)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.le(8) null:D dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* The MOV changes the type from float to signed integer. If dest is in
* the range (-1, 1), the conversion will clamp it to zero. If dest is
* NaN, the conversion will also clamp it to zero. It is not safe to
* propagate the LE back to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_LE,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_D,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
TEST_F(cmod_propagation_test, fadd_f2i_ge)
{
/* = Before =
* 0: add(8) dest:F src0:F src1:F
* 1: mov.ge(8) null:D dest:F
*
* = After =
intel/fs: cmod propagate from MOV with any condition There were tests related to propagating conditional modifiers from a MOV to an instruction with a .SAT modifier for a very long time, but they were #if'ed out. There are restrictions later in the function that limit the kinds of MOV instructions that can propagate. This avoids the dangers of type-converting MOVs that may generate flags in different ways. v2: Update the added comment to look more like the existing comment. That makes the small differences between the two cases more obvious. Noticed by Marcin. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 19827127 -> 19826924 (<.01%) instructions in affected programs: 62024 -> 61821 (-0.33%) helped: 201 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1 helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36% 95% mean confidence interval for instructions value: -1.02 -1.00 95% mean confidence interval for instructions %-change: -0.36% -0.34% Instructions are helped. total cycles in shared programs: 954655879 -> 954655356 (<.01%) cycles in affected programs: 1212877 -> 1212354 (-0.04%) helped: 155 HURT: 6 helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4 helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07% HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8 HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15% 95% mean confidence interval for cycles value: -3.60 -2.90 95% mean confidence interval for cycles %-change: -0.07% -0.05% Cycles are helped. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:09:11 -07:00
* No changes.
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
*
* The MOV changes the type from float to signed integer. If dest is in
* the range (-1, 1), the conversion will clamp it to zero. If dest is
* NaN, the conversion will also clamp it to zero. It is not safe to
* propagate the GE back to the ADD.
*/
test_mov_prop(BRW_CONDITIONAL_GE,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F,
BRW_TYPE_D,
intel/fs: Add many cmod propagation tests involving MOV instructions Of particular interest are the tests where the MOV performs a type conversion. If the restriction on conditional modifier for a MOV is ever relaxed, some of these cases must still be disallowed. v2: s/NZ/Z/ in one of the comments. Notice by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 16:04:09 -07:00
false);
}
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
void
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
cmod_propagation_test::test_saturate_prop(enum brw_conditional_mod before,
enum opcode op,
enum brw_reg_type add_type,
enum brw_reg_type op_type,
bool expected_cmod_prop_progress)
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, add_type);
brw_reg src0 = vgrf(bld, exp, add_type);
brw_reg src1 = vgrf(bld, exp, add_type);
brw_reg zero = brw_imm_ud(0);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
bld.ADD(dest, src0, src1)->saturate = true;
assert(op == BRW_OPCODE_CMP || op == BRW_OPCODE_MOV);
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
if (op == BRW_OPCODE_CMP) {
bld.CMP(bld.vgrf(op_type, 0),
retype(dest, op_type),
retype(zero, op_type),
before);
} else {
bld.MOV(bld.vgrf(op_type, 0), retype(dest, op_type))
->conditional_mod = before;
}
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS_RESULT(expected_cmod_prop_progress,
brw_opt_cmod_propagation, bld);
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
if (expected_cmod_prop_progress) {
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_inst *add = exp.ADD(dest, src0, src1);
add->saturate = true;
add->conditional_mod = before;
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
}
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, float_saturate_nz_cmp)
{
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
/* With the saturate modifier, the comparison happens after clamping to
* [0, 1].
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: cmp.nz.f0(8) null dest 0.0f
*
* = After =
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
* 0: add.sat.nz.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_NZ, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F, BRW_TYPE_F,
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, float_saturate_nz_mov)
{
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
/* With the saturate modifier, the comparison happens after clamping to
* [0, 1].
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: mov.nz.f0(8) null dest
*
* = After =
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
* 0: add.sat.nz.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_NZ, BRW_OPCODE_MOV,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F, BRW_TYPE_F,
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, float_saturate_z_cmp)
{
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
/* With the saturate modifier, the comparison happens after clamping to
* [0, 1].
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: cmp.z.f0(8) null dest 0.0f
*
* = After =
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
* 0: add.sat.z.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_Z, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F, BRW_TYPE_F,
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, float_saturate_z_mov)
{
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
/* With the saturate modifier, the comparison happens after clamping to
* [0, 1].
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: mov.z.f0(8) null dest
*
* = After =
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
* 0: add.sat.z.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_Z, BRW_OPCODE_MOV,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F, BRW_TYPE_F,
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, float_saturate_g_cmp)
{
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
/* With the saturate modifier, the comparison happens after clamping to
* [0, 1].
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: cmp.g.f0(8) null dest 0.0f
*
* = After =
* 0: add.sat.g.f0(8) dest src0 src1
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_G, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F, BRW_TYPE_F,
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, float_saturate_g_mov)
{
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
/* With the saturate modifier, the comparison happens after clamping to
* [0, 1].
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: mov.g.f0(8) null dest
*
* = After =
* 0: add.sat.g.f0(8) dest src0 src1
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_G, BRW_OPCODE_MOV,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F, BRW_TYPE_F,
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, float_saturate_le_cmp)
{
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
/* With the saturate modifier, the comparison happens after clamping to
* [0, 1].
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: cmp.le.f0(8) null dest 0.0f
*
* = After =
* 0: add.sat.le.f0(8) dest src0 src1
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_LE, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F, BRW_TYPE_F,
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, float_saturate_le_mov)
{
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
/* With the saturate modifier, the comparison happens after clamping to
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
* [0, 1]. (sat(x) <= 0) == (x <= 0).
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: mov.le.f0(8) null dest
*
* = After =
* 0: add.sat.le.f0(8) dest src0 src1
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_LE, BRW_OPCODE_MOV,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F, BRW_TYPE_F,
intel/fs: Refactor some cmod propagation tests This will simplify some later changes to these tests. v2: Combine test_positive_saturate_prop and test_negative_saturate_prop into a single function. Suggested by Marcin. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-21 13:56:34 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, float_saturate_l_cmp)
{
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
/* With the saturate modifier, the comparison happens after clamping to
* [0, 1].
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: cmp.l.f0(8) null dest 0.0f
*
* = After =
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
* 0: add.sat.l.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_L, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F, BRW_TYPE_F,
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, float_saturate_l_mov)
{
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
/* With the saturate modifier, the comparison happens after clamping to
* [0, 1].
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
* 1: mov.l.f0(8) null dest
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = After =
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
* 0: add.sat.l.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_L, BRW_OPCODE_MOV,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F, BRW_TYPE_F,
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, float_saturate_ge_cmp)
{
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
/* With the saturate modifier, the comparison happens after clamping to
* [0, 1].
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: cmp.ge.f0(8) null dest 0.0f
*
* = After =
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
* 0: add.sat.ge.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_GE, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F, BRW_TYPE_F,
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, float_saturate_ge_mov)
{
/* With the saturate modifier, the comparison happens before clamping to
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
* [0, 1].
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
* 1: mov.ge.f0(8) null dest
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*
* = After =
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
* 0: add.sat.ge.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_GE, BRW_OPCODE_MOV,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_F, BRW_TYPE_F,
intel/fs: Remove condition-based restriction for cmod propagation to saturated operations I don't know why the float_saturate_l_mov test was #if'ed out, but it passes... so this commit enables it. No shader-db or fossil-db changes. In a previous iteration of this MR, this commit helped ~200 shaders in shader-db. Now all of those same shaders are helped by "intel/fs: cmod propagate from MOV with any condition". All of these shaders come from Mad Max. After initial translation from NIR to assembly, these shader contain patterns like: mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat(8) g90<1>F g90<8,8,1>F ... cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */ An initial pass of cmod propagation converts this to mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit, XX is G. With this commit, XX is NZ. Saturate propagation moves the saturate: mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ ... mov.XX.f0(8) g90<1>F g90<8,8,1>F Without this commit (but with "intel/fs: cmod propagate from MOV with any condition"), the G gets propagated: mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ With this commit (with or without "intel/fs: cmod propagate from MOV with any condition"), the NZ gets propagated: mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */ Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:15:50 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, int_saturate_nz_cmp)
{
/* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: cmp.nz.f0(8) null dest 0
*
* = After =
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
* 0: add.sat.nz.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_NZ, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
}
TEST_F(cmod_propagation_test, uint_saturate_nz_cmp)
{
/* = Before =
*
* 0: add.sat(8) dest:UD src0:UD src1:UD
* 1: cmp.nz.f0(8) null:D dest:D 0
*
* = After =
* 0: add.sat.nz.f0(8) dest:UD src0:UD src1:UD
*/
test_saturate_prop(BRW_CONDITIONAL_NZ, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_UD, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, int_saturate_nz_mov)
{
/* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: mov.nz.f0(8) null dest
*
* = After =
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
* 0: add.sat.nz.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_NZ, BRW_OPCODE_MOV,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, int_saturate_z_cmp)
{
/* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: cmp.z.f0(8) null dest 0
*
* = After =
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
* 0: add.sat.z.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_Z, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
}
TEST_F(cmod_propagation_test, uint_saturate_z_cmp)
{
/* = Before =
*
* 0: add.sat(8) dest:UD src0:UD src1:UD
* 1: cmp.z.f0(8) null:D dest:D 0
*
* = After =
* 0: add.sat.z.f0(8) dest:UD src0:UD src1:UD
*/
test_saturate_prop(BRW_CONDITIONAL_Z, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_UD, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, int_saturate_z_mov)
{
/* With the saturate modifier, the comparison happens before clamping to
* [0, 1]. (sat(x) == 0) == (x <= 0).
*
* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: mov.z.f0(8) null dest
*
* = After =
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
* 0: add.sat.z.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_Z, BRW_OPCODE_MOV,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, int_saturate_g_cmp)
{
/* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: cmp.g.f0(8) null dest 0
*
* = After =
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
* 0: add.sat.g.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_G, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, int_saturate_g_mov)
{
/* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: mov.g.f0(8) null dest
*
* = After =
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
* 0: add.sat.g.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_G, BRW_OPCODE_MOV,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, int_saturate_le_cmp)
{
/* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: cmp.le.f0(8) null dest 0
*
* = After =
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
* 0: add.sat.le.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_LE, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, int_saturate_le_mov)
{
/* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: mov.le.f0(8) null dest
*
* = After =
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
* 0: add.sat.le.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_LE, BRW_OPCODE_MOV,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, int_saturate_l_cmp)
{
/* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: cmp.l.f0(8) null dest 0
*
* = After =
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
* 0: add.sat.l.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_L, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, int_saturate_l_mov)
{
/* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: mov.l.f0(8) null dest 0
*
* = After =
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
* 0: add.sat.l.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_L, BRW_OPCODE_MOV,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, int_saturate_ge_cmp)
{
/* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: cmp.ge.f0(8) null dest 0
*
* = After =
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
* 0: add.sat.ge.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_GE, BRW_OPCODE_CMP,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
TEST_F(cmod_propagation_test, int_saturate_ge_mov)
{
/* = Before =
*
* 0: add.sat(8) dest src0 src1
* 1: mov.ge.f0(8) null dest
*
* = After =
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
* 0: add.sat.ge.f0(8) dest src0 src1
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
*/
intel/fs: Remove after parameter from test_saturate_prop Originally this was part of "intel/fs: Remove condition-based restriction for cmod propagation to saturated operations". With some additional changes to that commit, it caused a lot of extra churn in the unit tests. I felt that made it harder to see the actual changes in the unit tests, so I split it out. Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-08-17 12:11:09 -07:00
test_saturate_prop(BRW_CONDITIONAL_GE, BRW_OPCODE_MOV,
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
BRW_TYPE_D, BRW_TYPE_D,
intel/fs: Remove type-based restriction for cmod propagation to saturated operations Previously, we misunderstood how conditional modifiers and saturate interacted. We thought the condition was evaulated before the saturate was applied. For the floating point cases, we went to some heroics to modify the condition to maintain the same results. For integer cases, it was not clear that this could even work. We had no use-cases and no tests-cases, so we just disallowed everything. Now we understand that the condition is evaluated after the saturate. Earlier commits in this series removed the various floating point heroics. It is easier to just delete the code that prevents some cases that just work. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
2021-07-16 18:16:59 -07:00
true);
intel/fs: Allow cmod propagation to instructions with saturate modifier v2: Add unit tests. Suggested by Matt. All Intel GPUs had similar results. (Ice Lake shown) total instructions in shared programs: 17229441 -> 17228658 (<.01%) instructions in affected programs: 159574 -> 158791 (-0.49%) helped: 489 HURT: 0 helped stats (abs) min: 1 max: 5 x̄: 1.60 x̃: 1 helped stats (rel) min: 0.07% max: 2.70% x̄: 0.61% x̃: 0.59% 95% mean confidence interval for instructions value: -1.72 -1.48 95% mean confidence interval for instructions %-change: -0.64% -0.58% Instructions are helped. total cycles in shared programs: 360944149 -> 360937144 (<.01%) cycles in affected programs: 1072195 -> 1065190 (-0.65%) helped: 254 HURT: 27 helped stats (abs) min: 2 max: 234 x̄: 30.51 x̃: 9 helped stats (rel) min: 0.04% max: 8.99% x̄: 0.75% x̃: 0.24% HURT stats (abs) min: 2 max: 83 x̄: 27.56 x̃: 24 HURT stats (rel) min: 0.09% max: 3.79% x̄: 1.28% x̃: 1.16% 95% mean confidence interval for cycles value: -30.11 -19.75 95% mean confidence interval for cycles %-change: -0.70% -0.41% Cycles are helped. Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
2019-03-11 15:49:26 -07:00
}
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
TEST_F(cmod_propagation_test, not_to_or)
{
/* Exercise propagation of conditional modifier from a NOT instruction to
* another ALU instruction as performed by cmod_propagate_not.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_UD);
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
bld.OR(dest, src0, src1);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
bld.NOT(bld.null_reg_ud(), dest)->conditional_mod = BRW_CONDITIONAL_NZ;
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
/* = Before =
*
* 0: or(8) dest src0 src1
* 1: not.nz.f0(8) null dest
*
* = After =
* 0: or.z.f0(8) dest src0 src1
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.OR(dest, src0, src1)->conditional_mod = BRW_CONDITIONAL_Z;
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
}
TEST_F(cmod_propagation_test, not_to_and)
{
/* Exercise propagation of conditional modifier from a NOT instruction to
* another ALU instruction as performed by cmod_propagate_not.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_reg dest = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_UD);
bld.AND(dest, src0, src1);
bld.NOT(bld.null_reg_ud(), dest)->conditional_mod = BRW_CONDITIONAL_NZ;
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.AND(dest, src0, src1)->conditional_mod = BRW_CONDITIONAL_Z;
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
}
TEST_F(cmod_propagation_test, not_to_uadd)
{
/* Exercise propagation of conditional modifier from a NOT instruction to
* another ALU instruction as performed by cmod_propagate_not.
*
* The optimization pass currently restricts to just OR and AND. It's
* possible that this is too restrictive, and the actual, necessary
* restriction is just the the destination type of the ALU instruction is
* the same as the source type of the NOT instruction.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_UD);
brw_reg src0 = bld.vgrf(BRW_TYPE_UD);
brw_reg src1 = bld.vgrf(BRW_TYPE_UD);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
bld.ADD(dest, src0, src1);
set_condmod(BRW_CONDITIONAL_NZ, bld.NOT(bld.null_reg_ud(), dest));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
}
TEST_F(cmod_propagation_test, not_to_fadd_to_ud)
{
/* Exercise propagation of conditional modifier from a NOT instruction to
* another ALU instruction as performed by cmod_propagate_not.
*
* The optimization pass currently restricts to just OR and AND. It's
* possible that this is too restrictive, and the actual, necessary
* restriction is just the the destination type of the ALU instruction is
* the same as the source type of the NOT instruction.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_UD);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg src1 = bld.vgrf(BRW_TYPE_F);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
bld.ADD(dest, src0, src1);
set_condmod(BRW_CONDITIONAL_NZ, bld.NOT(bld.null_reg_ud(), dest));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
}
TEST_F(cmod_propagation_test, not_to_fadd)
{
/* Exercise propagation of conditional modifier from a NOT instruction to
* another ALU instruction as performed by cmod_propagate_not.
*
* The optimization pass currently restricts to just OR and AND. It's
* possible that this is too restrictive, and the actual, necessary
* restriction is just the the destination type of the ALU instruction is
* the same as the source type of the NOT instruction.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg src1 = bld.vgrf(BRW_TYPE_F);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
bld.ADD(dest, src0, src1);
set_condmod(BRW_CONDITIONAL_NZ,
bld.NOT(bld.null_reg_ud(),
intel/brw: Stop using long BRW_REGISTER_TYPE enum names s/BRW_REGISTER_TYPE/BRW_TYPE/g Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-20 17:08:02 -07:00
retype(dest, BRW_TYPE_UD)));
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
}
TEST_F(cmod_propagation_test, not_to_or_intervening_flag_read_compatible_value)
{
/* Exercise propagation of conditional modifier from a NOT instruction to
* another ALU instruction as performed by cmod_propagate_not.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest0 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg dest1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg src2 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0.0f);
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
set_condmod(BRW_CONDITIONAL_Z, bld.OR(dest0, src0, src1));
set_predicate(BRW_PREDICATE_NORMAL, bld.SEL(dest1, src2, zero));
set_condmod(BRW_CONDITIONAL_NZ, bld.NOT(bld.null_reg_ud(), dest0));
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
set_condmod(BRW_CONDITIONAL_Z, exp.OR(dest0, src0, src1));
set_predicate(BRW_PREDICATE_NORMAL, exp.SEL(dest1, src2, zero));
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
}
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
TEST_F(cmod_propagation_test,
not_to_or_intervening_flag_read_compatible_value_mismatch_flag)
{
/* Exercise propagation of conditional modifier from a NOT instruction to
* another ALU instruction as performed by cmod_propagate_not.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest0 = bld.vgrf(BRW_TYPE_UD);
brw_reg dest1 = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_UD);
brw_reg src1 = bld.vgrf(BRW_TYPE_UD);
brw_reg src2 = bld.vgrf(BRW_TYPE_F);
brw_reg zero(brw_imm_f(0.0f));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
set_condmod(BRW_CONDITIONAL_Z, bld.OR(dest0, src0, src1))
->flag_subreg = 1;
set_predicate(BRW_PREDICATE_NORMAL, bld.SEL(dest1, src2, zero));
set_condmod(BRW_CONDITIONAL_NZ, bld.NOT(bld.null_reg_ud(), dest0));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Fix flag_subreg handling in cmod propagation There were two errors. First, the pass could propagate conditional modifiers from an instruction that writes on flag register to an instruction that writes a different flag register. For example, cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F cmp.nz.f0.1(16) null:F, vgrf6:F, vgrf5:F could be come cmp.nz.f0.0(16) null:F, vgrf6:F, vgrf5:F Second, if an instruction writes f0.1 has it's condition propagated, the modified instruction will incorrectly write flag f0.0. For example, linterp(16) vgrf6:F, g2:F, attr0:F cmp.z.f0.1(16) null:F, vgrf6:F, vgrf5:F (-f0.1) discard_jump(16) (null):UD could become linterp.z.f0.0(16) vgrf6:F, g2:F, attr0:F (-f0.1) discard_jump(16) (null):UD None of these cases will occur currently. The only time we use f0.1 is for generating discard intrinsics. In all those cases, we generate a squence like: cmp.nz.f0.0(16) vgrf7:F, vgrf6:F, vgrf5:F (+f0.1) cmp.z(16) null:D, vgrf7:D, 0d (-f0.1) discard_jump(16) (null):UD Due to the mixed types and incompatible conditions, this sequence would never see any cmod propagation. The next patch will change this. No shader-db changes on any Intel platform. v2: Fix typo in comment in test case subtract_delete_compare_other_flag. Noticed by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 10:18:06 -07:00
}
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
TEST_F(cmod_propagation_test, not_to_or_intervening_flag_read_incompatible_value)
{
/* Exercise propagation of conditional modifier from a NOT instruction to
* another ALU instruction as performed by cmod_propagate_not.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest0 = bld.vgrf(BRW_TYPE_UD);
brw_reg dest1 = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_UD);
brw_reg src1 = bld.vgrf(BRW_TYPE_UD);
brw_reg src2 = bld.vgrf(BRW_TYPE_F);
brw_reg zero(brw_imm_f(0.0f));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
set_condmod(BRW_CONDITIONAL_NZ, bld.OR(dest0, src0, src1));
set_predicate(BRW_PREDICATE_NORMAL, bld.SEL(dest1, src2, zero));
set_condmod(BRW_CONDITIONAL_NZ, bld.NOT(bld.null_reg_ud(), dest0));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Add missing tests for cmod_propagate_not Tests like this should have been added in 4467040cb65 ("i965/fs: Propagate conditional modifiers from not instructions"). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 11:06:19 -07:00
}
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
TEST_F(cmod_propagation_test, not_to_or_intervening_mismatch_flag_write)
{
/* Exercise propagation of conditional modifier from a NOT instruction to
* another ALU instruction as performed by cmod_propagate_not.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest0 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg dest1 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_UD);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
bld.OR(dest0, src0, src1);
set_condmod(BRW_CONDITIONAL_Z, bld.OR(dest1, src0, src1))
->flag_subreg = 1;
set_condmod(BRW_CONDITIONAL_NZ, bld.NOT(bld.null_reg_ud(), dest0));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
set_condmod(BRW_CONDITIONAL_Z, exp.OR(dest0, src0, src1));
set_condmod(BRW_CONDITIONAL_Z, exp.OR(dest1, src0, src1))
->flag_subreg = 1;
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
}
TEST_F(cmod_propagation_test, not_to_or_intervening_mismatch_flag_read)
{
/* Exercise propagation of conditional modifier from a NOT instruction to
* another ALU instruction as performed by cmod_propagate_not.
*/
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest0 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg dest1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_UD);
brw_reg src2 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0.0f);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
bld.OR(dest0, src0, src1);
set_predicate(BRW_PREDICATE_NORMAL, bld.SEL(dest1, src2, zero))
->flag_subreg = 1;
set_condmod(BRW_CONDITIONAL_NZ, bld.NOT(bld.null_reg_ud(), dest0));
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.OR(dest0, src0, src1)->conditional_mod = BRW_CONDITIONAL_Z;
set_predicate(BRW_PREDICATE_NORMAL, exp.SEL(dest1, src2, zero))
->flag_subreg = 1;
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: Allow cmod propagation across reads and writes of different flags This also helps a later patch (intel/fs: Improve discard_if code generation) on about 200 shaders. v2: Document that other instruction sequences are also valid in subtract_merge_with_compare_intervening_mismatch_flag_write. Suggested by Caio. All Intel platforms had similar results. (Ice Lake shown) total instructions in shared programs: 17224438 -> 17224434 (<.01%) instructions in affected programs: 296 -> 292 (-1.35%) helped: 4 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.99% max: 1.92% x̄: 1.43% x̃: 1.40% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.04% -0.81% Instructions are helped. total cycles in shared programs: 361468455 -> 361468458 (<.01%) cycles in affected programs: 2862 -> 2865 (0.10%) helped: 2 HURT: 2 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.24% max: 0.39% x̄: 0.31% x̃: 0.31% HURT stats (abs) min: 3 max: 4 x̄: 3.50 x̃: 3 HURT stats (rel) min: 0.32% max: 0.70% x̄: 0.51% x̃: 0.51% 95% mean confidence interval for cycles value: -4.34 5.84 95% mean confidence interval for cycles %-change: -0.70% 0.90% Inconclusive result (value mean confidence interval includes 0). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2019-05-22 12:32:03 -07:00
}
intel/compiler: don't propagate cmp to add if add is saturated From the Kaby Lake PRM Vol. 7 "Assigning Conditional Flags": * Note that the [post condition signal] bits generated at the output of a compute are before the .sat. Paragraph about post_zero does not mention saturation, but testing it on actual GPUs shows that conditional modifiers are applied after saturation. * post_zero bit: This bit reflects whether the final result is zero after all the clamping, normalizing, or format conversion logic. For signed types we don't care about saturation: it won't change the result of conditional modifier. For floating and unsigned types there two special cases, when we can remove inst even if scan_inst is saturated: G and LE. Since conditional modifiers are just comparations against zero, saturating positive values to the upper limit never changes the result of comparation. For negative values: (sat(x) > 0) == (x > 0) --- false (sat(x) <= 0) == (x <= 0) --- true Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2610 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4167>
2020-03-12 19:42:37 +02:00
TEST_F(cmod_propagation_test, cmp_to_add_float_e)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
intel/brw: Replace uses of fs_reg with brw_reg And remove the fs_reg alias. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29791>
2024-06-18 23:42:59 -07:00
brw_reg dest = bld.vgrf(BRW_TYPE_F);
brw_reg src0 = bld.vgrf(BRW_TYPE_F);
brw_reg neg10(brw_imm_f(-10.0f));
brw_reg pos10(brw_imm_f(10.0f));
intel/compiler: don't propagate cmp to add if add is saturated From the Kaby Lake PRM Vol. 7 "Assigning Conditional Flags": * Note that the [post condition signal] bits generated at the output of a compute are before the .sat. Paragraph about post_zero does not mention saturation, but testing it on actual GPUs shows that conditional modifiers are applied after saturation. * post_zero bit: This bit reflects whether the final result is zero after all the clamping, normalizing, or format conversion logic. For signed types we don't care about saturation: it won't change the result of conditional modifier. For floating and unsigned types there two special cases, when we can remove inst even if scan_inst is saturated: G and LE. Since conditional modifiers are just comparations against zero, saturating positive values to the upper limit never changes the result of comparation. For negative values: (sat(x) > 0) == (x > 0) --- false (sat(x) <= 0) == (x <= 0) --- true Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2610 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4167>
2020-03-12 19:42:37 +02:00
bld.ADD(dest, src0, neg10)->saturate = true;
bld.CMP(bld.null_reg_f(), src0, pos10, BRW_CONDITIONAL_EQ);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_NO_PROGRESS(brw_opt_cmod_propagation, bld);
intel/compiler: don't propagate cmp to add if add is saturated From the Kaby Lake PRM Vol. 7 "Assigning Conditional Flags": * Note that the [post condition signal] bits generated at the output of a compute are before the .sat. Paragraph about post_zero does not mention saturation, but testing it on actual GPUs shows that conditional modifiers are applied after saturation. * post_zero bit: This bit reflects whether the final result is zero after all the clamping, normalizing, or format conversion logic. For signed types we don't care about saturation: it won't change the result of conditional modifier. For floating and unsigned types there two special cases, when we can remove inst even if scan_inst is saturated: G and LE. Since conditional modifiers are just comparations against zero, saturating positive values to the upper limit never changes the result of comparation. For negative values: (sat(x) > 0) == (x > 0) --- false (sat(x) <= 0) == (x <= 0) --- true Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2610 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4167>
2020-03-12 19:42:37 +02:00
}
TEST_F(cmod_propagation_test, cmp_to_add_float_g)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg neg10 = brw_imm_f(-10.0f);
brw_reg pos10 = brw_imm_f(10.0f);
intel/compiler: don't propagate cmp to add if add is saturated From the Kaby Lake PRM Vol. 7 "Assigning Conditional Flags": * Note that the [post condition signal] bits generated at the output of a compute are before the .sat. Paragraph about post_zero does not mention saturation, but testing it on actual GPUs shows that conditional modifiers are applied after saturation. * post_zero bit: This bit reflects whether the final result is zero after all the clamping, normalizing, or format conversion logic. For signed types we don't care about saturation: it won't change the result of conditional modifier. For floating and unsigned types there two special cases, when we can remove inst even if scan_inst is saturated: G and LE. Since conditional modifiers are just comparations against zero, saturating positive values to the upper limit never changes the result of comparation. For negative values: (sat(x) > 0) == (x > 0) --- false (sat(x) <= 0) == (x <= 0) --- true Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2610 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4167>
2020-03-12 19:42:37 +02:00
bld.ADD(dest, src0, neg10)->saturate = true;
bld.CMP(bld.null_reg_f(), src0, pos10, BRW_CONDITIONAL_G);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/compiler: don't propagate cmp to add if add is saturated From the Kaby Lake PRM Vol. 7 "Assigning Conditional Flags": * Note that the [post condition signal] bits generated at the output of a compute are before the .sat. Paragraph about post_zero does not mention saturation, but testing it on actual GPUs shows that conditional modifiers are applied after saturation. * post_zero bit: This bit reflects whether the final result is zero after all the clamping, normalizing, or format conversion logic. For signed types we don't care about saturation: it won't change the result of conditional modifier. For floating and unsigned types there two special cases, when we can remove inst even if scan_inst is saturated: G and LE. Since conditional modifiers are just comparations against zero, saturating positive values to the upper limit never changes the result of comparation. For negative values: (sat(x) > 0) == (x > 0) --- false (sat(x) <= 0) == (x <= 0) --- true Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2610 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4167>
2020-03-12 19:42:37 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_inst *add = exp.ADD(dest, src0, neg10);
add->saturate = true;
add->conditional_mod = BRW_CONDITIONAL_G;
intel/compiler: don't propagate cmp to add if add is saturated From the Kaby Lake PRM Vol. 7 "Assigning Conditional Flags": * Note that the [post condition signal] bits generated at the output of a compute are before the .sat. Paragraph about post_zero does not mention saturation, but testing it on actual GPUs shows that conditional modifiers are applied after saturation. * post_zero bit: This bit reflects whether the final result is zero after all the clamping, normalizing, or format conversion logic. For signed types we don't care about saturation: it won't change the result of conditional modifier. For floating and unsigned types there two special cases, when we can remove inst even if scan_inst is saturated: G and LE. Since conditional modifiers are just comparations against zero, saturating positive values to the upper limit never changes the result of comparation. For negative values: (sat(x) > 0) == (x > 0) --- false (sat(x) <= 0) == (x <= 0) --- true Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2610 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4167>
2020-03-12 19:42:37 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/compiler: don't propagate cmp to add if add is saturated From the Kaby Lake PRM Vol. 7 "Assigning Conditional Flags": * Note that the [post condition signal] bits generated at the output of a compute are before the .sat. Paragraph about post_zero does not mention saturation, but testing it on actual GPUs shows that conditional modifiers are applied after saturation. * post_zero bit: This bit reflects whether the final result is zero after all the clamping, normalizing, or format conversion logic. For signed types we don't care about saturation: it won't change the result of conditional modifier. For floating and unsigned types there two special cases, when we can remove inst even if scan_inst is saturated: G and LE. Since conditional modifiers are just comparations against zero, saturating positive values to the upper limit never changes the result of comparation. For negative values: (sat(x) > 0) == (x > 0) --- false (sat(x) <= 0) == (x <= 0) --- true Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2610 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4167>
2020-03-12 19:42:37 +02:00
}
TEST_F(cmod_propagation_test, cmp_to_add_float_le)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg neg10 = brw_imm_f(-10.0f);
brw_reg pos10 = brw_imm_f(10.0f);
intel/compiler: don't propagate cmp to add if add is saturated From the Kaby Lake PRM Vol. 7 "Assigning Conditional Flags": * Note that the [post condition signal] bits generated at the output of a compute are before the .sat. Paragraph about post_zero does not mention saturation, but testing it on actual GPUs shows that conditional modifiers are applied after saturation. * post_zero bit: This bit reflects whether the final result is zero after all the clamping, normalizing, or format conversion logic. For signed types we don't care about saturation: it won't change the result of conditional modifier. For floating and unsigned types there two special cases, when we can remove inst even if scan_inst is saturated: G and LE. Since conditional modifiers are just comparations against zero, saturating positive values to the upper limit never changes the result of comparation. For negative values: (sat(x) > 0) == (x > 0) --- false (sat(x) <= 0) == (x <= 0) --- true Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2610 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4167>
2020-03-12 19:42:37 +02:00
bld.ADD(dest, src0, neg10)->saturate = true;
bld.CMP(bld.null_reg_f(), src0, pos10, BRW_CONDITIONAL_LE);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/compiler: don't propagate cmp to add if add is saturated From the Kaby Lake PRM Vol. 7 "Assigning Conditional Flags": * Note that the [post condition signal] bits generated at the output of a compute are before the .sat. Paragraph about post_zero does not mention saturation, but testing it on actual GPUs shows that conditional modifiers are applied after saturation. * post_zero bit: This bit reflects whether the final result is zero after all the clamping, normalizing, or format conversion logic. For signed types we don't care about saturation: it won't change the result of conditional modifier. For floating and unsigned types there two special cases, when we can remove inst even if scan_inst is saturated: G and LE. Since conditional modifiers are just comparations against zero, saturating positive values to the upper limit never changes the result of comparation. For negative values: (sat(x) > 0) == (x > 0) --- false (sat(x) <= 0) == (x <= 0) --- true Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2610 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4167>
2020-03-12 19:42:37 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_inst *add = exp.ADD(dest, src0, neg10);
add->saturate = true;
add->conditional_mod = BRW_CONDITIONAL_LE;
intel/compiler: don't propagate cmp to add if add is saturated From the Kaby Lake PRM Vol. 7 "Assigning Conditional Flags": * Note that the [post condition signal] bits generated at the output of a compute are before the .sat. Paragraph about post_zero does not mention saturation, but testing it on actual GPUs shows that conditional modifiers are applied after saturation. * post_zero bit: This bit reflects whether the final result is zero after all the clamping, normalizing, or format conversion logic. For signed types we don't care about saturation: it won't change the result of conditional modifier. For floating and unsigned types there two special cases, when we can remove inst even if scan_inst is saturated: G and LE. Since conditional modifiers are just comparations against zero, saturating positive values to the upper limit never changes the result of comparation. For negative values: (sat(x) > 0) == (x > 0) --- false (sat(x) <= 0) == (x <= 0) --- true Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2610 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4167>
2020-03-12 19:42:37 +02:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/compiler: don't propagate cmp to add if add is saturated From the Kaby Lake PRM Vol. 7 "Assigning Conditional Flags": * Note that the [post condition signal] bits generated at the output of a compute are before the .sat. Paragraph about post_zero does not mention saturation, but testing it on actual GPUs shows that conditional modifiers are applied after saturation. * post_zero bit: This bit reflects whether the final result is zero after all the clamping, normalizing, or format conversion logic. For signed types we don't care about saturation: it won't change the result of conditional modifier. For floating and unsigned types there two special cases, when we can remove inst even if scan_inst is saturated: G and LE. Since conditional modifiers are just comparations against zero, saturating positive values to the upper limit never changes the result of comparation. For negative values: (sat(x) > 0) == (x > 0) --- false (sat(x) <= 0) == (x <= 0) --- true Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2610 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4167>
2020-03-12 19:42:37 +02:00
}
intel/fs: sel.cond writes the flags on Gfx4 and Gfx5 On Gfx4 and Gfx5, sel.l (for min) and sel.ge (for max) are implemented using a separte cmpn and sel instruction. This lowering occurs in fs_vistor::lower_minmax which is called very, very late... a long, long time after the first calls to opt_cmod_propagation. As a result, conditional modifiers can be incorrectly propagated across sel.cond on those platforms. No tests were affected by this change, and I find that quite shocking. After just changing flags_written(), all of the atan tests started failing on ILK. That required the change in cmod_propagatin (and the addition of the prop_across_into_sel_gfx5 unit test). Shader-db results for ILK and GM45 are below. I looked at a couple before and after shaders... and every case that I looked at had experienced incorrect cmod propagation. This affected a LOT of apps! Euro Truck Simulator 2, The Talos Principle, Serious Sam 3, Sanctum 2, Gang Beasts, and on and on... :( I discovered this bug while working on a couple new optimization passes. One of the passes attempts to remove condition modifiers that are never used. The pass made no progress except on ILK and GM45. After investigating a couple of the affected shaders, I noticed that the code in those shaders looked wrong... investigation led to this cause. v2: Trivial changes in the unit tests. v3: Fix type in comment in unit tests. Noticed by Jason and Priit. v4: Tweak handling of BRW_OPCODE_SEL special case. Suggested by Jason. Fixes: df1aec763eb ("i965/fs: Define methods to calculate the flag subset read or written by an fs_inst.") Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Tested-by: Dave Airlie <airlied@redhat.com> Iron Lake total instructions in shared programs: 8180493 -> 8181781 (0.02%) instructions in affected programs: 541796 -> 543084 (0.24%) helped: 28 HURT: 1158 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.35% max: 0.86% x̄: 0.53% x̃: 0.50% HURT stats (abs) min: 1 max: 3 x̄: 1.14 x̃: 1 HURT stats (rel) min: 0.12% max: 4.00% x̄: 0.37% x̃: 0.23% 95% mean confidence interval for instructions value: 1.06 1.11 95% mean confidence interval for instructions %-change: 0.31% 0.38% Instructions are HURT. total cycles in shared programs: 239420470 -> 239421690 (<.01%) cycles in affected programs: 2925992 -> 2927212 (0.04%) helped: 49 HURT: 157 helped stats (abs) min: 2 max: 284 x̄: 62.69 x̃: 70 helped stats (rel) min: 0.04% max: 6.20% x̄: 1.68% x̃: 1.96% HURT stats (abs) min: 2 max: 48 x̄: 27.34 x̃: 24 HURT stats (rel) min: 0.02% max: 2.91% x̄: 0.31% x̃: 0.20% 95% mean confidence interval for cycles value: -0.80 12.64 95% mean confidence interval for cycles %-change: -0.31% <.01% Inconclusive result (value mean confidence interval includes 0). GM45 total instructions in shared programs: 4985517 -> 4986207 (0.01%) instructions in affected programs: 306935 -> 307625 (0.22%) helped: 14 HURT: 625 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.35% max: 0.82% x̄: 0.52% x̃: 0.49% HURT stats (abs) min: 1 max: 3 x̄: 1.13 x̃: 1 HURT stats (rel) min: 0.12% max: 3.90% x̄: 0.34% x̃: 0.22% 95% mean confidence interval for instructions value: 1.04 1.12 95% mean confidence interval for instructions %-change: 0.29% 0.36% Instructions are HURT. total cycles in shared programs: 153827268 -> 153828052 (<.01%) cycles in affected programs: 1669290 -> 1670074 (0.05%) helped: 24 HURT: 84 helped stats (abs) min: 2 max: 232 x̄: 64.33 x̃: 67 helped stats (rel) min: 0.04% max: 4.62% x̄: 1.60% x̃: 1.94% HURT stats (abs) min: 2 max: 48 x̄: 27.71 x̃: 24 HURT stats (rel) min: 0.02% max: 2.66% x̄: 0.34% x̃: 0.14% 95% mean confidence interval for cycles value: -1.94 16.46 95% mean confidence interval for cycles %-change: -0.29% 0.11% Inconclusive result (value mean confidence interval includes 0). Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12191>
2021-08-02 21:33:17 -07:00
intel/brw: Remove pass test cases for Gfx8- And update the mock devinfo versions to be at least Gfx9. Acked-by: Ivan Briano <ivan.briano@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27768>
2024-02-15 15:22:53 -08:00
TEST_F(cmod_propagation_test, prop_across_sel)
intel/fs: sel.cond writes the flags on Gfx4 and Gfx5 On Gfx4 and Gfx5, sel.l (for min) and sel.ge (for max) are implemented using a separte cmpn and sel instruction. This lowering occurs in fs_vistor::lower_minmax which is called very, very late... a long, long time after the first calls to opt_cmod_propagation. As a result, conditional modifiers can be incorrectly propagated across sel.cond on those platforms. No tests were affected by this change, and I find that quite shocking. After just changing flags_written(), all of the atan tests started failing on ILK. That required the change in cmod_propagatin (and the addition of the prop_across_into_sel_gfx5 unit test). Shader-db results for ILK and GM45 are below. I looked at a couple before and after shaders... and every case that I looked at had experienced incorrect cmod propagation. This affected a LOT of apps! Euro Truck Simulator 2, The Talos Principle, Serious Sam 3, Sanctum 2, Gang Beasts, and on and on... :( I discovered this bug while working on a couple new optimization passes. One of the passes attempts to remove condition modifiers that are never used. The pass made no progress except on ILK and GM45. After investigating a couple of the affected shaders, I noticed that the code in those shaders looked wrong... investigation led to this cause. v2: Trivial changes in the unit tests. v3: Fix type in comment in unit tests. Noticed by Jason and Priit. v4: Tweak handling of BRW_OPCODE_SEL special case. Suggested by Jason. Fixes: df1aec763eb ("i965/fs: Define methods to calculate the flag subset read or written by an fs_inst.") Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Tested-by: Dave Airlie <airlied@redhat.com> Iron Lake total instructions in shared programs: 8180493 -> 8181781 (0.02%) instructions in affected programs: 541796 -> 543084 (0.24%) helped: 28 HURT: 1158 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.35% max: 0.86% x̄: 0.53% x̃: 0.50% HURT stats (abs) min: 1 max: 3 x̄: 1.14 x̃: 1 HURT stats (rel) min: 0.12% max: 4.00% x̄: 0.37% x̃: 0.23% 95% mean confidence interval for instructions value: 1.06 1.11 95% mean confidence interval for instructions %-change: 0.31% 0.38% Instructions are HURT. total cycles in shared programs: 239420470 -> 239421690 (<.01%) cycles in affected programs: 2925992 -> 2927212 (0.04%) helped: 49 HURT: 157 helped stats (abs) min: 2 max: 284 x̄: 62.69 x̃: 70 helped stats (rel) min: 0.04% max: 6.20% x̄: 1.68% x̃: 1.96% HURT stats (abs) min: 2 max: 48 x̄: 27.34 x̃: 24 HURT stats (rel) min: 0.02% max: 2.91% x̄: 0.31% x̃: 0.20% 95% mean confidence interval for cycles value: -0.80 12.64 95% mean confidence interval for cycles %-change: -0.31% <.01% Inconclusive result (value mean confidence interval includes 0). GM45 total instructions in shared programs: 4985517 -> 4986207 (0.01%) instructions in affected programs: 306935 -> 307625 (0.22%) helped: 14 HURT: 625 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.35% max: 0.82% x̄: 0.52% x̃: 0.49% HURT stats (abs) min: 1 max: 3 x̄: 1.13 x̃: 1 HURT stats (rel) min: 0.12% max: 3.90% x̄: 0.34% x̃: 0.22% 95% mean confidence interval for instructions value: 1.04 1.12 95% mean confidence interval for instructions %-change: 0.29% 0.36% Instructions are HURT. total cycles in shared programs: 153827268 -> 153828052 (<.01%) cycles in affected programs: 1669290 -> 1670074 (0.05%) helped: 24 HURT: 84 helped stats (abs) min: 2 max: 232 x̄: 64.33 x̃: 67 helped stats (rel) min: 0.04% max: 4.62% x̄: 1.60% x̃: 1.94% HURT stats (abs) min: 2 max: 48 x̄: 27.71 x̃: 24 HURT stats (rel) min: 0.02% max: 2.66% x̄: 0.34% x̃: 0.14% 95% mean confidence interval for cycles value: -1.94 16.46 95% mean confidence interval for cycles %-change: -0.29% 0.11% Inconclusive result (value mean confidence interval includes 0). Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12191>
2021-08-02 21:33:17 -07:00
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
brw_reg dest1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg dest2 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src2 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg src3 = vgrf(bld, exp, BRW_TYPE_F);
brw_reg zero = brw_imm_f(0.0f);
intel/fs: sel.cond writes the flags on Gfx4 and Gfx5 On Gfx4 and Gfx5, sel.l (for min) and sel.ge (for max) are implemented using a separte cmpn and sel instruction. This lowering occurs in fs_vistor::lower_minmax which is called very, very late... a long, long time after the first calls to opt_cmod_propagation. As a result, conditional modifiers can be incorrectly propagated across sel.cond on those platforms. No tests were affected by this change, and I find that quite shocking. After just changing flags_written(), all of the atan tests started failing on ILK. That required the change in cmod_propagatin (and the addition of the prop_across_into_sel_gfx5 unit test). Shader-db results for ILK and GM45 are below. I looked at a couple before and after shaders... and every case that I looked at had experienced incorrect cmod propagation. This affected a LOT of apps! Euro Truck Simulator 2, The Talos Principle, Serious Sam 3, Sanctum 2, Gang Beasts, and on and on... :( I discovered this bug while working on a couple new optimization passes. One of the passes attempts to remove condition modifiers that are never used. The pass made no progress except on ILK and GM45. After investigating a couple of the affected shaders, I noticed that the code in those shaders looked wrong... investigation led to this cause. v2: Trivial changes in the unit tests. v3: Fix type in comment in unit tests. Noticed by Jason and Priit. v4: Tweak handling of BRW_OPCODE_SEL special case. Suggested by Jason. Fixes: df1aec763eb ("i965/fs: Define methods to calculate the flag subset read or written by an fs_inst.") Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Tested-by: Dave Airlie <airlied@redhat.com> Iron Lake total instructions in shared programs: 8180493 -> 8181781 (0.02%) instructions in affected programs: 541796 -> 543084 (0.24%) helped: 28 HURT: 1158 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.35% max: 0.86% x̄: 0.53% x̃: 0.50% HURT stats (abs) min: 1 max: 3 x̄: 1.14 x̃: 1 HURT stats (rel) min: 0.12% max: 4.00% x̄: 0.37% x̃: 0.23% 95% mean confidence interval for instructions value: 1.06 1.11 95% mean confidence interval for instructions %-change: 0.31% 0.38% Instructions are HURT. total cycles in shared programs: 239420470 -> 239421690 (<.01%) cycles in affected programs: 2925992 -> 2927212 (0.04%) helped: 49 HURT: 157 helped stats (abs) min: 2 max: 284 x̄: 62.69 x̃: 70 helped stats (rel) min: 0.04% max: 6.20% x̄: 1.68% x̃: 1.96% HURT stats (abs) min: 2 max: 48 x̄: 27.34 x̃: 24 HURT stats (rel) min: 0.02% max: 2.91% x̄: 0.31% x̃: 0.20% 95% mean confidence interval for cycles value: -0.80 12.64 95% mean confidence interval for cycles %-change: -0.31% <.01% Inconclusive result (value mean confidence interval includes 0). GM45 total instructions in shared programs: 4985517 -> 4986207 (0.01%) instructions in affected programs: 306935 -> 307625 (0.22%) helped: 14 HURT: 625 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.35% max: 0.82% x̄: 0.52% x̃: 0.49% HURT stats (abs) min: 1 max: 3 x̄: 1.13 x̃: 1 HURT stats (rel) min: 0.12% max: 3.90% x̄: 0.34% x̃: 0.22% 95% mean confidence interval for instructions value: 1.04 1.12 95% mean confidence interval for instructions %-change: 0.29% 0.36% Instructions are HURT. total cycles in shared programs: 153827268 -> 153828052 (<.01%) cycles in affected programs: 1669290 -> 1670074 (0.05%) helped: 24 HURT: 84 helped stats (abs) min: 2 max: 232 x̄: 64.33 x̃: 67 helped stats (rel) min: 0.04% max: 4.62% x̄: 1.60% x̃: 1.94% HURT stats (abs) min: 2 max: 48 x̄: 27.71 x̃: 24 HURT stats (rel) min: 0.02% max: 2.66% x̄: 0.34% x̃: 0.14% 95% mean confidence interval for cycles value: -1.94 16.46 95% mean confidence interval for cycles %-change: -0.29% 0.11% Inconclusive result (value mean confidence interval includes 0). Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12191>
2021-08-02 21:33:17 -07:00
bld.ADD(dest1, src0, src1);
bld.emit_minmax(dest2, src2, src3, BRW_CONDITIONAL_GE);
bld.CMP(bld.null_reg_f(), dest1, zero, BRW_CONDITIONAL_GE);
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/fs: sel.cond writes the flags on Gfx4 and Gfx5 On Gfx4 and Gfx5, sel.l (for min) and sel.ge (for max) are implemented using a separte cmpn and sel instruction. This lowering occurs in fs_vistor::lower_minmax which is called very, very late... a long, long time after the first calls to opt_cmod_propagation. As a result, conditional modifiers can be incorrectly propagated across sel.cond on those platforms. No tests were affected by this change, and I find that quite shocking. After just changing flags_written(), all of the atan tests started failing on ILK. That required the change in cmod_propagatin (and the addition of the prop_across_into_sel_gfx5 unit test). Shader-db results for ILK and GM45 are below. I looked at a couple before and after shaders... and every case that I looked at had experienced incorrect cmod propagation. This affected a LOT of apps! Euro Truck Simulator 2, The Talos Principle, Serious Sam 3, Sanctum 2, Gang Beasts, and on and on... :( I discovered this bug while working on a couple new optimization passes. One of the passes attempts to remove condition modifiers that are never used. The pass made no progress except on ILK and GM45. After investigating a couple of the affected shaders, I noticed that the code in those shaders looked wrong... investigation led to this cause. v2: Trivial changes in the unit tests. v3: Fix type in comment in unit tests. Noticed by Jason and Priit. v4: Tweak handling of BRW_OPCODE_SEL special case. Suggested by Jason. Fixes: df1aec763eb ("i965/fs: Define methods to calculate the flag subset read or written by an fs_inst.") Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Tested-by: Dave Airlie <airlied@redhat.com> Iron Lake total instructions in shared programs: 8180493 -> 8181781 (0.02%) instructions in affected programs: 541796 -> 543084 (0.24%) helped: 28 HURT: 1158 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.35% max: 0.86% x̄: 0.53% x̃: 0.50% HURT stats (abs) min: 1 max: 3 x̄: 1.14 x̃: 1 HURT stats (rel) min: 0.12% max: 4.00% x̄: 0.37% x̃: 0.23% 95% mean confidence interval for instructions value: 1.06 1.11 95% mean confidence interval for instructions %-change: 0.31% 0.38% Instructions are HURT. total cycles in shared programs: 239420470 -> 239421690 (<.01%) cycles in affected programs: 2925992 -> 2927212 (0.04%) helped: 49 HURT: 157 helped stats (abs) min: 2 max: 284 x̄: 62.69 x̃: 70 helped stats (rel) min: 0.04% max: 6.20% x̄: 1.68% x̃: 1.96% HURT stats (abs) min: 2 max: 48 x̄: 27.34 x̃: 24 HURT stats (rel) min: 0.02% max: 2.91% x̄: 0.31% x̃: 0.20% 95% mean confidence interval for cycles value: -0.80 12.64 95% mean confidence interval for cycles %-change: -0.31% <.01% Inconclusive result (value mean confidence interval includes 0). GM45 total instructions in shared programs: 4985517 -> 4986207 (0.01%) instructions in affected programs: 306935 -> 307625 (0.22%) helped: 14 HURT: 625 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.35% max: 0.82% x̄: 0.52% x̃: 0.49% HURT stats (abs) min: 1 max: 3 x̄: 1.13 x̃: 1 HURT stats (rel) min: 0.12% max: 3.90% x̄: 0.34% x̃: 0.22% 95% mean confidence interval for instructions value: 1.04 1.12 95% mean confidence interval for instructions %-change: 0.29% 0.36% Instructions are HURT. total cycles in shared programs: 153827268 -> 153828052 (<.01%) cycles in affected programs: 1669290 -> 1670074 (0.05%) helped: 24 HURT: 84 helped stats (abs) min: 2 max: 232 x̄: 64.33 x̃: 67 helped stats (rel) min: 0.04% max: 4.62% x̄: 1.60% x̃: 1.94% HURT stats (abs) min: 2 max: 48 x̄: 27.71 x̃: 24 HURT stats (rel) min: 0.02% max: 2.66% x̄: 0.34% x̃: 0.14% 95% mean confidence interval for cycles value: -1.94 16.46 95% mean confidence interval for cycles %-change: -0.29% 0.11% Inconclusive result (value mean confidence interval includes 0). Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12191>
2021-08-02 21:33:17 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.ADD(dest1, src0, src1)->conditional_mod = BRW_CONDITIONAL_GE;
exp.SEL(dest2, src2, src3)->conditional_mod = BRW_CONDITIONAL_GE;
intel/fs: sel.cond writes the flags on Gfx4 and Gfx5 On Gfx4 and Gfx5, sel.l (for min) and sel.ge (for max) are implemented using a separte cmpn and sel instruction. This lowering occurs in fs_vistor::lower_minmax which is called very, very late... a long, long time after the first calls to opt_cmod_propagation. As a result, conditional modifiers can be incorrectly propagated across sel.cond on those platforms. No tests were affected by this change, and I find that quite shocking. After just changing flags_written(), all of the atan tests started failing on ILK. That required the change in cmod_propagatin (and the addition of the prop_across_into_sel_gfx5 unit test). Shader-db results for ILK and GM45 are below. I looked at a couple before and after shaders... and every case that I looked at had experienced incorrect cmod propagation. This affected a LOT of apps! Euro Truck Simulator 2, The Talos Principle, Serious Sam 3, Sanctum 2, Gang Beasts, and on and on... :( I discovered this bug while working on a couple new optimization passes. One of the passes attempts to remove condition modifiers that are never used. The pass made no progress except on ILK and GM45. After investigating a couple of the affected shaders, I noticed that the code in those shaders looked wrong... investigation led to this cause. v2: Trivial changes in the unit tests. v3: Fix type in comment in unit tests. Noticed by Jason and Priit. v4: Tweak handling of BRW_OPCODE_SEL special case. Suggested by Jason. Fixes: df1aec763eb ("i965/fs: Define methods to calculate the flag subset read or written by an fs_inst.") Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Tested-by: Dave Airlie <airlied@redhat.com> Iron Lake total instructions in shared programs: 8180493 -> 8181781 (0.02%) instructions in affected programs: 541796 -> 543084 (0.24%) helped: 28 HURT: 1158 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.35% max: 0.86% x̄: 0.53% x̃: 0.50% HURT stats (abs) min: 1 max: 3 x̄: 1.14 x̃: 1 HURT stats (rel) min: 0.12% max: 4.00% x̄: 0.37% x̃: 0.23% 95% mean confidence interval for instructions value: 1.06 1.11 95% mean confidence interval for instructions %-change: 0.31% 0.38% Instructions are HURT. total cycles in shared programs: 239420470 -> 239421690 (<.01%) cycles in affected programs: 2925992 -> 2927212 (0.04%) helped: 49 HURT: 157 helped stats (abs) min: 2 max: 284 x̄: 62.69 x̃: 70 helped stats (rel) min: 0.04% max: 6.20% x̄: 1.68% x̃: 1.96% HURT stats (abs) min: 2 max: 48 x̄: 27.34 x̃: 24 HURT stats (rel) min: 0.02% max: 2.91% x̄: 0.31% x̃: 0.20% 95% mean confidence interval for cycles value: -0.80 12.64 95% mean confidence interval for cycles %-change: -0.31% <.01% Inconclusive result (value mean confidence interval includes 0). GM45 total instructions in shared programs: 4985517 -> 4986207 (0.01%) instructions in affected programs: 306935 -> 307625 (0.22%) helped: 14 HURT: 625 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.35% max: 0.82% x̄: 0.52% x̃: 0.49% HURT stats (abs) min: 1 max: 3 x̄: 1.13 x̃: 1 HURT stats (rel) min: 0.12% max: 3.90% x̄: 0.34% x̃: 0.22% 95% mean confidence interval for instructions value: 1.04 1.12 95% mean confidence interval for instructions %-change: 0.29% 0.36% Instructions are HURT. total cycles in shared programs: 153827268 -> 153828052 (<.01%) cycles in affected programs: 1669290 -> 1670074 (0.05%) helped: 24 HURT: 84 helped stats (abs) min: 2 max: 232 x̄: 64.33 x̃: 67 helped stats (rel) min: 0.04% max: 4.62% x̄: 1.60% x̃: 1.94% HURT stats (abs) min: 2 max: 48 x̄: 27.71 x̃: 24 HURT stats (rel) min: 0.02% max: 2.66% x̄: 0.34% x̃: 0.14% 95% mean confidence interval for cycles value: -1.94 16.46 95% mean confidence interval for cycles %-change: -0.29% 0.11% Inconclusive result (value mean confidence interval includes 0). Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12191>
2021-08-02 21:33:17 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/fs: sel.cond writes the flags on Gfx4 and Gfx5 On Gfx4 and Gfx5, sel.l (for min) and sel.ge (for max) are implemented using a separte cmpn and sel instruction. This lowering occurs in fs_vistor::lower_minmax which is called very, very late... a long, long time after the first calls to opt_cmod_propagation. As a result, conditional modifiers can be incorrectly propagated across sel.cond on those platforms. No tests were affected by this change, and I find that quite shocking. After just changing flags_written(), all of the atan tests started failing on ILK. That required the change in cmod_propagatin (and the addition of the prop_across_into_sel_gfx5 unit test). Shader-db results for ILK and GM45 are below. I looked at a couple before and after shaders... and every case that I looked at had experienced incorrect cmod propagation. This affected a LOT of apps! Euro Truck Simulator 2, The Talos Principle, Serious Sam 3, Sanctum 2, Gang Beasts, and on and on... :( I discovered this bug while working on a couple new optimization passes. One of the passes attempts to remove condition modifiers that are never used. The pass made no progress except on ILK and GM45. After investigating a couple of the affected shaders, I noticed that the code in those shaders looked wrong... investigation led to this cause. v2: Trivial changes in the unit tests. v3: Fix type in comment in unit tests. Noticed by Jason and Priit. v4: Tweak handling of BRW_OPCODE_SEL special case. Suggested by Jason. Fixes: df1aec763eb ("i965/fs: Define methods to calculate the flag subset read or written by an fs_inst.") Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Tested-by: Dave Airlie <airlied@redhat.com> Iron Lake total instructions in shared programs: 8180493 -> 8181781 (0.02%) instructions in affected programs: 541796 -> 543084 (0.24%) helped: 28 HURT: 1158 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.35% max: 0.86% x̄: 0.53% x̃: 0.50% HURT stats (abs) min: 1 max: 3 x̄: 1.14 x̃: 1 HURT stats (rel) min: 0.12% max: 4.00% x̄: 0.37% x̃: 0.23% 95% mean confidence interval for instructions value: 1.06 1.11 95% mean confidence interval for instructions %-change: 0.31% 0.38% Instructions are HURT. total cycles in shared programs: 239420470 -> 239421690 (<.01%) cycles in affected programs: 2925992 -> 2927212 (0.04%) helped: 49 HURT: 157 helped stats (abs) min: 2 max: 284 x̄: 62.69 x̃: 70 helped stats (rel) min: 0.04% max: 6.20% x̄: 1.68% x̃: 1.96% HURT stats (abs) min: 2 max: 48 x̄: 27.34 x̃: 24 HURT stats (rel) min: 0.02% max: 2.91% x̄: 0.31% x̃: 0.20% 95% mean confidence interval for cycles value: -0.80 12.64 95% mean confidence interval for cycles %-change: -0.31% <.01% Inconclusive result (value mean confidence interval includes 0). GM45 total instructions in shared programs: 4985517 -> 4986207 (0.01%) instructions in affected programs: 306935 -> 307625 (0.22%) helped: 14 HURT: 625 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.35% max: 0.82% x̄: 0.52% x̃: 0.49% HURT stats (abs) min: 1 max: 3 x̄: 1.13 x̃: 1 HURT stats (rel) min: 0.12% max: 3.90% x̄: 0.34% x̃: 0.22% 95% mean confidence interval for instructions value: 1.04 1.12 95% mean confidence interval for instructions %-change: 0.29% 0.36% Instructions are HURT. total cycles in shared programs: 153827268 -> 153828052 (<.01%) cycles in affected programs: 1669290 -> 1670074 (0.05%) helped: 24 HURT: 84 helped stats (abs) min: 2 max: 232 x̄: 64.33 x̃: 67 helped stats (rel) min: 0.04% max: 4.62% x̄: 1.60% x̃: 1.94% HURT stats (abs) min: 2 max: 48 x̄: 27.71 x̃: 24 HURT stats (rel) min: 0.02% max: 2.66% x̄: 0.34% x̃: 0.14% 95% mean confidence interval for cycles value: -1.94 16.46 95% mean confidence interval for cycles %-change: -0.29% 0.11% Inconclusive result (value mean confidence interval includes 0). Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12191>
2021-08-02 21:33:17 -07:00
}
intel/brw: Relax is_partial_write check in cmod propagation The is_partial_write check is too strict because it tests two separate things. It tests whether or not the instruction always writes a value (i.e., is it predicated), and it tests whether or not the instruction writes a complete register. This latter check is problematic as it perevents cmod propagation in SIMD1, and it prevents cmod propagation in SIMD8 when the destination size is 16 bits. This check is unnecessary. Cmod propagation already checks that the region written and region read overlap. It also already checks that the execution sizes of the instructions match. Further restriction based on the specific parts of the register written only generates false negatives. v2: Relax all of the calls to is_partial_write. Suggested by Caio. No shader-db changes on any Intel platform. fossil-db: Meteor Lake Totals: Instrs: 151505520 -> 151502923 (-0.00%); split: -0.00%, +0.00% Cycle count: 17201385104 -> 17194901423 (-0.04%); split: -0.06%, +0.02% Spill count: 80827 -> 80837 (+0.01%) Fill count: 152693 -> 152692 (-0.00%); split: -0.01%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1257205 -> 1254608 (-0.21%); split: -0.21%, +0.00% Cycle count: 5532845647 -> 5526361966 (-0.12%); split: -0.18%, +0.06% Spill count: 32903 -> 32913 (+0.03%) Fill count: 64338 -> 64337 (-0.00%); split: -0.03%, +0.03% DG2 Totals: Instrs: 151531440 -> 151528055 (-0.00%); split: -0.00%, +0.00% Cycle count: 17200238927 -> 17197996676 (-0.01%); split: -0.03%, +0.02% Spill count: 81003 -> 80971 (-0.04%); split: -0.04%, +0.00% Fill count: 152975 -> 152912 (-0.04%); split: -0.05%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1260363 -> 1256978 (-0.27%); split: -0.27%, +0.00% Cycle count: 5532019670 -> 5529777419 (-0.04%); split: -0.09%, +0.05% Spill count: 33046 -> 33014 (-0.10%); split: -0.11%, +0.01% Fill count: 64581 -> 64518 (-0.10%); split: -0.13%, +0.03% Tiger Lake and Ice Lake had similar results. (Tiger Lake shown) Totals: Instrs: 149972324 -> 149972289 (-0.00%) Cycle count: 15566495293 -> 15565151171 (-0.01%); split: -0.01%, +0.00% Totals from 16 (0.00% of 629912) affected shaders: Instrs: 351194 -> 351159 (-0.01%) Cycle count: 3922227030 -> 3920882908 (-0.03%); split: -0.04%, +0.00% Skylake Totals: Instrs: 140787999 -> 140787983 (-0.00%); split: -0.00%, +0.00% Cycle count: 14665614947 -> 14665515855 (-0.00%); split: -0.00%, +0.00% Spill count: 58500 -> 58501 (+0.00%) Fill count: 102097 -> 102100 (+0.00%) Totals from 16 (0.00% of 625685) affected shaders: Instrs: 343560 -> 343544 (-0.00%); split: -0.01%, +0.01% Cycle count: 3354997898 -> 3354898806 (-0.00%); split: -0.01%, +0.01% Spill count: 16864 -> 16865 (+0.01%) Fill count: 27479 -> 27482 (+0.01%) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30251>
2024-07-17 11:36:24 -07:00
TEST_F(cmod_propagation_test, Boolean_size_conversion)
{
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_builder bld = make_shader();
brw_builder exp = make_shader();
intel/brw: Relax is_partial_write check in cmod propagation The is_partial_write check is too strict because it tests two separate things. It tests whether or not the instruction always writes a value (i.e., is it predicated), and it tests whether or not the instruction writes a complete register. This latter check is problematic as it perevents cmod propagation in SIMD1, and it prevents cmod propagation in SIMD8 when the destination size is 16 bits. This check is unnecessary. Cmod propagation already checks that the region written and region read overlap. It also already checks that the execution sizes of the instructions match. Further restriction based on the specific parts of the register written only generates false negatives. v2: Relax all of the calls to is_partial_write. Suggested by Caio. No shader-db changes on any Intel platform. fossil-db: Meteor Lake Totals: Instrs: 151505520 -> 151502923 (-0.00%); split: -0.00%, +0.00% Cycle count: 17201385104 -> 17194901423 (-0.04%); split: -0.06%, +0.02% Spill count: 80827 -> 80837 (+0.01%) Fill count: 152693 -> 152692 (-0.00%); split: -0.01%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1257205 -> 1254608 (-0.21%); split: -0.21%, +0.00% Cycle count: 5532845647 -> 5526361966 (-0.12%); split: -0.18%, +0.06% Spill count: 32903 -> 32913 (+0.03%) Fill count: 64338 -> 64337 (-0.00%); split: -0.03%, +0.03% DG2 Totals: Instrs: 151531440 -> 151528055 (-0.00%); split: -0.00%, +0.00% Cycle count: 17200238927 -> 17197996676 (-0.01%); split: -0.03%, +0.02% Spill count: 81003 -> 80971 (-0.04%); split: -0.04%, +0.00% Fill count: 152975 -> 152912 (-0.04%); split: -0.05%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1260363 -> 1256978 (-0.27%); split: -0.27%, +0.00% Cycle count: 5532019670 -> 5529777419 (-0.04%); split: -0.09%, +0.05% Spill count: 33046 -> 33014 (-0.10%); split: -0.11%, +0.01% Fill count: 64581 -> 64518 (-0.10%); split: -0.13%, +0.03% Tiger Lake and Ice Lake had similar results. (Tiger Lake shown) Totals: Instrs: 149972324 -> 149972289 (-0.00%) Cycle count: 15566495293 -> 15565151171 (-0.01%); split: -0.01%, +0.00% Totals from 16 (0.00% of 629912) affected shaders: Instrs: 351194 -> 351159 (-0.01%) Cycle count: 3922227030 -> 3920882908 (-0.03%); split: -0.04%, +0.00% Skylake Totals: Instrs: 140787999 -> 140787983 (-0.00%); split: -0.00%, +0.00% Cycle count: 14665614947 -> 14665515855 (-0.00%); split: -0.00%, +0.00% Spill count: 58500 -> 58501 (+0.00%) Fill count: 102097 -> 102100 (+0.00%) Totals from 16 (0.00% of 625685) affected shaders: Instrs: 343560 -> 343544 (-0.00%); split: -0.01%, +0.01% Cycle count: 3354997898 -> 3354898806 (-0.00%); split: -0.01%, +0.01% Spill count: 16864 -> 16865 (+0.01%) Fill count: 27479 -> 27482 (+0.01%) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30251>
2024-07-17 11:36:24 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
brw_reg dest1 = vgrf(bld, exp, BRW_TYPE_W);
brw_reg src0 = vgrf(bld, exp, BRW_TYPE_W);
brw_reg zero = brw_imm_w(0);
intel/brw: Relax is_partial_write check in cmod propagation The is_partial_write check is too strict because it tests two separate things. It tests whether or not the instruction always writes a value (i.e., is it predicated), and it tests whether or not the instruction writes a complete register. This latter check is problematic as it perevents cmod propagation in SIMD1, and it prevents cmod propagation in SIMD8 when the destination size is 16 bits. This check is unnecessary. Cmod propagation already checks that the region written and region read overlap. It also already checks that the execution sizes of the instructions match. Further restriction based on the specific parts of the register written only generates false negatives. v2: Relax all of the calls to is_partial_write. Suggested by Caio. No shader-db changes on any Intel platform. fossil-db: Meteor Lake Totals: Instrs: 151505520 -> 151502923 (-0.00%); split: -0.00%, +0.00% Cycle count: 17201385104 -> 17194901423 (-0.04%); split: -0.06%, +0.02% Spill count: 80827 -> 80837 (+0.01%) Fill count: 152693 -> 152692 (-0.00%); split: -0.01%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1257205 -> 1254608 (-0.21%); split: -0.21%, +0.00% Cycle count: 5532845647 -> 5526361966 (-0.12%); split: -0.18%, +0.06% Spill count: 32903 -> 32913 (+0.03%) Fill count: 64338 -> 64337 (-0.00%); split: -0.03%, +0.03% DG2 Totals: Instrs: 151531440 -> 151528055 (-0.00%); split: -0.00%, +0.00% Cycle count: 17200238927 -> 17197996676 (-0.01%); split: -0.03%, +0.02% Spill count: 81003 -> 80971 (-0.04%); split: -0.04%, +0.00% Fill count: 152975 -> 152912 (-0.04%); split: -0.05%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1260363 -> 1256978 (-0.27%); split: -0.27%, +0.00% Cycle count: 5532019670 -> 5529777419 (-0.04%); split: -0.09%, +0.05% Spill count: 33046 -> 33014 (-0.10%); split: -0.11%, +0.01% Fill count: 64581 -> 64518 (-0.10%); split: -0.13%, +0.03% Tiger Lake and Ice Lake had similar results. (Tiger Lake shown) Totals: Instrs: 149972324 -> 149972289 (-0.00%) Cycle count: 15566495293 -> 15565151171 (-0.01%); split: -0.01%, +0.00% Totals from 16 (0.00% of 629912) affected shaders: Instrs: 351194 -> 351159 (-0.01%) Cycle count: 3922227030 -> 3920882908 (-0.03%); split: -0.04%, +0.00% Skylake Totals: Instrs: 140787999 -> 140787983 (-0.00%); split: -0.00%, +0.00% Cycle count: 14665614947 -> 14665515855 (-0.00%); split: -0.00%, +0.00% Spill count: 58500 -> 58501 (+0.00%) Fill count: 102097 -> 102100 (+0.00%) Totals from 16 (0.00% of 625685) affected shaders: Instrs: 343560 -> 343544 (-0.00%); split: -0.01%, +0.01% Cycle count: 3354997898 -> 3354898806 (-0.00%); split: -0.01%, +0.01% Spill count: 16864 -> 16865 (+0.01%) Fill count: 27479 -> 27482 (+0.01%) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30251>
2024-07-17 11:36:24 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
bld.CMP(dest1, src0, zero, BRW_CONDITIONAL_NZ);
bld.MOV(bld.null_reg_d(), dest1)->conditional_mod = BRW_CONDITIONAL_NZ;
intel/brw: Relax is_partial_write check in cmod propagation The is_partial_write check is too strict because it tests two separate things. It tests whether or not the instruction always writes a value (i.e., is it predicated), and it tests whether or not the instruction writes a complete register. This latter check is problematic as it perevents cmod propagation in SIMD1, and it prevents cmod propagation in SIMD8 when the destination size is 16 bits. This check is unnecessary. Cmod propagation already checks that the region written and region read overlap. It also already checks that the execution sizes of the instructions match. Further restriction based on the specific parts of the register written only generates false negatives. v2: Relax all of the calls to is_partial_write. Suggested by Caio. No shader-db changes on any Intel platform. fossil-db: Meteor Lake Totals: Instrs: 151505520 -> 151502923 (-0.00%); split: -0.00%, +0.00% Cycle count: 17201385104 -> 17194901423 (-0.04%); split: -0.06%, +0.02% Spill count: 80827 -> 80837 (+0.01%) Fill count: 152693 -> 152692 (-0.00%); split: -0.01%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1257205 -> 1254608 (-0.21%); split: -0.21%, +0.00% Cycle count: 5532845647 -> 5526361966 (-0.12%); split: -0.18%, +0.06% Spill count: 32903 -> 32913 (+0.03%) Fill count: 64338 -> 64337 (-0.00%); split: -0.03%, +0.03% DG2 Totals: Instrs: 151531440 -> 151528055 (-0.00%); split: -0.00%, +0.00% Cycle count: 17200238927 -> 17197996676 (-0.01%); split: -0.03%, +0.02% Spill count: 81003 -> 80971 (-0.04%); split: -0.04%, +0.00% Fill count: 152975 -> 152912 (-0.04%); split: -0.05%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1260363 -> 1256978 (-0.27%); split: -0.27%, +0.00% Cycle count: 5532019670 -> 5529777419 (-0.04%); split: -0.09%, +0.05% Spill count: 33046 -> 33014 (-0.10%); split: -0.11%, +0.01% Fill count: 64581 -> 64518 (-0.10%); split: -0.13%, +0.03% Tiger Lake and Ice Lake had similar results. (Tiger Lake shown) Totals: Instrs: 149972324 -> 149972289 (-0.00%) Cycle count: 15566495293 -> 15565151171 (-0.01%); split: -0.01%, +0.00% Totals from 16 (0.00% of 629912) affected shaders: Instrs: 351194 -> 351159 (-0.01%) Cycle count: 3922227030 -> 3920882908 (-0.03%); split: -0.04%, +0.00% Skylake Totals: Instrs: 140787999 -> 140787983 (-0.00%); split: -0.00%, +0.00% Cycle count: 14665614947 -> 14665515855 (-0.00%); split: -0.00%, +0.00% Spill count: 58500 -> 58501 (+0.00%) Fill count: 102097 -> 102100 (+0.00%) Totals from 16 (0.00% of 625685) affected shaders: Instrs: 343560 -> 343544 (-0.00%); split: -0.01%, +0.01% Cycle count: 3354997898 -> 3354898806 (-0.00%); split: -0.01%, +0.01% Spill count: 16864 -> 16865 (+0.01%) Fill count: 27479 -> 27482 (+0.01%) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30251>
2024-07-17 11:36:24 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_PROGRESS(brw_opt_cmod_propagation, bld);
intel/brw: Relax is_partial_write check in cmod propagation The is_partial_write check is too strict because it tests two separate things. It tests whether or not the instruction always writes a value (i.e., is it predicated), and it tests whether or not the instruction writes a complete register. This latter check is problematic as it perevents cmod propagation in SIMD1, and it prevents cmod propagation in SIMD8 when the destination size is 16 bits. This check is unnecessary. Cmod propagation already checks that the region written and region read overlap. It also already checks that the execution sizes of the instructions match. Further restriction based on the specific parts of the register written only generates false negatives. v2: Relax all of the calls to is_partial_write. Suggested by Caio. No shader-db changes on any Intel platform. fossil-db: Meteor Lake Totals: Instrs: 151505520 -> 151502923 (-0.00%); split: -0.00%, +0.00% Cycle count: 17201385104 -> 17194901423 (-0.04%); split: -0.06%, +0.02% Spill count: 80827 -> 80837 (+0.01%) Fill count: 152693 -> 152692 (-0.00%); split: -0.01%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1257205 -> 1254608 (-0.21%); split: -0.21%, +0.00% Cycle count: 5532845647 -> 5526361966 (-0.12%); split: -0.18%, +0.06% Spill count: 32903 -> 32913 (+0.03%) Fill count: 64338 -> 64337 (-0.00%); split: -0.03%, +0.03% DG2 Totals: Instrs: 151531440 -> 151528055 (-0.00%); split: -0.00%, +0.00% Cycle count: 17200238927 -> 17197996676 (-0.01%); split: -0.03%, +0.02% Spill count: 81003 -> 80971 (-0.04%); split: -0.04%, +0.00% Fill count: 152975 -> 152912 (-0.04%); split: -0.05%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1260363 -> 1256978 (-0.27%); split: -0.27%, +0.00% Cycle count: 5532019670 -> 5529777419 (-0.04%); split: -0.09%, +0.05% Spill count: 33046 -> 33014 (-0.10%); split: -0.11%, +0.01% Fill count: 64581 -> 64518 (-0.10%); split: -0.13%, +0.03% Tiger Lake and Ice Lake had similar results. (Tiger Lake shown) Totals: Instrs: 149972324 -> 149972289 (-0.00%) Cycle count: 15566495293 -> 15565151171 (-0.01%); split: -0.01%, +0.00% Totals from 16 (0.00% of 629912) affected shaders: Instrs: 351194 -> 351159 (-0.01%) Cycle count: 3922227030 -> 3920882908 (-0.03%); split: -0.04%, +0.00% Skylake Totals: Instrs: 140787999 -> 140787983 (-0.00%); split: -0.00%, +0.00% Cycle count: 14665614947 -> 14665515855 (-0.00%); split: -0.00%, +0.00% Spill count: 58500 -> 58501 (+0.00%) Fill count: 102097 -> 102100 (+0.00%) Totals from 16 (0.00% of 625685) affected shaders: Instrs: 343560 -> 343544 (-0.00%); split: -0.01%, +0.01% Cycle count: 3354997898 -> 3354898806 (-0.00%); split: -0.01%, +0.01% Spill count: 16864 -> 16865 (+0.01%) Fill count: 27479 -> 27482 (+0.01%) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30251>
2024-07-17 11:36:24 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
exp.CMP(dest1, src0, zero, BRW_CONDITIONAL_NZ);
intel/brw: Relax is_partial_write check in cmod propagation The is_partial_write check is too strict because it tests two separate things. It tests whether or not the instruction always writes a value (i.e., is it predicated), and it tests whether or not the instruction writes a complete register. This latter check is problematic as it perevents cmod propagation in SIMD1, and it prevents cmod propagation in SIMD8 when the destination size is 16 bits. This check is unnecessary. Cmod propagation already checks that the region written and region read overlap. It also already checks that the execution sizes of the instructions match. Further restriction based on the specific parts of the register written only generates false negatives. v2: Relax all of the calls to is_partial_write. Suggested by Caio. No shader-db changes on any Intel platform. fossil-db: Meteor Lake Totals: Instrs: 151505520 -> 151502923 (-0.00%); split: -0.00%, +0.00% Cycle count: 17201385104 -> 17194901423 (-0.04%); split: -0.06%, +0.02% Spill count: 80827 -> 80837 (+0.01%) Fill count: 152693 -> 152692 (-0.00%); split: -0.01%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1257205 -> 1254608 (-0.21%); split: -0.21%, +0.00% Cycle count: 5532845647 -> 5526361966 (-0.12%); split: -0.18%, +0.06% Spill count: 32903 -> 32913 (+0.03%) Fill count: 64338 -> 64337 (-0.00%); split: -0.03%, +0.03% DG2 Totals: Instrs: 151531440 -> 151528055 (-0.00%); split: -0.00%, +0.00% Cycle count: 17200238927 -> 17197996676 (-0.01%); split: -0.03%, +0.02% Spill count: 81003 -> 80971 (-0.04%); split: -0.04%, +0.00% Fill count: 152975 -> 152912 (-0.04%); split: -0.05%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1260363 -> 1256978 (-0.27%); split: -0.27%, +0.00% Cycle count: 5532019670 -> 5529777419 (-0.04%); split: -0.09%, +0.05% Spill count: 33046 -> 33014 (-0.10%); split: -0.11%, +0.01% Fill count: 64581 -> 64518 (-0.10%); split: -0.13%, +0.03% Tiger Lake and Ice Lake had similar results. (Tiger Lake shown) Totals: Instrs: 149972324 -> 149972289 (-0.00%) Cycle count: 15566495293 -> 15565151171 (-0.01%); split: -0.01%, +0.00% Totals from 16 (0.00% of 629912) affected shaders: Instrs: 351194 -> 351159 (-0.01%) Cycle count: 3922227030 -> 3920882908 (-0.03%); split: -0.04%, +0.00% Skylake Totals: Instrs: 140787999 -> 140787983 (-0.00%); split: -0.00%, +0.00% Cycle count: 14665614947 -> 14665515855 (-0.00%); split: -0.00%, +0.00% Spill count: 58500 -> 58501 (+0.00%) Fill count: 102097 -> 102100 (+0.00%) Totals from 16 (0.00% of 625685) affected shaders: Instrs: 343560 -> 343544 (-0.00%); split: -0.01%, +0.01% Cycle count: 3354997898 -> 3354898806 (-0.00%); split: -0.01%, +0.01% Spill count: 16864 -> 16865 (+0.01%) Fill count: 27479 -> 27482 (+0.01%) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30251>
2024-07-17 11:36:24 -07:00
brw: Simplify the test code for brw passes The key change is to use a builder to write the expected shader result and compare that. To make this less error prone, a few helper functions were added - a way to allocate VGRFs from both shaders in parallel, that way the same brw_reg can be used in both of them; - assertions that a pass will make progress or not, and proper output when the unexpected happens; - use a common brw_shader_pass_test class so to collect some of the helpers; - make some helpers work directly with builder. The idea is to improve the signal in tests, so that the disasm comments are not necessary anymore. For example ``` TEST_F(saturate_propagation_test, basic) { brw_reg dst1 = bld.vgrf(BRW_TYPE_F); brw_reg src0 = bld.vgrf(BRW_TYPE_F); brw_reg src1 = bld.vgrf(BRW_TYPE_F); brw_reg dst0 = bld.ADD(src0, src1); set_saturate(true, bld.MOV(dst1, dst0)); /* = Before = * * 0: add(16) dst0 src0 src1 * 1: mov.sat(16) dst1 dst0 * * = After = * 0: add.sat(16) dst0 src0 src1 * 1: mov(16) dst1 dst0 */ brw_calculate_cfg(*v); bblock_t *block0 = v->cfg->blocks[0]; EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_TRUE(saturate_propagation(v)); EXPECT_EQ(0, block0->start_ip); EXPECT_EQ(1, block0->end_ip); EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode); EXPECT_TRUE(instruction(block0, 0)->saturate); EXPECT_EQ(BRW_OPCODE_MOV, instruction(block0, 1)->opcode); EXPECT_FALSE(instruction(block0, 1)->saturate); } ``` becomes ``` TEST_F(saturate_propagation_test, basic) { brw_builder bld = make_shader(MESA_SHADER_FRAGMENT, 16); brw_builder exp = make_shader(MESA_SHADER_FRAGMENT, 16); brw_reg dst0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg dst1 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src0 = vgrf(bld, exp, BRW_TYPE_F); brw_reg src1 = vgrf(bld, exp, BRW_TYPE_F); bld.ADD(dst0, src0, src1); bld.MOV(dst1, dst0)->saturate = true; EXPECT_PROGRESS(brw_opt_saturate_propagation, bld); exp.ADD(dst0, src0, src1)->saturate = true; exp.MOV(dst1, dst0); EXPECT_SHADERS_MATCH(bld, exp); } ``` Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33936>
2025-03-05 16:58:32 -08:00
EXPECT_SHADERS_MATCH(bld, exp);
intel/brw: Relax is_partial_write check in cmod propagation The is_partial_write check is too strict because it tests two separate things. It tests whether or not the instruction always writes a value (i.e., is it predicated), and it tests whether or not the instruction writes a complete register. This latter check is problematic as it perevents cmod propagation in SIMD1, and it prevents cmod propagation in SIMD8 when the destination size is 16 bits. This check is unnecessary. Cmod propagation already checks that the region written and region read overlap. It also already checks that the execution sizes of the instructions match. Further restriction based on the specific parts of the register written only generates false negatives. v2: Relax all of the calls to is_partial_write. Suggested by Caio. No shader-db changes on any Intel platform. fossil-db: Meteor Lake Totals: Instrs: 151505520 -> 151502923 (-0.00%); split: -0.00%, +0.00% Cycle count: 17201385104 -> 17194901423 (-0.04%); split: -0.06%, +0.02% Spill count: 80827 -> 80837 (+0.01%) Fill count: 152693 -> 152692 (-0.00%); split: -0.01%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1257205 -> 1254608 (-0.21%); split: -0.21%, +0.00% Cycle count: 5532845647 -> 5526361966 (-0.12%); split: -0.18%, +0.06% Spill count: 32903 -> 32913 (+0.03%) Fill count: 64338 -> 64337 (-0.00%); split: -0.03%, +0.03% DG2 Totals: Instrs: 151531440 -> 151528055 (-0.00%); split: -0.00%, +0.00% Cycle count: 17200238927 -> 17197996676 (-0.01%); split: -0.03%, +0.02% Spill count: 81003 -> 80971 (-0.04%); split: -0.04%, +0.00% Fill count: 152975 -> 152912 (-0.04%); split: -0.05%, +0.01% Totals from 346 (0.05% of 630198) affected shaders: Instrs: 1260363 -> 1256978 (-0.27%); split: -0.27%, +0.00% Cycle count: 5532019670 -> 5529777419 (-0.04%); split: -0.09%, +0.05% Spill count: 33046 -> 33014 (-0.10%); split: -0.11%, +0.01% Fill count: 64581 -> 64518 (-0.10%); split: -0.13%, +0.03% Tiger Lake and Ice Lake had similar results. (Tiger Lake shown) Totals: Instrs: 149972324 -> 149972289 (-0.00%) Cycle count: 15566495293 -> 15565151171 (-0.01%); split: -0.01%, +0.00% Totals from 16 (0.00% of 629912) affected shaders: Instrs: 351194 -> 351159 (-0.01%) Cycle count: 3922227030 -> 3920882908 (-0.03%); split: -0.04%, +0.00% Skylake Totals: Instrs: 140787999 -> 140787983 (-0.00%); split: -0.00%, +0.00% Cycle count: 14665614947 -> 14665515855 (-0.00%); split: -0.00%, +0.00% Spill count: 58500 -> 58501 (+0.00%) Fill count: 102097 -> 102100 (+0.00%) Totals from 16 (0.00% of 625685) affected shaders: Instrs: 343560 -> 343544 (-0.00%); split: -0.01%, +0.01% Cycle count: 3354997898 -> 3354898806 (-0.00%); split: -0.01%, +0.01% Spill count: 16864 -> 16865 (+0.01%) Fill count: 27479 -> 27482 (+0.01%) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30251>
2024-07-17 11:36:24 -07:00
}
Reference in a new issue Copy permalink