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.