As Chia-I Wu said 'There are two libGL providers, Xlib and DRI based
they cannot coexist'
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Marek Olšák <maraeo@gmail.com>
This version is mostly Dan's post to the mesa-dev mailing list on
6/22/2011.
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Use the new swap event type so we get valid SBC values.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
libdrm is used in multiple places. Always check for it and set
have_libdrm. Each user can then check the variable.
This is useful when only EGL and DRI drivers are needed.
The idea is that DRI driver, libGL and libOSMesa are libraries that can
be independently enabled, yet --with-driver does not allow us to easily
do that, if not impossible. This also matches what
--enable-{egl,xorg,d3d1x} do for the respective libraries.
There are two libGL providers: Xlib-based and DRI-based. They cannot
coexist. To be able to choose between them, --enable-xlib-glx is also
added.
With this commit, --with-driver=dri can be replaced by
$ ./configure --enable-dri --enable-glx --disable-osmesa
--with-driver=xlib can be replaced by
$ ./configure --disable-dri --enable-glx --enable-osmesa \
--enable-xlib-glx
and --with-driver=osmesa can be replaced by
$ ./configure --disable-dri --disable-glx --enable-osmesa
Some combinations that cannot be supported with --with-driver will
produce errors at the moment. But in the future, we would like to
support, for example,
$ ./configure --enable-dri --disable-glx --enable-egl
(build libEGL and DRI drivers, but not libGL)
Note that this commit still keeps --with-driver for transitional
purpose.
All it's going to do is generate lots and lots and lots of
'warning: visibility attribute not supported in this configuration; ignored'
warnings
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
If --disable-gallium is passed, llvm-config isn't checked for, so mark
it explicitly as absent, through LLVM_CONFIG=no.
Passing --disable-gallium would result in:
| ../configure: line 9739: --version: command not found
| ../configure: line 9740: --cppflags: command not found
| ../configure: line 9741: --libs: command not found
| ../configure: line 9743: --ldflags: command not found
With this commit, one gets that instead:
| configure: error: LLVM is required to build Gallium R300 on x86 and x86_64
Signed-off-by: Cyril Brulebois <kibi@debian.org>
This removes all the --enable-gallium-$driver options and --disable-gallium.
Gallium can be disabled by --with-gallium-drivers= (without parameters).
Default is:
--with-gallium-drivers=r300,swrast
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
There is an obvious redundancy:
--with-driver=dri VS --with-state-trackers=dri
--with-driver=xlib VS --with-state-trackers=glx
--enable-openvg VS --with-state-trackers=vega
--enable-egl VS --with-state-trackers=egl
This patch adds two new options for the remaining state trackers:
--enable-xorg
--enable-d3d1x
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
- Based on the work of Себастьян Gliţa Κατινα <cglita@yahoo.com>
- Split Makefile.template into Makefile.defines and Makefile.targets
- Adapt other drivers to new situation
- Fixes https://bugs.freedesktop.org/show_bug.cgi?id=35441
Signed-off-by: Brian Paul <brianp@vmware.com>
Based uppon a patch from Pali Rohár <pali.rohar@gmail.com>.
This seems to get at least YUV->RGB conversion working.
So a simple "mplayer -vo vdpau" now seems to work fine.
Correctly links against selinux library when MESA is built with --enable-selinux option.
Fixes bug #36333 in Freedesktop bugzilla
Signed-off-by: Dave Airlie <airlied@redhat.com>
We only handle a 32 bit swap count, so use the new structure definitions.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
So --enable-texture-float it is.
Hardware drivers (including the Gallium ones) should
use #ifdef TEXTURE_FLOAT_ENABLED to hide any code that may
expose floating-point renderbuffers via any interface,
public or private.
v2: Print a warning when using --enable-texture-float.
Add Cygwin platform-specific settings and drivers to build for dri driver:
- by default, disable direct rendering.
- if direct rendering is enabled, the swrast dridriver is the only one it's
sensible to try to build (this doesn't work at the moment as additional patches
are required to build a libGL which can load just swrast without the DRM headers,
even though there's no actual functional dependency)
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Julien Cristau <jcristau@debian.org>
The Hurd kernel doesn't have DRM yet.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-By: Jakob Bornecrantz <wallbraker@gmail.com>
Fix build when configured --with-driver=dri --disable-driglx-direct on targets
without drm e.g. GNU/Hurd and Cygwin
Based on the Debian patch file '05_hurd-ftbfs.diff' by Samuel Thibault.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-By: Jakob Bornecrantz <wallbraker@gmail.com>
We need more and more of these, and it is difficult and prone to version
incompatability issues trying to single out every one of them.
This mimicks what was done in SCons.
This commit is basically a copy-over of the fix
Chia-I Wu's commited to wayland:
http://cgit.freedesktop.org/wayland/wayland-demos/commit/?id=1b6c0ed95
"Workaround an xcb-dri2 bug.
xcb_dri2_connect_device_name generated by xcb-proto 1.6 is broken.
It only works when the length of the driver name is a multiple of 4."
In my last commit I introduced a build dependency upon a new libdrm.
Add the associated autoconf checks. As the headers are part of the core
libdrm, we need to bump that version and so may as well bump the chipset
specific versions simultaneously.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fix a typo which meant that --enable-shared-glapi didn't actually cause a shared glapi to be built
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
This an adds --enable-shared-dricore option to configure. When enabled,
DRI modules will link against a shared copy of the common mesa routines
rather than statically linking these.
This saves about 30MB on disc with a full complement of classic DRI
drivers.
v2: Only enable with a gcc-compatible compiler that handles rpath
Handle DRI_CFLAGS without filter-out magic
Build shared libraries with the full mklib voodoo
Fix typos
v3: Resolve conflicts with talloc removal patches
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
When --enable-shared-glapi is specified, libGL will share libglapi with
OpenGL ES instead of defining its own copy of glapi. This makes sure an
app will get only one copy of glapi in its address space.
The new option is disabled by default. When enabled, libGL and libglapi
must be built from the same source tree and distributed together. This
requirement comes from the fact that the dispatch offsets used by these
libraries are re-assigned whenever GLAPI XMLs are changed.
For GLX, indirect rendering for has_different_protocol() functions is
tricky. A has_different_protocol() function is assigned only one
dispatch offset, yet each entry point needs a different protocol opcode.
It cannot be supported by the shared glapi. The fix to this is to make
glXGetProcAddress handle such functions specially before calling
_glapi_get_proc_address.
Note that these files are automatically generated/re-generated
src/glx/indirect.c
src/glx/indirect.h
src/mapi/glapi/glapi_mapi_tmp.h
Move _glapi_* symbols from libGLESv1_CM.so and libGLESv2.so to
libglapi.so. This makes sure an app will get only one copy of glapi in
its address space.
Note that with this change, libGLES* and libglapi must be built from the
same source tree and distributed together. This requirement comes from
the fact that the dispatch offsets used by these libraries are
re-assigned whenever GLAPI XMLs are changed.
With core mesa doing runtime API checks, GLES overlay is no longer
needed. Make --enable-gles-overlay equivalent to --enable-gles[12].
There may still be places where compile-time checks are done. They
could be fixed case by case.
If you want to enable noop set GALLIUM_NOOP=1 as an env variable.
You need first to enable noop wrapping for your driver see change
to src/gallium/targets/dri-r600/ in this commit as an example.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
st/egl should be enabled with --enable-openvg even the driver is xlib or
osmesa. Also, GLX_DIRECT_RENDERING should not be defined because libdrm
is not checked.
This driver is a fake swdri driver that perform no operations
beside allocation gallium structure and buffer for upper layer
usage.
It's purpose is to help profiling core mesa/gallium without
having pipe driver overhead hidding hot spot of core code.
scons file are likely inadequate i am unfamiliar with this
build system.
To use it simply rename is to swrast_dri.so and properly set
LIBGL_DRIVERS_PATH env variable.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Make autoconf decide the client APIs enabled first. Then when OpenGL
and OpenGL ES are disabled, there is no need to build src/mesa/; when
OpenGL is disabled, no $mesa_driver should be built. Finally, add
--enable-openvg to enable OpenVG.
With these changes, an OpenVG only build can be configured with
$ ./configure --disable-opengl --enable-openvg
src/mesa, src/glsl, and src/glx will be skipped, which saves a great
deal of compilation time.
And an OpenGL ES only build can be configured with
$ ./configure --disable-opengl --enable-gles-overlay
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>
Currently makedepend is used by the Mesa Makefile-based build system,
but not required.
Unfortunately, not having it makes dependency resolution non-existent,
which is a source of subtle bugs, and is a rarely tested
configuration, since all Mesa developers likely have it installed.
Furthermore some idioms require dependency resolution to work at all,
such as making headers depend on generated files.
Code in glx/glxcmds.c which uses the XF86VIDMODE extension is already guarded. Also use
that guard to control inclusion of the xf86vmode.h header, and only enable that guard if the
XF86VIDMODE extension is found by pkgconfig.
This changes the behaviour on platforms which XF86VIDMODE exists, in that XF86VIDMODE used to
be mandatory, but is now optional.
Presumably other build systems are already arranging for -DXF86VIDMODE to be supplied to the
complier when glxcmds.c is compiled, so are not affected by this change
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Teach mklib/minstall more about cygwin so libraries are properly installed
Have mklib install the .dll into the lib/ staging directory as well
Have minstall install the .dll into PREFIX/bin at the same time as
installing the .dll.a link library into PREFIX/lib
mklib uses a '-' rather than a '.' as the separator before the version
number in library names on cygwin. Change the install globs so they match
library names like that.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Brian Paul <brianp@vmware.com>
I had used pkg-config from the Makefile because I didn't want to screw
around with the non-autoconf build, but that doesn't work because the
PKG_CONFIG_PATH or TALLOC_LIBS/TALLOC_CFLAGS that people set at
configure time needs to be respected and may not be present at build
time.
Bug #29585
This pulls in multiple i965 driver fixes which will help ensure better
testing coverage during development, and also gets past the conflicts
of the src/mesa/shader -> src/mesa/program move.
Conflicts:
src/mesa/Makefile
src/mesa/main/shaderapi.c
src/mesa/main/shaderobj.h
Fix this build error (in MesaGLUT-7.6.1)...
glut_cmap.c:23:66: error: X11/Xmu/StdCmap.h: No such file or directory
...by not preventing the cflags that pkg-config finds for glut dependencies
(including 'xmu') from being used.
Defining GLUT_CFLAGS before running the pkg-config prevents the
cflags found by pkg-config from being used.
This patch lets GLUT_CFLAGS that configure & pkg-config work
so hard to set actually get used.
Also make sure the generated configs/autoconf defines GLUT_CFLAGS
used in (at least) src/glut/glx/Makefile.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Merge all targets into targets/egl/. The target produces
egl_gallium_<HW>.so for each pipe driver and st_<API>.so for each client
APIs. This enables us to further merge egl_gallium_<HW>.so into
egl_gallium.so later.
Christian König
Emil Velikov
Ian Romanick
Marek Olšák
Jesse Barnes
Thomas Hellstrom
Benjamin Franzke
Chia-I Wu
Chia-I Wu
Alan Hourihane
Jon TURNEY
Cyril Brulebois
Johannes Obermayr
Brian Paul
Tapani Pälli
Dave Airlie
nobled
Samuel Thibault
José Fonseca
Chris Wilson
Tom Fogal
Christopher James Halse Rogers
Kristian Høgsberg
Kenneth Graunke
Tormod Volden
Jerome Glisse
Pierre Allegraud
Christoph Bumiller
Eric Anholt
Thomas Balling Sørensen
Luca Barbieri
Li Peng
Thomas Balling Sørensen
Jakob Bornecrantz
John Hein
Jakob Bornecrantz
Corbin Simpson