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