testdisplay.c:117:1: warning: comparison between signed and unsigned
integer expressions
testdisplay.c:125:1: warning: comparison between signed and unsigned
integer expressions
testdisplay.c:145:1: warning: comparison between signed and unsigned
integer expressions
testdisplay.c:1060:16: warning: comparison between signed and unsigned
integer expressions
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Creating a zero-length bo should fail, so check that. Still run
the minimal batchbuffer, but without the zero-length reloc.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Hangs gen3 and simply writes garbage into the unmappable part of
gtt on gen4+, which might cause issues later on.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- now also handles ascii dumps like i915_ringbuffer_data
- getoptified
- totally lazy binary detector
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Using a dummy reloc that doesn't matter to trick the kernel into
synchroizing the rings.
v2: properly apply MI_NOOP workaround to MI_FLUSH_DW and
switch to MI_COND_BATCH_BUFFER_END as a dummy command on the
render ring to avoid PIPE_CONTROL errata.
v3: somebody clever decided that in C, you cound from 1,
i.e. I915_EXEC_RENDER == 1. It works now ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also start to shortly explain testcases with an easily-greppable
header like this:
/*
* Testcase:
*
* [Possible further explanation.]
*
*/
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
MI_*/PIPE_CONTROL writes need to be in DOMAIN_INSTRUCTION, because
that is what mesa uses and I plan to use this to work around a
gen6 ppgtt issue.
Also testing with intentionally b0rked GFX_MODE on my snb shows that
we need to increase the loop counter a bit to reliably hit the tlb
invalidation problem. Test still completes within a few seconds.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Previously, "make check" failed because the main() function was not
defined.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Without this patch, intel_gpu_top will try to get access to the hardware
after running the profiling command in the background. In case such access
fails, the main process quits, but the background one will continue
running.
So let's move this test up, so it is done before we fork.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
This patch adds support for running intel_gpu_top to profile specific
commands. The required command will be carried out in separate process,
and main intel_gpu_top will leave when the child process will exit.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
This patch adds support for non-interactive mode, invoked by running with
'-o output' switch. In this case, no interactive output is being
performed, but the execution statistics are being saved into the output
file.
The output file is generated in both human and gnuplot-readable format.
Unlike interactive mode, where non-supported pipes and non-active
registers are skipped, the content of such pipes and registers is recorded
into the log file to simplify parsing and standardize the list of columns.
Also, unlike interactive mode, the registers are not sorted according to
the usage - this way, their variation over time can be analysed offline.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
the monitoring itself. This way, the first measure will already contain
the difference from the previous value instead of non-initialized value.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
This patch initializes the last_stats[] for registers prior to starting
the monitoring itself. This way, the first measure will already contain
the difference from the previous value instead of non-initialized value.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
This patch adds initial support for non-stdio output, to be used for
non-interactive monitoring.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
second
This patch adds support for getopt, and adds two default parameters to it:
-h to show usage notes; and -s to allow user to define number of samples
to acquire per second.
Manpage documentation is also adjusted accordingly.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
This allows intel_gpu_top to properly account for time spent inside system
calls. Effectively, with previous implementation, intel_gpu_top could
spent longer than 1s between consecutive measures. This attempts to
minimize the extra time spent while polling for data.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Add a couple of simple store dword tests to test memory coherence.
gem_storedw_loop simply executes a batch that continually stores an
incremented value to a target buffer object, checking the results after
each batch completes.
gem_storedw_batches_loop does the same thing, but creates a new command
batch buffer for each iteration, which can exercise the buffer creation
code. This test is based on one from Andrzej Kacprowski from Intel.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
high level summary of the files:
* debug_rdata - get current state from debug registers. Helpful
when developing the debugger, and could serve some purpose in the
future.
* eudb - the debugger itself
* eviction_macro - generate the proper macro to flush the EU render
cache until I get control flow working
* pre_cpp - an evaluating c preprocesser like thing, to be used before
cpp
* sr - the system routine, exception handler which runs on the EU
* test - a very basic test system routine
* debug.h
This app is required for debug features which seem to (undocumented)
reset themselves if/when the GT goes to sleep.
It is also useful for those doing general debugging or profiling from
userspace when they do not wish to have the GT sleep.
v2: made forcewaked more daemon-like
Cc: Chris Wilson <chris@chris-wilson.co.uk>
In other news: We've been missing a unmapping_mapping_range somewhere
in the kernel. But lazy me never came around to digging up the real
cause.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
