ParseSourceList() can be used to parse a source list file and returns
the source files defined in it. It is supposed to be used like this
# get the list of source files from C_SOURCES in Makefile.sources
sources = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
The syntax of a source list file is compatible with GNU Make. This
effectively allows SConscript and Makefile to share the source lists.
Acked-by: José Fonseca <jfonseca@vmware.com>
Acked-by: Chad Versace <chad@chad-versace.us>
Optional parallel rendering of spans using OpenMP.
Initial implementation for aa triangles. A new option for scons is
also provided to activate the openmp support (off by default).
Signed-off-by: Brian Paul <brianp@vmware.com>
Because:
- bindings are not fully automatic, and they are broken most of the time
- unit tests/samples can be written in C on top of graw
- tracing/retracing is more useful at API levels with stable ABIs such as
GL, producing traces that cover more layers of the driver stack and and
can be used for regression testing
platform.system in SCons on Cygwin includes the OS version number.
Windows XP - CYGWIN_NT-5.1
Windows Vista - CYGWIN_NT-6.0
Windows 7 - CYGWIN_NT-6.1
Reduce all Cygwin platform variants to just 'cygwin' so anything
downstream can simply use 'cygwin' instead of the different full
platform names.
Certain mingw32 cross compilers (e.g. RedHat's) defaults to use DLL gcc
runtime.
Given the main deliverable from this project are self-contained drivers,
which are loaded by any application, this dependency can cause havoc.
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.
The Mac OS X SCons build failed on 32-bit CPUs starting with commit
2f6d47a7c8 during linking of graw-null.
The build succeeds though on a 64-bit CPU. See FDO bug 29117.
This was the compiler error.
scons: building associated VariantDir targets: build/darwin-x86-debug
Linking build/darwin-x86-debug/gallium/targets/graw-null/libgraw.dylib ...
Undefined symbols:
"_lp_swizzled_cbuf", referenced from:
_lp_swizzled_cbuf$non_lazy_ptr in libllvmpipe.a(lp_rast.os)
_lp_swizzled_cbuf$non_lazy_ptr in libllvmpipe.a(lp_rast_tri.os)
(maybe you meant: _lp_swizzled_cbuf$non_lazy_ptr)
"_lp_dummy_tile", referenced from:
_lp_dummy_tile$non_lazy_ptr in libllvmpipe.a(lp_rast.os)
_lp_dummy_tile$non_lazy_ptr in libllvmpipe.a(lp_rast_tri.os)
_lp_dummy_tile$non_lazy_ptr in libllvmpipe.a(lp_setup.os)
(maybe you meant: _lp_dummy_tile$non_lazy_ptr)
The patch adds -fno-common to all Mac OS X builds to work around this issue.
Now that draw depends on llvm it is very difficult to correctly handle
broken llvm installations. Either the user requests LLVM and it needs to
supply a working installation. Or it doesn't, and it gets no LLVM
accelerate pipe drivers.
This serves several purposes:
- disable caching in situations were is it useless or undesired
- share caches among all trees
- simplify purging the cache (when it's a single location)
- move the cache out of the tree, since that slows downs IDEs considerably
To retain previous behavior just define do
export SCONS_CACHE_DIR=$PWD/build/cache
before invoking scons.
Everybody is using the C99's integer types. Everybody except Microsoft,
which in turns means everybody is including their own definitions of C99
integer types for MSVC, causing duplicate definitions when linking two
projects. This is the case of building Gallium and LLVM with MSVC.
Shipping alternative stdint.h and stdbool.h headers for MSVC allows us
to share a single definition. It also removes clutter from the Gallium
headers.
Some of the demo progams legitimately need the functionality
that's disabled by WIN32_LEAN_AND_MEAN.
Instead the solution should be to define WIN32_LEAN_AND_MEAN just before
including windows.h on a case by case basis.
Strict aliasing tule violations were fixed on master, but
they're still causing problem in this branch, so disable this assumptions.
Do not apply this fix to master (revert when you merge).
-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.
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.
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.
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.
It a scary world out there: people use all sort of non standard C stuff,
and we must enable support for that in here in order to build.
-pedantic still warn us when we use that nonstandard though.
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.
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.
To build an alternative opengl32.dll with Gallium's software-rasterizer from a
debian-based distribution run:
sudo apt-get install mingw32
scons platform=windows toolchain=crossmingw machine=x86 winsys=gdi dri=no
To build an alternative opengl32.dll with Gallium's software-rasterizer from a
debian-based distribution run:
sudo apt-get install mingw32
scons platform=windows toolchain=crossmingw machine=x86 winsys=gdi dri=no
env.CodeGenerate(
target = 'my_source.c',
script = 'my_generator.py',
source = ['input.txt', 'another.txt'],
command = 'python $SCRIPT $SOURCE > $TARGET'
)
It will take care generating all appropriate dependencies, including any
module imported by the generator script, and the respective .pyc file
side effects.
Chia-I Wu
José Fonseca
Andreas Fänger
José Fonseca
Vinson Lee
Jakob Bornecrantz
Brian Paul
Alan Hourihane
Michel Dänzer
Keith Whitwell
Keith Whitwell
José Fonseca
Alan Hourihane
Michal Krol
Michel Dänzer
Jonathan White