[Mesa-dev] [PATCH] gallivm: fix rsq behavior
Roland Scheidegger
sroland at vmware.com
Thu Jul 11 09:33:22 PDT 2013
Am 11.07.2013 18:18, schrieb Zack Rusin:
> GLSL spec says that rsq is undefined for src<=0, but the D3D10
> spec says it needs to be a NaN, so lets stop taking an absolute
> value of the source which completely breaks that behavior.
>
> Signed-off-by: Zack Rusin <zackr at vmware.com>
> ---
> src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c
> index 1feaa19..8c26918 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c
> @@ -633,8 +633,6 @@ rsq_emit(
> struct lp_build_tgsi_context * bld_base,
> struct lp_build_emit_data * emit_data)
> {
> - emit_data->args[0] = lp_build_emit_llvm_unary(bld_base, TGSI_OPCODE_ABS,
> - emit_data->args[0]);
> if (bld_base->rsq_action.emit) {
> bld_base->rsq_action.emit(&bld_base->rsq_action, bld_base, emit_data);
> } else {
>
I have some faint recollection this breaks something if you do that.
Also the tgsi instruction is clearly defined to behave that way, I
suspect it comes from some older definition (most likely
ARB_vertex_program, which states "The RSQ instruction approximates the
reciprocal of the square root of the absolute value of the scalar
operand and replicates it to all four components of the result vector."
So I think if you want to fix that you'd need to adjust docs too, plus
mesa_to_tgsi code to add the abs value, and it looks like d3d9 needs the
abs too.
Not sure what the right fix is, another opcode seems kind of overkill
but might be easiest.
Roland
More information about the mesa-dev
mailing list