2018-10-22 16:44:59 -05:00
|
|
|
/*
|
|
|
|
|
* Copyright © 2018 Intel Corporation
|
|
|
|
|
*
|
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
|
*
|
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
|
* Software.
|
|
|
|
|
*
|
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
|
* IN THE SOFTWARE.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "nir.h"
|
|
|
|
|
#include "nir_builder.h"
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
assert_ssa_def_is_not_1bit(nir_ssa_def *def, UNUSED void *unused)
|
|
|
|
|
{
|
|
|
|
|
assert(def->bit_size > 1);
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
rewrite_1bit_ssa_def_to_32bit(nir_ssa_def *def, void *_progress)
|
|
|
|
|
{
|
|
|
|
|
bool *progress = _progress;
|
|
|
|
|
if (def->bit_size == 1) {
|
|
|
|
|
def->bit_size = 32;
|
|
|
|
|
*progress = true;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
nir/lower_bool: ntt: Generate a good opcode for bcsel
This is heavily copy-pasted from a patch of Ian Romanick, including the
commit message.
Previously, this pass always generated fcsel for bcsel. This was the
only place that generate fcsel, so various drivers assumed (and needed!)
that src0 was a Boolean with 0.0 or 1.0 as the only values.
Specifically, many DX9 / GL_ARB_vertex_program platforms lack a CMP
instruction in vertex shaders. In those cases, they would use LRP to
implement fcsel. The bummer is that many plaforms have a real fcsel
instruction, and those platforms would benefit from other places
generating that opcode.
Instead of leaving assumptions in drivers about the sources of an opcode
that they can't really support, allow them to control the way the
lowering pass translates bcsel. Two flags are used to control this:
- If the driver sets has_fused_comp_and_csel in nir_options, fcsel_gt
will be used. Since the Boolean value is 0.0 or 1.0, this is
equivalent to fcsel.
- If the parameter has_fcsel_ne is set, fcsel will be used. This is the
old path.
- Otherwise, the lowering pass assumes we're on a crufty, old DX9 vertex
program, and it emits flrp.
With this, the assumptions about src0 of fcsel in NTT can be removed.
If a platform can't handle fcsel, it should ensure that the lowering
pass won't generate it.
No change in shader-db.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20162>
2022-11-24 09:24:35 +01:00
|
|
|
lower_alu_instr(nir_builder *b, nir_alu_instr *alu, bool has_fcsel_ne,
|
|
|
|
|
bool has_fcsel_gt)
|
2018-10-22 16:44:59 -05:00
|
|
|
{
|
|
|
|
|
const nir_op_info *op_info = &nir_op_infos[alu->op];
|
|
|
|
|
|
|
|
|
|
b->cursor = nir_before_instr(&alu->instr);
|
|
|
|
|
|
|
|
|
|
/* Replacement SSA value */
|
|
|
|
|
nir_ssa_def *rep = NULL;
|
|
|
|
|
switch (alu->op) {
|
2019-05-31 16:04:10 -04:00
|
|
|
case nir_op_mov:
|
2019-01-29 09:09:07 -05:00
|
|
|
case nir_op_vec2:
|
|
|
|
|
case nir_op_vec3:
|
|
|
|
|
case nir_op_vec4:
|
2020-11-23 13:05:58 +00:00
|
|
|
case nir_op_vec5:
|
2019-03-09 17:17:55 +01:00
|
|
|
case nir_op_vec8:
|
|
|
|
|
case nir_op_vec16:
|
2020-08-21 19:02:02 -05:00
|
|
|
if (alu->dest.dest.ssa.bit_size != 1)
|
|
|
|
|
return false;
|
2019-01-29 09:09:07 -05:00
|
|
|
/* These we expect to have booleans but the opcode doesn't change */
|
|
|
|
|
break;
|
|
|
|
|
|
2019-05-06 11:45:46 -05:00
|
|
|
case nir_op_b2f32: alu->op = nir_op_mov; break;
|
|
|
|
|
case nir_op_b2i32: alu->op = nir_op_mov; break;
|
2020-03-27 00:18:43 -05:00
|
|
|
case nir_op_b2b1: alu->op = nir_op_mov; break;
|
2018-10-22 16:44:59 -05:00
|
|
|
|
|
|
|
|
case nir_op_flt: alu->op = nir_op_slt; break;
|
|
|
|
|
case nir_op_fge: alu->op = nir_op_sge; break;
|
|
|
|
|
case nir_op_feq: alu->op = nir_op_seq; break;
|
2020-08-18 19:51:57 +02:00
|
|
|
case nir_op_fneu: alu->op = nir_op_sne; break;
|
2018-10-22 16:44:59 -05:00
|
|
|
case nir_op_ilt: alu->op = nir_op_slt; break;
|
|
|
|
|
case nir_op_ige: alu->op = nir_op_sge; break;
|
|
|
|
|
case nir_op_ieq: alu->op = nir_op_seq; break;
|
|
|
|
|
case nir_op_ine: alu->op = nir_op_sne; break;
|
|
|
|
|
case nir_op_ult: alu->op = nir_op_slt; break;
|
|
|
|
|
case nir_op_uge: alu->op = nir_op_sge; break;
|
|
|
|
|
|
|
|
|
|
case nir_op_ball_fequal2: alu->op = nir_op_fall_equal2; break;
|
|
|
|
|
case nir_op_ball_fequal3: alu->op = nir_op_fall_equal3; break;
|
|
|
|
|
case nir_op_ball_fequal4: alu->op = nir_op_fall_equal4; break;
|
|
|
|
|
case nir_op_bany_fnequal2: alu->op = nir_op_fany_nequal2; break;
|
|
|
|
|
case nir_op_bany_fnequal3: alu->op = nir_op_fany_nequal3; break;
|
|
|
|
|
case nir_op_bany_fnequal4: alu->op = nir_op_fany_nequal4; break;
|
|
|
|
|
case nir_op_ball_iequal2: alu->op = nir_op_fall_equal2; break;
|
|
|
|
|
case nir_op_ball_iequal3: alu->op = nir_op_fall_equal3; break;
|
|
|
|
|
case nir_op_ball_iequal4: alu->op = nir_op_fall_equal4; break;
|
|
|
|
|
case nir_op_bany_inequal2: alu->op = nir_op_fany_nequal2; break;
|
|
|
|
|
case nir_op_bany_inequal3: alu->op = nir_op_fany_nequal3; break;
|
|
|
|
|
case nir_op_bany_inequal4: alu->op = nir_op_fany_nequal4; break;
|
|
|
|
|
|
nir/lower_bool: ntt: Generate a good opcode for bcsel
This is heavily copy-pasted from a patch of Ian Romanick, including the
commit message.
Previously, this pass always generated fcsel for bcsel. This was the
only place that generate fcsel, so various drivers assumed (and needed!)
that src0 was a Boolean with 0.0 or 1.0 as the only values.
Specifically, many DX9 / GL_ARB_vertex_program platforms lack a CMP
instruction in vertex shaders. In those cases, they would use LRP to
implement fcsel. The bummer is that many plaforms have a real fcsel
instruction, and those platforms would benefit from other places
generating that opcode.
Instead of leaving assumptions in drivers about the sources of an opcode
that they can't really support, allow them to control the way the
lowering pass translates bcsel. Two flags are used to control this:
- If the driver sets has_fused_comp_and_csel in nir_options, fcsel_gt
will be used. Since the Boolean value is 0.0 or 1.0, this is
equivalent to fcsel.
- If the parameter has_fcsel_ne is set, fcsel will be used. This is the
old path.
- Otherwise, the lowering pass assumes we're on a crufty, old DX9 vertex
program, and it emits flrp.
With this, the assumptions about src0 of fcsel in NTT can be removed.
If a platform can't handle fcsel, it should ensure that the lowering
pass won't generate it.
No change in shader-db.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20162>
2022-11-24 09:24:35 +01:00
|
|
|
case nir_op_bcsel:
|
|
|
|
|
if (has_fcsel_gt)
|
|
|
|
|
alu->op = nir_op_fcsel_gt;
|
|
|
|
|
else if (has_fcsel_ne)
|
|
|
|
|
alu->op = nir_op_fcsel;
|
|
|
|
|
else {
|
|
|
|
|
/* Only a few pre-VS 4.0 platforms (e.g., r300 vertex shaders) should
|
|
|
|
|
* hit this path.
|
|
|
|
|
*/
|
|
|
|
|
rep = nir_flrp(b,
|
|
|
|
|
nir_ssa_for_alu_src(b, alu, 2),
|
|
|
|
|
nir_ssa_for_alu_src(b, alu, 1),
|
|
|
|
|
nir_ssa_for_alu_src(b, alu, 0));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
break;
|
2018-10-22 16:44:59 -05:00
|
|
|
|
|
|
|
|
case nir_op_iand: alu->op = nir_op_fmul; break;
|
|
|
|
|
case nir_op_ixor: alu->op = nir_op_sne; break;
|
|
|
|
|
case nir_op_ior: alu->op = nir_op_fmax; break;
|
|
|
|
|
|
|
|
|
|
case nir_op_inot:
|
|
|
|
|
rep = nir_seq(b, nir_ssa_for_alu_src(b, alu, 0),
|
|
|
|
|
nir_imm_float(b, 0));
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
assert(alu->dest.dest.ssa.bit_size > 1);
|
|
|
|
|
for (unsigned i = 0; i < op_info->num_inputs; i++)
|
|
|
|
|
assert(alu->src[i].src.ssa->bit_size > 1);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (rep) {
|
|
|
|
|
/* We've emitted a replacement instruction */
|
2021-03-03 00:13:38 -06:00
|
|
|
nir_ssa_def_rewrite_uses(&alu->dest.dest.ssa, rep);
|
2018-10-22 16:44:59 -05:00
|
|
|
nir_instr_remove(&alu->instr);
|
|
|
|
|
} else {
|
|
|
|
|
if (alu->dest.dest.ssa.bit_size == 1)
|
|
|
|
|
alu->dest.dest.ssa.bit_size = 32;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-12 13:04:59 +01:00
|
|
|
static bool
|
|
|
|
|
lower_tex_instr(nir_tex_instr *tex)
|
|
|
|
|
{
|
|
|
|
|
bool progress = false;
|
|
|
|
|
rewrite_1bit_ssa_def_to_32bit(&tex->dest.ssa, &progress);
|
|
|
|
|
if (tex->dest_type == nir_type_bool1) {
|
|
|
|
|
tex->dest_type = nir_type_bool32;
|
|
|
|
|
progress = true;
|
|
|
|
|
}
|
|
|
|
|
return progress;
|
|
|
|
|
}
|
|
|
|
|
|
nir/lower_bool: ntt: Generate a good opcode for bcsel
This is heavily copy-pasted from a patch of Ian Romanick, including the
commit message.
Previously, this pass always generated fcsel for bcsel. This was the
only place that generate fcsel, so various drivers assumed (and needed!)
that src0 was a Boolean with 0.0 or 1.0 as the only values.
Specifically, many DX9 / GL_ARB_vertex_program platforms lack a CMP
instruction in vertex shaders. In those cases, they would use LRP to
implement fcsel. The bummer is that many plaforms have a real fcsel
instruction, and those platforms would benefit from other places
generating that opcode.
Instead of leaving assumptions in drivers about the sources of an opcode
that they can't really support, allow them to control the way the
lowering pass translates bcsel. Two flags are used to control this:
- If the driver sets has_fused_comp_and_csel in nir_options, fcsel_gt
will be used. Since the Boolean value is 0.0 or 1.0, this is
equivalent to fcsel.
- If the parameter has_fcsel_ne is set, fcsel will be used. This is the
old path.
- Otherwise, the lowering pass assumes we're on a crufty, old DX9 vertex
program, and it emits flrp.
With this, the assumptions about src0 of fcsel in NTT can be removed.
If a platform can't handle fcsel, it should ensure that the lowering
pass won't generate it.
No change in shader-db.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20162>
2022-11-24 09:24:35 +01:00
|
|
|
struct lower_bool_to_float_data {
|
|
|
|
|
bool has_fcsel_ne;
|
|
|
|
|
bool has_fcsel_gt;
|
|
|
|
|
};
|
|
|
|
|
|
2018-10-22 16:44:59 -05:00
|
|
|
static bool
|
2021-08-09 13:50:53 +02:00
|
|
|
nir_lower_bool_to_float_instr(nir_builder *b,
|
|
|
|
|
nir_instr *instr,
|
nir/lower_bool: ntt: Generate a good opcode for bcsel
This is heavily copy-pasted from a patch of Ian Romanick, including the
commit message.
Previously, this pass always generated fcsel for bcsel. This was the
only place that generate fcsel, so various drivers assumed (and needed!)
that src0 was a Boolean with 0.0 or 1.0 as the only values.
Specifically, many DX9 / GL_ARB_vertex_program platforms lack a CMP
instruction in vertex shaders. In those cases, they would use LRP to
implement fcsel. The bummer is that many plaforms have a real fcsel
instruction, and those platforms would benefit from other places
generating that opcode.
Instead of leaving assumptions in drivers about the sources of an opcode
that they can't really support, allow them to control the way the
lowering pass translates bcsel. Two flags are used to control this:
- If the driver sets has_fused_comp_and_csel in nir_options, fcsel_gt
will be used. Since the Boolean value is 0.0 or 1.0, this is
equivalent to fcsel.
- If the parameter has_fcsel_ne is set, fcsel will be used. This is the
old path.
- Otherwise, the lowering pass assumes we're on a crufty, old DX9 vertex
program, and it emits flrp.
With this, the assumptions about src0 of fcsel in NTT can be removed.
If a platform can't handle fcsel, it should ensure that the lowering
pass won't generate it.
No change in shader-db.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20162>
2022-11-24 09:24:35 +01:00
|
|
|
void *cb_data)
|
2018-10-22 16:44:59 -05:00
|
|
|
{
|
nir/lower_bool: ntt: Generate a good opcode for bcsel
This is heavily copy-pasted from a patch of Ian Romanick, including the
commit message.
Previously, this pass always generated fcsel for bcsel. This was the
only place that generate fcsel, so various drivers assumed (and needed!)
that src0 was a Boolean with 0.0 or 1.0 as the only values.
Specifically, many DX9 / GL_ARB_vertex_program platforms lack a CMP
instruction in vertex shaders. In those cases, they would use LRP to
implement fcsel. The bummer is that many plaforms have a real fcsel
instruction, and those platforms would benefit from other places
generating that opcode.
Instead of leaving assumptions in drivers about the sources of an opcode
that they can't really support, allow them to control the way the
lowering pass translates bcsel. Two flags are used to control this:
- If the driver sets has_fused_comp_and_csel in nir_options, fcsel_gt
will be used. Since the Boolean value is 0.0 or 1.0, this is
equivalent to fcsel.
- If the parameter has_fcsel_ne is set, fcsel will be used. This is the
old path.
- Otherwise, the lowering pass assumes we're on a crufty, old DX9 vertex
program, and it emits flrp.
With this, the assumptions about src0 of fcsel in NTT can be removed.
If a platform can't handle fcsel, it should ensure that the lowering
pass won't generate it.
No change in shader-db.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20162>
2022-11-24 09:24:35 +01:00
|
|
|
struct lower_bool_to_float_data *data = cb_data;
|
|
|
|
|
|
2021-08-09 13:50:53 +02:00
|
|
|
switch (instr->type) {
|
|
|
|
|
case nir_instr_type_alu:
|
nir/lower_bool: ntt: Generate a good opcode for bcsel
This is heavily copy-pasted from a patch of Ian Romanick, including the
commit message.
Previously, this pass always generated fcsel for bcsel. This was the
only place that generate fcsel, so various drivers assumed (and needed!)
that src0 was a Boolean with 0.0 or 1.0 as the only values.
Specifically, many DX9 / GL_ARB_vertex_program platforms lack a CMP
instruction in vertex shaders. In those cases, they would use LRP to
implement fcsel. The bummer is that many plaforms have a real fcsel
instruction, and those platforms would benefit from other places
generating that opcode.
Instead of leaving assumptions in drivers about the sources of an opcode
that they can't really support, allow them to control the way the
lowering pass translates bcsel. Two flags are used to control this:
- If the driver sets has_fused_comp_and_csel in nir_options, fcsel_gt
will be used. Since the Boolean value is 0.0 or 1.0, this is
equivalent to fcsel.
- If the parameter has_fcsel_ne is set, fcsel will be used. This is the
old path.
- Otherwise, the lowering pass assumes we're on a crufty, old DX9 vertex
program, and it emits flrp.
With this, the assumptions about src0 of fcsel in NTT can be removed.
If a platform can't handle fcsel, it should ensure that the lowering
pass won't generate it.
No change in shader-db.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20162>
2022-11-24 09:24:35 +01:00
|
|
|
return lower_alu_instr(b, nir_instr_as_alu(instr),
|
|
|
|
|
data->has_fcsel_ne, data->has_fcsel_gt);
|
2021-08-09 13:50:53 +02:00
|
|
|
|
|
|
|
|
case nir_instr_type_load_const: {
|
|
|
|
|
nir_load_const_instr *load = nir_instr_as_load_const(instr);
|
|
|
|
|
if (load->def.bit_size == 1) {
|
|
|
|
|
nir_const_value *value = load->value;
|
|
|
|
|
for (unsigned i = 0; i < load->def.num_components; i++)
|
|
|
|
|
load->value[i].f32 = value[i].b ? 1.0 : 0.0;
|
|
|
|
|
load->def.bit_size = 32;
|
|
|
|
|
return true;
|
2018-10-22 16:44:59 -05:00
|
|
|
}
|
2021-08-09 13:50:53 +02:00
|
|
|
return false;
|
2018-10-22 16:44:59 -05:00
|
|
|
}
|
|
|
|
|
|
2021-08-09 13:50:53 +02:00
|
|
|
case nir_instr_type_intrinsic:
|
|
|
|
|
case nir_instr_type_ssa_undef:
|
|
|
|
|
case nir_instr_type_phi: {
|
|
|
|
|
bool progress = false;
|
|
|
|
|
nir_foreach_ssa_def(instr, rewrite_1bit_ssa_def_to_32bit, &progress);
|
|
|
|
|
return progress;
|
2018-10-22 16:44:59 -05:00
|
|
|
}
|
|
|
|
|
|
2021-08-09 13:50:53 +02:00
|
|
|
case nir_instr_type_tex:
|
|
|
|
|
return lower_tex_instr(nir_instr_as_tex(instr));
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
nir_foreach_ssa_def(instr, assert_ssa_def_is_not_1bit, NULL);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2018-10-22 16:44:59 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool
|
nir/lower_bool: ntt: Generate a good opcode for bcsel
This is heavily copy-pasted from a patch of Ian Romanick, including the
commit message.
Previously, this pass always generated fcsel for bcsel. This was the
only place that generate fcsel, so various drivers assumed (and needed!)
that src0 was a Boolean with 0.0 or 1.0 as the only values.
Specifically, many DX9 / GL_ARB_vertex_program platforms lack a CMP
instruction in vertex shaders. In those cases, they would use LRP to
implement fcsel. The bummer is that many plaforms have a real fcsel
instruction, and those platforms would benefit from other places
generating that opcode.
Instead of leaving assumptions in drivers about the sources of an opcode
that they can't really support, allow them to control the way the
lowering pass translates bcsel. Two flags are used to control this:
- If the driver sets has_fused_comp_and_csel in nir_options, fcsel_gt
will be used. Since the Boolean value is 0.0 or 1.0, this is
equivalent to fcsel.
- If the parameter has_fcsel_ne is set, fcsel will be used. This is the
old path.
- Otherwise, the lowering pass assumes we're on a crufty, old DX9 vertex
program, and it emits flrp.
With this, the assumptions about src0 of fcsel in NTT can be removed.
If a platform can't handle fcsel, it should ensure that the lowering
pass won't generate it.
No change in shader-db.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20162>
2022-11-24 09:24:35 +01:00
|
|
|
nir_lower_bool_to_float(nir_shader *shader, bool has_fcsel_ne)
|
2018-10-22 16:44:59 -05:00
|
|
|
{
|
nir/lower_bool: ntt: Generate a good opcode for bcsel
This is heavily copy-pasted from a patch of Ian Romanick, including the
commit message.
Previously, this pass always generated fcsel for bcsel. This was the
only place that generate fcsel, so various drivers assumed (and needed!)
that src0 was a Boolean with 0.0 or 1.0 as the only values.
Specifically, many DX9 / GL_ARB_vertex_program platforms lack a CMP
instruction in vertex shaders. In those cases, they would use LRP to
implement fcsel. The bummer is that many plaforms have a real fcsel
instruction, and those platforms would benefit from other places
generating that opcode.
Instead of leaving assumptions in drivers about the sources of an opcode
that they can't really support, allow them to control the way the
lowering pass translates bcsel. Two flags are used to control this:
- If the driver sets has_fused_comp_and_csel in nir_options, fcsel_gt
will be used. Since the Boolean value is 0.0 or 1.0, this is
equivalent to fcsel.
- If the parameter has_fcsel_ne is set, fcsel will be used. This is the
old path.
- Otherwise, the lowering pass assumes we're on a crufty, old DX9 vertex
program, and it emits flrp.
With this, the assumptions about src0 of fcsel in NTT can be removed.
If a platform can't handle fcsel, it should ensure that the lowering
pass won't generate it.
No change in shader-db.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20162>
2022-11-24 09:24:35 +01:00
|
|
|
struct lower_bool_to_float_data data = {
|
|
|
|
|
.has_fcsel_ne = has_fcsel_ne,
|
|
|
|
|
.has_fcsel_gt = shader->options->has_fused_comp_and_csel
|
|
|
|
|
};
|
|
|
|
|
|
2021-08-09 13:50:53 +02:00
|
|
|
return nir_shader_instructions_pass(shader, nir_lower_bool_to_float_instr,
|
|
|
|
|
nir_metadata_block_index |
|
|
|
|
|
nir_metadata_dominance,
|
nir/lower_bool: ntt: Generate a good opcode for bcsel
This is heavily copy-pasted from a patch of Ian Romanick, including the
commit message.
Previously, this pass always generated fcsel for bcsel. This was the
only place that generate fcsel, so various drivers assumed (and needed!)
that src0 was a Boolean with 0.0 or 1.0 as the only values.
Specifically, many DX9 / GL_ARB_vertex_program platforms lack a CMP
instruction in vertex shaders. In those cases, they would use LRP to
implement fcsel. The bummer is that many plaforms have a real fcsel
instruction, and those platforms would benefit from other places
generating that opcode.
Instead of leaving assumptions in drivers about the sources of an opcode
that they can't really support, allow them to control the way the
lowering pass translates bcsel. Two flags are used to control this:
- If the driver sets has_fused_comp_and_csel in nir_options, fcsel_gt
will be used. Since the Boolean value is 0.0 or 1.0, this is
equivalent to fcsel.
- If the parameter has_fcsel_ne is set, fcsel will be used. This is the
old path.
- Otherwise, the lowering pass assumes we're on a crufty, old DX9 vertex
program, and it emits flrp.
With this, the assumptions about src0 of fcsel in NTT can be removed.
If a platform can't handle fcsel, it should ensure that the lowering
pass won't generate it.
No change in shader-db.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20162>
2022-11-24 09:24:35 +01:00
|
|
|
&data);
|
2018-10-22 16:44:59 -05:00
|
|
|
}
|