Age | Commit message (Collapse) | Author | Files | Lines |
|
We'll be using the drmGetDevice[s]2 API in src/loader with next patch.
v2: Rebase.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
Tested-by: Mike Lothian <mike@fireburn.co.uk>
|
|
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
|
Noticed while skimming through, although admittedly there's many other
dependencies that are not tracked by the scons build.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
|
Analogous to previous commit - just set the lot once throughout.
Cc: Jose Fonseca <jfonseca@vmware.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
|
|
We must make sure that xserver has an equivalent one-line
change to its configure.ac as the glx/glapi headers get copied over.
Then again, xserver does _not_ seem to set HAVE_ALIAS to begin with so
one might want to look into that first.
Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
|
|
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
|
|
v2: reworded commit message
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
|
|
Drivers that contain C++ .hpp files need to ignore them too, along
with .h files, when building source file lists.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
|
|
configure.ac already requires 2.4.66.
Fix SCons build. drmDevicePtr is not available until libdrm 2.4.65.
Compiling src/loader/loader.c ...
src/loader/loader.c:111:40: error: unknown type name ‘drmDevicePtr’
static char *drm_construct_id_path_tag(drmDevicePtr device)
^
Fixes: 4a183f4d06f8 ("scons: loader: use libdrm when available")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98421
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Vedran Miletić <vedran@miletic.net>
|
|
Analogous to previous automake/autoconf commit.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
|
|
modulefinder wasn't searching for dependencies in the script dir.
It's not capable of detecting the sys.path manipulations scripts do
internally neither.
This change fixes the first issue, and hacks around the second.
Honestly, I've come to the conclusion that automatic Python dependency it will always be
too brittle. I think we should start manually typing the dependencies
like we do in automake. At very least it will enable any person to
eyeball and spot/fix missing dependencies, without dig into SCons internals.
|
|
For opt build, add VMX86_STATS to the list of cpp defines.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
The get_implicit_deps changed in SCons 2.5, expecting a callable rather
than a path as third argument. Detect the SCons versions and set the
argument appropriately to support both 2.5 and earlier versions.
This closes #95211.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95211
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
Several NIR scripts were using `from ... import ...` syntax, which wasn't
supported.
Using Python standard libary's modulefinder solves the problem with less
effort and hacks.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
- Introduce 'gcc_compat' env flag, for all compilers that define __GNUC__,
(which includes Clang when it's not emulating MSVC.)
- Clang doesn't support whole program optimization
- Disable enumerator value warnings (not sure why Clang warns about them,
as my understanding is that MSVC promotes enums to unsigned ints
automatically.)
This is not enough to build with Clang + AddressSanitizer though. More
follow up changes will be required for that.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
These were being defined in SCons, but it's not practical:
- we actually need to include Gallium headers from external source trees, with
completely disjoint build infrastructure, and it's unsustainable to
replicate the HAVE_xxx checks or even hard-coded defines across
everywhere.
- checking compiler version via command line doesn't really work due to
Clang essentially being like a cameleon which can fake either GCC or
MSVC
There's no change for autoconf.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
|
|
Except:
- u_cache_test -- too long
- translate_test -- unreliable (it's probably testing corner cases that
translate module doesn't care about.)
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
|
|
libasan is never linked to shared objects (which doesn't go well with
-z,defs). It must either be linked to the main executable, or (more
practically for OpenGL drivers) be pre-loaded via LD_PRELOAD.
Otherwise works.
I didn't find anything with llvmpipe. I suspect the fact that the
JIT compiled code isn't instrumented means there are lots of errors it
can't catch.
But for non-JIT drivers, the Address/Leak Sanitizers seem like a faster
alternative to Valgrind.
Usage (Ubuntu 15.10):
scons asan=1 libgl-xlib
export LD_LIBRARY_PATH=$PWD/build/linux-x86_64-debug/gallium/targets/libgl-xlib
LD_PRELOAD=libasan.so.2 any-opengl-application
Acked-by: Roland Scheidegger <sroland@vmware.com>
|
|
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
|
|
The ISO C99 standard (7.18.4) specifies that C++
implementations should define UINT64_C only when
__STDC_CONSTANT_MACROS is defined.
Because we now use UINT64_C in our cpp files (since commit
208bfc493debe0344d0b9cb93975981f14412628), we need to add this define.
This also solves compilation errors with GCC 4.8.x on ppc64le machines.
v2: add this define to SCons build system
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
|
|
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
|
|
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91591
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
|
|
It doesn't do everything we want. In particular it doesn't allow to
detect jumps or return opcodes. Currently we detect the x86's RET
opcode.
Even though it's worse for LLVM 3.3, it's an improvement for LLVM 3.7,
which was totally busted.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
|
|
llvm/Config/llvm-config.h is parsed instead of llvm/Config/config.h for
detecting LLVM version
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073707.html).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
|
|
Somehow, merely including any of the *intrin.h headers causes dozens of
this warnings (when compiling pretty much every source file). MSVC does
not always complain the same -- so it's possible we're doing something
weird --, but silence these warnings in the meanwhile.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
MSVC.
Most cases seem harmless, though that might not always be the case. Maybe
one day we can get gcc to complain about these and fix them throughout
the code, but until then let's silence them.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
It's a bit hackish couldn't find another solution. See code comment
for details. The warning is useful, so universally disabling doesn't
sound a good idea.
Fixes
warning C4005: 'xxx' : macro redefinition
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
It warns about change in MSVC behavior -- array initialisation used to
be non-standard, but is standard now, assuming I understand correctly
http://en.cppreference.com/w/cpp/language/zero_initialization .
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
This avoids MSVC the warning
warning C4013: 'isatty' undefined; assuming extern returning int
with certain versions of flex.
Reviewed-by: Brian Paul <brianp@vmware.com>
v2: Add win flex-bison link to docs/install.html.
|
|
This prevents the MSVC from
warning C4090: 'function' : different 'const' qualifiers
when compiling flex generated lexers.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
MSVC defaults to no exceptions unless /EH option is passed (which we don't), while
MSVC's STL defaults to use exceptions unless _HAS_EXCEPTIONS=0 is defined,
which we didn't.
This fixes
warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
These get triggered even when using the standard C99 INFINITY/NAN
constants.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
By default gcc ignores the issue, and as result code that mixes
signed/unsigned is so widespread through the code base that it ends up
being little more than noise, potentially obscuring more pertinent
warnings.
Maybe one day we enable the corresponding gcc warnings and cleanup, but
until then, this change disables them.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
|
|
Suggested-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
Matching what we already do with autotools builds.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
Fix GCC cpp warnings with glibc >= 2.19.
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
^
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
These definitions must be moved before `cppdefines` is used to have effect.
Trivial.
|
|
LLVMBitReader dependency was introduced, as pointed out by Rob Conde.
|
|
Mac OS X XQuartz places X11 headers at /opt/X11/include.
This patch fixes this Mac OS X SCons build error.
Compiling src/gallium/state_trackers/glx/xlib/glx_api.c ...
In file included from src/gallium/state_trackers/glx/xlib/glx_api.c:34:
include/GL/glx.h:30:10: fatal error: 'X11/Xlib.h' file not found
^
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
- SSE2 is available on all x86 processors we care about.
- It's recommended by Intel:
https://software.intel.com/en-us/blogs/2012/09/26/gcc-x86-performance-hints
- And has been the default since MSVC 2012:
http://msdn.microsoft.com/en-us/library/7t5yh4fd(v=vs.110).aspx
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
|
|
- Remove no-op if-clause.
- -mstackrealign has been enabled again on MinGW for quite some time and
appears to work alright nowadays.
- Drop -mmmx option as it is implied my -msse, and we don't use MMX
intrinsics anyway.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
|
|
GLXBadProfileARB and X_GLXCreateContextAtrribsARB require glproto >=
1.4.13. These symbols were added in commit
d5d41112cbccd9301500e8e023be77eb9cb622cd "st/xlib: Generate errors as
specified."
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Cc: "10.4" <mesa-stable@lists.freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
|
|
With the assumptions that xlocale.h implies newlocale and strtof_l. SCons is
updated to define HAVE_XLOCALE_H on linux and darwin.
Signed-off-by: Chia-I Wu <olv@lunarg.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
We'll need to update gallivm for the interface changes in LLVM 3.6, and
the fewer the number of older LLVM versions we support the less hairy that
will be.
As consequence HAVE_AVX define can disappear. (Note HAVE_AVX meant
whether LLVM version supports AVX or not. Runtime support for AVX is
always checked and enforced independently.)
Verified llvmpipe builds and runs with with LLVM 3.3, 3.4, and 3.5.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
|
|
Note that I had to add support for testing the packed attribute to
m4/ax_gcc_func_attribute.m4.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> [C bits]
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Presumbly this will let clang and other compilers use the built-ins as
well.
Notice two changes specifically:
- in _mesa_next_pow_two_64(), always use __builtin_clzll and add a
static assertion that this is safe.
- in macros.h, remove the clang-specific definition since it should
be able to detect __builtin_unreachable in configure.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> [C bits]
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Just like b26503b196d51dc46c815e241343e42ab30e8d66 for MSVC.
|