1. 18 1月, 2017 3 次提交
  2. 12 1月, 2017 1 次提交
  3. 10 1月, 2017 2 次提交
  4. 05 1月, 2017 1 次提交
  5. 24 12月, 2016 1 次提交
  6. 08 12月, 2016 2 次提交
  7. 07 12月, 2016 2 次提交
  8. 02 12月, 2016 9 次提交
  9. 01 12月, 2016 2 次提交
  10. 26 11月, 2016 1 次提交
  11. 25 11月, 2016 1 次提交
  12. 23 11月, 2016 1 次提交
  13. 22 11月, 2016 2 次提交
    • R
      drm/i915: advertise available metrics via sysfs · 442b8c06
      Robert Bragg 提交于
      Each metric set is given a sysfs entry like:
      
      /sys/class/drm/card0/metrics/<guid>/id
      
      This allows userspace to enumerate the specific sets that are available
      for the current system. The 'id' file contains an unsigned integer that
      can be used to open the associated metric set via
      DRM_IOCTL_I915_PERF_OPEN. The <guid> is a globally unique ID for a
      specific OA unit register configuration that can be reliably used by
      userspace as a key to lookup corresponding counter meta data and
      normalization equations.
      
      The guid registry is currently maintained as part of gputop along with
      the XML metric set descriptions and code generation scripts, ref:
      
       https://github.com/rib/gputop
       > gputop-data/guids.xml
       > scripts/update-guids.py
       > gputop-data/oa-*.xml
       > scripts/i915-perf-kernelgen.py
      
       $ make -C gputop-data -f Makefile.xml SYSFS=1 WHITELIST=RenderBasic
      Signed-off-by: NRobert Bragg <robert@sixbynine.org>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Reviewed-by: NSourab Gupta <sourab.gupta@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-8-robert@sixbynine.org
      442b8c06
    • R
      drm/i915: Add i915 perf infrastructure · eec688e1
      Robert Bragg 提交于
      Adds base i915 perf infrastructure for Gen performance metrics.
      
      This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
      properties to configure a stream of metrics and returns a new fd usable
      with standard VFS system calls including read() to read typed and sized
      records; ioctl() to enable or disable capture and poll() to wait for
      data.
      
      A stream is opened something like:
      
        uint64_t properties[] = {
            /* Single context sampling */
            DRM_I915_PERF_PROP_CTX_HANDLE,        ctx_handle,
      
            /* Include OA reports in samples */
            DRM_I915_PERF_PROP_SAMPLE_OA,         true,
      
            /* OA unit configuration */
            DRM_I915_PERF_PROP_OA_METRICS_SET,    metrics_set_id,
            DRM_I915_PERF_PROP_OA_FORMAT,         report_format,
            DRM_I915_PERF_PROP_OA_EXPONENT,       period_exponent,
         };
         struct drm_i915_perf_open_param parm = {
            .flags = I915_PERF_FLAG_FD_CLOEXEC |
                     I915_PERF_FLAG_FD_NONBLOCK |
                     I915_PERF_FLAG_DISABLED,
            .properties_ptr = (uint64_t)properties,
            .num_properties = sizeof(properties) / 16,
         };
         int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, &param);
      
      Records read all start with a common { type, size } header with
      DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
      contain an extensible number of fields and it's the
      DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
      determine what's included in every sample.
      
      No specific streams are supported yet so any attempt to open a stream
      will return an error.
      
      v2:
          use i915_gem_context_get() - Chris Wilson
      v3:
          update read() interface to avoid passing state struct - Chris Wilson
          fix some rebase fallout, with i915-perf init/deinit
      v4:
          s/DRM_IORW/DRM_IOW/ - Emil Velikov
      Signed-off-by: NRobert Bragg <robert@sixbynine.org>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Reviewed-by: NSourab Gupta <sourab.gupta@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
      eec688e1
  14. 17 11月, 2016 3 次提交
  15. 15 11月, 2016 1 次提交
  16. 14 11月, 2016 1 次提交
  17. 11 11月, 2016 2 次提交
  18. 05 11月, 2016 2 次提交
    • L
      drm/i915: Reinit polling before hpd when resuming · e0b70061
      Lyude 提交于
      Now that we don't run the connector reprobing from i915_drm_resume(), we
      need to make it so we don't have to wait for reprobing to finish so that
      we actually speed things up. In order to do this, we need to make sure
      that i915_drm_resume() doesn't get blocked by i915_hpd_poll_init_work()
      while trying to acquire the mode_config lock that
      drm_kms_helper_poll_enable() needs to acquire.
      
      The easiest way to do this is to just enable polling before hpd. This
      shouldn't break anything since at that point we have everything else we
      need for polling enabled.
      
      As well, this should result in a rather significant improvement in how
      quickly we can resume the system.
      Signed-off-by: NLyude <lyude@redhat.com>
      Tested-by: NDavid Weinehall <david.weinehall@linux.intel.com>
      Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
      Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915
      e0b70061
    • L
      drm/i915: Remove redundant reprobe in i915_drm_resume · f97f1936
      Lyude 提交于
      Weine's investigation on benchmarking the suspend/resume process pointed
      out a lot of the time in suspend/resume is being spent reprobing. While
      the reprobing process is a lengthy one for good reason, we don't need to
      hold up the entire suspend/resume process while we wait for it to
      finish. Luckily as it turns out, we already trigger a full connector
      reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
      i915_drm_resume() entirely.
      
      This won't lead to less time spent resuming just yet since now the
      bottleneck will be waiting for the mode_config lock in
      drm_kms_helper_poll_enable(), since that will be held as long as
      i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
      address that in the next patch.
      Signed-off-by: NLyude <lyude@redhat.com>
      Tested-by: NDavid Weinehall <david.weinehall@linux.intel.com>
      Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
      Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915
      f97f1936
  19. 02 11月, 2016 2 次提交
  20. 01 11月, 2016 1 次提交