All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Widawsky <ben@bwidawsk.net>
To: Intel GFX <intel-gfx@lists.freedesktop.org>,
	mesa-dev <mesa-dev@lists.freedesktop.org>
Cc: Ben Widawsky <ben@bwidawsk.net>,
	Ben Widawsky <benjamin.widawsky@intel.com>
Subject: [PATCH 0/3] MOCS versioning
Date: Thu,  6 Jul 2017 16:27:00 -0700	[thread overview]
Message-ID: <20170706232703.14229-1-ben@bwidawsk.net> (raw)

Copying the kernel commit message:

Starting with GEN9, Memory Object Control State (MOCS) becomes an index
into a table as opposed to the direct programming within the command.
The table has 62 usable entries (ie 6 bits can represent all settings),
and each buffer type may use one of these 62 entries to describe
cacheability type, and age (and some other less useful fields).

Because we hadn't dealt with MOCS settings like this, we didn't think
ahead too well and have ended up with a mess for GEN9 (and soon GEN10)
platform. The plan for for future platforms is that the ideal MOCS
settings will be determined, defined, and written in the public PRMs.
After this point, the i915.ko will absorb these settings and sometime
afterwards flip the alpha switch. All driver releases without the final
MOCS table must be considered alpha. Here on, userspace can assume the
MOCS table is definitively done. There will be some reserved entries for
'oh shit' scenarios. This avoids versioning the MOCS table which leaves
somewhat of a mess in userspace trying to handle arbitrarily many MOCS
versions.

But we do have a mess on GEN9. In the beginning, the MOCS table entries
were pre-populated by the hardware based on estimations made prior to
tapeout and we could just use that. Subsequently much performance tuning
was done to determine optimal settings that the i915 driver should load
on top of the hardware defaults. That was posted last as v6 of the
original per-engine MOCS settings:
https://patchwork.freedesktop.org/patch/53237/. Since the MOCS table is
not context saved/restored, it isn't feasible to let userspace upload
its own MOCS table. After a good amount of debate, it was decided that
we'd utilize only the minimal set of entires in mesa anyway, and so we
took only those entries for our MOCS entries.

Now we've come to the realization that indeed there are other MOCS
entries which are more optimal for various buffer types and workloads.
The problem is that the meaning of the indices is ABI (we assume index 0
is the uncached entry, and that there are only 3 entries total).

What this patch [simply] aims to do is expose a parameter to inform
userspace which "version" of the table was loaded by i915. Upon
sufficient data, new entries can be added, and the version can be
bumped. For example, from my original mesa mocs branch:

commit c9b0481bce24af032386701de0266eb5bc24e988
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Fri Apr 8 10:21:16 2016 -0700

    i965: Use PTE mocs

    Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>

diff --git a/src/mesa/drivers/dri/i965/brw_mocs.c b/src/mesa/drivers/dri/i965/brw_mocs.c
index 5df154eb86..b7bfdab671 100644
--- a/src/mesa/drivers/dri/i965/brw_mocs.c
+++ b/src/mesa/drivers/dri/i965/brw_mocs.c
@@ -14,6 +14,9 @@
 /* Skylake: MOCS is now an index into an array of 62 different caching
  * configurations programmed by the kernel.
  */
+
+/* TC=PTE, LeCC=PTE, LRUM=3, L3CC=WB */
+#define SKL_MOCS_PTE_PTE (3 << 1)
 /* TC=LLC/eLLC, LeCC=WB, LRUM=3, L3CC=WB */
 #define SKL_MOCS_WB  (2 << 1)
 /* TC=LLC/eLLC, LeCC=PTE, LRUM=3, L3CC=WB */
@@ -26,6 +29,9 @@ brw_mocs_get_control_state(const struct brw_context *brw,
    switch (brw->gen) {
    default:
    case 9:
+      if (brw->intelScreen->mocs_version > 1)
+         return SKL_MOCS_PTE_PTE;
+
       return type == INTEL_MOCS_PTE ? SKL_MOCS_PTE : SKL_MOCS_WB;
    case 8:
       return type == INTEL_MOCS_PTE ? BDW_MOCS_PTE : BDW_MOCS_WB;

tl;dr: A versioned MOCS table will allow userspace to be aware of new
and potentially interesting cacheability settings. Next GEN platforms
will not be considered production worthy until the MOCS table is
finalized.

Ben Widawsky (1):
  drm/i915: Version the MOCS settings

 drivers/gpu/drm/i915/i915_drv.c |  3 +++
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_pci.c | 13 +++++++++----
 include/uapi/drm/i915_drm.h     |  8 ++++++++
 4 files changed, 22 insertions(+), 4 deletions(-)

Ben Widawsky (2):
  intel: Merge latest i915 uapi
  intel: Make driver aware of MOCS table version

 src/intel/drm/i915_drm.h                  |  8 ++++++++
 src/intel/vulkan/anv_device.c             | 12 ++++++++++++
 src/intel/vulkan/anv_private.h            |  2 ++
 src/mesa/drivers/dri/i915/intel_context.c |  7 ++++++-
 src/mesa/drivers/dri/i965/intel_screen.c  | 14 ++++++++++++++
 src/mesa/drivers/dri/i965/intel_screen.h  |  2 ++
 6 files changed, 44 insertions(+), 1 deletion(-)

-- 
2.13.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

             reply	other threads:[~2017-07-06 23:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-06 23:27 Ben Widawsky [this message]
2017-07-06 23:27 ` [PATCH 1/1] drm/i915: Version the MOCS settings Ben Widawsky
2017-07-07 10:34   ` [Intel-gfx] " Chris Wilson
2017-07-07 11:06     ` [Mesa-dev] " Emil Velikov
2017-07-07 16:23     ` Jason Ekstrand
2017-07-07 18:44       ` Ben Widawsky
2017-07-07 18:42     ` Ben Widawsky
2017-07-07 19:42       ` Chris Wilson
2017-07-06 23:27 ` [PATCH 2/3] intel: Merge latest i915 uapi Ben Widawsky
2017-07-06 23:27 ` [PATCH 3/3] intel: Make driver aware of MOCS table version Ben Widawsky
2017-07-07 16:28   ` Jason Ekstrand
2017-07-21  4:24     ` Ben Widawsky

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=20170706232703.14229-1-ben@bwidawsk.net \
    --to=ben@bwidawsk.net \
    --cc=benjamin.widawsky@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mesa-dev@lists.freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.