[Intel-gfx] [PATCH 1/3] tests/gem_userptr_blits: Expanded userptr test cases

[Tvrtko Ursulin]

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 at intel.com>
>>
>> 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 at intel.com>
>> ---
>> +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