Vinay Belgaumkar be2d5188f6 tests/gem_softpin: New tests for softpin feature
These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin patch in order to pin buffers
to a certain VA.

Caveat: These tests were designed to run on 64-bit system. Future work
includes adding logic to ensure these tests can run on 32-bit systems with
PPGTT support. Some tests are currently disabled for 32-bit systems for that
reason.

v2: Added cc and signed-off-by fields

v3: Fixed review comments, added helper functions. Removed userptr error
scenarios covered by existing userptr tests. Modified stress test to have
100K buffers, it now runs for ~30 mins, checks every element has been written
to correctly, and pins buffers at different VMAs.

v4: Changed name to gem_softpin

v5: More fixes. Removed the file based tests, will move them to userptr tests.
Added a function that validates appropriate PPGTT support before running tests.
Optimized stack space and memory footprint in stress test. Removed the eviction
test, will add it back after verifying proper functionality.

v6: Split basic test into userptr and bo
Fixed some coding style issues.

v7: Enhanced invalid vma pinning test to verify 32-bit PPGTT functionality.
Enabled the test for 32-bit PPGTT systems, and verify pinning fails above
32-bit addresses. Enhanced the high adress pinning test to ensure pinning
fails when EXEC_OBJECT_PINNED flag is not used. Some more cosmetic fixes to
close buffer handles. Changed userptr function to used synchronized operations.

v8: Minor change to high address pinning test as per comment.

v9: Skip the tests if softpin support is not present.

v10: Removed trailing white spaces.

v11: Keep alphabetical order in Makefile and gitignore; update error code
returned while trying to pin above the max vm size (EINVAL); test attempt
to pin above 4GB without the support 48b flag.

Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v11)
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2015-12-09 10:27:12 +00:00
2015-12-02 15:02:52 +00:00
2015-09-18 17:30:41 +01:00
2015-09-08 16:14:45 +01:00
2014-07-23 16:43:05 +01:00
2014-03-11 17:19:47 +01:00
2012-01-04 10:47:10 +01:00
2014-12-10 15:49:14 +00:00
2014-11-06 13:24:30 +00:00

Intel GPU Tools
===============

Description
-----------

Intel GPU Tools 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
the 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. Therefore, Intel GPU Tools includes low-level tools and tests
specifically for development and testing of the Intel DRM Driver.

Intel GPU Tools is split into several sections:

benchmarks/
	This is a collection of useful microbenchmarks that can be used to tune
	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. Many of the tests have subtests, which can be listed by using
	the --list-subtests command line option and then run using the
	--run-subtest option. If --run-subtest is not used, all subtests will
	be run. Some tests have futher options and these are detailed by using
	the --help option.

	The test suite can be run using the run-tests.sh script available in
	the scripts directory. Piglit is used to run the tests and can either
	be installed from your distribution (if available), or can be
	downloaded locally for use with the script by running:

	./scripts/run-tests.sh -d

	run-tests.sh has options for filtering and excluding tests from test
	runs:

	  -t <regex>      only include tests that match the regular expression
	  -x <regex>      exclude tests that match the regular expression

	Useful patterns for test filtering are described in the API
	documentation and the full list of tests and subtests can be produced
	by passing -l to the run-tests.sh script.

	Results are written to a JSON file and an HTML summary can also be
	created by passing -s to the run-tests.sh script. Further options are
	are detailed by using the -h option.


	If not using the script, piglit can be obtained from:

	git://anongit.freedesktop.org/piglit

	There is no need to build and install piglit if it is only going to be
	used for running i-g-t tests.

	Set the IGT_TEST_ROOT environment variable to point to the tests
	directory, or set the path key in the "igt" section of piglit.conf to
	the intel-gpu-tools root directory.

	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 igt <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 -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.

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.

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"

docs/
	Contains the automatically generated intel-gpu-tools libraries
	reference documentation in docs/reference/. You need to have the
	gtk-doc tools installed and use the "--enable-gtk-doc" configure flag
	to generate this API documentation.

	To regenerate the html files when updating documentation, use:

	$ make clean -C docs && make -C docs

	If you've added/changed/removed a symbol or anything else that changes
	the overall structure or indexes, this needs to be reflected in
	intel-gpu-tools-sections.txt. Entirely new sections will also need to be
	added to intel-gpu-tools-docs.xml in the appropriate place.


Requirements
------------

This is a non-exhaustive list of package dependencies required for building
everything (package names may vary):

	gtk-doc-tools
	libcairo2-dev
	libdrm-dev
	libpciaccess-dev
	libunwind-dev
	python-docutils
	x11proto-dri2-dev
	xutils-dev
Description
No description provided
Readme 18 MiB
Languages
C 95.5%
Yacc 2.5%
Makefile 0.5%
Shell 0.5%
Lex 0.3%
Other 0.6%