| Age | Commit message (Collapse) | Author |
|---|
|
The _block postfix meant to convey that a C statement/block must
follow can be misread as the verb to block. So drop it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Doesn't do more than an if (drmtest_run_test(name)) right now, but
as soon as we get a bit of infrastructure to handle test failures and
skipping, this will get more interesting.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Let's start by a small set of tests, to eventually consider running
more.
The current list should then be:
gem_mmap
gem_pread_after_blit
gem_ring_sync_loop
gem_ctx_basic
gem_pipe_control_store_loop
gem_storedw_loop_render
gem_storedw_loop_blt
gem_storedw_loop_bsd
gem_render_linear_blits
gem_tiled_blits
gem_cpu_reloc
gem_exec_nop
gem_mmap_gtt
v2 add (Daniel Vetter)
gem_exec_bad_domains
gem_exec_faulting_reloc
gem_flink
gem_reg_read
gem_reloc_overflow
gem_tiling_max_stride
prime_*
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
|
|
Otherwise we won't update all the tests if we add new render
copyfuncs.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
|
|
This thing takes ages on older chips.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Double-include ftl and local variable shadowing. While fixing the
later I've noticed that we mix up width and height in the blt copy
function.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
On SandyBridge, the BLT commands were split from the RENDER commands as
well as the BSD split inherited from Ironlake. So we need to make sure
we do exercise each ring, and in order to do so we also need to make
sure each batch takes longer to execute than it takes for us to
submit it.
v2: Exercise each ring sequentially.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
I was looking into some strange behavior in Mesa that looks like
batches maybe being skipped, but this test didn't catch it.
|
|
Depends on libdrm 057fab3382c02af54126ce395c43d4e6dce9439a
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31123
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A few of the tools can be performed post-mortem from a different system,
so it is useful to be able to compile those tools on those foreign
systems. Obviously, any program to interact with the PCI device or talk
to GEM will fail on a non-Intel system.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Did this while trying to debug the Ubuntu DRI1+compiz issue. Didn't succeed
in filling the ring.
|
