[Mesa-dev] [Bug 29407] llvm 2.8 asserts: "Tried to create an integer operation on a non-integer type!"

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29407

--- Comment #7 from steckdenis at yahoo.fr 2010-08-06 08:14:55 PDT ---
Created an attachment (id=37640)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37640)
Compressed output of neverball when running with llvmpipe (4,7 MB uncompressed)

Hello,

I looked at the code and found the source of the bug I reported in my previous
comment. The line 231 in gallivm/lp_bld_arit.c uses the lp_type found in the
lp_build_context struct, without taking in account the ones of a and b.

When this function is called by draw_llvm_generate (line 737 of
draw/draw_llvm.c), this type is set as .floating=1 and .fixed=0, by
lp_build_context_init() I think.

This is wrong for this first addition, made just after the prolog of the LLVM
function. I made a quick and highly dirty hack to work around this issue :

diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index de99b00..8e40c35 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -734,7 +734,11 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant)

    lp_build_context_init(&bld, builder, vs_type);

+   bld.type.fixed = 1;
+   bld.type.floating = 0;
    end = lp_build_add(&bld, start, count);
+   bld.type.fixed = 0;
+   bld.type.floating = 1;

    step = LLVMConstInt(LLVMInt32Type(), max_vertices, 0);

It's awful, but it works. I was able to see Glxgears running at 97 fps entirely
software rendered, on my AMD Athlon 64 L110 at 1,2Ghz, single core, without HT,
with 512Kb of cache. Good job, it is nearly seven times as fast as softpipe !

Unfortunately, I was not able to test llvmpipe with Neverball because some
errors are still there. I looked at your patch, and it is full of "if
(type.floating)", where type is the lp_type of the current lp_build_context.

Is it possible to use the LLVMValueRefs passed to all these functions to get
their type, and to choose the correct function for them ? It will be more
robust than assuming that all variables used in a shader are of the same type.

Note:

I found in the Core.h file of LLVM some interesting things : 

LLVMTypeRef LLVMTypeOf(LLVMValueRef Val);  // You get the type of the variable
LLVMTypeKind LLVMGetTypeKind(LLVMTypeRef Ty); // Now you have informations for
the type

// And here are the types :
typedef enum {
  LLVMVoidTypeKind,
  LLVMFloatTypeKind,
  LLVMDoubleTypeKind,
  LLVMX86_FP80TypeKind,
  LLVMFP128TypeKind,
  LLVMPPC_FP128TypeKind,
  LLVMLabelTypeKind,
  LLVMIntegerTypeKind,     // The interesting one
  LLVMFunctionTypeKind,
  LLVMStructTypeKind,
  LLVMArrayTypeKind,
  LLVMPointerTypeKind,
  LLVMOpaqueTypeKind,
  LLVMVectorTypeKind,      // Here we don't known what is contained in the
vector
  LLVMMetadataTypeKind,
  LLVMUnionTypeKind
} LLVMTypeKind;

But I don't know if it's possible, and if it will be fast enough.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.