[Mesa-dev] [PATCH] radeonsi: fix an off-by-one error in the bounds check for max_vertices
Edward O'Callaghan
funfunctor at folklore1984.net
Tue Dec 6 22:21:11 UTC 2016
Reviewed-by: Edward O'Callaghan <funfunctor at folklore1984.net>
On 12/07/2016 07:06 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle <nicolai.haehnle at amd.com>
>
> The spec actually says that calling EmitStreamVertex is undefined when
> you exceed max_vertices. But we do need to avoid trampling over memory
> outside the GSVS ring.
>
> Cc: mesa-stable at lists.freedesktop.org
> --
> One more thing I noticed on top of all the other GS changes...
> ---
> src/gallium/drivers/radeonsi/si_shader.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c b/src/gallium/drivers/radeonsi/si_shader.c
> index dee2a17..749823d 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -5181,21 +5181,21 @@ static void si_llvm_emit_vertex(
> "");
>
> /* If this thread has already emitted the declared maximum number of
> * vertices, skip the write: excessive vertex emissions are not
> * supposed to have any effect.
> *
> * If the shader has no writes to memory, kill it instead. This skips
> * further memory loads and may allow LLVM to skip to the end
> * altogether.
> */
> - can_emit = LLVMBuildICmp(gallivm->builder, LLVMIntULE, gs_next_vertex,
> + can_emit = LLVMBuildICmp(gallivm->builder, LLVMIntULT, gs_next_vertex,
> lp_build_const_int32(gallivm,
> shader->selector->gs_max_out_vertices), "");
>
> bool use_kill = !info->writes_memory;
> if (use_kill) {
> kill = lp_build_select(&bld_base->base, can_emit,
> lp_build_const_float(gallivm, 1.0f),
> lp_build_const_float(gallivm, -1.0f));
>
> lp_build_intrinsic(gallivm->builder, "llvm.AMDGPU.kill",
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161207/b008cf5c/attachment.sig>
More information about the mesa-dev
mailing list