Age | Commit message (Collapse) | Author |
|
Something is not quite right, however. The piglit tests mentioned in
fd.o bug 31226 still don't pass.
|
|
Use scons target and dependency system instead of ad-hoc options.
Now is simply a matter of naming what to build. For example:
scons libgl-xlib
scons libgl-gdi
scons graw-progs
scons llvmpipe
and so on. And there is also the possibility of scepcified subdirs, e.g.
scons src/gallium/drivers
If nothing is specified then everything will be build.
There might be some rough corners over the next days. Please bare with me.
|
|
Unnecessary now that lp_set_target_options() successful disables MMX code
emission.
|
|
|
|
|
|
First, it changes autoconf to use a "python2" binary when available,
rather than plain "python" (which is ambiguous). Secondly, it changes
the Makefiles to use $(PYTHON) $(PYTHON_FLAGS) rather than calling
python directly.
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
Signed-off-by: Matthew William Cox <matt@mattcox.ca>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
|
|
|
|
|
|
|
|
Conflicts:
docs/relnotes-7.10.html
This branch is a re-do of the primitive-restart branch with all
the intermediate/temporary stuff cleaned out.
|
|
|
|
|
|
Fixes this GCC warning.
gallivm/lp_bld_tgsi_aos.c: In function 'lp_build_tgsi_aos':
gallivm/lp_bld_tgsi_aos.c:516: warning: 'dst0' may be used uninitialized in this function
gallivm/lp_bld_tgsi_aos.c:516: note: 'dst0' was declared here
|
|
Fixes these GCC warnings.
gallivm/lp_bld_sample_aos.c: In function 'lp_build_sample_image_nearest':
gallivm/lp_bld_sample_aos.c:271: warning: 't_ipart' may be used uninitialized in this function
gallivm/lp_bld_sample_aos.c:271: warning: 'r_ipart' may be used uninitialized in this function
|
|
Fixes these GCC warnings.
gallivm/lp_bld_sample_aos.c: In function 'lp_build_sample_image_linear':
gallivm/lp_bld_sample_aos.c:439: warning: 'r_ipart' may be used uninitialized in this function
gallivm/lp_bld_sample_aos.c:438: warning: 't_ipart' may be used uninitialized in this function
gallivm/lp_bld_sample_aos.c:438: warning: 't_fpart' may be used uninitialized in this function
gallivm/lp_bld_sample_aos.c:439: warning: 'r_fpart' may be used uninitialized in this function
gallivm/lp_bld_sample_aos.c:438: warning: 't_fpart_hi' may be used uninitialized in this function
gallivm/lp_bld_sample_aos.c:438: warning: 't_fpart_lo' may be used uninitialized in this function
gallivm/lp_bld_sample_aos.c:439: warning: 'r_fpart_hi' may be used uninitialized in this function
gallivm/lp_bld_sample_aos.c:439: warning: 'r_fpart_lo' may be used uninitialized in this function
|
|
|
|
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...)
|
|
|
|
|
|
http://bugs.freedesktop.org/show_bug.cgi?id=30974
|
|
|
|
|
|
|
|
|
|
Derivatives are now scalar.
Broken since 17dbd41cf23e7e7de2f27e5e9252d7f792d932f3.
|
|
|
|
There's no LLVM C LLVMBuildLoadVolatile() function so roll our own.
Not used anywhere at this time but can come in handy during debugging.
|
|
|
|
Instead of having a NAME_SOFTWARE check just use the GALLIUM_DRIVER
instead but set the default to native which is the same as not wrapped.
|
|
|
|
|
|
|
|
|
|
Disabling address printing is helpful for diffing.
|
|
Fixes recompilation, but seems to be broken with llvm 2.8.
|
|
|
|
The bug only happens on the AOS / fixed-pt path.
|
|
|
|
This is relying on lp_build_pack2 using the sse2 pack intrinsics which
handle clamping.
(Alternatively could have make it use lp_build_packs2 but it might
not even produce more efficient code than not using the fastpath
in the first place.)
|
|
There's no apparent reason for the former to exist. And they didn't
even have the same value.
|
|
|
|
There seems to be no reason for it, so do same math for both
(except the scale mul, of course).
|
|
|
|
Has similiar use cases to the S8X24 and X24S8 formats.
|
|
these formats are needed for hw that can sample and write stencil values.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
this adds the capability + a stencil semantic id, + tgsi scan support.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|