| Age | Commit message (Collapse) | Author |
|---|
|
Currently we have multiple different parts of IGT that define their own
wrapper around the gettid() syscall (or just call it directly with no
wrapper).
Additionally, add the appropriate #includes for igt_aux.h to make sure
syscall() is available.
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
While for stressing the system we want to submit as many batches as we
can as that shows us worst case impact on system latency, it is not a
very realistic case. To introduce a bit more realism allow the batches
run for a user defined duration.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Normally we use a hog per CPU to ensure that the system is fully
loaded to see how much latency we cause. For simple sanitychecking, allow
ourselves to limit it to just one CPU hog.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Extend the i915 load to (optionally) pass a write hazard between
engines, causing us to wait on the interrupt between engines. Thus
adding MI_USER_INTERRUPT irq handling to our list of sins.
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>
|
|
This patch gets rid of the Android support, deleting all the hacks and
moving code around to the places it belongs.
Android build is not really maintained properly and rots rather fast.
With recent push for Meson here and Android going for Soong it will only
accelerate.
It's a good time to drop the illusion of providing any support.
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Kalyan Kondapally <kalyan.kondapally@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
|
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
We are, the build system takes care of that.
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Lots of test cases are re-declaring this.
v2: Remove definition in benchmarks/gem_syslatency.c
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
|
|
Android defines __USE_GNU but does not provide pthread_attr_setaffinity_np()
so added an extra guard arround pthread_attr_setaffinity_np().
Signed-off-by: Derek Morton <derek.j.morton@intel.com>
|
|
Only if the trial __gem_execbuf reports an error do we want to remove
the fancy LUT flags.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
pthread_setaffinity_np is a GNU extensions, so add some __USE_GNU
ifdeffry and hope for the best if unavailable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Since clock_gettime() should be a fixed overhead that adds to the
latency result, subtract it from the result.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In order to keep the latency as low as possible for the idle load, we
need to keep the CPU awake. Otherwise we end up with the busy workload
having lower latency than the idle workload!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Also useful to know how much worse than baseline the latency is when the
gem load is applied. For slower systems, presenting in nanoseconds makes
it hard to read, so switch to microseconds for output.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Instead of measuring the wakeup latency of a GEM client, we turn the
tables here and ask what is the wakeup latency of a normal process
competing with GEM. In particular, a realtime process that expects
deterministic latency.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
