Age | Commit message (Collapse) | Author |
|
Unnecessary now that lp_set_target_options() successful disables MMX code
emission.
|
|
|
|
|
|
LLVM 2.8 is pickier about int vs float instructions and operands.
|
|
We were working around an LLVM 2.5 bug but we're using LLVM 2.6 or later now.
This basically reverts commit baddcbc5225e12052b3bc8c07a8b65243d76574d.
This fixes the piglit bug/tri-tex-crash.c failure.
|
|
Fixes MSVC build.
|
|
The viewport state was being baked in at compile time (oops...)
|
|
|
|
|
|
|
|
|
|
Fixes recompilation, but seems to be broken with llvm 2.8.
|
|
There's no apparent reason for the former to exist. And they didn't
even have the same value.
|
|
|
|
|
|
http://bugs.freedesktop.org/show_bug.cgi?id=30516
|
|
Fixes a regression caused from the change to make min/max lod dynamic
state.
https://bugs.freedesktop.org/show_bug.cgi?id=30437
|
|
Corrections in store_clip to store clip coordinates in AoS form.
Viewport & cliptest flag options based on variant key.
Put back draw_pt_post_vs and now 2 paths based on whether clipping
occurs or not.
|
|
Cliptesting now done at the end of vs in draw_llvm instead of
draw_pt_post_vs.
Added viewport mapping transformation and further cliptesting to
vertex shader in draw_llvm.c
Alternative path where vertex header setup, clip coordinates store,
cliptesting and viewport mapping are done earlier in the vertex
shader.
Still need to hook this up properly according to the return value of
"draw_llvm_shader" function.
|
|
|
|
|
|
Changes in v2:
- Change function name
Currently draw_llvm refuses to create itself on non-SSE2 CPUs due to
an alleged LLVM bug.
However, this is implemented improperly, because other parts of draw
still attempt to access draw->llvm, resulting in segfaults.
Instead, put the check in debug_get_option_draw_use_llvm, check that
before calling draw_llvm_create, and then check whether draw->llvm is
non-null everywhere else.
|
|
|
|
Two integers were being operated on as
a vector of floats in draw_llvm_generate().
This bug got uncovered by fixing this bug:
http://bugs.freedesktop.org/29407
|
|
|
|
|
|
|
|
This is a work-around for an apparent bug in LLVM seen with piglit's
glsl-vs-sqrt-zero test.
|
|
|
|
fixes instancing in draw llvm
|
|
|
|
textures is an array of size PIPE_MAX_VERTEX_SAMPLERS.
|
|
softpipe doesn't implement the draw's llvm tex sampling interface
so make sure draw can handle the cases where the driver doesn't
implement the interface
|
|
|
|
we used to create and cache unltimited number of variant, this
change limits the number of variants kept around to a fixed number.
the change is based on a similar patch by Roland for llvmpipe fragment
shaders.
|
|
|
|
|
|
|
|
|
|
|
|
Note that this also requires X86 for llvm, if llvmpipe/draw_llvm works
on PPC then the condition should be extended to include && x86.
Signed-off-by: Török Edwin <edwintorok@gmail.com>
Signed-off-by: José Fonseca <jfonseca@vmware.com>
|
|
This gives a ~30% shader optimization time improvement on blender.
Tested by comparing the dumped LLVM modules.
Current ordering:
time ~/llvm-git/obj/Release-Asserts/bin/opt l.bc -constprop -instcombine
-mem2reg -gvn -simplifycfg
real 0m1.126s
user 0m1.108s
sys 0m0.012s
With this patch:
time ~/llvm-git/obj/Release-Asserts/bin/opt l.bc -mem2reg -constprop -instcombine -gvn -simplifycfg
real 0m0.885s
user 0m0.880s
sys 0m0.000s
The overall improvement in blender is ~15%.
Blender without the patch takes 1m13s:
edwin 5934 87.6 11.5 729440 458296 pts/5 SLl+ 17:35 1:13 blender
Blender with the patch takes 1m3s:
edwin 5726 94.2 11.2 716424 446168 pts/5 SLl+ 17:32 1:03 blender
It is still slow with the patch, but better (most of the optimization time is
taken up by GVN, see LLVM PR7023).
Signed-off-by: Török Edwin <edwintorok@gmail.com>
Signed-off-by: José Fonseca <jfonseca@vmware.com>
|
|
|
|
if fetch_count % 4 != 0 then on the last iteration we fetch garbage.
this patch makes sure we stay within bounds
|
|
we were only running the llvm paths when the input elts were linear,
now we can handle abritrary fetch elts arrays. we do this by generating
two paths - linear and fetch_elts one and just selecting the right one
at run time.
|
|
Everybody should respect max_index, specially llvm generated code, which
likes to eat vertices 4 at a time, so it may end up chew a bit a bit more
than actually exists.
|
|
|
|
a bit more involved than indirect addressing over consts, but still
fairly reasonable. we allocate an array instead of individual alloca's,
and we do it only if the shader does indirect addressing.
|
|
|
|
use just one constructor to figure out whether to use llvm.
|