| Age | Commit message (Collapse) | Author |
|---|
|
Due to Gamma/Degamma limitation wrt representation of intermediate
values between 0 and 1.0 causing rounding issues and inaccuracies,
applying linear gamma affects crc. This patch fixes the same by
making ctm max test independent of gamma/degamma.
v2: Disable degamma/gamma programming for ctm max test as it
leads to crc mimsmatch. Limiting it to this test case alone as
other tests need it to be enabled, hence not touching those
scenarios.
v3: Fixed a fumble with compilation.
v4: Disabling degamma and gamma for ctm max tests, after the logic
in kernel has been updated by Ville's series.
v5: Disabled gamma/degamma for all ctm tests as suggested by Ville.
v6: Restricting disabling of linear gamma luts for ctm max test.
Updated the commit message and comment as suggested by Daniel.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108147
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Lot of tests fail, when assertion checking
how many vblanks should have passed during
suspend/resume is compared to magic value 150.
At the same time even for failed cases, sometimes
it is clearly visible that there were no issue -
simply suspend took longer on that machine.
If suspend took around 10 s and we get roughly
60 vblanks per second the value then should be
around 600 and not 150.
This change removes 150 magic value and starts
to use calculation of what it is expected to
be instead of being hardcoded.
v2: Add possible error delta interval, where expected
vblanks must lie, i.e:
[estimated_vblanks - err, estimated_vblanks + err]
v3: Made an error range for estimated vblanks a bit less
strict.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104894
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Let's add a check for supported pixel format. Otherwise, we fail the test,
for example, with the following error message
"[drm:intel_framebuffer_init [i915]] unsupported pixel format Y210 little-endian
(0x30313259) / modifier 0x100000000000003"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110369
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
If we have two tasks running on xcs0 and xcs1 independently, but who
queue subsequent work onto rcs, we may insert semaphores before the rcs
work and pick unwisely which task to run first. To maximise throughput,
we want to run on rcs whichever task is ready first. Conversely, if we
pick wrongly that can be used to trigger a GPU hang with unaware
userspace.
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>
|
|
The test uses the new library helper so it doesn't need any local
helper.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Antonio Argenziano <antonio.argenziano@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Let's check if 90/270 rotation is supported for the format that we are
trying to test.
Currently, if we try to test unsupported format the kernel complains with
the following message.
"[drm:skl_plane_check [i915]] Unsupported pixel format Y210
little-endian (0x30313259) for 90/270!"
v2: Use igt_plane_has_format_mod() function to select formats that are
capable of 90/270 rotation (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
I was looking into a failure in which I had
libkmod: ERROR ../libkmod/libkmod-config.c:790 conf_files_list: opendir(/etc/modprobe.d): Too many open files
libkmod: ERROR ../libkmod/libkmod-config.c:790 conf_files_list: opendir(/lib/modprobe.d): Too many open files
(gem_exec_parallel:1315) igt_kmod-WARNING: Could not load i915
(gem_exec_parallel:1315) igt_kmod-WARNING: Could not load i915
I got curious because libkmod doesn't open more than one config file at
a time. What's happening is that libkmod is not the culprit, it's just
the one that failed because we open /dev/dri/card0 -ETOOMANYTIMES.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Share the implementation to tweak the maximum number of open files.
The version in tests/i915/gem_exec_reuse.c was a little bit different,
but I don't think it needs to be because it would still return a
failure if any of the calls to setrlimit() fail. So I'm using the other
one.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
__for_each_engine_class_instance(fd, e) doesn't need and doesn't
use the fd argument. Remove it.
Signed-off-by: Andi Shyti <andi.shyti@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
backlight fade with suspend test turns off dpms which turns off the edp
backlight. Then it does a system suspend and resume. After resume,
the edp backlight would still be off, but the test sets the brightness
value and reads it back. Since the edp backlight is off, the brightness
values written and read are different causing the test to fail.
Do not turn off the DPMS before suspend so that after system resume,
the edp backlight would be on and setting the brightness value would
be successful.
v2: Remove "DPMS off" before system suspend instead of adding
"DPMS on" after system resume.
Cc: Jyoti Yadav <jyoti.r.yadav@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Harish Chegondi <harish.chegondi@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=107820
Fixes: 377752242995 ("Brightness test with DPMS and System suspend.")
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
|
We only need the warning once, not for the several thousand relocations
we try. The current execbuf implementation will set all presumed_offset
to -1 so this loop should quit on the first entry if we hit the
pagefault, but for the sake of completeness check all.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110269
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Not displaying the flip on the next vblank is bad, but not the end of
the world -- so long as that is only a temporary glitch. Give the vblank
a few more frames to complete, and warn instead of failing if it takes
more than one vblank interval to flip.
v2: Bump the warning to >1 missed flip, to spare us the noise.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
i915_ring_missed_irq was removed from debugfs in kernel patch
789659f4307a ("drm/i915: Drop fake breadcrumb irq") and it was the
base of which i915_missed_irq was written, so removing this test for
good.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
stridechange subtest
As explained in c1edee186d18 ("tests/frontbuffer_tracking: Do not
assert FBC state after a page flip changing stride") after changing
the plane stride there is the possibility that CFB will not be big
enough to keep FBC enabled, that is why do_assertions() is called
with DONT_ASSERT_FEATURE_STATUS but DONT_ASSERT_FEATURE_STATUS is
overkill and will not check the status of the other features like PSR
and DRRS when running combined feature tests and possibly hiding
bugs.
So lets add a new flag that will only not assert FBC.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
|
|
changing stride
When the stridechange subtest was introduced f23ea58f1fbb
("kms_frontbuffer_tracking: expand badstride and stridechange")
atomic was not around and change the stride using drmModePageFlip()
was not allowed so it was expected that it would return -EINVAL and
kernel would keep the old framebuffer with the smaller plane that is
know to fit on CFB(if it don't fit the test will skip on the first
full-modeset because "not enough stolen memory" is set).
But after the introduction of atomic the subtest was updated by
f63e070b469d ("kms_frontbuffer_tracking: Fix tests with the new
atomic reality.") to accept a no error return from drmModePageFlip()
but the do_assertions() that follows it was not updated.
As the subtest function comment states, kernel will do fastsets in
this scenario and the allocated CFB could not be enough to keep FBC
enabled over the new framebuffer, so here adding the missing
DONT_ASSERT_FEATURE_STATUS to ignore the FBC state and just test if
CRC match and if kernel do not misbehave.
Other way to solve this issue would be make the kernel do a
full-modeset when CFB is not enough for the new plane so FBC is
disabled with the CRC freeing the actual CFB and then after enable
CRTC again it will try to enable FBC again if it can allocate the
required CFB but by the subtest comment this is not intended.
v2: Assert features when drmModePageFlip() fails aka non-atomic driver(Dhinakaran)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105683
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
|
|
No reason why we shouldn't be able to execute the legacy-gamma-reset
test with a partial color pipeline.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Split the invalid-lut-sizes test into separate gamma and degamma tests.
This way we can report SKIP for the thing we don't have. Also make the
CTM invalid sizes test report a skip too.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Requiring a full color pipeline when we're just testing eg. the gamma
LUT is silly. Make the requirements more sensible.
Also include an igt_require() for the CTM, which was totally missing
before.
v2: Note the added igt_require(CTM) (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
We already compute the lut_size*entry_size so let's reuse those
when allocating the LUTs.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
To make life easier let's wrap the LUTs in a small struct.
v2: igt_assert(gamma) (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
I think we can assume fresh enough headers by now, so remove
the local _drm_color_ctm and _drm_color_lut structs definitions.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
It's a generic testcase, originally for a chv issue, but we can hit
legit bugs with this on any platforms. And we do, which then results
in confused managers.
Let's rename for clarity.
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: "Peres, Martin" <martin.peres@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Acked-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Acked-by: "Peres, Martin" <martin.peres@intel.com>
Acked-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
We may not be able to enable all the planes simultaneously. In that
case just keep going with fewer planes. The test already requires
atomic so let's use TEST_ONLY unconditionally.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
These tests intend to test scaling on hardware with overlay planes.
They will incorrectly try to scale the cursor plane or occasionally
crash by trying to access planes that don't exist for hardware that
doesn't expose any overlay planes.
Make plane selection explicit by requesting the plane by type and index
using the igt helper igt_pipe_get_plane_type_index.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
|
|
If we caused a fault on a GEM buffer while in the middle of trying to
write/read into that buffer, we could conceivably deadlock (e.g.
recursing on struct_mutex if we are not careful). Exercise these cases
by supplying a fresh mmap to pread/pwrite in both non-overlapping and
overlapping copies.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
|
|
Set the src/dst viewports correctly when trying to crop off the
edges.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110296
Fixes: 80eb61459791 ("tests/kms_plane: Remove the upscaling requirement")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
We want to use a child in order to detect an uninterruptable sleep (a
potential bug we might hit), but we can use igt_waitchildren_timeout()
to replace our risky self-signaling + nanosleep.
v2: Remove the now redundant signal() setup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103182
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
ICL has some many planes per pipe that it is causing this test to
skip due bandwidth limitation when combined with 4K displays.
The objective of this test is test the visibility of the planes when
switching between high and low resolution, more information in the
patch that added this test 12e34d8c909a ("tests/kms_plane_lowres:
Plane visibility after atomic modesets").
So it was setting all the planes the tested pipe in the bottom left
of the display using the height of high resolution, checking the
visibility and then switching to the low resolution mode and checking
again the visibility and now it is expected that all planes would be
invisible.
So to overcome ICL bandwidth issues, here it is testing each plane
individually.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
|
|
Three test were duplicating this 1024x768 mode so lets move it to lib
and share it.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
|
|
get_lowres_mode() was looking for the desired mode over all
connectors what could cause commit to fail due incompatibility.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
|
|
We may use HW semaphores to schedule nearly-ready work such that they
are already spinning on the GPU waiting for the completion on another
engine. However, we don't want for that spinning task to actually block
any real work should it be scheduled.
v2: No typeof autos
v3: Don't cheat, check gen8 as well
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>
|
|
Replace the convoluted raising of SIGALRM from the child with an
interruptible sleep in the parent with the equivalent and far more
natural igt_waitchildren_timeout().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103182
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
gem-execbuf-stress
Extra 5sec delay does not add any value more than gem-execbuf-stress.
It waits until suspend state after a job is added by gem_execbuf().
There is no need to do more when GPU becomes suspended state.
I confirm this by looking at pm_runtime_force_suspend() which exits
on suspend state.
Signed-off-by: Caz Yokoyama <caz.yokoyama@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>
|
|
By clean up idle work, gem-execbuf-stress subtest runs 1.2 sec.
I divide "i915_pm_rpm: remove gem-execbuf-stress-extra-wait because
same as gem-execbuf-stress" into 2 patches. This is one of them.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Caz Yokoyama <caz.yokoyama@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
One significant usecase for intel_reg/etc. is to be able to examine
the hardware state *before* loading the driver. If the tool forces
the driver to load we've totally lost that capability.
This reverts commit 8ae86621d6fff60b6e20c6b0f9b336785c935b0f.
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Michał Winiarski <michal.winiarski@intel.com>
|
|
We may not be able to turn on all the planes (eg. due to memory
bandwidth limitations). Let's accept that fact and simply turn
on as many planes as we can.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Instead of just testing each pixel format let's test every
format+modifier combo.
Obviously testing with solid filled fbs isn't the most effective
way to detect tiling problems, but we can't really do much more if
we want to keep comparing YUV vs. RGB results (unless we start to
render the RGB content in a way that matches the YUV subsampling
behaviour of the hardware).
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Move the pipe/primary plane stuff outside the plane loop so that
we can avoid all that overhead (including a modeset) when switching
from one plane to another.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Reduce the plane size further to speed up the test. 64x64 is the
universal i915 minimum cursor size so we'll use that. And since
we chose wisely we'll make cursors use the reduced size as well.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
No point in requiring upscaling when trying to use a small fb to test
pixel formats.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
We not only need to check that userspace is allowed to use the objects
it's changing, but also the objects it's using as property values. The
only ones relevant for leases are the CRTC_ID properties on connectors
and planes.
Current kernels fail this.
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
The conversion from idr to xarray will change the errno for already
inserted object ids from ENOSPC to EBUSY. Allow both.
Cc: Matthew Wilcox <willy@infradead.org>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
I dropped a superfluous check for negative object id (the kernel
did a cast to s32, despite that object ids are always unsigned).
Which changes the errno from EINVAL to ENOENT. Allow both.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Figured I'll only test the SetCursor interface since in the kernel
it's all the same anyway, it's just libdrm that splits it up.
Current kernels fail this.
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Again we need to make sure that a lease can't use planes it's not
allowed to through legacy ioctls. SetCrtc is a bit more tricky, since
we should still allow to shut down a CRTC, e.g. when we're allowed to
use other planes on that CRTC.
Current kernels fail this.
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
We need to make sure that legacy ioctls don't operate on a lease if
the lesse doesn't have access to the implicitly used primary plane.
Current kernels fail this.
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
It's just added to in a loop later without any initialization or
direct assignment.
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Even with 128MiB reserved for other use, a single pass of gem_exec_big
runs out of memory. Give in and halve our batch size, that has to be
enough slack! As to why it keeps on failing, is left as an exercise to
the reader -- we have to solve the mm/ mystery one day, as eventually it
will be our only remaining source of bugs!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
|
|
This function checks whether a port is an analog bridge. Analog
bridges provide their own EDID thus the vendor should be different
from "IGT".
There was a typo that made the function always return true for VGA
ports. The condition was essentially:
thing != 'I' || thing != 'T'
which is always true.
Apparently this didn't cause any harm, but it's probably better to fix
it anyway in case some tests were skipped and shouldn't.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Acked-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
To make the demonstration of the cheeky preemption more impactful, make
the second context a nop to contrast the first being 1024
MI_STORE_DWORD_IMM. Then if we execute and wait on the second context
before executing the first, the client latency is even more drastically
reduced.
To more clearly show any effect on wait reordering, measure the
alternative path and present both.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
