Changed the text for the default demos to be "auto" instead of "yes"
since that didn't make much sense in this context. Added an example
value for the --with-dri-drivers option as suggested by Brian.
Allow the user to disable use of assembly code through the --disable-asm
option. This is only relevant on the platforms where assembly is
normally enabled such as Linux and FreeBSD.
Putting the bufmgr in the screen is not thread-safe since the emit_reloc
changes. It also led to a significant performance hit from pthread usage
for the attempted thread-safety (up to 12% of a cpu spent on refcounting
protection in single-threaded 965). The motivation had been to allow
multi-context bufmgr sharing in classic mode, but it wasn't worth the cost.
Allow the user to set the compiler debug flags and macros through the
option --enable-debug. This addes -DDEBUG to the macros and -g to the
CFLAGS and CXXFLAGS if gcc and g++ are in use.
Added a check that PKG_PROG_PKG_CONFIG is defined before calling it so
the user can see a proper error. Without it, the generated configure
script will just pass on to the next statement and bomb with a strange
shell syntax error.
Rather than having the user run `make autoconf' and have the Makefile
setup the configs/current -> autoconf symlink, we can just do that in
configure. This allows the user to just run `make' to build.
Since install-sh is only used to satisfy an autoconf requirement, we
don't need the actual script. Instead, it's now just a symlink to
minstall, which provides a similar install wrapper script.
This is currently believed to work but be a significant performance loss.
Performance recovery should be soon to follow.
The dri_bo_fake_disable_backing_store() call was added to allow backing store
disable like bufmgr_fake.c did, which is a significant performance win (though
it's missing the no-fence-subdata part).
This commit is a squash merge of the 965-ttm branch, which had some history
I wanted to avoid pulling due to noisiness and brokenness at many points
for git-bisecting.
The user can request specific DRI drivers to build rather than the
default of "all that build on this platform". This allows the list of
drivers to be easily slimmed down.
This is controlled through the option --with-dri-drivers. For example:
./configure --with-driver=dri --with-dri-drivers="i965,nouveau"
Unfortunately, using this setting means the DRI drivers aren't filtered
by platform anymore and you might try to build something that doesn't
work.
Allow the user to specify that they want static libraries through the
--{enable,disable}-{static,shared} switches like libtool. The mesa build
only allows for one at a time, so static will be chosen if someone has
passed --enable-static or --disable-shared.
This also allows the mklib options to be set at build time. This allows
-static to be set for mklib, but any platform specific settings are
allowed by setting MKLIB_OPTIONS for configure.
Handling of the program libraries through the APP_LIB_DEPS variable is
pretty ugly, but it seems to work.
The user can request specific demos directories to build in. For
example:
./configure --with-demos="demos,xdemos"
The drawback is that we don't check for the necessary libararies in
that case, only that the directory in progs/ exists.
Allow the user to specify channel bits of 16 or 32 to enable OSMesa16 or
OSMesa32 instead of the default OSMesa. This option is controlled
through the option --with-osmesa-bits=BITS and is only honored when the
driver is osmesa.
The osdemos are not enabled in the 16 or 32 bit case because the
Makefile is currently hardcoded to link to -lOSMesa.
Added autoconf support for using OSMesa as the driver instead linking
it to libGL. This is enabled through --with-driver=osmesa.
To differentiate these cases, another option --enable-x11-osmesa is used
to enable or disable building OSMesa when the driver is x11.
Added autoconf bits to allow using DRI as the driver through the option
--with-dri-driver=DRIVER. The options are x11 (default) and dri. Three
DRI specific options for controlling the driver directory, direct
rendering and TLS are also added.
The DRI will probably not work for platforms besides linux and freebsd.
Add targets to the top Makefile so that configure and the necessary
scripts are added to the tarball for distribution.
Variables are used for autoconf and aclocal in case anyone needs to use
a specific version or pass any extra flags.
This adds the initial support for using autoconf configuration. Support
is available for shared Xlib driver builds. Later this will be extended
to dri and osmesa-only builds and possibly targetting non-X backends.
Support for static library builds will also be added.
The configure script fills in the autoconf config. This is then used by
running `make autoconf' after ./configure.
Testing has been done on Linux/GNU. The configure script tries to
faithfully reproduce the current configs/linux* and configs/freebsd*.
Other platforms can be handled later by adding similar statements and
feature tests.
Pkg-config is used to search for packages when possible. This makes the
build much more flexible and robust to the user's configuration. This
requires that the pkg-config autoconf macros pkg.m4 are included in
aclocal.m4. This requires autoconf and aclocal from autoconf and
automake, respectively.
The standard autoconf initialization macros require that config.guess,
config.sub and install-sh exist. The config.* scripts are from gnulib
HEAD, and the install-sh script is from automake HEAD.
Most of the programs list their dependencies on the Mesa libraries in
their Makefiles. This works with the default configuration where
APP_LIB_DEPS only lists external libraries. This changes the
linux-osmesa configs and the osdemos Makefile to follow that convention.
Some cleanup of the Makefile is also added to refer to the GL libraries
through the existing variables rather than hardcoding their names.
I had forgotten part of brw_state_cache.c that made this fix not relevant for
master (last_addr comparison and flagging based on cache id).
This reverts commit a4642f3d18.
Otherwise, choosing a new program wouldn't necessarily update the state, and
and an old program could be executed, leading to various sorts of pretty
pictures or hangs.
