Age | Commit message (Collapse) | Author | Files | Lines |
|
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
|
|
We do not use wayland-egl anywhere ... so let's remove it.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
|
|
Otherwise these tests fail in odd ways when running from an installed
instance.
Cc: Alejandro Piñeiro <apinheiro@igalia.com>
Cc: Clayton Craft <clayton.a.craft@intel.com>
Reviewed-by: Mark Janes <mark.a.janes@intel.com>
Tested-by: Mark Janes <mark.a.janes@intel.com>
|
|
Most of our dependencies no longer support python 3.3, it isn't widely
available in distros (for reference debian old stable has 3.4), it's not
longer supported by upstream python, and even for very old or LTS
distros we still have python 2.7 support.
Also, the requirements section in README.md has been updated with an
earlier patch.
Suggested-by: Rhys Kidd <rhyskidd@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
|
|
Reviewed-by: Rhys Kidd <rhyskidd@gmail.com>
|
|
If system has installed both GL libraries such as
Legacy and GLVND, cmake will dump warning:
"OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY",
so for compatibility with CMake 3.10 and below the legacy GL
library will be used."
Added usage of Policy CMP0072 as OLD (that selects LEGACY-library
libGL.so by default).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106857
Signed-off-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
|
|
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
|
This build error occurs with cmake 2.8.12.
/bin/sh: BYPRODUCTS: command not found
BYPRODUCTS is not available until cmake 3.2.
https://cmake.org/cmake/help/v3.2/release/3.2.html
Fixes: 2f02cf0d4c2d ("Generate xml for builtin profiles")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106370
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
|
|
This results in substantially smaller profiles and doesn't seem to
affect runtime.
v2: - install xml and xml.gz files. This is needed so that meta profiles
will be installed.
Tested-by: Rafael Antognolli <rafael.antognolli@intel.com>
|
|
This creates and installs xml for all builtin profiles. Using these
profiles I see startup times of ~1 second as opposed to more than 10
with current master, and runtimes that drop by ~1 minute.
v2: - Fix compilation with make. v1 only worked with ninja.
Tested-by: Rafael Antognolli <rafael.antognolli@intel.com>
|
|
This is a rather sizeable commit, I'm sorry for that. Basically there
was no clean way I could come up with to make the change from a single
python file to multiple xml files.
The reason we want this is to to avoid duplication amongst profiles (and
very long build times), by allowing a single profile to be included in
multiple other profiles. This means that the all profile is now composed
of the "glslparser", "shader", and "opengl" (everything in all that's
not glslparser, asmparser, or shader tests). Running `piglit run all
foo` still produces the same results. This also allows us to mix native
and non-native tests so that traditional targets like quick_cl still
work.
Tested-by: Rafael Antognolli <rafael.antognolli@intel.com>
|
|
MSVC build of Piglit was broken for over a month. No point in
sustaining it.
Building with MinGW is the way forward.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
Like the glx tests/utility code, but for wgl.
Note, one must set the PIGLIT_PLATFORM env var to "wgl" before running
Piglit. It looks like there's some Waffle work to look at before this
can be made automatic.
|
|
Fixes: 2e423dd3f4ca ("egl_khr_fence_sync: Add sw_sync lib.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101641
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
|
|
c6e1dc5247 switched to use gbm_bo_get_offset and gbm_bo_get_stride_for_plane.
These symbols were added in mesa 17.1. Since there is no alternative to using them, bump the gbm requirement to 17.1.
Fixes: c6e1dc5247 "piglit_drm_dma_buf: fix GPU offsets and strides"
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Tested-by: Vinson Lee <vlee@freedesktop.org>
|
|
Fixes: 2217871ac937 ("CMake: define GBM_BO_MAP only when symbol is found")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101358
Signed-off-by: Jan Vesely <jano.vesely@gmail.com>
Tested-by: Vinson Lee <vlee@freedesktop.org>
|
|
gbm_bo_map() and _unmap() have been added recently to Mesa,
and this update may not have reached all implementations of
GBM, such as the one provided by Mali r6, where said
definitions can be found in the header file but not in the
library itself. This leads to errors like the following when
linking:
../../../../lib/libpiglitutil_gl.so.0: undefined reference to `gbm_bo_unmap'
../../../../lib/libpiglitutil_gl.so.0: undefined reference to `gbm_bo_map'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/point-sprite] Error 1
Instead of relying on the header file, actually try to link
using that symbol to determine if PIGLIT_HAS_GBM_BO_MAP
should be defined.
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Reviewed-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
|
|
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
|
|
Trivial
|
|
This enables us to support keys properly on Wayland backend.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
|
|
Ok, so the basic problem with the YUV tests is that they currently
completely ignore driver/hw pitch requirements, since the code that
allocates the buffer doesn't know the pixel format, only the 'cpp'.
The yuv test creates a small 4x4 yuv eglimage. If, say, the hardware
requires the pitch to be aligned to, say, 32pixels, everything is fine
for the Y plane, but the subsampled U/V or U+V plane has half as many
pixels. (This did help me catch a bug in driver, not rejecting the
dmabuf import with invalid pitch, but that doesn't help to get the
piglit tests running.)
The best approach I could come up with to fix this is to pass the
fourcc all the way down to the code that creates the dmabuf (and copies
src data into the dmabuf). Unfortunately this makes the patch a bit
bigger than I was hoping, and not really sure a good way to split it
up.
This is tested on i965 (with the intel dma-buf backend) and freedreno
(with the gbm dma-buf backend). In the gbm case, it requires new
gbm format values for R8 and GR88, which is on mesa master as of
this morning. (So I bumped the gbm version dependency to 12.1.)
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
mesa 11.0 is needed for EGLDeviceEXT symbol.
egl_ext_device_query.c: In function ‘main’:
egl_ext_device_query.c:33:2: error: unknown type name ‘EGLDeviceEXT’
EGLDeviceEXT device = EGL_NO_DEVICE_EXT;
^
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
|
|
Linking CXX executables with gold linker leads to:
libpiglitutil_gl.so.0: error: undefined reference to 'xcb_connect'
libpiglitutil_gl.so.0: error: undefined reference to 'xcb_get_setup'
libpiglitutil_gl.so.0: error: undefined reference to 'xcb_setup_roots_iterator'
This may have appeared now because xcb-dri2 used to overlink publicly
but now does not.
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
|
|
In commit a1efbfb9 support was added for dmabuf with GBM on non-intel
platforms, but the requirements were set incorrectly. They require
symbols added in mesa commit 8aeb6d76, which is not in any mesa 11
release, only in mesa 12.
This corrects the requirement to be version 12.0
bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97435
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Previously the dmabuf tests only worked on the intel driver. However,
thanks to the new GBM BO mapping interface by Rob Herring, we can make
a generic framework for other drivers.
Reviewed-by: Rob Clark <robdclark@gmail.com>
|
|
Files ending in '.comp', which is used for compute shader extensions of
GLSLparsertests were not installed. This is obviously problematic.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
|
|
CONFIG is not available until cmake 2.8.8.
Fix build error with cmake < 2.8.8.
CMake Error at CMakeLists.txt:219 (find_package):
find_package called with invalid argument "CONFIG"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94620
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
|
|
This uses the bash-completion cmake file provided by bash-completions to
install the file to the system (if one does a system install). Otherwise
one can just copy the file to somewhere it will get sourced by their
bashrc.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
|
|
The previous version (1.6.2) fails to compile against python 3, and is
from 2012. Version 1.7.0 does compile against python 3, and is still
from February 2013, old enough that even stable Linux distributions
should have picked it up by now.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
|
|
We actually define a minimum required mako version in cmake. Since tox
is supposed to be useful for testing, we should test that version.
Mako 1.0.2 contains bug fixes for python 3.5. For versions of python
earlier than 3.5 0.8.0, is still sufficient, but for 3.5 1.0.2 is needed.
CMake is updated to check this as well.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
|
|
Without them, the build will fail on a system without the X headers with
a recent Mesa from the master branch. The EGL_CFLAGS_OTHER define the
MESA_EGL_NO_X11_HEADERS macro that guards the #includes of the X
headers.
Signed-off-by: Mircea Gherzan <mircea.gherzan@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
|
|
CMake actually marks that we require six 1.4.0, however, I can't find
any packages anywhere for 1.4.0, and the lowest version I've seen
requested is 1.5.2.
This fixes requirements for working with six 1.5.2, and sets tox to use
1.5.2 (and a suitable version of mock). Primarily there are a few things
we're using that are not available: six.moves.getcwd, six.viewvalues,
six.python_2_unicode_compatible.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Tested-by: Brian Paul <brianp@vmware.com>
|
|
The generators have supported 3.x for some time, this now makes 3.x the
default, and falls back to 2.7
This has been tested with 3.5 and 2.7
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Acked-by: Jose Fonseca <jfonseca@vmware.com>
|
|
Matches Waffle's https://github.com/waffle-gl/waffle/commit/d15a83a453c87b445d8abf19d82668bca1a389d4
Trivial.
|
|
GCC 5.x and 4.x have different defaults, so it's better to explicitly
specify the target C standard to keep builds consistent.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Thanked-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
It's been replaced by shader_runner.
Reviewed-by: Dylan Baker <dylanx.c.baker@intel.com>
|
|
MSVC defaults to 1MB stack size. MinGW defaults to a larger value.
But in order to trap problems with excessive usage of the stack on
Windows we really want to match MSVC.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
GLES tests require EGL support, so it only make sense that they are on
on systems which support EGL, which is Linux ATM.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
|
|
They can be quite distracting.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
This reintroduces libpng support, but makes it optional since I only
plan to use it in an optional feature most people won't use.
This code is based on:
commit ed98ddebb21483c40325aaa4d1caecf3860a9906
Author: Nicolai Haehnle <nhaehnle@gmail.com>
Date: Sun Mar 25 22:48:07 2007 +0200
texline: Write screenshot using libpng
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
|
|
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
These are needed to pass tests, but they weren't being installed for
running out of tree. Fixes ~100 warns when running out of tree with
beignet. Trivial.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
|
|
Void pointer arithmetic is not supported on MSVC, so passing
-Werror=pointer-arith will make it easier for everybody to catch this
sort of portability issues as the code is written.
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
future_imports was added in Mako 0.8.0.
http://docs.makotemplates.org/en/latest/changelog.html#change-0.8.0
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89347
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
|
|
six.PY2 was added in 1.4.0.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
|
|
Six is a module that provides a clean, standardized interface for
handling python2 and python3 from the same code base. This adds a
requirement on six as a build-time dependency, the plan is to use it
only for python generators (those called during build time)
While it certainly is possible to reimplement much of what six does
scratch and not add another python dependency, I think it's better to
just use six. For one thing a large number of python modules already
depend on six, so the chances are good that most people already have it
installed. Second, it's the de facto standard for supporting complex
code bases in 2 and 3, so it's familiar and many of the corner cases
have already been addressed.
This adds the necessary cmake boilerplate to ensure that six is
available. At this time I don't know of a specific version being
required, but I am currently using 1.9.0
v2: - update README with six dependency (Jordan)
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
|
|
Although the non-standard GCC syntax has some nice properties, for most
practical cases the standard C99 syntax is perfectly fine. Particuarly
for printf-like macros, which pretty much account for most the uses of
variadic macros in piglit.
Unfortunately this will only be effective on newer GCC versions, due a
bug in GCC. See comment for more details.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
|