mirror of
https://github.com/tiagovignatti/intel-gpu-tools.git
synced 2025-06-10 17:36:11 +00:00
a896ef9c1f
Fix usage of shared variable LOCAL_PATH in deferred variable expansion area. In Makefile language, rule and dependency definitions use immediate expansions of variables, so they get expanded as soon as the rule is created (1st pass). Rule implementation (a.k.a recipe) use deferred expansion (2nd pass). Android effectively makes all Android.mk files a single makefile by including them all in a big tree from the toplevel makefile. The rules are all evaluated in the first pass and targets are generated. Then the 2nd pass happens and the required target's recipes are run. At this point, LOCAL_PATH has been assigned the value from the last evaluated Android.mk in the 1st phase that defined LOCAL_PATH (most Android.mk use this variable). In my particular case, it was the bootloader's Android.mk that was evaluated last and had defined LOCAL_PATH to it's path. The errors are rather misleading due to it looking like a bug in another module's Android.mk rather than this one :) Basically, if you want to use a variable that any other Android.mk defines, then you can only use it in an immediate expansion context, not a deferred expansion context as it will likely be re-defined by the time the 2nd pass happens. This patch stores it in a unique variable that should not be being used by other Android.mk files. An alternative fix would be to use $@ and $< as the files in question are target and dependency, but I never like using those as they can easily break if dependencies are added etc. I prefer variable to be explicitly named to make them obvious. See gnu make manual for explanation of deferred vs immediate expansion of variables : http://www.gnu.org/software/make/manual/make.html#Reading-Makefiles Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Robert Beckett <robert.beckett@intel.com>
This is a collection of tools for development and testing of the Intel DRM driver. There are many macro-level test suites that get used against our driver, including xtest, rendercheck, piglit, and oglconform, but failures from those can be difficult to track down to kernel changes, and many require complicated build procedures or specific testing environments to get useful results. Thus, intel-graphics-tools was a project I started to collect some low-level tools I intended to build. benchmarks/ This should be a collection of useful microbenchmarks. The hope is that people can use these to tune some pieces of DRM code in relevant ways. The benchmarks require KMS to be enabled. When run with an X Server running, they must be run as root to avoid the authentication requirement. Note that a few other microbenchmarks are in tests (like gem_gtt_speed). tests/ This is a set of automated tests to run against the DRM to validate changes. Hopefully this can cover the relevant cases we need to worry about, including backwards compatibility. Note: The old automake based testrunner had to be scraped due to upstream changes which broke dynamic creation of the test list. Of course it is still possible to directly run tests, even when not always limiting tests to specific subtests (like piglit does). The more comfortable way to run tests is with piglit. First grab piglit from: git://anongit.freedesktop.org/piglit and build it (no need to install anything). Then we need to link up the i-g-t sources with piglit piglit-sources $ cd bin piglit-sources/bin $ ln $i-g-t-sources igt -s To avoid some hassles with piglit's use of Waffle just disable it. Run piglit-sources $ cmake -D PIGLIT_USE_WAFFLE=OFF . With piglit-sources $ ccmake . you can check your configuration with a curses interface, too. The tests in the i-g-t sources need to have been built already. Then we can run the testcases with (as usual as root, no other drm clients running): piglit-sources # ./piglit-run.py tests/igt.tests <results-file> The testlist is built at runtime, so no need to update anything in piglit when adding new tests. See piglit-sources $ ./piglit-run.py -h for some useful options. Piglit only runs a default set of tests and is useful for regression testing. Other tests not run are: - tests that might hang the gpu, see HANG in Makefile.am - gem_stress, a stress test suite. Look at the source for all the various options. - testdisplay is only run in the default mode. testdisplay has tons of options to test different kms functionality, again read the source for the details. When creating new tests or subtests please read and follow tests/NAMING-CONVENTION. lib/ Common helper functions and headers used by the other tools. man/ Manpages, unfortunately rather incomplete. tools/ This is a collection of debugging tools that had previously been built with the 2D driver but not shipped. Some distros were hacking up the 2D build to ship them. Instead, here's a separate package for people debugging the driver. These tools generally must be run as root, safe for the ones that just decode dumps. tools/quick_dump Quick dumper is a python tool built with SWIG bindings to important libraries exported by the rest of the tool suite. The tool itself is quite straight forward, and should also be a useful example for others wishing to write python based i915 tools. Note to package maintainers: It is not recommended to package this directory, as the tool is not yet designed for wide usage. If the package is installed via "make install" the users will have to set their python library path appropriately. Use --disable-dumper debugger/ This tool is to be used to do shader debugging. It acts like a debug server accepting connections from debug clients such as mesa. The connections is made with unix domain sockets, and at some point it would be nice if this directory contained a library for initiating connections with debug clients.. The debugger must be run as root: "sudo debugger/eudb" DEPENDENCIES This is a non-exchaustive list of package dependencies required for building everything: libpciaccess-dev libdrm-dev xutils-dev libcairo2-dev swig2.0 libpython3.3-dev x11proto-dri2-dev