On 03/05/2014 02:48 PM, Chris Wilson wrote:
On Wed, Feb 26, 2014 at 04:17:43PM +0000, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
A set of userptr test cases to support the new feature.
For the eviction and swapping stress testing I have extracted
some common behaviour from gem_evict_everything and made both
test cases use it to avoid duplicating the code.
Both unsynchronized and synchronized userptr objects are
tested but the latter set of tests will be skipped if kernel
is compiled without MMU_NOTIFIERS.
Also, with 32-bit userspace swapping tests are skipped if
the system has a lot more RAM than process address space.
Forking swapping tests are not skipped since they can still
trigger swapping by cumulative effect.
v2:
* Fixed dmabuf test.
* Added test for rejecting read-only.
* Fixed ioctl detection for latest kernel patch.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
---
+static void
+copy(int fd, uint32_t dst, uint32_t src, unsigned int error)
+{
+ uint32_t batch[10];
+ struct drm_i915_gem_relocation_entry reloc[2];
+ struct drm_i915_gem_exec_object2 obj[3];
+ struct drm_i915_gem_execbuffer2 exec;
+ uint32_t handle;
+ int ret;
+
+ batch[0] = XY_SRC_COPY_BLT_CMD |
+ XY_SRC_COPY_BLT_WRITE_ALPHA |
+ XY_SRC_COPY_BLT_WRITE_RGB | 6;
Hmm, you made blit() bdw-aware, but not this copy() routine?
You give me too much credit, it is all c&p from other tests. :)
As for the rest, I think we have good coverage.
What I would like to see exercised as well is mmap(fd), shm_open() and
sysv shmem.
What do you mean by mmap(fd), what fd?
And for shared memory flavours - you mean just creating userptr objects
from them or something more perverse?
Another thing to test is transfering our device fd over a unix socket to
another process and checking that we can continue to access the memory.
(That should just be the same as forking and continuing to use the
parent fd.)
Not sure I follow - transfer drm fd to a new process and then what?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
