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
- python2 chosen prior to python3
v2: use python2 by default
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Eric Engestrom <eric.engestrom@intel.com>
Seemingly that at some point clang started accepting _any_ flags,
whereas previously it would error out.
These days, you can give it -Whamsandwich and it will succeed, while
at the same time throwing an annoying warning.
Add -Werror so that everything gets flagged and set accordingly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108082
Cc: Vinson Lee <vlee@freedesktop.org>
Repored-by: Vinson Lee <vlee@freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
In the pursuit of lowering driver overhead, it became clear that some
amount of redesign of how libdrm_freedreno constructs the submit ioctl
would be needed. In particular, as the gallium driver is starting to
make heavier use of CP_SET_DRAW_STATE state groups/objects, the over-
head of tracking cmd buffers and relocs becomes too much. And for
"streaming" state, which isn't ever reused (like uniform uploads) the
overhead of allocating/freeing ringbuffer[1] objects is too high.
This redesign makes two main changes:
1) Introduces a fd_submit object for tracking bos and cmds table
for the submit ioctl, making ringbuffer objects more light-
weight. This was previously done in the ringbuffer. But we
have many ringbuffer instances involved in a submit (gmem +
draw + potentially 1000's of state-group rbs), and only need
a single bos and cmds table. (Reloc table is still per-rb)
The submit is also a convenient place for a slab allocator for
ringbuffer objects. Other options would have required locking
because, while we can guarantee allocations will only happen on
a single thread, free's could happen either on the application
thread or the flush_queue thread. With the slab allocator in
the submit object, any frees that happen on the flush_queue
thread happen after we know that the application thread is done
with the submit.
2) Introduce a new "softpin" msm_ringbuffer_sp implementation that
does not use relocs and only has cmds table entries for IB1 (ie.
the cmdstream buffers that kernel needs to CP_INDIRECT_BUFFER
to from the RB). To do this properly will require some updates
on the kernel side, so whether you get the softpin or legacy
submit/ringbuffer implementation at runtime depends on your
kernel version.
To make all these changes in libdrm would basically require adding a
libdrm_freedreno2, so this is a good point to just pull the libdrm code
into mesa. Plus it allows for using mesa's hashtable, slab allocator,
etc. And it lets us have asserts enabled for debug mesa buids but
omitted for release builds. And it makes life easier if further API
changes become necessary.
At this point I haven't tried to pull in the kgsl backend. Although
I left the level of vfunc indirection which would make it possible
to have other backends. (And this was convenient to keep to allow
for the "softpin" ringbuffer to coexist.)
NOTE: if bisecting a build error takes you here, try a clean build.
There are a bunch of ways things can go wrong if you still have
libdrm_freedreno cflags.
[1] "ringbuffer" is probably a bad name, the only level of cmdstream
buffer that is actually a ring is RB managed by kernel. User-
space cmdstream is all IB1/IB2 and state-groups.
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add helper to add state-groups to emit, and code to emit CP_DRAW_STATE
packet if we have any state-groups.
Signed-off-by: Rob Clark <robdclark@gmail.com>
While I generally trust rediculousfish to have done his homework, we've
made some adjustments to suit the needs of mesa and it'd be good to
test those. Also, there's no better place than unit tests to clearly
document the different edge cases of the different methods.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
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 <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
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: 9f1bbbdbbd
("util: try to fix the Android and MacOS build")
Cc: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
This reverts commit ae7898dfdb.
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
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 <emil.velikov@collabora.com>
Acked-by: Eric Engestrom <eric.engestrom@intel.com>
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 <dylan@pnwbakers.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
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 <timothy.o.rowley@intel.com>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: Dylan Baker <dylan@pnwbakers.com>
Cc: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
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 <hoegsberg@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
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: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
It's not a thing that can work, nor is a wise idea to attempt.
v2: Tweak error message (Dylan)
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com> (v1)
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: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This has been a requirement for ages, yet it seems like we never
explicitly errored out during configure.
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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 <emil.velikov@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
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: b87ef9e606 "util: fix MSVC build issue in disk_cache.h"
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
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 <tfiga@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
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 <se@FreeBSD.org>
Reported-by: Stefan Esser <se@FreeBSD.org>
Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228673
Fixes: 1914c814a6 ("configure: error out if building OMX w/o supported platform")
Fixes: 63e11ac2b5 ("configure: error out if building VA w/o supported platform")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
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 <timothy.o.rowley@intel.com>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: Dylan Baker <dylan@pnwbakers.com>
Cc: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Bruce Cherniak <bruce.cherniak@intel.com>
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 <keithp@keithp.com>
Fixes: dbac8e25f8 "radv: Add EXT_acquire_xlib_display to radv driver [v2]"
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
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 <marek.olsak@amd.com> (v1)
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (v2)
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
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 <eric.engestrom@imgtec.com>
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 <jason@jlekstrand.net>
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 <jason.ekstrand@intel.com>
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 <jason.ekstrand@intel.com>
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 <jason.ekstrand@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
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 <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
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 <mattst88@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106861
Fixes: 1db4ec0546 "egl: rewire the build systems to use libwayland-egl"
Suggested-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Andreas Hartmetz <ahartmetz@gmail.com>
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106784
Fixes: 17201a2eb0 "radv: port to using updated anv
entrypoint/extension generator."
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
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 <jason@jlekstrand.net>
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 <stschake@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
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 <stschake@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
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.
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 <robdclark@gmail.com>
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 <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The configure.ac logic added in commit
2ef7f23820 ("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 <mattst88@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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.
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 <mattst88@gmail.com>
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Due using a new VP9 config we use, required VA API 0.39
Fixes: 413c5ca372 ("travis: update libva required version")
CC: 18.1 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Add needed infrastructure to use performance monitor
requests for queries.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Chris Healy <cphealy@gmail.com>
Emil Velikov
Rob Clark
Boyuan Zhang
Jason Ekstrand
Eric Engestrom
Dylan Baker
Emil Velikov
Juan A. Suarez Romero
Kristian H. Kristensen
Marek Olšák
Bas Nieuwenhuizen
Caio Marcelo de Oliveira Filho
Chad Versace
Keith Packard
Gert Wollny
Timothy Arceri
Andrew Galante
Scott D Phillips
Stefan Schake
Eric Anholt
Thomas Hellstrom
Thomas Petazzoni
Matt Turner
Nicolas Boichat
Christian Gmeiner