[Mesa-dev] [PATCH] gallivm: fix improper clamping of vertex index when fetching gs inputs
Jose Fonseca
jfonseca at vmware.com
Thu Nov 8 13:59:41 UTC 2018
Good find.
On 08/11/2018 01:54, sroland at vmware.com wrote:
> From: Roland Scheidegger <sroland at vmware.com>
>
> Because we only have one file_max for the (2d) gs input file, the value
> actually represents the max of attrib and vertex index (although I'm
> not entirely sure if we really want the max, since the max valid value
> of the vertex dimension can be easily deduced from the input primitive).
Yes, perhaps we should have a 2nd file_max array for the 2nd axis. But
it would be a more invasive change.
> Thus in cases where the number of inputs is higher than the number of
> vertices per prim, we did not properly clamp the vertex index, which
> would result in out-of-bound fetches, potentially causing segfaults
> (the segfaults seemed actually difficult to trigger, but valgrind
> certainly wasn't happy). This might have happened even if the shader
> did not actually try to fetch bogus vertices, if the fetching happened
> in non-active conditional clauses.
>
> To fix simply use the correct max vertex index value (derived from
> the input prim type) instead when clamping for this case.
> ---
> .../auxiliary/gallivm/lp_bld_tgsi_soa.c | 38 ++++++++++++++-----
> 1 file changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> index 83d7dbea9a..0db81b31ad 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> @@ -41,6 +41,7 @@
> #include "util/u_debug.h"
> #include "util/u_math.h"
> #include "util/u_memory.h"
> +#include "util/u_prim.h"
> #include "tgsi/tgsi_dump.h"
> #include "tgsi/tgsi_exec.h"
> #include "tgsi/tgsi_info.h"
> @@ -1059,7 +1060,8 @@ emit_mask_scatter(struct lp_build_tgsi_soa_context *bld,
> static LLVMValueRef
> get_indirect_index(struct lp_build_tgsi_soa_context *bld,
> unsigned reg_file, unsigned reg_index,
> - const struct tgsi_ind_register *indirect_reg)
> + const struct tgsi_ind_register *indirect_reg,
> + unsigned index_limit)
file_max array is signed, so let's make index_limit also signed, and
assert here in this function that it is positive. This would trap if
some caller gets the limit for the wrong file.
Which reminds me -- SM4 allows to declare constant buffers with
undeclared size. What exactly would we get passed here in those
circunstances? In practice constant buffers can't be larger than 64KB,
which means we could presume filemax is 4K registers.
> {
> LLVMBuilderRef builder = bld->bld_base.base.gallivm->builder;
> struct lp_build_context *uint_bld = &bld->bld_base.uint_bld;
> @@ -1107,8 +1109,7 @@ get_indirect_index(struct lp_build_tgsi_soa_context *bld,
> */
> if (reg_file != TGSI_FILE_CONSTANT) {
> max_index = lp_build_const_int_vec(bld->bld_base.base.gallivm,
> - uint_bld->type,
> - bld->bld_base.info->file_max[reg_file]);
> + uint_bld->type, index_limit);
>
> assert(!uint_bld->type.sign);
> index = lp_build_min(uint_bld, index, max_index);
> @@ -1224,7 +1225,8 @@ emit_fetch_constant(
> indirect_index = get_indirect_index(bld,
> reg->Register.File,
> reg->Register.Index,
> - ®->Indirect);
> + ®->Indirect,
> + bld->bld_base.info->file_max[reg->Register.File]);
>
> /* All fetches are from the same constant buffer, so
> * we need to propagate the size to a vector to do a
> @@ -1341,7 +1343,8 @@ emit_fetch_immediate(
> indirect_index = get_indirect_index(bld,
> reg->Register.File,
> reg->Register.Index,
> - ®->Indirect);
> + ®->Indirect,
> + bld->bld_base.info->file_max[reg->Register.File]);
> /*
> * Unlike for other reg classes, adding pixel offsets is unnecessary -
> * immediates are stored as full vectors (FIXME??? - might be better
> @@ -1414,7 +1417,8 @@ emit_fetch_input(
> indirect_index = get_indirect_index(bld,
> reg->Register.File,
> reg->Register.Index,
> - ®->Indirect);
> + ®->Indirect,
> + bld->bld_base.info->file_max[reg->Register.File]);
>
> index_vec = get_soa_array_offsets(&bld_base->uint_bld,
> indirect_index,
> @@ -1502,7 +1506,15 @@ emit_fetch_gs_input(
> attrib_index = get_indirect_index(bld,
> reg->Register.File,
> reg->Register.Index,
> - ®->Indirect);
> + ®->Indirect,
> + /*
> + * XXX: this is possibly not quite the right value, since file_max may be
> + * larger than the max attrib index, due to it being the max of declared
> + * inputs AND the max vertices per prim (which is 6 for tri adj).
> + * It should however be safe to use (since we always allocate
> + * PIPE_MAX_SHADER_INPUTS (80) for it, which is overallocated quite a bit).
> + */
> + info->file_max[reg->Register.File]);
> } else {
> attrib_index = lp_build_const_int32(gallivm, reg->Register.Index);
> }
> @@ -1511,7 +1523,11 @@ emit_fetch_gs_input(
> vertex_index = get_indirect_index(bld,
> reg->Register.File,
> reg->Dimension.Index,
> - ®->DimIndirect);
> + ®->DimIndirect,
> + /*
> + * A fixed 6 should do as well (which is what we allocate).
> + */
This mid-call comment makes code hard to read. let's just put the
`u_vertices_per_prim(info->properties[TGSI_PROPERTY_GS_INPUT_PRIM])` in
a local variable before get_indirect_index call and comment there.
> + u_vertices_per_prim(info->properties[TGSI_PROPERTY_GS_INPUT_PRIM]));
> } else {
> vertex_index = lp_build_const_int32(gallivm, reg->Dimension.Index);
> }
> @@ -1565,7 +1581,8 @@ emit_fetch_temporary(
> indirect_index = get_indirect_index(bld,
> reg->Register.File,
> reg->Register.Index,
> - ®->Indirect);
> + ®->Indirect,
> + bld->bld_base.info->file_max[reg->Register.File]);
>
> index_vec = get_soa_array_offsets(&bld_base->uint_bld,
> indirect_index,
> @@ -1785,7 +1802,8 @@ emit_store_chan(
> indirect_index = get_indirect_index(bld,
> reg->Register.File,
> reg->Register.Index,
> - ®->Indirect);
> + ®->Indirect,
> + bld->bld_base.info->file_max[reg->Register.File]);
> } else {
> assert(reg->Register.Index <=
> bld_base->info->file_max[reg->Register.File]);
>
Otherwise looks great.
Reviewed-by: Jose Fonseca <jfonseca at vmware.com>
More information about the mesa-dev
mailing list