gallivm: fix small but severe bug in handling multiple lod level strides

Inserting the value for the second quad in the wrong place for the
following shuffle. This meant the row or image stride was undefined which is
quite catastrophic, can lead to bogus texels fetched or just segfault.
This code is only hit for SoA path currently, still surprising it
didn't crash more or caused more visible issues (I think llvm used a
broadcast shuffle for the undefined parts of the vector, hence the undefined
value for the second quad was just the same as that from the first quad,
so as long as both quads hit the same mip level everything was fine, and since
lower mips always have the same large stride it made it less likely to
hit out-of-bound memory in case of differing lods).

Note: this is a candidate for stable branches.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This commit is contained in:
Roland Scheidegger 2013-04-15 03:57:23 +02:00
parent 02b808b08a
commit 1d6eb23f2d
1 changed files with 1 additions and 1 deletions

View File

@ -934,7 +934,7 @@ lp_build_get_level_stride_vec(struct lp_build_sample_context *bld,
stride = bld->int_coord_bld.undef;
for (i = 0; i < bld->num_lods; i++) {
LLVMValueRef indexi = lp_build_const_int32(bld->gallivm, i);
LLVMValueRef indexo = lp_build_const_int32(bld->gallivm, i);
LLVMValueRef indexo = lp_build_const_int32(bld->gallivm, 4 * i);
indexes[1] = LLVMBuildExtractElement(builder, level, indexi, "");
stride1 = LLVMBuildGEP(builder, stride_array, indexes, 2, "");
stride1 = LLVMBuildLoad(builder, stride1, "");