From: sourab gupta <sourab.gupta@intel.com>
To: Robert Bragg <robert@sixbynine.org>
Cc: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
David Airlie <airlied@linux.ie>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Vetter, Daniel" <daniel.vetter@intel.com>
Subject: Re: [PATCH v8 05/12] drm/i915: don't whitelist oacontrol in cmd parser
Date: Fri, 04 Nov 2016 14:47:01 +0530 [thread overview]
Message-ID: <1478251021.18863.20.camel@sourab-desktop> (raw)
In-Reply-To: <20161028021430.2177-6-robert@sixbynine.org>
On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> Being able to program OACONTROL from a non-privileged batch buffer is
> not sufficient to be able to configure the OA unit. This was originally
> allowed to help enable Mesa to expose OA counters via the
> INTEL_performance_query extension, but the current implementation based
> on programming OACONTROL via a batch buffer isn't able to report useable
> data without a more complete OA unit configuration. Mesa handles the
> possibility that writes to OACONTROL may not be allowed and so only
> advertises the extension after explicitly testing that a write to
> OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
> should be ok for userspace.
>
> Removing this simplifies adding a new kernel api for configuring the OA
> unit without needing to consider the possibility that userspace might
> trample on OACONTROL state which we'd like to start managing within
> the kernel instead. In particular running any Mesa based GL application
> currently results in clearing OACONTROL when initializing which would
> disable the capturing of metrics.
>
> Signed-off-by: Robert Bragg <robert@sixbynine.org>
> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Seems reasonable.
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-11-04 9:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-28 2:14 [PATCH v8 00/12] Enable i915 perf stream for Haswell OA unit Robert Bragg
2016-10-28 2:14 ` [PATCH v8 01/12] ctx-pin placeholder from chris Robert Bragg
2016-10-28 2:14 ` [PATCH v8 02/12] drm/i915: Add i915 perf infrastructure Robert Bragg
2016-10-28 14:27 ` Matthew Auld
2016-10-31 16:27 ` Robert Bragg
2016-10-31 17:13 ` Matthew Auld
2016-10-31 18:54 ` Robert Bragg
2016-11-04 8:59 ` sourab gupta
2016-11-04 13:19 ` Robert Bragg
2016-11-07 8:40 ` sourab gupta
2016-10-28 2:14 ` [PATCH v8 03/12] drm/i915: rename OACONTROL GEN7_OACONTROL Robert Bragg
2016-11-02 6:35 ` sourab gupta
2016-10-28 2:14 ` [PATCH v8 04/12] drm/i915: return EACCES for check_cmd() failures Robert Bragg
2016-11-04 5:18 ` sourab gupta
2016-10-28 2:14 ` [PATCH v8 05/12] drm/i915: don't whitelist oacontrol in cmd parser Robert Bragg
2016-11-04 9:17 ` sourab gupta [this message]
2016-10-28 2:14 ` [PATCH v8 06/12] drm/i915: Add 'render basic' Haswell OA unit config Robert Bragg
2016-10-28 2:14 ` [PATCH v8 07/12] drm/i915: Enable i915 perf stream for Haswell OA unit Robert Bragg
2016-10-31 21:44 ` Matthew Auld
2016-10-28 2:14 ` [PATCH v8 08/12] drm/i915: advertise available metrics via sysfs Robert Bragg
2016-11-04 9:01 ` sourab gupta
2016-10-28 2:14 ` [PATCH v8 09/12] drm/i915: Add dev.i915.perf_stream_paranoid sysctl option Robert Bragg
2016-11-04 9:06 ` sourab gupta
2016-10-28 2:14 ` [PATCH v8 10/12] drm/i915: add oa_event_min_timer_exponent sysctl Robert Bragg
2016-11-02 6:29 ` sourab gupta
2016-11-04 0:58 ` Robert Bragg
2016-10-28 2:14 ` [PATCH v8 11/12] drm/i915: Add more Haswell OA metric sets Robert Bragg
2016-11-01 14:57 ` Chris Wilson
2016-11-01 16:53 ` Robert Bragg
2016-10-28 2:14 ` [PATCH v8 12/12] drm/i915: Add a kerneldoc summary for i915_perf.c Robert Bragg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1478251021.18863.20.camel@sourab-desktop \
--to=sourab.gupta@intel.com \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=robert@sixbynine.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).