1. 28 10月, 2010 11 次提交
    • D
      drm/i915: use the complete gtt · 53984635
      Daniel Vetter 提交于
      At least the part that's currently enabled by the BIOS.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      53984635
    • D
      drm/i915: unbind unmappable objects on fault/pin · 16e809ac
      Daniel Vetter 提交于
      In i915_gem_object_pin obviously unbind only if mappable is true.
      
      This is the last part to enable gtt_mappable_end != gtt_size, which
      the next patch will do.
      
      v2: Fences on g33/pineview only work in the mappable part of the
      gtt.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      16e809ac
    • D
      drm/i915: range-restricted bind_to_gtt · 920afa77
      Daniel Vetter 提交于
      Like before add a parameter mappable (also to gem_object_pin) and
      set it depending upon the context. Only bos that are brought into
      the gtt due to an execbuffer call can be put into the unmappable
      part of the gtt, everything else (especially pinned objects) need
      to be put into the mappable part of the gtt.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      920afa77
    • D
      drm/i915: range-restricted eviction support · a6e0aa42
      Daniel Vetter 提交于
      Add a mappable parameter to i915_gem_evict_something to distinguish
      the two cases (non-restricted vs. mappable gtt allocations). No
      functional changes because the mappable limit is set to the end of
      the gtt currently.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      a6e0aa42
    • D
    • C
      3cce469c
    • C
      b2223497
    • C
      drm/i915/debugfs: Include info for the other rings · c2c347a9
      Chris Wilson 提交于
      The render ring is not alone any more! And the other rings are just as
      troublesome...
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      c2c347a9
    • C
      drm/i915: Fix hangcheck to handle multiple rings · 893eead0
      Chris Wilson 提交于
      Currently, we believe the GPU is idle if just the RENDER ring is idle.
      This is obviously wrong if we only using either the BLT or the BSD
      rings and so masking genuine hangs.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      893eead0
    • C
      drm/i915: Move object to GPU domains after dispatching execbuffer · 7e318e18
      Chris Wilson 提交于
      In the event that we fail to dispatch the execbuffer, for example if
      there is insufficient space on the ring, we were leaving the objects in
      an inconsistent state. Notably they were marked as being in the GPU
      write domain, but were not added to the ring or any list. This would
      lead to inevitable oops:
      
      [ 1010.522940] [drm:i915_gem_do_execbuffer] *ERROR* dispatch failed -16
      [ 1010.523055] BUG: unable to handle kernel NULL pointer dereference at
      0000000000000088
      [ 1010.523097] IP: [<ffffffff8122d006>] i915_gem_flush_ring+0x26/0x140
      [ 1010.523120] PGD 14cf2f067 PUD 14ce04067 PMD 0
      [ 1010.523140] Oops: 0000 [#1] SMP
      [ 1010.523154] last sysfs file: /sys/devices/virtual/vc/vcsa2/uevent
      [ 1010.523173] CPU 0
      [ 1010.523183] Pid: 716, comm: X Not tainted 2.6.36+ #34 LosLunas
      CRB/SandyBridge Platform
      [ 1010.523206] RIP: 0010:[<ffffffff8122d006>]  [<ffffffff8122d006>]
      i915_gem_flush_ring+0x26/0x140
      [ 1010.523233] RSP: 0018:ffff88014bf97cd8  EFLAGS: 00010296
      [ 1010.523249] RAX: ffff88014e2d1808 RBX: 0000000000000000 RCX: 0000000000000000
      [ 1010.523270] RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
      [ 1010.523290] RBP: ffff88014e2d1000 R08: 0000000000000002 R09: 00000000400c645f
      [ 1010.523311] R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000002
      [ 1010.523331] R13: ffff88014e29a000 R14: 00000000000000c8 R15: ffffffff8162eb28
      [ 1010.523352] FS:  00007fc62379d700(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
      [ 1010.523375] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1010.523392] CR2: 0000000000000088 CR3: 000000014bf87000 CR4: 00000000000406f0
      [ 1010.523412] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 1010.523433] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [ 1010.523454] Process X (pid: 716, threadinfo ffff88014bf96000, task ffff88014cc1ee40)
      [ 1010.523475] Stack:
      [ 1010.523483]  ffff88014d5199c0 0000000000000200 0000000000000000 ffff88014bcc6400
      [ 1010.523509] <0> 0000000000000000 0000000000000001 ffff88014e29a000 ffff88014bcc6400
      [ 1010.523537] <0> ffffffff8162eb28 ffffffff8122faa8 ffff88014e29a000 ffff88014bcc6400
      [ 1010.523568] Call Trace:
      [ 1010.523578]  [<ffffffff8122faa8>] ?  i915_gem_object_flush_gpu_write_domain+0x48/0x80
      [ 1010.523601]  [<ffffffff8122fb8e>] ?  i915_gem_object_set_to_gtt_domain+0x2e/0xb0
      [ 1010.523623]  [<ffffffff8123113b>] ?  i915_gem_set_domain_ioctl+0xdb/0x1f0
      [ 1010.523644]  [<ffffffff8120a3f1>] ? drm_ioctl+0x3d1/0x460
      [ 1010.523660]  [<ffffffff81231060>] ?  i915_gem_set_domain_ioctl+0x0/0x1f0
      [ 1010.523682]  [<ffffffff81092618>] ?  vma_prio_tree_insert+0x28/0x120
      [ 1010.523701]  [<ffffffff8109f379>] ? vma_link+0x99/0xf0
      [ 1010.523717]  [<ffffffff810a111d>] ? mmap_region+0x1ed/0x4f0
      [ 1010.523734]  [<ffffffff810c306f>] ? do_vfs_ioctl+0x9f/0x580
      [ 1010.523750]  [<ffffffff810c3599>] ? sys_ioctl+0x49/0x80
      [ 1010.523767]  [<ffffffff810022eb>] ?  system_call_fastpath+0x16/0x1b
      [ 1010.523785] Code: 00 00 00 00 00 41 57 89 ce 41 56 41 55 41 54 45 89 c4 55 48 89 fd 53 48 89 d3 44 89 c2 48 89 df 4c 8d b3 c8 00 00 00 48 83 ec 18 <ff> 93 88 00 00 00 48 8b 83 c8 00 00 00 4c 8b bd 30 03 00 00 48
      [ 1010.523946] RIP  [<ffffffff8122d006>] i915_gem_flush_ring+0x26/0x140
      [ 1010.523966]  RSP <ffff88014bf97cd8>
      [ 1010.523977] CR2: 0000000000000088
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      7e318e18
    • C
      drm/i915: Propagate errors from writing to ringbuffer · e1f99ce6
      Chris Wilson 提交于
      Preparing the ringbuffer for adding new commands can fail (a timeout
      whilst waiting for the GPU to catch up and free some space). So check
      for any potential error before overwriting HEAD with new commands, and
      propagate that error back to the user where possible.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      e1f99ce6
  2. 27 10月, 2010 29 次提交