| Age | Commit message (Collapse) | Author |
|---|
|
Just forget about earlier request_in events.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
Incomplete requests (no notify, no context complete) have to be corrected
by looking at the engine timeline, and not the sorted-by-start-time view
as was previously used.
Per-engine timelines are generated on demand and cached for later use.
v2: Find end of current context on the engine timeline instead of just
using the next request for adjusting the incomplete start time.
v3: Improve scaling with large datasets by only walking each engine
timeline once and some caching. (John Harrison)
v4:
* Fix logic fail from v3.
* Refactor the code a bit to separate the stages better.
* Do not account batches with unknown duration in avg stats.
* Handle two user interrupts with the same seqno.
* Handle user interrupt arriving after request_out.
v5:
* Update for class:instance.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
Improve the timeline legend to show actual context colours.
v2: (Tvrtko Ursulin)
* Commit msg.
* Tweak layout for more compactness and more readability.
v3:
* Limit number of shown contexts in the legend. (John Harrison)
v4:
* Unbreak legend display with small context counts. (John Harrison)
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
John reports that on a long runnning systems the huge disparity between
kernel context and user context id's causes all interesting colours to be
clustered too close together.
Fix this by assigning colours to seen contexts instead of basing purely
on context id's.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: John Harrison <John.C.Harrison@Intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
We add stripes for different stages of request execution so it is easier
to follow one context in the multi-colour mode.
Vertical stripe pattern indicates pipeline "blockages" - requests waiting
for dependencies before they are runnable.
Diagonal stripes indicate runnable requests waiting for GPU time.
Horizontal strips are requests executing on the GPU.
Also use this new multi-coloured mode from media-bench.pl.
v2:
John Harrison:
* Mention media-bench.pl in the commit.
* Fix HTML for single colour mode.
v3:
* Rebase.
* Apply stripes to legacy colouring as well.
v4:
John Harrison:
* Use per context colours for ctxsave and incomplete boxes.
* Clearer timeline legend.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
It is possible to customize the axis display so change it to display
timestamps in seconds on the major axis (with six decimal spaces) and
millisecond offsets on the minor axis.
v2:
* Give up on broken relative timestamps.
v3:
* Drop all date complications and just use micro seconds throughout.
(John Harrison)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
Currently we indirectly try to evict the test buffers by mmaping enough
bo that should fill the aperture. However, this assumes that the kernel
is trying to fill the aperture and does not use random replacement
(which it does) or use small partials to avoid mmaping the whole object
(which it does). Rather than assume, use the debugfs interface to force
the eviction of the bound objects.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
|
|
Dropping duplicated definitions of registers,fields
and shiftsm, which were implemented in gen4 and
does not changed in gen6.
v3: Rebase
Signed-off-by: Lukasz Kalamarz <lukasz.kalamarz@intel.com>
Cc: Katarzyna Dec <katarzyna.dec@intel.com>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Katarzyna Dec <katarzyna.dec@intel.com>
|
|
Instead of using definitions duplicated in gen7_render header,
we should use the oldest definition that is working with chosen
gen. This patch reuse gen6 definitons if registers/fields/shifts
that were introduced in other genX_render headers.
v3: Rebase and checkpatch
Signed-off-by: Lukasz Kalamarz <lukasz.kalamarz@intel.com>
Cc: Katarzyna Dec <katarzyna.dec@intel.com>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Katarzyna Dec <katarzyna.dec@intel.com>
|
|
Add rendercopy implementation for gen4/5. Basic structure
copied from the gen6 implementation, and the gen4/5 specific
bits were mostly lifted from sna.
v2: Renamed registers definitions, which are GEN4 specific
to include that prefix (Lukasz)
v3: Rebase and checkpatch
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lukasz Kalamarz <lukasz.kalamarz@intel.com>
Cc: Katarzyna Dec <katarzyna.dec@intel.com>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Katarzyna Dec <katarzyna.dec@intel.com>
|
|
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
|
kms_frontbuffer_tracking should test PSR the same way that kms_psr does.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
kms_frontbuffer_tracking and kms_psr test PSR in different ways, let'
fix that by creating common library functions.
v2: Include the new file in meson.build
v3: Leave --no-psr intact (Rodrigo)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Change the function arguments to not rely on test specific data as
the following patches change kms_frontbuffer_tracking to reuse PSR
functions.
v2: Leave --no-psr intact (Rodrigo)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
"drm/i915: Kill sink_crc for good" removes the kernel support for sink
crc.
References: https://patchwork.freedesktop.org/series/46039/
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
This was always a placeholder for GVT stakeholders to provide some
better tests. 2 years later and none have been put forward so stop
wasting CI's time running a placeholder.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106989
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Acked-by: Martin Peres <martin.peres@linux.intel.com>
|
|
Before running a hang test, check if we can inject a hang and expect
recover to work. If we can't control a hang, skip the subtest.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
According to Display WA #1172, to truly bypass the color data on Gen 10
use ARGB8888 instead of XRGB8888 to pass compliance.
v2: Use ARGB8888 format only for video pattern fb, set per pixel alpha
value to 0xff in fill_framebuffer.(Imre)
v3: Set the aplha value for each pixel(Imre)
Cc: Imre Deak <imre.deak@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
As we try to blit into the buffer to check CPU<->GPU snooping, we have
to check we have a functional GPU first.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
|
|
We don't use sink CRC anymore in this test.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Wait for PSR HW status to show active before starting an PSR exit action.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
eDP sink crc reads use vblank interrupts that cause PSR exit and
therefore makes them unsuitable for PSR testing. Besides that, reading
sink CRC via the AUX channel for testing when the HW also is most likely
is going to be using AUX channel is a recipe for inconsistent test
results. Thirdly, CRC's have been seen to be noisy/inconsistent across
sinks. We tradeoff the ability to validate what the sink is displaying
for correctness.
We also make use of source PSR status register to check whether HW tracking
triggered PSR exit upon an exit event.
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
eDP sink crc reads use vblank interrupts that cause PSR exit and
therefore makes them unsuitable for PSR testing. Besides that, reading
sink CRC via the AUX channel for testing when the HW also is most likely
is going to be using AUX channel is a recipe for inconsistent test
results. Thirdly, CRC's have been seen to be noisy or vary across sinks for
the same driver and test code. We tradeoff the ability to validate what the
sink is displaying for correctness.
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
An hanging batch is nothing more than a spinning batch that never gets
stopped, so re-use the routines implemented in dummyload.c.
v2: Let caller decide spin loop size
v3: Only use loose loops for hangs (Chris)
v4: No requires
v5: Free the spinner
v6: Chamelium exists.
Signed-off-by: Antonio Argenziano <antonio.argenziano@intel.com> #v3
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Setup a userptr object that only has a read-only mapping back to a file
store (memfd). Then attempt to write into that mapping using the GPU and
assert that those writes do not land (while also writing via a writable
userptr mapping into the same memfd to verify that the GPU is working!)
v2: Pull the random batch construction into a routine to avoid
duplication.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Time intervals as produced by timersub() are normalized to have
the tv_usec in the range 0-999999. That leads to very confusing
looking debug output for negative interval. Eg. an interval
of -0.1 seconds would be represented as tv_sec=-1, tv_usec=900000.
Let's just convert the thing to a float seconds value and print
that so that we'll get less confusing debug output.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As we want to make the buffers active on the GPU before removing their
fence, an operational GPU (not wedged!) is required.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
As render copy wants to use the GPU, we should make sure it is not
wedged first.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
As we need GEM and the GPU to do a GPGPU fill, we should check that it
is operable before using -- skipping rather than failing when the device
is wedged.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
We use options!=NULL to determine if we should require the module to be
reloaded and fail if we find it already loaded. In pm_rpm, we are only
ensuring the MSR module is loaded, and only want default options.
Fixes: 4dc2ce0e ("lib/kmod: Fail if the module is already loaded")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
|
|
In split mode all requests have to be added up since they were previously
re-arranged so there is no overlap.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
Turn off timeline stacking in favour of putting all the boxes belonging to
a single context at the same vertical slot.
Also remove the custom sorting function in favour of correctly assigning
the subgroup id's and order which greatly speeds up the library operations.
And finally remove the 'Toggle stacking' button which never worked.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
Now that we scale timestamps to get better timeline granularity, the hacky
hand rolled micro-second time to HTML date conversion does no longer cut
it.
Use perl built-in gmtime to handle things properly.
v2: Do not bother with the epoch since timeline times are relative to
unknown system boot time. (John Harrison)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
Commit 87d2affc380da96ba66c258c5337c363fe8651ef ("trace.pl: Add support
for colouring context execution"), due some dodgy attempts at patch
splitting broke the legacy colouring mode.
Fix it by passing in the request stage into the helper so all stages can
be correctly coloured in both modes.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
Now that we can use _Static_assert() due to C11, make it future proof so
we remember to update this if IGT_MAX_PIPES changes. Also reduce
verbosity a little bit by calculating indexes instead of if/else chain.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Properly check for errors and rename the function since we are checking if we are
running under gdb, not making it run under gdb. Previously we were
passing uninitialized data to basename() due to not properly adding the
nul termination.
==22293== Conditional jump or move depends on uninitialised value(s)
==22293== at 0x4C306D0: rindex (vg_replace_strmem.c:199)
==22293== by 0x4EC55DD: basename (in /usr/lib64/libc-2.27.so)
==22293== by 0x400744: running_under_gdb (in /tmp/a)
There's another problem with this function that it doesn't detect when
we are running gdb from a toolchain using a toolchain triplet, but
that's left for another patch.
v2: remove the fix for repeating the argument on readlink() since that
landed in another patch
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
It's been a long time and all reasonable toolchains support gnu11
already.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
pthread_create() expects a void *(*start_routine) (void *). Fix warning
the following warning on gcc 8:
../tests/sw_sync.c:773:37: warning: cast between incompatible function types from ‘int (*)(void *)’ to ‘void * (*)(void *)’ [-Wcast-function-type]
pthread_create(&threads[i], NULL, (void * (*)(void *))
^
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
This commit fix the GCC warning:
warning: bitwise comparison always evaluates to false
[-Wtautological-compare]
} else if ((val & DPLLB_MODE_LVDS) == DPLLB_MODE_DAC_SERIAL) {
The first comparison already checks DPLLB_MODE_LVDS, in this sense, the
second 'if' condition always will be false. This commit changes the
comparison to DPLLB_MODE_DAC_SERIAL.
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Acked-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Note that 'proc_path' parameter in __igt_lsof_fds receives a string
which was initialized with the size of PATH_MAX and the local variable
'path' has the same size, but it also have to append: '/', '\0', and the
directory name. This situation caused the warning described below.
warning: ‘%s’ directive output may be truncated writing up to 255 bytes
into a region of size between 0 and 4095 [-Wformat-truncation=]
snprintf(path, sizeof(path), "%s/%s", proc_path, d->d_name);
note: ‘snprintf’ output between 2 and 4352 bytes into a destination of
size 4096 [..]
This commit fixes this problem by changing the string size passed by
__igt_lsoft to __igt_lsof_fds. The max size for the string is
strlen("/proc/%d/cwd")+1 where "%d" can be estimated with
CEILING(LOG_10(INT_MAX)), in this sense, it is safe to define a path
size of 30 characters.
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
This commit fixes the following GCC warning:
warning: passing argument 2 to restrict-qualified parameter aliases with
argument 1 [-Wrestrict]
return (readlink (buf, buf, sizeof (buf)) != -1 &&
This commit fixes the GCC warning by creating a second buffer only to
keep the path.
v2: make pathname smaller (A. Hiler)
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Acked-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Sometimes, we do not want to allow control to escape from the spinner,
e.g. for when we want to hang the GPU inside the batch.
(Split out from the preempt-timeout test case.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
If we want to set new module options, we must load the module or die
trying. We may want to always fail if the module if already loaded, but
for now, take the small incremental step and insist that the options are
set if requested.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As we ordinarily use a spinning batch to trigger a hang, we cannot do so
without execbuf. On the other hand, if we do a manual reset of the
wedged driver, we expect it to remain wedged and for the reset to fail;
failing the test. Even if we remove the igt_assert(!wedged), the test is
suspect as we don't know if the reset took place and so do not know if
the conditions the test is trying to setup apply.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
gem_render_copy requires a working GPU so check first.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
I missed these when sprinkling the memsets. Using stack garbage as the
aux surface state isn't a good idea. Causes kms_front_buffer_tracking
to fail on skl+.
Fixes: a4393c3951ec ("lib: Add aux surface state to igt_buf")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Mark up gem_pwrite_pread's dependence on a functioning GPU, by calling
igt_require_gem in its setup fixture.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Distinguish between the latency required to switch away from the
pollable spinner into the target nops from the client wakeup of
synchronisation on the last nop.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
To further defeat any contemplated spin-optimisations to avoid the irq
latency for synchronous wakeups, increase the queue length.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Apply a different sort of stress by timing how long it takes to sync a
second nop batch in the pipeline. We first start a spinner on the
engine, then when we know the GPU is active, we submit the second nop;
start timing as we then release the spinner and wait for the nop to
complete.
As with every other gem_sync test, it serves two roles. The first is
that it checks that we do not miss a wakeup under common stressful
conditions (the more conditions we check, the happier we will be that
they do not occur in practice). And the second role it fulfils, is that
it provides a very crude estimate for how long it takes for a nop to
execute from a running start (we already have a complimentary estimate
for an idle start).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
