[Intel-gfx] [PATCH 57/66] drm/i915: Disallow pin with full ppgtt

[Daniel Vetter]

On Sat, Jun 29, 2013 at 8:44 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Fri, Jun 28, 2013 at 10:43:30PM -0700, Ben Widawsky wrote:
>> On Fri, Jun 28, 2013 at 09:55:27AM +0100, Chris Wilson wrote:
>> > On Thu, Jun 27, 2013 at 04:30:58PM -0700, Ben Widawsky wrote:
>> > > Pin doesn't fit with PPGTT since the interface doesn't allow for the
>> > > context for which we want to pin.
>> >
>> > Nak. Pin still retains it semantics with the gtt and only applies to the
>> > gtt.
>>
>>
>> Here is the error I have on pin. I was trying to debug it previously but
>> got sidetracked. I thought some combo of EXEC_GTT flag and hacks would
>> make it work, but I never finished. Maybe you know offhand what I've
>> messed up, and the right way to fix it?
>>
>> gem_pin: gem_pin.c:84: exec: Assertion `gem_exec[0].offset == offset' failed.
>
> Ok, that is a condition that no longer holds with full ppgtt. Now
> fortunately, userspace that might depend upon that is limited to DRI1
> era machines (at least in the userspace I know about) and we can just
> update the test to understand that pinning and exec are two different
> address spaces.
>
> How do you handle EXEC_OBJECT_NEEDS_GTT? As that may be an acceptable
> w/a. Or just skip that portion of the test if PRAM_HAS_FULL_PPGTT. Soft
> pinning should be tested separately (so that it isn't confused with
> pinning to the ggtt), but that is also a viable solution to this portion
> of the test.

NEEDS_GTT is only valid where we alias the global GTT and PPGTT (i.e.
snb). So I think we should reject it on other platforms (or silently
ignore it if userspace uses it already).

Now since we've had a few funny bugs in this area already which proved
to be rather hard to track down I think it's time to implement the
relevant igt tests. The (currently only internal) i-g-t wiki has some
information about what exactly blows up and what I think should be
tested. I think it'd be a good requirement to block the real ppgtt
enabling (not all the vma prep patches) until that test is ready.

On that topic: Do we have other gaps in our testing, or is the current
igt coverage sufficient for this massive refactoring? Ben, has
anything blown up while you've developed these patches which was not
caught by i-g-t?

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch