Ah, something I forgot to highlight in the cover letter is an issue with
the "drm/i915: don't whitelist oacontrol in cmd parser" patch in this
series...

I was hoping that I could get away with this without breaking any existing
userspace, since the only userspace I know that attempts to configure
OACONTROL via LRIs is Mesa which attempts to verify that it can
successfully write to OACONTROL before exposing its current
INTEL_performance_query implementation, and it seems like it should
gracefully handle a failure here as if the command parser where disabled.

Something curious here is that this patch seemed to work as expected when
my series was recently based on a v4.5 kernel, but since rebasing last week
on a couple of different recent nightlies I'm now seeing gnome-shell
failing to run.

Incidentally, entirely disabling the command parser seems to work; but
removing just OACONTROL seems to cause trouble.

Hopefully I can get a better understanding of what's going on here, though
I can at least confirm the problem is triggered via the
intel_extensions.c:can_write_oacontrol() check in Mesa. Bypassing this
check (with a true or false status) is enough to get gnome-shell running
again.

This could be a fiddly compatibility issue if it turns out to not be
possible to remove OACONTROL from the cmd parser white list. One basic
problem that stems from here is that whenever a GL application starts and
this OACONTROL check is done it ends up resetting OACONTROL to zero which
disables the OA unit which may be in use via the i915 perf interface.

Regards,
- Robert


On Wed, Apr 20, 2016 at 3:23 PM, Robert Bragg <rob...@sixbynine.org> wrote:

> I've been working on some i-g-t tests for this new interface and while I
> still
> have some more tests to write, it still seemed worth sending out another
> updated
> series in the mean time.
>
>
> Firstly this includes updates based on Emil's previous comments.
>
> Then there have been a few issue hit while writing tests:
>
> * It seems it can take a fairly long time for the MUX config to apply after
>   the register writes have finished, and now the driver inserts a delay
> after
>   configuration, before enabling periodic sampling.
> * I've found that sometimes the HW tail pointer can get ahead of OA buffer
>   writes, especially with higher sampling frequencies, and so now the
> driver
>   maintains a margin behind the HW tail pointer to ensure the most recent
>   reports have some time to land before attempting to copy them to
> userspace.
> * As a sanity check that a report is valid before it's copied to userspace
> the
>   driver checks the report-id field != 0
> * The _BUFFER_OVERFLOW record has been replaced with a _BUFFER_LOST record
> with
>   more specific semantics.
> * Since we can't clear the overflow status on Haswell while periodic
> sampling
>   is enabled, if an overflow occurs we now restart the unit.
> * The maximum OA periodic sampling exponent is now 31
> * We verify the head/tail pointers read back from HW look sane before
> using as
>   offsets to read reports from the OA buffer. We reset the HW if they look
> bad.
>
>
> For reference the work-in-progress i-g-t tests can be found here:
>
> https://github.com/rib/intel-gpu-tools
> branch = wip/rib/i915-perf-tests
>
> or browsed here:
> https://github.com/rib/intel-gpu-tools/commits/wip/rib/i915-perf-tests
>
> Also for reference these patches can be fetched from here:
>
> https://github.com/rib/linux
> branch = wip/rib/oa-2016-04-19-nightly
>
> Regards,
> - Robert
>
>
> Robert Bragg (9):
>   drm/i915: Add i915 perf infrastructure
>   drm/i915: rename OACONTROL GEN7_OACONTROL
>   drm/i915: don't whitelist oacontrol in cmd parser
>   drm/i915: Add 'render basic' Haswell OA unit config
>   drm/i915: Enable i915 perf stream for Haswell OA unit
>   drm/i915: advertise available metrics via sysfs
>   drm/i915: Add dev.i915.perf_event_paranoid sysctl option
>   drm/i915: add oa_event_min_timer_exponent sysctl
>   drm/i915: Add more Haswell OA metric sets
>
>  drivers/gpu/drm/i915/Makefile           |    4 +
>  drivers/gpu/drm/i915/i915_cmd_parser.c  |   33 +-
>  drivers/gpu/drm/i915/i915_dma.c         |    8 +
>  drivers/gpu/drm/i915/i915_drv.h         |  155 ++++
>  drivers/gpu/drm/i915/i915_gem_context.c |   24 +-
>  drivers/gpu/drm/i915/i915_oa_hsw.c      |  658 ++++++++++++++
>  drivers/gpu/drm/i915/i915_oa_hsw.h      |   38 +
>  drivers/gpu/drm/i915/i915_perf.c        | 1439
> +++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/i915_reg.h         |  340 +++++++-
>  include/uapi/drm/i915_drm.h             |  133 +++
>  10 files changed, 2795 insertions(+), 37 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
>  create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h
>  create mode 100644 drivers/gpu/drm/i915/i915_perf.c
>
> --
> 2.7.1
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to