| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
It's not sampling based so its results are biased towards functions called
many times.
|
| |
|
|
|
|
|
| |
Doesn't quite work yet though, as small differences in the compilation flags
used when building LLVM and Mesa cause link failures for STL symbols.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-mstackrealign causes stack corruption on MinGW. And without it the ability
to use SSE instrinsics goes down the drain. Even if we use
__attribute__((force_align_arg_pointer)) for the functions we explicitly
use SSE instrinsics, the SSE code automatically generated by gcc will
cause assertion failures. What a nightmare.
Thankfully LLVM gets this right, so all runtime generated SSE code just
works. rtasm code doesn't assume 16byte alignment. Therefore the bulk of
our performance sensitive code is not affected by this.
Still, intrinsics can be convenient, and it would be nice
to get this working again some day, sp will try to get a reduced test
case.
|
|
|
|
| |
Not always present.
|
|
|
|
|
|
| |
gprof is useful for shared libraries, hence our drivers. Nevertheless
profilers like oprofile can benefit from disabling some relatively
minor optimizations for more accurate / complete results.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It is impossible to have gcc generate SSE code without it, as thirdparty
applications often call us with an unaligned stack pointer.
|
|
|
|
|
| |
Ubuntu 8.10 has llvm-config version 2.2, which doesn't have
nativecodegen. This triggers an exception.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Makefile
progs/glsl/multitex.c
src/mesa/main/enums.c
src/mesa/main/state.c
src/mesa/main/texenvprogram.c
src/mesa/main/version.h
|
| |
| |
| |
| |
| |
| | |
See also:
- http://bugs.python.org/issue6476
- http://scons.tigris.org/issues/show_bug.cgi?id=2449
|
|\| |
|
| |
| |
| |
| |
| | |
Unfortunately scons does not check if a tool exists before it invokes
its generate function.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
gcc-4.2's optimizer has a strange bug where it looses code from inner
loops in certain situations. For example, if the appearently innocent
looking code below is compiled with gcc-4.2 -S -O1, the inner loop's
code is missing from the outputed assembly.
struct Size {
unsigned width;
};
struct Command {
unsigned length;
struct Size sizes[32];
};
extern void emit_command(void *command, unsigned length);
void
create_surface( struct Size size, unsigned faces, unsigned levels)
{
struct Command cmd;
unsigned face;
unsigned level;
cmd.length = faces*levels*sizeof(cmd.sizes[0]);
for(face = 0; face < faces; ++face) {
for(level = 0; level < levels; ++level) {
cmd.sizes[face*levels + level] = size;
// This should generate a shrl statement, but the whole for body
// disappears in gcc-4.2 -O1/-O2/-O3!
size.width >>= 1;
}
}
emit(&cmd, sizeof cmd.length + cmd.length);
}
Note that this is not specific to MinGW's gcc-4.2 crosscompiler (the
version typically found in debian/ubuntu's mingw32 packages). gcc-4.2 on
Linux also displays the same error. gcc-4.3 and above gets this
correctly though.
Updated MinGW debian packages with gcc-4.3 are available from
http://people.freedesktop.org/~jrfonseca/debian/pool/main/m/
|
| |
| |
| |
| |
| |
| |
| |
| | |
This prevents the error
relocation R_X86_64_PC32 against symbol `_gl_DispatchTSD' can not be used when making a shared object; recompile with -fPIC
when building on x86_64 architecture.
|
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Makefile
src/gallium/drivers/softpipe/sp_screen.c
src/mesa/main/version.h
|
| |
| |
| |
| |
| | |
Also works with MinGW, as long as the path to the DirectX SDK top
directory is set in the DXSDK_DIR environment variable.
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/drivers/dri/i915/i915_tex_layout.c
src/mesa/drivers/dri/i965/brw_wm_glsl.c
src/mesa/drivers/dri/intel/intel_buffer_objects.c
src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
src/mesa/drivers/dri/intel/intel_pixel_draw.c
src/mesa/main/enums.c
src/mesa/main/texstate.c
src/mesa/vbo/vbo_exec_array.c
|
| | |
|
| |
| |
| |
| |
| |
| | |
Per Brian's request.
This reverts commit 25f0c33bb3509958a532bdd72b3945c1d5d1cad5.
|
| |
| |
| |
| | |
Match what autotools and other build systems do by default.
|
|/
|
|
| |
Also add ASPPCOMSTR.
|
|
|
|
| |
This reverts commit fc7f92478286041a018ac4e72d2ccedeea7c0eca.
|
|
|
|
|
|
| |
MSVC 64bit compiler takes forever on some of the files.
Might want to revisit this again later.
|
|
|
|
| |
You can still get the old behavior by passing the option quiet=no to scons.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Have to use LINK /LIB instead. The biggest problem is when the command
line is very long and all the options are included in a argument file --
link doesn't like if /LIB is included in the argument file.
|
| |
|
| |
|
|
|
|
| |
x86_64 is also supported.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/gallium/auxiliary/pipebuffer/pb_bufmgr_mm.c
src/gallium/auxiliary/util/u_tile.c
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
MSVC may not support full C99, but supports more than plain C90. And
-pedantic without -std=c99 generates too many spurious warnings
(specially C++ style comments) to be of any use.
Note that using certain C99 features in the cross-platform parts of Gallium
is still not possible; namely mid-of-scope variable declarations and named
structure initializers will break MSVC builds.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Just demos and trivial dirs for starters.
Conflicts:
.gitignore
|
| | |
|
| | |
|