- Mar 15, 2020
-
-
Chris Wilson authored
The intent is just to push beyond the [working] GTT size to force the driver to have to rearrange the buffers, so scale back until we just poke past that threshold. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1322 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
- Mar 13, 2020
-
-
Chris Wilson authored
To set a property on an engine, we need to use its canonical name (%class%instance). Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Chris Wilson authored
When we can control the preempt_timeout_ms property on an engine, we can specify a much faster timeout and so expect our tests to run much faster. Then we can also avoid the embarrassment if the preempt reset is disabled and the tests start failing because we are not waiting 10+s for the hangcheck. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1440 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Chris Wilson authored
Make setting engine tunables easier! Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Chris Wilson authored
We [will] expose various per-engine scheduling controls. One of which, 'timeslice_duration_ms', defines the scheduling quantum. If a context exhausts its timeslice, it will be preempted in favour of running one of its compatriots. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Andi Shyti <andi.shyti@intel.com>
-
Chris Wilson authored
We [will] expose various per-engine scheduling controls. One of which, 'heartbeat_duration_ms', defines how often we send a heartbeat down the engine to check upon the health of the engine. If a heartbeat does not complete within the interval (or two), the engine is declared hung. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Andi Shyti <andi.shyti@intel.com>
-
Chris Wilson authored
We [will] expose various per-engine scheduling controls. One of which, 'preempt_timeout_ms', defines how we wait for a preemption request to be honoured by the currently executing context. If it fails to relieve the GPU within the required timeout, the engine is reset and the miscreant forcibly evicted. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Andi Shyti <andi.shyti@intel.com>
-
Chris Wilson authored
Simplify testing sysfs/engines by providing a convenience routine that iterates over each engine, calling a igt_dynamic routine. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Andi Shyti <andi.shyti@intel.com>
-
Chris Wilson authored
Quite frequently we want to execute on one precise engine, so add a convenience routine to create a context that contains only that engine in the default [0] slot. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Andi Shyti <andi.shyti@intel.com>
-
Chris Wilson authored
Use a fence to submit the pair of batches tightly together, and in particular not allow the system time to retire in between. Then by passing the fence along the inter-context chain, we can force the explicit order of execution, which we currently lack as we are avoiding the implicit fences. In particular, without the explicit ordering the second batch could execute before the first had managed to asynchronously bind the hidden buffer. References: https://gitlab.freedesktop.org/drm/intel/issues/1420 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
Replace the open-coded version of gem_mmap__device_coherent() with itself Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Petri Latvala authored
Instead of reading one record at a time between select() calls and tainted-checks etc, use the same at-the-end dmesg dumper whenever there's activity in /dev/kmsg. It's possible that the occasional chunk of missing dmesg we're sometimes hitting is due to reading too slowly, especially if there's a huge gem traceback. Also print a clear message if we hit a log buffer underrun so we know it. Reference: #79 Signed-off-by:
Petri Latvala <petri.latvala@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Petri Latvala authored
Signed-off-by:
Petri Latvala <petri.latvala@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Petri Latvala authored
Signed-off-by:
Petri Latvala <petri.latvala@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- Mar 12, 2020
-
-
KunalJoshi95 authored
Currently, only hard coded pixel formats are validated which are not generic across platforms which leads to SKIPS. Added support to validate only those pixel formats which are supported by platform. Covering both RGB and YUV pixel formats. v2: added support for RGB pixel formats (Swati) v3: simplified constraint and made it more readable (Petri) v4: -used igt_format_str instead of macro to print fourcc code (Ville) -dropped patch#1 because of above change v5: -Removed connector_dynamic_subtest_end macro and modified connector_dynamic_subtest to allow scoping depending on requirement (Petri) -Changed test names to make it more revealing (Arek) Signed-off-by:
Kunal Joshi <kunal1.joshi@intel.com> Reviewed-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com>
-
- Mar 11, 2020
-
-
This test adds three distinct subtests: - drop/set master as root - drop/set master as non-root - drop/set master for a shared fd Currently the second subtest will fail, with kernel patch to address that has been submitted. v2: - Add to the autotools build v3: - Add igt_describe() - Use igt_fixture() for tweak_perm - Enhance comments v4: - More comment tweaks - Add close(drm_open_driver()) workaround - Use igt_require() for the fd, in final test v5: - Drop the close(drm_open_driver()) workaround Cc: Petri Latvala <petri.latvala@intel.com> Reviewed-by:
Petri Latvala <petri.latvala@intel.com> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com>
-
- Mar 09, 2020
-
-
Chris Wilson authored
The spin->handle is already validated by igt_spin_new(), and in particular we need to be careful when using INVALID_CS that it the hang may be detect and the request reset + completed before the gem_bo_busy is called. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Juha-Pekka Heikkilä authored
When run on more than one monitor there may be modeset in queue which will block flip. Kernel will timeout with modeset at ten seconds so lets wait in test also that same ten seconds at maximum. V2 Ville Syrjälä: lets just wait for five seconds Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com>
-
- Mar 07, 2020
-
-
Chris Wilson authored
Use a different batch on each engine (still within the same fd/vm) to avoid ww_mutex contention. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
- Mar 06, 2020
-
-
Mirroring addfb2, add tests for the new ioctl which will return us information about framebuffers containing multiple buffers, as well as modifiers. Changes since v5: - Add documentation Changes since v4: - Remove unnecessary bo creation for getfb2-handle-closed subtest Changes since v3: - Add subtests to ensure handles aren't returned for non-root and non-master callers Changes since v1: - Add test that uses getfb2 output to call addfb2 as suggested by Ville Signed-off-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
Juston Li <juston.li@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Generated with make headers_install from drm-misc-next: commit e62bf83aa1bb9d9953eec2e3663528c766b148ea Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Feb 11 16:47:53 2020 +0200 drm/irq: remove check on dev->dev_private include/drm-uapi/drm_fourcc.h was not synced as the local copy has changes not merged upstream. Changes since v5: - Rebase and resync imported headers Signed-off-by:
Juston Li <juston.li@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
We want to mark workload contexts as non-persistent if possible so that we do not have to worry about leaving long (or infinite!) batches running post exit. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
VCS is a special (non-physical) engine id/name which means load-balancing in legacy workloads. As such when i915 balancing is not enabled it needs to have a calibration as well. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Sanity check that kernel rejects invalid batch_start_offset and batch_len. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Add a variant that also attaches a igt_spin_t to the userptr, waits for it to start executing, call igt_spin_set_timeout and then do the munmap. Suggested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Attempts to create a userptr object on top of a GTT mapping to another GEM object are currently expected to succeed. However, attempts to pin the object pages in memory are expected to fail with -EFAULT. There is a subtests that already exercises that behavior. Having a closer look at the driver behavior we can see that the very first operation which tries to set the object pages fails with -EAGAIN. Moreover, if I915_USERPTR_UNSYNCHRONIZED flag has been used by object creation, MMU notifier is activated for the object. Consecutive attempts may also fail with -EAGAIN while the driver tries to acquire the pages in background, with the MMU notifier still possibly active, but then the background attempt to pin the pages in memory finally fails, the notifier is deactivated, and all following set pages operations fail with -EFAULT. That behavior can be observed not only for userptr objects created on top of GTT mappings, but also on new mapping types introduced by MMAP_GTT API v4 aka MMAP_OFFSET. Extend the scope of the subtest by converting it to a set of dynamic subtests which exercise each MMAP_OFFSET mapping type supported by hardware. Moreover, since the driver detailed behavior depends on the I915_USERPTR_UNSYNCHRONIZED flag being requested or not by object creation, move the subtest to a section where the state of the flag, which now defaults to being set, is set explicitly. Also, rename the subtest to reflect that change. v2: For as long as the lockdep loop issue is not fixed, don't succeed if a preventive failure occurs but skip (Chris), - otherwise, warn about possible risk, - put a FIXME placeholder until we learn how to anger lockdep. v3: Use dynamic subtests, with skips handled at mmap-offset attempt performed by the test anyway (Chris), - for better clarity of the patch, drop cosmetic only changes, - use more concise wording in subtest description. v4: Separate problematic lockdep loop trigger attempts from this patch to a follow up one, reword commit message and description, - move the subtest to "unsynchronized" section, - rebase on top of "lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support". Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Antonio Argenziano <antonio.argenziano@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- Mar 05, 2020
-
-
map-fixed-invalidate* subtests utilize gem_set_tiling() which may fail, e.g. on hardware with no mappable aperture, due to missing fences. Skip those subtests if fences are not available. Moreover, those subtests use GEM_MMAP_GTT IOCTL which has been replaced by GEM_MMAP_OFFSET that supports other mapping types, not only GTT. Use the new IOCTL and dynamically examine all MMAP_OFFSET types supported by hardware. v2: Examine all supported MMAP_OFFSET types, not only the first one that works, - add subtest description. v3: Refresh on top of commit 384e7ecb ("lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support"). Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Our goal with bonded submission is to submit the pair of user batches to the HW at roughly the same time, and so try to avoid any bubbles. If we submit the secondary batch too early, it will be running before the first and stuck on the HW preventing others from utilising the GPU. At worst, it may even appear unresponsive and trigger a GPU hang as it waits for its master. If we submit the secondary too late, the reverse situation may apply to the master as it has to wait for the secondaries. This test tries to verify that using a submit-fence to create a bonded pair does not prevent others from using the HW. By using a pair of spinners, we can create a bonded hog that when set in motion will fully utilize both engines [if the scheduling is incorrect]. We then use a third party submitted after the bonded pair to cancel the spinner from the GPU -- if it is unable to run, the spinner is never cancelled, and the bonded pair will cause a GPU hang. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Tvrtko Ursulin authored
When providing engine calibrations on the command line, we need to apply the one given for RCS to DEFAULT as well. Also when load balancing is used we need to get calibration from one of the real engines from the map which should provide a better match. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Tvrtko Ursulin authored
These are not input fields and i915 currently leaves them untouched. In the spirit of trusting the query as the authoritative source of information, stop asserting these output only reserved fields are zero. This should prevent the test from auto-failing if we extend the data in the future. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Brian Welty <brian.welty@intel.com> Reviewed-by:
Brian Welty <brian.welty@intel.com>
-
- Mar 04, 2020
-
-
Chris Wilson authored
Sigh, the kernel only accepts up to 511 duplicate handles before collapsing. Work within its limits, for the moment. References: 003d8b9143a6 ("drm/i915/gem: Only call eb_lookup_vma once during execbuf ioctl") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
Update -EINVAL tests for duplicate handles to accept -EALREADY. References: 003d8b9143a6 ("drm/i915/gem: Only call eb_lookup_vma once during execbuf ioctl") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
DPMS igt tests were skipping for non-psr panels due to psr_sink_support sink check added to igt_fixture() at commit <6cbe6af3>. DPMS dc state igt test don't require psr_sink_support, as it validates DC states with all display being DPMS off. Removing the psr sink check from igt_fixture and adding it only for dc*- psr tests. v2: - Adding psr sink check to dc3co and moving ahead it in dc5/6 psr tests. [Jose] Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com>
-
Dump i915_power_domain_info debugfs attribute on DC state test failures, it will help to identify culprit, which causes non zero refcount for "DC off" power well. v2: - Fix the mem leak. [Jose] v3: - Removed pwr_dmn_info global. [Jose] Cc: Animesh Manna <animesh.manna@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com>
-
- Mar 03, 2020
-
-
Chris Wilson authored
Minor ABI break in reporting a new error code for a self-inflicted user overlap within an execbuf. References: 2920bb94e65f ("drm/i915: Drop inspection of execbuf flags during evict") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
As it may take 17ms to create a context and execute, there is no advantage in doing it a thousand times before checking for timeout. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
As we skip work if we exceed our timeout, we may not fill every dword in every surface, so confirm this thread has written into this dword before checking. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
Sigh, last minute adjustment to reduce a hard coded value goes wrong. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
The test is supposed to create a context for each execution, so do so. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
gem_create + gem_execbuf should be long enough that the accuracy of gettime is insignificant; and this is a test not a benchmark! Remove the 1024 loop so that we check for timeout more frequently. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-