1. 10 Jul, 2020 2 commits
    • Chris Wilson's avatar
      i915/gem_close: Adapt to allow duplicate handles · 6c008a2f
      Chris Wilson authored
      With an upcoming change, we can relax the rule about handles not being
      duplicated in the execocbj[]. Duplicate handles must not otherwise
      conflict in their placements (e.g. two EXEC_OBJECT_PINNED at different
      offsets), but otherwise if they are able to be resolved to the same GPU
      address, then the operation is harmless and decreed legal.
      
      Since this is a relaxation in the negative ABI, update the test case to
      allow the permissible duplicate handles.
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Tvrtko Ursulin's avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      6c008a2f
    • Stanislav Lisovskiy's avatar
      igt/tests: Clear pipes properly in kms_atomic_transition · bc81be69
      Stanislav Lisovskiy authored
      There is an issue happening from time to time in kms_atomic_transition
      (bug #1918). We periodically get assertion that some two outputs
      attempt to use same pipe like this:
      
      "Failed assertion: output->pending_pipe != b->pending_pipe"
      
      After some investigation came to conclusion that this is happening
      because we are calling igt_output_set_pipe(output, PIPE_NONE) only
      for connected outputs, which is wrong.
      Periodically igt_display_refresh/igt_output_refresh call calls can
      update the output state to disconnected. However that doesn't clear
      the pipe being assigned(i.e output->pending_pipe).
      So this causes assertion to be triggered on next igt_display_refresh
      called during commit.
      
      Bugzilla: intel#1918
      
      v2: - Do not use for_each_valid_output_on_pipe as it also iterates
            only on connected outputs(Maarten)
          - Also fix run_modeset_tests function
      Signed-off-by: Stanislav Lisovskiy's avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      bc81be69
  2. 08 Jul, 2020 4 commits
  3. 07 Jul, 2020 1 commit
  4. 06 Jul, 2020 7 commits
  5. 03 Jul, 2020 4 commits
  6. 02 Jul, 2020 2 commits
  7. 01 Jul, 2020 1 commit
    • Chris Wilson's avatar
      i915/gem_close_race: Mix in a contexts and a small delay to closure · 54731f01
      Chris Wilson authored
      Keep the old handles in a small ring so that we build up a small amount
      of pressure for i915_gem_close_object() and throw in a few concurrent
      contexts so we have to process an obj->lut_list containing more than one
      element. And to make sure the list is truly long enough to schedule,
      start leaking the contexts.
      
      Note that the only correctness check is that the selfcopy doesn't
      explode; the challenge would be to prove that the old handles are no
      longer accessible via the execbuf lut. However, this is sufficient to
      make sure we at least hit the interruptible spinlock used by
      close-objects.
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michael J. Ruhl <michael.j.ruhl@intel.com>
      Reviewed-by: default avatarMichael J. Ruhl <michael.j.ruhl@intel.com>
      54731f01
  8. 26 Jun, 2020 3 commits
  9. 23 Jun, 2020 1 commit
  10. 22 Jun, 2020 5 commits
  11. 19 Jun, 2020 10 commits