summaryrefslogtreecommitdiffstats
path: root/configure.ac
Commit message (Collapse)AuthorAgeFilesLines
* meson+autotools: get rid of spammy GCC warning -Wformat-truncationEric Engestrom2018-09-251-0/+2
| | | | | | | | | | | | | | | That warning fires every time a string function takes an argument that could possibly be longer than its max output, which triggers all over the place, especially when working with file paths ("what if every file path is MAX_PATH long?" is what GCC is saying, which is really annoying when we *know* that "/dev/dri/cardN" is not gonna be 4096 char long and it's safe to store it in a 32-char array). Anyway, we either add a ton of dead code all over the place to make GCC happy, or we get rid of its spam. I chose the latter. Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* move pthread_setaffinity_np check to the build systemDylan Baker2018-09-171-0/+16
| | | | | | | | | | | | | | | | | Rather than trying to encode all of the rules in a header, lets just put them in the build system where they belong. This fixes the build on FreeBSD, which does have pthraed_setaffinity_np, but it's in a pthread_np.h, not behind _GNU_SOURCE. FreeBSD also implements cpu_set slightly differently, so additional changes would be required to get it working right there anyway. v2: - fix #define in autotools Fixes: 9f1bbbdbbd77d346c74c7abbb31f399151a85713 ("util: try to fix the Android and MacOS build") Cc: Emil Velikov <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* Revert "configure: allow building with python3"Emil Velikov2018-08-241-3/+5
| | | | | | | | | | | | | | This reverts commit ae7898dfdbe5c8dab7d11c71862353f1ae43feb0. Turns out the python scripts are _not_ fully python 3 compatible. As Ilia reported using get_xmlpool.py with LANG=C produces some weird output - see the link for details. Even though the issue was spotted with the autoconf build, it exposes a genuine problem with the script (and lack of lang handling of the meson build.) https://lists.freedesktop.org/archives/mesa-dev/2018-August/203508.html
* configure: allow building with python3Emil Velikov2018-08-231-5/+3
| | | | | | | | | | | | Pretty much all of the scripts are python2+3 compatible. Check and allow using python3, while adjusting the PYTHON2 refs. Note: - python3.4 is used as it's the earliest supported version - python3 chosen prior to python2 Signed-off-by: Emil Velikov <[email protected]> Acked-by: Eric Engestrom <[email protected]>
* configure: enforce python 2.7 with AM_PATH_PYTHONEmil Velikov2018-08-231-2/+5
| | | | | | | | | | | | | | | Currently we use AC_CHECK_PROGS looking for python2.7, python2 and finally python. That is due to the varying names used across the different OS. Use the handy AM_PATH_PYTHON which finds the correct name and checks for the version. Note: python2.7 has been an unofficial requirement for quite some time. Update the docs to reflect that. Cc: Dylan Baker <[email protected]> Signed-off-by: Emil Velikov <[email protected]>
* swr: bump minimum supported LLVM version to 6.0Juan A. Suarez Romero2018-08-201-4/+3
| | | | | | | | | | | | | | | | | RADV now requires LLVM 6.0 or greater, and thus we can't build dist tarball because swr requires LLVM 5.0. Let's bump required LLVM to 6.0 in swr too. v2: bump also in meson.build (Eric) Fixes: fd1121e839 ("amd: remove support for LLVM 5.0") Cc: Tim Rowley <[email protected]> Cc: Emil Velikov <[email protected]> Cc: Dylan Baker <[email protected]> Cc: Eric Engestrom <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Bruce Cherniak <[email protected]>
* freedreno: Add a6xx backendKristian H. Kristensen2018-08-161-1/+1
| | | | | | | | | | This adds a freedreno backend for the a6xx generation GPUs, which at the time of this commit is about 98% GLES2 conformant. Much remains to be done - both performance work and feature work towards more recent GLES versions, but this is a good start. Signed-off-by: Kristian H. Kristensen <[email protected]> Signed-off-by: Rob Clark <[email protected]>
* autotools: use correct gl.pc LIBS when using glvndEmil Velikov2018-08-081-0/+9
| | | | | | | | | This is more of a hack, since glvnd itself should be providing the file. Until that happens, ensure the libs is correctly set to -lGL CC: <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Adam Jackson <[email protected]>
* autotools: error out when building with mangling and glvndEmil Velikov2018-08-081-0/+3
| | | | | | | | | | It's not a thing that can work, nor is a wise idea to attempt. v2: Tweak error message (Dylan) CC: <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Adam Jackson <[email protected]> (v1)
* autotools: error out when using the broken --with-{gl, osmesa}-lib-nameEmil Velikov2018-08-081-6/+6
| | | | | | | | | | The toggles were broken with the introduction of --enable-mangling. Fixing that up might be possible, but it's not worth the complexity since one can rename the libraries at any point. CC: <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Adam Jackson <[email protected]>
* automake: require shared glapi when using DRI based libGLEmil Velikov2018-08-081-0/+2
| | | | | | | | | This has been a requirement for ages, yet it seems like we never explicitly errored out during configure. CC: <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Adam Jackson <[email protected]>
* autoconf: stop exporting internal wayland detailsEmil Velikov2018-08-071-0/+4
| | | | | | | | | | | | | | | | | With version v1.15 the "code" option was deprecated in favour of "private-code" or "public-code". Before the interface symbol generated was exported (which is a bad idea since it's internal implementation detail) and others may misuse it. That was the case with libva approx. 1 year ago. Since then libva was fixed, so we can finally hide it by using "private-code" Inspired by similar xserver patch by Adam Jackson. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Dylan Baker <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* configure: install KHR/khrplatform.h when neededEric Engestrom2018-08-071-0/+1
| | | | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107511 Fixes: f7d42ee7d319256608ad "include: update GL & GLES headers (v2)" Signed-off-by: Eric Engestrom <[email protected]> Tested-by: Brad King <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* amd: remove support for LLVM 5.0Marek Olšák2018-08-031-2/+2
| | | | | | Users are encouraged to switch to LLVM 6.0 released in March 2018. Reviewed-by: Timothy Arceri <[email protected]>
* winsys/amdgpu: pass the BO list via the CS ioctl on DRM >= 3.27.0Marek Olšák2018-08-031-1/+1
|
* util/disk_cache: Fix disk_cache_get_function_timestamp with disabled cache.Bas Nieuwenhuizen2018-07-201-0/+1
| | | | | | | | | | radv always needs it, so just check the header instead. Also do not declare the function if the variable is not set, so we get a nice compile error instead of failing to open a device at runtime. Fixes: b87ef9e606a "util: fix MSVC build issue in disk_cache.h" Reviewed-by: Timothy Arceri <[email protected]>
* util/set: add a basic unit testCaio Marcelo de Oliveira Filho2018-07-121-0/+1
| | | | Reviewed-by: Eric Anholt <[email protected]>
* gallium: Fix automake for Android (v2)Chad Versace2018-06-271-0/+3
| | | | | | | | | | | | | | | Chromium OS uses Autotools and pkg-config when building Mesa for Android. The gallium drivers were failing to find the headers and libraries for zlib and Android's libbacktrace. v2: - Don't add a check for zlib.pc. configure.ac already checks for zlib.pc elsewhere. [for tfiga] - Check for backtrace.pc separately from the other Android libs. [for tfiga] Reviewed-by: Tomasz Figa <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* configure: use compliant grep regex checksEmil Velikov2018-06-211-2/+2
| | | | | | | | | | | | | The current `grep "foo\|bar"' trips on some grep implementations, like the FreeBSD one. Instead use `egrep "foo|bar"' as suggested by Stefan. Cc: Stefan Esser <[email protected]> Reported-by: Stefan Esser <[email protected]> Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228673 Fixes: 1914c814a6c ("configure: error out if building OMX w/o supported platform") Fixes: 63e11ac2b5c ("configure: error out if building VA w/o supported platform") Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* swr: bump minimum supported LLVM version to 5.0Juan A. Suarez Romero2018-06-211-3/+4
| | | | | | | | | | | | | | | | RADV now requires LLVM 5.0 or greater, and thus we can't build dist tarball because swr requires LLVM 4.0. Let's bump required LLVM to 5.0 in swr too. Fixes: f9eb1ef870 ("amd: remove support for LLVM 4.0") Cc: Tim Rowley <[email protected]> Cc: Emil Velikov <[email protected]> Cc: Dylan Baker <[email protected]> Cc: Eric Engestrom <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Acked-by: Bruce Cherniak <[email protected]>
* vulkan: EXT_acquire_xlib_display requires libXrandr headers to buildKeith Packard2018-06-201-0/+2
| | | | | | | | | | | | | | | | | When VK_USE_PLATFORM_XLIB_XRANDR_EXT is defined, vulkan.h includes X11/extensions/Xrandr.h for the RROutput typedef which is used in the vkGetRandROutputDisplayEXT interface. Make sure we have the required header by checking during the build, and also set CFLAGS to point at the right directory. We don't need to link against the library as we don't use any functions from there, so don't add the _LIBS value in the autotools build. Signed-off-by: Keith Packard <[email protected]> Fixes: dbac8e25f851ed44c51f "radv: Add EXT_acquire_xlib_display to radv driver [v2]" Reviewed-by: Eric Engestrom <[email protected]>
* configure.ac: Add CFLAG -Wno-missing-field-initializers (v5)Gert Wollny2018-06-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This warning is misleading: When a struct is partially initialized without assigning to the structure members by name, then the remaining fields will be zeroed out, and this warning will be issued (if enabled). If, on the other hand, the partial initialization is done by assigning to named members, the remaining structure elements may hold random data, but the warning is not issued. Since in Mesa the first approach to initialize structure elements is used very often, and it is usually assumed that the remaining elements are zeroed out, heeding this warning would be counter-productive. v2: - add -Wno-missing-field-initializers to meson-build - fix empty line error (both Eric Engestrom) v3: * check for -Wmissing-field-initializers warning and then disable it because gcc and clang always accept -Wno-* (Dylan Baker) * Also disable this warning for C++ v4: * meson.build add -Wno-missing-field-initializers to c_args instead of no_override_init_args (Eric Engstrom) v5: * configure.ac: Correct copy/paste error with CFLAGS/CXXFLAGS Reviewed-by: Marek Olšák <[email protected]> (v1) Reviewed-by: Emil Velikov <[email protected]> (v2) Reviewed-by: Eric Engestrom <[email protected]> Signed-off-by: Gert Wollny <[email protected]>
* vulkan: Add EXT_acquire_xlib_display [v5]Keith Packard2018-06-191-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This extension adds the ability to borrow an X RandR output for temporary use directly by a Vulkan application. For DRM, we use the Linux resource leasing mechanism. v2: Clean up xlib_lease detection * Use separate temporary '_xlib_lease' variable to hold the option value to avoid changin the type of a variable. * Use boolean expressions instead of additional if statements to compute resulting with_xlib_lease value. * Simplify addition of VK_USE_PLATFORM_XLIB_XRANDR_KHR to vulkan_wsi_args Suggested-by: Eric Engestrom <[email protected]> Move mode list from wsi_display to wsi_display_connector Fix scope for wsi_display_mode and wsi_display_connector allocs Suggested-by: Jason Ekstrand <[email protected]> v3: Adopt Jason Ekstrand's coding conventions Declare variables at first use, eliminate extra whitespace between types and names. Wrap lines to 80 columns. Explicitly forbid multiple DRM leases. Making the code support this looks tricky and will require additional thought. Use xcb_randr_output_t throughout the internals of the implementation. Convert at the public API (wsi_get_randr_output_display). Clean up check for usable active_crtc (possible when only the desired output is connected to the crtc). Suggested-by: Jason Ekstrand <[email protected]> v4: Move output resource fetching closer to use in wsi_display_get_output. This simplifies the error returns in earlier parts of the code a bit. Return VK_ERROR_INITIALIZATION_FAILED from wsi_acquire_xlib_display. Jason says this is the right error message. Suggested-by: Jason Ekstrand <[email protected]> v5: randr doesn't pass vscan over the wire, so we set vscan to 0 for randr-acquired modes, and test wsi modes for vscan <= 1 when comparing against randr modes. Suggested-by: Jason Ekstrand <[email protected]> Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: Unconditionally enable floating-point texturesTimothy Arceri2018-06-181-15/+0
| | | | | | | | | | | | | | ARB_texture_float references US Patent #6,650,327 [1] which has a filing date of June 16 1998. According to [2], patents filed after 1995 expire 20 years from the filing date, giving an expiration of June 17 2018. [1] https://www.google.com/patents/US6650327 [2] https://en.wikipedia.org/wiki/Term_of_patent_in_the_United_States Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* configure.ac: Test for __atomic_add_fetch in atomic checksAndrew Galante2018-06-131-2/+4
| | | | | | | | | | Some platforms have 64-bit __atomic_load_n but not 64-bit __atomic_add_fetch, so test for both of them. Bug: https://bugs.gentoo.org/655616 Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* autotools/meson: compile against wayland-egl-*backend*Eric Engestrom2018-06-081-2/+2
| | | | | | | | Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106861 Fixes: 1db4ec05462914096b1f "egl: rewire the build systems to use libwayland-egl" Suggested-by: Emil Velikov <[email protected]> Tested-by: Andreas Hartmetz <[email protected]> Signed-off-by: Eric Engestrom <[email protected]>
* egl: rewire the build systems to use libwayland-eglEric Engestrom2018-06-061-2/+4
| | | | | | | Cc: Emil Velikov <[email protected]> Cc: Daniel Stone <[email protected]> Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Eric Engestrom <[email protected]>
* configure: radv depends on makoEric Engestrom2018-06-051-0/+3
| | | | | | | | Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106784 Fixes: 17201a2eb0b1b85387136 "radv: port to using updated anv entrypoint/extension generator." Acked-by: Bas Nieuwenhuizen <[email protected]> Signed-off-by: Eric Engestrom <[email protected]>
* util: Add a randomized test for the virtual memory allocatorScott D Phillips2018-05-311-0/+1
| | | | | | | | | | | | | | | | | The test pseudo-randomly makes allocations and deallocations with the virtual memory allocator and checks that the results are consistent. Specifically, we test that: * no result from the allocator overlaps an already allocated range * allocated memory fulfills the stated alignment requirement * a failed result from the allocator could not have been fulfilled * memory freed to the allocator can later be allocated again v2: - fix if() in test() to actually run fill() v3: - add c++11 build flag (Jason) - test the full 64-bit range (Jason) Reviewed-by: Jason Ekstrand <[email protected]>
* amd: remove support for LLVM 4.0Marek Olšák2018-05-171-2/+2
| | | | | | | It doesn't support GFX9. Acked-by: Dave Airlie <[email protected]> Acked-by: Samuel Pitoiset <[email protected]>
* broadcom/vc4: Bump libdrm requirementStefan Schake2018-05-171-0/+2
| | | | | | | | | | Require a version of libdrm with syncobj support. v2: Don't require a libdrm_vc4, just bump core libdrm if vc4 enabled (by anholt) Signed-off-by: Stefan Schake <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* broadcom/vc4: Drop libdrm_vc4 requirementStefan Schake2018-05-171-1/+0
| | | | | | | | | This was missed in the move back to the local uapi copy. libdrm_vc4 only seems to consist of headers that also exist in the Mesa tree. Signed-off-by: Stefan Schake <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* v3d: Enable the driver by default.Eric Anholt2018-05-161-1/+1
| | | | | Now that we have a stabilized ABI and a fairly conformant driver, turn it on.
* v3d: Rename the driver files from "vc5" to "v3d".Eric Anholt2018-05-161-2/+2
|
* v3d: Rename the vc5_dri.so driver to v3d_dri.so.Eric Anholt2018-05-161-9/+9
| | | | | | This allows the driver to load against the merged kernel DRM driver. In the process, rename most of the build system variables and gallium plumbing functions.
* freedreno: fence should hold a ref to pipeRob Clark2018-05-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Since the fence can outlive the context, and all it really needs to wait on a fence is the pipe, use the new fd_pipe reference counting to hold a ref to the pipe and drop the ctx pointer. This fixes a crash seen with (for example) glmark2: #0 fd_pipe_wait_timeout (pipe=0xbf48678b3cd7b32b, timestamp=0, timeout=18446744073709551615) at freedreno_pipe.c:101 #1 0x0000ffffbdf75914 in fd_fence_finish (pscreen=0x561110, ctx=0x0, fence=0xc55c10, timeout=18446744073709551615) at ../src/gallium/drivers/freedreno/freedreno_fence.c:96 #2 0x0000ffffbde154e4 in dri_flush (cPriv=0xb1ff80, dPriv=0x556660, flags=3, reason=__DRI2_THROTTLE_SWAPBUFFER) at ../src/gallium/state_trackers/dri/dri_drawable.c:569 #3 0x0000ffffbecd8b44 in loader_dri3_flush (draw=0x558a28, flags=3, throttle_reason=__DRI2_THROTTLE_SWAPBUFFER) at ../src/loader/loader_dri3_helper.c:656 #4 0x0000ffffbecbc36c in glx_dri3_flush_drawable (draw=0x558a28, flags=3) at ../src/glx/dri3_glx.c:132 #5 0x0000ffffbecd91e8 in loader_dri3_swap_buffers_msc (draw=0x558a28, target_msc=0, divisor=0, remainder=0, flush_flags=3, force_copy=false) at ../src/loader/loader_dri3_helper.c:827 #6 0x0000ffffbecbcfc4 in dri3_swap_buffers (pdraw=0x5589f0, target_msc=0, divisor=0, remainder=0, flush=1) at ../src/glx/dri3_glx.c:587 #7 0x0000ffffbec98218 in glXSwapBuffers (dpy=0x502bb0, drawable=2097154) at ../src/glx/glxcmds.c:840 #8 0x000000000040994c in CanvasGeneric::update (this=0xfffffffff400) at ../src/canvas-generic.cpp:114 #9 0x0000000000411594 in MainLoop::step (this=this@entry=0x5728f0) at ../src/main-loop.cpp:108 #10 0x0000000000409498 in do_benchmark (canvas=...) at ../src/main.cpp:117 #11 0x00000000004071b0 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.cpp:210 Signed-off-by: Rob Clark <[email protected]>
* st/xa: Bump minorThomas Hellstrom2018-05-151-1/+1
| | | | | | | | | | | | | Bump xa minor to signal that the underlying mesa version is suitable for dri3. This is a bit ugly since it doesn't relate to a specific xa interface change. Recently there has been a number of fixes in mesa that helps enabling dri3 without any significant regressions in automated testing and common desktop usage latency. However, the xf86-video-vmware driver has no other way to tell but inspecting the xa version. Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* configure.ac: rework -latomic checkThomas Petazzoni2018-05-101-17/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The configure.ac logic added in commit 2ef7f23820a67e958c2252bd81eb0458903ebf33 ("configure: check if -latomic is needed for __atomic_*") makes the assumption that if a 64-bit atomic intrinsic test program fails to link without -latomic, it is because we must use -latomic. Unfortunately, this is not completely correct: libatomic only appeared in gcc 4.8, and therefore gcc versions before that will not have libatomic, and therefore don't provide atomic intrinsics for all architectures. This issue was for example encountered on PowerPC with a gcc 4.7 toolchain, where the build fails with: powerpc-ctng_e500v2-linux-gnuspe/bin/ld: cannot find -latomic This commit aims at fixing that, by not assuming -latomic is available. The commit re-organizes the atomic intrinsics detection as follows: (1) Test if a program using 64-bit atomic intrinsics links properly, without -latomic. If this is the case, we have atomic intrinsics, and we're good to go. (2) If (1) has failed, then test to link the same program, but this time with -latomic in LDFLAGS. If this is the case, then we have atomic intrinsics, provided we link with -latomic. This has been tested in three situations: - On x86-64, where atomic instrinsics are all built-in, with no need for libatomic. In this case, config.log contains: GCC_ATOMIC_BUILTINS_SUPPORTED_FALSE='#' GCC_ATOMIC_BUILTINS_SUPPORTED_TRUE='' LIBATOMIC_LIBS='' This means: atomic intrinsics are available, and we don't need to link with libatomic. - On NIOS2, where atomic intrinsics are available, but some of them (64-bit ones) require using libatomic. In this case, config.log contains: GCC_ATOMIC_BUILTINS_SUPPORTED_FALSE='#' GCC_ATOMIC_BUILTINS_SUPPORTED_TRUE='' LIBATOMIC_LIBS='-latomic' This means: atomic intrinsics are available, and we need to link with libatomic. - On PowerPC with an old gcc 4.7 toolchain, where 32-bit atomic instrinsics are available, but not 64-bit atomic instrinsics, and there is no libatomic. In this case, config.log contains: GCC_ATOMIC_BUILTINS_SUPPORTED_FALSE='' GCC_ATOMIC_BUILTINS_SUPPORTED_TRUE='#' With means that atomic intrinsics are not usable. Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
* configure.ac: Check for grep with AC_PROG_GREPMatt Turner2018-05-091-0/+1
| | | | | | | | | | | | | | | | | | Perhaps with a new version of autoconf, I began seeing: | checking the name lister (/usr/bin/nm -B) interface... ./configure: line 6973: External.*some_variable: command not found | BSD nm This is because AC_PROG_NM expands to ... if $GREP 'External.*some_variable' conftest.out > /dev/null; then lt_cv_nm_interface="MS dumpbin" fi ... I'm not sure if it's a bug in AC_PROG_NM that it doesn't call AC_PROG_GREP, but it's easy enough for us to do it.
* configure.ac/meson.build: Fix -latomic testNicolas Boichat2018-05-071-2/+4
| | | | | | | | | | | | | | | | | | When compiling with LLVM 6.0 on x86 (32-bit) for Android, the test fails to detect that -latomic is actually required, as the atomic call is inlined. In the code itself (src/util/disk_cache.c), we see this pattern: p_atomic_add(cache->size, - (uint64_t)size); where cache->size is an uint64_t *, and results in the following link time error without -latomic: src/util/disk_cache.c:628: error: undefined reference to '__atomic_fetch_add_8' Fix the configure/meson test to replicate this pattern, which then correctly realizes the need for -latomic. Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Nicolas Boichat <[email protected]>
* autotools, meson: bump up required VA versionJuan A. Suarez Romero2018-04-301-1/+1
| | | | | | | | Due using a new VP9 config we use, required VA API 0.39 Fixes: 413c5ca3727 ("travis: update libva required version") CC: 18.1 <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* gallium: move ddebug, noop, rbug, trace to auxiliary to improve build timesMarek Olšák2018-04-131-4/+0
| | | | which also simplifies the build scripts.
* etnaviv: add perfmon query implementationChristian Gmeiner2018-04-081-1/+1
| | | | | | | | Add needed infrastructure to use performance monitor requests for queries. Signed-off-by: Christian Gmeiner <[email protected]> Tested-by: Chris Healy <[email protected]>
* radeonsi: don't build libradeon.la separatelyMarek Olšák2018-04-051-2/+0
| | | | | | for better parallelism Acked-by: Timothy Arceri <[email protected]>
* build: Fix up nir_intrinsics.PloMatt Turner2018-03-281-0/+3
| | | | | | | | | | | | | nir_intrinsics.c existed as a static file until commit 76dfed8ae2d5 began generating it as part of the build process. autotools is incapable of coping, and so a build-tree from before this commit would then fail with it: [4]: *** No rule to make target '../../../mesa/src/compiler/nir/nir_intrinsics.c', needed by 'nir/nir_intrinsics.lo'. Stop. Add a few lines to configure.ac to update the broken build files. Fixes: 76dfed8ae2d5 ("nir: mako all the intrinsics")
* configure: use AC_CHECK_HEADERS to check for endian.hEmil Velikov2018-03-231-1/+1
| | | | | | | | | | | | | | | | | | | | | The currently we use the singular CHECK_HEADER combined with explicit append to the DEFINES variable. That is a legacy misnomer, since it requires us to add $DEFINES to every piece that we build. Using the plural version of the helper sets the HAVE_ macro for us, plus ensures it's passed to the compiler - if config.h is available in there (not in the case of mesa) otherwise on the command line. In hindsight, we should replace all the AC_CHECK_{FUNC,HEADER} instances with the plural version (or even the _ONCE suffixed version) and drop the DEFINES hacks. Fixes: cbee1bfb342 ("meson/configure: detect endian.h instead of trying to guess when it's available") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105717 Signed-off-by: Emil Velikov <[email protected]> Acked-by: Eric Engestrom <[email protected]> Tested-by: Clayton Craft <[email protected]>
* meson/configure: detect endian.h instead of trying to guess when it's availableEric Engestrom2018-03-231-0/+1
| | | | | | | | | | | Cc: Maxin B. John <[email protected]> Cc: Khem Raj <[email protected]> Cc: Rob Herring <[email protected]> Suggested-by: Jon Turney <[email protected]> Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Dylan Baker <[email protected]> Cc: <[email protected]>
* omx: always define ENABLE_ST_OMX_{BELLAGIO,TIZONIA}Mathias Fröhlich2018-03-221-0/+4
| | | | | | | | | | | | | | | | | We're trying to be -Wundef clean so that we can turn it on (and eventually make it an error). Note that the OMX code already used `#if ENABLE_ST_OMX_BELLAGIO` instead of #ifdef; I could've changed these, but the point of -Wundef is to catch typos, so we might as well make the change the right way. Fixes: 83d4a5d5aea5a8a05be2 "st/omx/tizonia: Add H.264 decoder" Fixes: b2f2236dc565dd1460f0 "st/omx/tizonia: Add H.264 encoder" Fixes: c62cf1f165919bc74296 "st/omx/tizonia/h264d: Add EGLImage support" Cc: Gurkirpal Singh <[email protected]> Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* dri3: Fix typo in version checkDaniel Stone2018-03-201-1/+1
| | | | | | | | | | | | | The have-new-DRI3 codepaths would never actually properly trigger, since there was a typo in configure.ac which broke the version check. This went unnoticed but for an error in config.log if you looked closely enough. Signed-off-by: Daniel Stone <[email protected]> Reported-by: Lukas F. Hartmann <[email protected]> Reviewed-by: Dylan Baker <[email protected]> Fixes: 7aeef2d4efdc ("dri3: allow building against older xcb (v3)") Cc: Dave Airlie <[email protected]>
* dri3: allow building against older xcb (v3)Dave Airlie2018-03-161-3/+9
| | | | | | | | | | | | | | | | | | | | | I'm not sure everyone wants to be updating their dri3 in a forced march setting, this allows a nicer approach, esp when you want to build on distro that aren't brand new. I'm sure there are plenty of ways this patch could be cleaner, and I've also not built it against an updated dri3. For meson I've just left it alone, since if you are using meson you probably don't mind xcb updates, and if you are using meson you can fix this better than me. v3: just don't put a version in for dri3/present without modifiers, should allow building with 1.11 as well (feel free to supply meson followups) Signed-off-by: Dave Airlie <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 11:04:44 +0000