From mboxrd@z Thu Jan 1 00:00:00 1970 From: Francisco Jerez Subject: Re: [PATCH v4] drm/i915 : Added Programming of the MOCS Date: Wed, 01 Jul 2015 18:17:18 +0300 Message-ID: <87k2uj3o1t.fsf@riseup.net> References: <1434554362-22384-1-git-send-email-peter.antoine@intel.com> <87ioact03d.fsf@riseup.net> <878ub13zdi.fsf@riseup.net> <874mlp3vtc.fsf@riseup.net> <87r3os2fl8.fsf@riseup.net> <87mvzf3omo.fsf@riseup.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1474550172==" Return-path: Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by gabe.freedesktop.org (Postfix) with ESMTPS id A6C0472132 for ; Wed, 1 Jul 2015 08:17:33 -0700 (PDT) In-Reply-To: <87mvzf3omo.fsf@riseup.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Peter Antoine Cc: intel-gfx@lists.freedesktop.org, Jesse Barnes , Ben Widawsky List-Id: intel-gfx@lists.freedesktop.org --===============1474550172== Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Francisco Jerez writes: > Peter Antoine writes: > >> On Wed, 1 Jul 2015, Francisco Jerez wrote: >> >>> Peter Antoine writes: >>> >>>> On Tue, 30 Jun 2015, Francisco Jerez wrote: >>>> >>>>> Francisco Jerez writes: >>>>> >>>>>> Peter Antoine writes: >>>>>> >>>>>>> On Mon, 29 Jun 2015, Peter Antoine wrote: >>>>>>> >>>>>>>> On Thu, 25 Jun 2015, Francisco Jerez wrote: >>>>>>>> >>>>>>>>> Peter Antoine writes: >>>>>>>>> >>>>>>>>>> This change adds the programming of the MOCS registers to the ge= n 9+ >>>>>>>>>> platforms. This change set programs the MOCS register values to = a set >>>>>>>>>> of values that are defined to be optimal. >>>>>>>>>> >>>>>>>>>> It creates a fixed register set that is programmed across the di= fferent >>>>>>>>>> engines so that all engines have the same table. This is done as= the >>>>>>>>>> main RCS context only holds the registers for itself and the sha= red >>>>>>>>>> L3 values. By trying to keep the registers consistent across the >>>>>>>>>> different engines it should make the programming for the registe= rs >>>>>>>>>> consistent. >>>>>>>>>> >>>>>>>>>> v2: >>>>>>>>>> -'static const' for private data structures and style changes.(M= att >>>>>>>> Turner) >>>>>>>>>> v3: >>>>>>>>>> - Make the tables "slightly" more readable. (Damien Lespiau) >>>>>>>>>> - Updated tables fix performance regression. >>>>>>>>>> v4: >>>>>>>>>> - Code formatting. (Chris Wilson) >>>>>>>>>> - re-privatised mocs code. (Daniel Vetter) >>>>>>>>>> >>>>>>>>>> Signed-off-by: Peter Antoine >>>>>>>>>> --- >>>>>>>>>> drivers/gpu/drm/i915/Makefile | 1 + >>>>>>>>>> drivers/gpu/drm/i915/i915_reg.h | 9 + >>>>>>>>>> drivers/gpu/drm/i915/intel_lrc.c | 10 +- >>>>>>>>>> drivers/gpu/drm/i915/intel_lrc.h | 4 + >>>>>>>>>> drivers/gpu/drm/i915/intel_mocs.c | 373 >>>>>>>> ++++++++++++++++++++++++++++++++++++++ >>>>>>>>>> drivers/gpu/drm/i915/intel_mocs.h | 64 +++++++ >>>>>>>>>> 6 files changed, 460 insertions(+), 1 deletion(-) >>>>>>>>>> create mode 100644 drivers/gpu/drm/i915/intel_mocs.c >>>>>>>>>> create mode 100644 drivers/gpu/drm/i915/intel_mocs.h >>>>>>>>>> >>>>>>>>>> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i91= 5/Makefile >>>>>>>>>> index b7ddf48..c781e19 100644 >>>>>>>>>> --- a/drivers/gpu/drm/i915/Makefile >>>>>>>>>> +++ b/drivers/gpu/drm/i915/Makefile >>>>>>>>>> @@ -35,6 +35,7 @@ i915-y +=3D i915_cmd_parser.o \ >>>>>>>>>> i915_irq.o \ >>>>>>>>>> i915_trace_points.o \ >>>>>>>>>> intel_lrc.o \ >>>>>>>>>> + intel_mocs.o \ >>>>>>>>>> intel_ringbuffer.o \ >>>>>>>>>> intel_uncore.o >>>>>>>>>> >>>>>>>>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h >>>>>>>> b/drivers/gpu/drm/i915/i915_reg.h >>>>>>>>>> index 7213224..3a435b5 100644 >>>>>>>>>> --- a/drivers/gpu/drm/i915/i915_reg.h >>>>>>>>>> +++ b/drivers/gpu/drm/i915/i915_reg.h >>>>>>>>>> @@ -7829,4 +7829,13 @@ enum skl_disp_power_wells { >>>>>>>>>> #define _PALETTE_A (dev_priv->info.display_mmio_offset + 0xa000) >>>>>>>>>> #define _PALETTE_B (dev_priv->info.display_mmio_offset + 0xa800) >>>>>>>>>> >>>>>>>>>> +/* MOCS (Memory Object Control State) registers */ >>>>>>>>>> +#define GEN9_LNCFCMOCS0 (0xB020) /* L3 Cache Control >>>>>>>> base */ >>>>>>>>>> + >>>>>>>>>> +#define GEN9_GFX_MOCS_0 (0xc800) /* Graphics MOCS base >>>>>>>> register*/ >>>>>>>>>> +#define GEN9_MFX0_MOCS_0 (0xc900) /* Media 0 MOCS base >>>>>>>> register*/ >>>>>>>>>> +#define GEN9_MFX1_MOCS_0 (0xcA00) /* Media 1 MOCS base >>>>>>>> register*/ >>>>>>>>>> +#define GEN9_VEBOX_MOCS_0 (0xcB00) /* Video MOCS base register*/ >>>>>>>>>> +#define GEN9_BLT_MOCS_0 (0xcc00) /* Blitter MOCS base >>>>>>>> register*/ >>>>>>>>>> + >>>>>>>>>> #endif /* _I915_REG_H_ */ >>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c >>>>>>>> b/drivers/gpu/drm/i915/intel_lrc.c >>>>>>>>>> index 9f5485d..73b919d 100644 >>>>>>>>>> --- a/drivers/gpu/drm/i915/intel_lrc.c >>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_lrc.c >>>>>>>>>> @@ -135,6 +135,7 @@ >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> #include "i915_drv.h" >>>>>>>>>> +#include "intel_mocs.h" >>>>>>>>>> >>>>>>>>>> #define GEN9_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE) >>>>>>>>>> #define GEN8_LR_CONTEXT_RENDER_SIZE (20 * PAGE_SIZE) >>>>>>>>>> @@ -796,7 +797,7 @@ static int logical_ring_prepare(struct >>>>>>>> intel_ringbuffer *ringbuf, >>>>>>>>>> * >>>>>>>>>> * Return: non-zero if the ringbuffer is not ready to be writte= n to. >>>>>>>>>> */ >>>>>>>>>> -static int intel_logical_ring_begin(struct intel_ringbuffer *ri= ngbuf, >>>>>>>>>> +int intel_logical_ring_begin(struct intel_ringbuffer *ringbuf, >>>>>>>>>> struct intel_context *ctx, int >>>>>>>> num_dwords) >>>>>>>>>> { >>>>>>>>>> struct intel_engine_cs *ring =3D ringbuf->ring; >>>>>>>>>> @@ -1379,6 +1380,13 @@ static int gen8_init_rcs_context(struct >>>>>>>> intel_engine_cs *ring, >>>>>>>>>> if (ret) >>>>>>>>>> return ret; >>>>>>>>>> >>>>>>>>>> + /* >>>>>>>>>> + * Failing to program the MOCS is non-fatal.The system will not >>>>>>>>>> + * run at peak performance. So generate a warning and carry on. >>>>>>>>>> + */ >>>>>>>>>> + if (gen9_program_mocs(ring, ctx) !=3D 0) >>>>>>>>>> + DRM_ERROR("MOCS failed to program: expect performance >>>>>>>> issues."); >>>>>>>>>> + >>>>>>>>>> return intel_lr_context_render_state_init(ring, ctx); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_lrc.h >>>>>>>> b/drivers/gpu/drm/i915/intel_lrc.h >>>>>>>>>> index 04d3a6d..dbbd6af 100644 >>>>>>>>>> --- a/drivers/gpu/drm/i915/intel_lrc.h >>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_lrc.h >>>>>>>>>> @@ -44,6 +44,10 @@ int intel_logical_rings_init(struct drm_devic= e *dev); >>>>>>>>>> >>>>>>>>>> int logical_ring_flush_all_caches(struct intel_ringbuffer *ring= buf, >>>>>>>>>> struct intel_context *ctx); >>>>>>>>>> + >>>>>>>>>> +int intel_logical_ring_begin(struct intel_ringbuffer *ringbuf, >>>>>>>>>> + struct intel_context *ctx, int >>>>>>>> num_dwords); >>>>>>>>>> + >>>>>>>>>> /** >>>>>>>>>> * intel_logical_ring_advance() - advance the ringbuffer tail >>>>>>>>>> * @ringbuf: Ringbuffer to advance. >>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_mocs.c >>>>>>>> b/drivers/gpu/drm/i915/intel_mocs.c >>>>>>>>>> new file mode 100644 >>>>>>>>>> index 0000000..7c09e67 >>>>>>>>>> --- /dev/null >>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_mocs.c >>>>>>>>>> @@ -0,0 +1,373 @@ >>>>>>>>>> +/* >>>>>>>>>> + * Copyright (c) 2015 Intel Corporation >>>>>>>>>> + * >>>>>>>>>> + * Permission is hereby granted, free of charge, to any person = obtaining >>>>>>>> a >>>>>>>>>> + * copy of this software and associated documentation files (the >>>>>>>> "Software"), >>>>>>>>>> + * to deal in the Software without restriction, including witho= ut >>>>>>>> limitation >>>>>>>>>> + * the rights to use, copy, modify, merge, publish, distribute, >>>>>>>> sublicense, >>>>>>>>>> + * and/or sell copies of the Software, and to permit persons to= whom the >>>>>>>>>> + * Software is furnished to do so, subject to the following con= ditions: * >>>>>>>>>> + * The above copyright notice and this permission notice (inclu= ding the >>>>>>>> next >>>>>>>>>> + * paragraph) shall be included in all copies or substantial po= rtions of >>>>>>>> the >>>>>>>>>> + * Software. >>>>>>>>>> + * >>>>>>>>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KI= ND, >>>>>>>> EXPRESS OR >>>>>>>>>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF >>>>>>>> MERCHANTABILITY, >>>>>>>>>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO= EVENT >>>>>>>> SHALL >>>>>>>>>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DA= MAGES OR >>>>>>>> OTHER >>>>>>>>>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWI= SE, >>>>>>>> ARISING FROM, >>>>>>>>>> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHE= R DEALINGS >>>>>>>> IN THE >>>>>>>>>> + * SOFTWARE. >>>>>>>>>> + * >>>>>>>>>> + * Authors: >>>>>>>>>> + * Peter Antoine >>>>>>>>>> + */ >>>>>>>>>> + >>>>>>>>>> +#include "intel_mocs.h" >>>>>>>>>> +#include "intel_lrc.h" >>>>>>>>>> +#include "intel_ringbuffer.h" >>>>>>>>>> + >>>>>>>>>> +/* structures required */ >>>>>>>>>> +struct drm_i915_mocs_entry { >>>>>>>>>> + u32 control_value; >>>>>>>>>> + u16 l3cc_value; >>>>>>>>>> +}; >>>>>>>>>> + >>>>>>>>>> +struct drm_i915_mocs_table { >>>>>>>>>> + u32 size; >>>>>>>>>> + const struct drm_i915_mocs_entry *table; >>>>>>>>>> +}; >>>>>>>>>> + >>>>>>>>>> +/* Defines for the tables (XXX_MOCS_0 - XXX_MOCS_63) */ >>>>>>>>>> +#define MOCS_CACHEABILITY(value) (value << 0) >>>>>>>>>> +#define MOCS_TGT_CACHE(value) (value << 2) >>>>>>>>>> +#define MOCS_LRUM(value) (value << 4) >>>>>>>>>> +#define MOCS_AOM(value) (value << 6) >>>>>>>>>> +#define MOCS_LECC_ESC(value) (value << 7) >>>>>>>>>> +#define MOCS_LECC_SCC(value) (value << 8) >>>>>>>>>> +#define MOC_PFM(value) (value << 11) >>>>>>>>>> +#define MOCS_SCF(value) (value << 14) >>>>>>>>>> + >>>>>>>>>> +/* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entrie= s per word >>>>>>>> */ >>>>>>>>>> +#define MOCS_ESC(value) (value << 0) >>>>>>>>>> +#define MOCS_SCC(value) (value << 1) >>>>>>>>>> +#define MOCS_L3_CACHEABILITY(value) (value << 4) >>>>>>>>>> + >>>>>>>>>> +/* Helper defines */ >>>>>>>>>> +#define GEN9_NUM_MOCS_RINGS (5) /* Number of mocs engines to pr= ogram >>>>>>>> */ >>>>>>>>>> +#define GEN9_NUM_MOCS_ENTRIES (63) /* 63 out of 64 - 64 is rsvrd >>>>>>>> */ >>>>>>>>>> + >>>>>>>>>> +/* EDRAM Caching options */ >>>>>>>>>> +#define EDRAM_PAGETABLE (0) >>>>>>>>>> +#define EDRAM_UC (1) >>>>>>>>>> +#define EDRAM_RESERVED (2) >>>>>>>>> >>>>>>>>> According to the BSpec this is WT rather than reserved?a >>>>>>>> Just checked the Bspec and you are correct, changing the text. >>>>>>>> As well as for the items below. >>>>>>> Just to add - I was looking at the wrong gen. >>>>>>>>> >>>>>>>>>> +#define EDRAM_WB (3) >>>>>>>>>> + >>>>>>>>>> +/* L3 Caching options */ >>>>>>>>>> +#define L3_DIRECT (0) >>>>>>>>>> +#define L3_UC (1) >>>>>>>>>> +#define L3_RESERVED (2) >>>>>>>>>> +#define L3_WB (3) >>>>>>>>>> + >>>>>>>>>> +/* target cache */ >>>>>>>>>> +#define ELLC (0) >>>>>>>>> >>>>>>>>> BSpec says that this is "Use TC/LRU controls from page table", bu= t upon >>>>>>>>> a closer look it seems like the BSpec is wrong and your patch is >>>>>>>>> correct. Can you confirm that this is what you intended? >>>>>>>> These values look good, they are bits 3:2 for the XXX_MOCS_N regis= ters >>>>>>>> (c800) and friends. >>>>>>>>> >>>>>>>>>> +#define LLC (1) >>>>>>>>>> +#define LLC_ELLC (2) >>>>>>>>>> + >>>>>>>>>> +/* >>>>>>>>>> + * MOCS tables >>>>>>>>>> + * >>>>>>>>>> + * These are the MOCS tables that are programmed across all the= rings. >>>>>>>>>> + * The control value is programmed to all the rings that suppor= t the >>>>>>>>>> + * MOCS registers. While the l3cc_values are only programmed to= the >>>>>>>>>> + * LNCFCMOCS0 - LNCFCMOCS32 registers. >>>>>>>>>> + * >>>>>>>>>> + * NOTE: These tables MUST start with being uncached and the le= ngth MUST >>>>>>>> be >>>>>>>>>> + * less than 63 as the last two registers are reserved by= the >>>>>>>> hardware. >>>>>>>>>> + */ >>>>>>>>>> +static struct drm_i915_mocs_entry skylake_mocs_table[] =3D { >>>>>>>>>> + /* {0x00000009, 0x0010} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(LLC_ELLC) | >>>>>>>>>> + MOCS_LRUM(0) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))}, >>>>>>>>>> + /* {0x0000003b, 0x0030} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC_ELLC) | >>>>>>>>>> + MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_WB))}, >>>>>>>>>> + /* {0x00000039, 0x0010} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(LLC_ELLC) | >>>>>>>>>> + MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))}, >>>>>>>>>> + /* {0x00000017, 0x0030} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) | >>>>>>>>>> + MOCS_LRUM(1) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_WB))}, >>>>>>>>>> + /* {0x00000017, 0x0010} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) | >>>>>>>>>> + MOCS_LRUM(1) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))}, >>>>>>>>>> + /* {0x00000019, 0x0010} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(LLC_ELLC) | >>>>>>>>>> + MOCS_LRUM(1) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))}, >>>>>>>>>> + /* {0x00000037, 0x0030} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) | >>>>>>>>>> + MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_WB))}, >>>>>>>>>> + /* {0x00000037, 0x0010} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) | >>>>>>>>>> + MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))}, >>>>>>>>>> + /* {0x0000003b, 0x0010} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC_ELLC) | >>>>>>>>>> + MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))}, >>>>>>>>>> +}; >>>>>>>>> >>>>>>>>> Mesa will want an additional entry with TC=3DLLC/eLLC, LeCC=3DPTE= , L3CC=3DWB, >>>>>>>>> everything else unset, I'll reply with a userspace patch making u= se of >>>>>>>>> your change if you add such an entry. >>>>>>> Ok. I think what you want is, same as entry two, but use the underl= ying >>>>>>> pagetable settings and not specify the EDRAM settings. Please confi= rm in >>>>>>> the new patchset. >>>>>> >>>>>> Yeah, that sounds good. >>>>>> >>>>>>>>> >>>>>>>>> Another thing worth mentioning is that entries 0, 2 and 5 seem to= do the >>>>>>>>> same thing suspiciously, the only difference is the LRUM field wh= ich >>>>>>>>> AFAIK doesn't have any effect for LeCC=3DUC. Is my understanding= correct? >>>>>>>>> >>>>>>>> These tables are generated via requests and then boiled down to th= e above. >>>>>>>> So some of the entries are by request. Swings and roundabouts, can= remove >>>>>>>> the ones that look redundant but then the tuning that has been don= e wont >>>>>>>> match. I'll add the new entry at the end of the table. >>>>> >>>>> Are you planning to propagate the entry you just added back to the >>>>> original table this was generated from? What about new entries we may >>>>> need to add in the future? What should be the process to make sure t= hat >>>>> our table and the master table don't diverge and end up with conflict= ing >>>>> entries we cannot remove because of ABI compatibility? I guess there >>>>> should be a comment on the top warning that the table is part of the >>>>> kernel ABI and supposed to be kept in sync with your table, so other >>>>> people don't change it unknowingly? >>>>> >>>>> Thanks. >>>> I am talking to the team that handles this and see if they will add th= is >>>> (so future gens this is baked in) but it is unlikely that the other ta= bles >>>> will stay in step as getting in changes will cause too much grief gett= ing >>>> them upstreamed and as the table is auto-generated we will not be able= to >>>> guarantee the ordering. It will have to be manual job for anyone doing >>>> this. It is required for other platforms for the tables to match the >>>> userspace for performance reasons, but on Linux it will be by request = if >>>> there is a problem. We will see what happens. >>>> >>> I think it only makes sense for Linux to maintain compatibility with >>> Android's tables if we agree on some straightforward process for us to >>> allocate new entries without causing conflicts (otherwise people are >>> likely to ignore the issue completely and let the tables diverge, as you >>> mentioned yourself), and have some guarantee that any entries ever >>> contributed by your team to the Linux kernel (and therefore part of our >>> stable ABI) will never be changed or reordered in the future. >>> >> I think internally (and informally) that we cannot keep sync between And= roid >> and Linux. We need to keep compatibility with userspace and there is no >> guarantee of ordering as these tables are generated at runtime. The tabl= es >> that are in Linux are a snapshot. These changes are supposed to stabilis= e at >> PV so they don't change in the future, but if a bug or good performance >> enhancement occurs I can't imagine that they wont make the changes. >> > Right... In that case I believe that if we import the Android driver's > tables now and pretend that we are compatible we will just be delaying > the inevitable. We could just as well start over with clean tables and > save us some unnecessary pain. I propose we start off with the > following minimal table that should be sufficient to suit the current > needs of Mesa, Beignet and the DDX: > > LeCC TC LRUM L3CC > 0: UC LLC_ELLC 3 UC=20=20=20 Oh, the 0-th entry may as well have LRUM=3D0 to match your current tables, it shouldn't make much of a difference for an uncacheable entry anyway AFAIK. > 1: PTE LLC_ELLC 3 WB > 2: WB LLC_ELLC 3 WB > > All other parameters unset. The same three entries would be used in > SKL's and BXT's table to avoid making userspace's life unnecessarily > more difficult. I'd understand if you consider redefining the tables to > be no longer your business, in that case please let me know and I'll > make the change myself as a follow-up on top of your patch. > > Thanks. > >>> I have the impression that because of your development model you have >>> far more freedom to make changes in your kernel ABI after the fact than >>> we do -- OTOH we would be locked in if we accept to import Android's >>> tables now, what brings me to the next question: How would you feel >>> about reversing the roles of our tables? The workflow could be as >>> follows: >> The Android kernel is more flexible, in what it accepts, and secondly (a= nd >> more importantly) you should be using the userspace drivers as this is >> the API and is tuned, so changing the tables are less of a problem. >>> >>> >>> - The MOCS tables part of the Linux kernel would be developed and >>> discussed publicly in this mailing list, independently from your team >>> (which doesn't mean that your contributions and feed-back regarding >>> future changes in the MOCS tables wouldn't be very much welcome). >>> >> This is fine. But be aware the RFC for the MOCS was first floated in Mar= ch and >> teams were directly contacted when this happened and not a lot of respon= se >> was received. MOCS ain't sexy and people only get interested when they >> feel that they maybe a performance problem - then they look to caching. >> >> But, I think this is the sensible model. For the new tables (new gens) a= drop >> from the internal cache models as these will have had some form of tunin= g from >> different teams and requirements (OpenCL, OpenGL, Media, Security, etc..= .) then >> these can be discussed on the mailing list as required. >> >> I am not sure if that is acceptable to everyone. As we are going to have= to >> carry some patches in Android and drop any upstream MOCS changes. >> >>> - If you wish you may maintain compatibility with Linux by sync'ing >>> your tables periodically. If you do you may still have the choice to >>> break compatibility in the future and start from scratch with clean >>> tables if this turns out to become a burden for you. (Note that the >>> converse statement doesn't work if the tables part of the Linux >>> kernel were to be considered downstream, because we have the >>> requirement of keeping backwards compatibility with previous >>> revisions of the ABI). >> This is not really possible. As mentioned above ordering may change. >>> >>> - If you choose to keep compatibility the process for you to allocate >>> new entries avoiding conflicts should be relatively straightforward: >>> Send a patch to this mailing list and once it's ACK'ed you would have >>> the guarantee that the same index wouldn't ever be reused for any >>> other purpose in the future, and you could start making use of it in >>> the Android stack right away. >> It would be possible to allocate a high number say in the 60's as the cu= rrent >> table is generated from 270+ policies and only spits out 8 or 9 entries.= So the >> chance of the tables getting into the 60's is quite low. That could be an >> option, but I can see that being poo-pooed upstream with the simple ques= tion >> of why not start at 0. >> >> Like you, it would be nice too see what others think. >> >> Peter. >> >>> >>> How do you feel about this proposal? It would also be nice to hear the >>> opinion of other people from the Linux side. Ben? Jesse? >>> >>>> Peter. >>>> >>>>> >>>>>>>>>> + >>>>>>>>>> +static struct drm_i915_mocs_entry broxton_mocs_table[] =3D { >>>>>>>>>> + /* {0x00000001, 0x0010} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(ELLC) | >>>>>>>>>> + MOCS_LRUM(0) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))}, >>>>>>>>>> + /* {0x00000005, 0x0010} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(LLC) | >>>>>>>>>> + MOCS_LRUM(0) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))}, >>>>>>>>>> + /* {0x00000005, 0x0030} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(LLC) | >>>>>>>>>> + MOCS_LRUM(0) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_WB))}, >>>>>>>>>> + /* {0x00000017, 0x0030} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) | >>>>>>>>>> + MOCS_LRUM(1) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_WB))}, >>>>>>>>>> + /* {0x00000017, 0x0010} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) | >>>>>>>>>> + MOCS_LRUM(1) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))}, >>>>>>>>>> + /* {0x00000019, 0x0010} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_UC) | MOCS_TGT_CACHE(LLC_ELLC) | >>>>>>>>>> + MOCS_LRUM(1) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))}, >>>>>>>>>> + /* {0x00000037, 0x0030} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) | >>>>>>>>>> + MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_WB))}, >>>>>>>>>> + /* {0x00000037, 0x0010} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC) | >>>>>>>>>> + MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))}, >>>>>>>>>> + /* {0x0000003b, 0x0010} */ >>>>>>>>>> + {(MOCS_CACHEABILITY(EDRAM_WB) | MOCS_TGT_CACHE(LLC_ELLC) | >>>>>>>>>> + MOCS_LRUM(3) | MOCS_AOM(0) | MOCS_LECC_ESC(0) | MOCS_SCC(0) | >>>>>>>>>> + MOC_PFM(0) | MOCS_SCF(0)), >>>>>>>>>> + (MOCS_ESC(0) | MOCS_SCC(0) | MOCS_L3_CACHEABILITY(L3_UC))}, >>>>>>>>>> +}; >>>>>>>>>> + >>>>>>>>> >>>>>>>>> Wouldn't it be a good idea to have BXT's entries match SKL's for = a given >>>>>>>>> index? The TC, LeCC and LRUM settings you do here arguably don't= have >>>>>>>>> any effect on BXT, L3CC does but it doesn't match SKL's setting f= or >>>>>>>>> entries 1 and 2. Is there any reason for this? >>>>>>>> As mentioned above this table is auto-generated and matches anothe= r tuned >>>>>>>> table, simply keeping them the same allows for the tuning to be co= nsistent >>>>>>>> across platforms. >>>>>>>> >>>>>>>> Peter. >>>>>>>>> >>>>>>>>> Other than that looks good. >>>>>>>>> >>>>>>>>>> +/** >>>>>>>>>> + * get_mocs_settings >>>>>>>>>> + * >>>>>>>>>> + * This function will return the values of the MOCS table that = needs to >>>>>>>>>> + * be programmed for the platform. It will return the values th= at need >>>>>>>>>> + * to be programmed and if they need to be programmed. >>>>>>>>>> + * >>>>>>>>>> + * If the return values is false then the registers do not need >>>>>>>> programming. >>>>>>>>>> + */ >>>>>>>>>> +static bool get_mocs_settings(struct drm_device *dev, >>>>>>>>>> + struct drm_i915_mocs_table *table) { >>>>>>>>>> + bool result =3D false; >>>>>>>>>> + >>>>>>>>>> + if (IS_SKYLAKE(dev)) { >>>>>>>>>> + table->size =3D ARRAY_SIZE(skylake_mocs_table); >>>>>>>>>> + table->table =3D skylake_mocs_table; >>>>>>>>>> + result =3D true; >>>>>>>>>> + } else if (IS_BROXTON(dev)) { >>>>>>>>>> + table->size =3D ARRAY_SIZE(broxton_mocs_table); >>>>>>>>>> + table->table =3D broxton_mocs_table; >>>>>>>>>> + result =3D true; >>>>>>>>>> + } else { >>>>>>>>>> + /* Platform that should have a MOCS table does not */ >>>>>>>>>> + WARN_ON(INTEL_INFO(dev)->gen >=3D 9); >>>>>>>>>> + } >>>>>>>>>> + >>>>>>>>>> + return result; >>>>>>>>>> +} >>>>>>>>>> + >>>>>>>>>> +/** >>>>>>>>>> + * emit_mocs_control_table() - emit the mocs control table >>>>>>>>>> + * @ringbuf: DRM device. >>>>>>>>>> + * @table: The values to program into the control regs. >>>>>>>>>> + * @reg_base: The base for the Engine that needs to be programm= ed. >>>>>>>>>> + * >>>>>>>>>> + * This function simply emits a MI_LOAD_REGISTER_IMM command fo= r the >>>>>>>>>> + * given table starting at the given address. >>>>>>>>>> + * >>>>>>>>>> + * Return: Nothing. >>>>>>>>>> + */ >>>>>>>>>> +static void emit_mocs_control_table(struct intel_ringbuffer *ri= ngbuf, >>>>>>>>>> + struct drm_i915_mocs_table *table, >>>>>>>>>> + u32 reg_base) >>>>>>>>>> +{ >>>>>>>>>> + unsigned int index; >>>>>>>>>> + >>>>>>>>>> + intel_logical_ring_emit(ringbuf, >>>>>>>>>> + MI_LOAD_REGISTER_IMM(GEN9_NUM_MOCS_ENTRIES)); >>>>>>>>>> + >>>>>>>>>> + for (index =3D 0; index < table->size; index++) { >>>>>>>>>> + intel_logical_ring_emit(ringbuf, reg_base + (index * 4)); >>>>>>>>>> + intel_logical_ring_emit(ringbuf, >>>>>>>>>> + table->table[index].control_value); >>>>>>>>>> + } >>>>>>>>>> + >>>>>>>>>> + /* >>>>>>>>>> + * Ok, now set the unused entries to uncached. These entries a= re >>>>>>>>>> + * officially undefined and no contact is given for the conten= ts and >>>>>>>>>> + * settings is given for these entries. >>>>>>>>>> + * >>>>>>>>>> + * Entry 0 in the table is uncached - so we are just written t= hat >>>>>>>>>> + * value to all the used entries. >>>>>>>>>> + */ >>>>>>>>>> + for (; index < GEN9_NUM_MOCS_ENTRIES; index++) { >>>>>>>>>> + intel_logical_ring_emit(ringbuf, reg_base + (index * 4)); >>>>>>>>>> + intel_logical_ring_emit(ringbuf, >>>>>>>> table->table[0].control_value); >>>>>>>>>> + } >>>>>>>>>> + >>>>>>>>>> + intel_logical_ring_emit(ringbuf, MI_NOOP); >>>>>>>>>> +} >>>>>>>>>> + >>>>>>>>>> +/** >>>>>>>>>> + * emit_mocs_l3cc_table() - emit the mocs control table >>>>>>>>>> + * @ringbuf: DRM device. >>>>>>>>>> + * @table: The values to program into the control regs. >>>>>>>>>> + * >>>>>>>>>> + * This function simply emits a MI_LOAD_REGISTER_IMM command fo= r the >>>>>>>>>> + * given table starting at the given address. This register set= is >>>>>>>> programmed >>>>>>>>>> + * in pairs. >>>>>>>>>> + * >>>>>>>>>> + * Return: Nothing. >>>>>>>>>> + */ >>>>>>>>>> +static void emit_mocs_l3cc_table(struct intel_ringbuffer *ringb= uf, >>>>>>>>>> + struct drm_i915_mocs_table *table) { >>>>>>>>>> + unsigned int count; >>>>>>>>>> + unsigned int i; >>>>>>>>>> + u32 value; >>>>>>>>>> + u32 filler =3D (table->table[0].l3cc_value & 0xffff) | >>>>>>>>>> + ((table->table[0].l3cc_value & 0xffff) << 16); >>>>>>>>>> + >>>>>>>>>> + intel_logical_ring_emit(ringbuf, >>>>>>>>>> + MI_LOAD_REGISTER_IMM(GEN9_NUM_MOCS_ENTRIES / 2)); >>>>>>>>>> + >>>>>>>>>> + for (i =3D 0, count =3D 0; i < table->size / 2; i++, count += =3D 2) { >>>>>>>>>> + value =3D (table->table[count].l3cc_value & 0xffff) | >>>>>>>>>> + ((table->table[count + 1].l3cc_value & 0xffff) << >>>>>>>> 16); >>>>>>>>>> + >>>>>>>>>> + intel_logical_ring_emit(ringbuf, GEN9_LNCFCMOCS0 + (i * 4)); >>>>>>>>>> + intel_logical_ring_emit(ringbuf, value); >>>>>>>>>> + } >>>>>>>>>> + >>>>>>>>>> + if (table->size & 0x01) { >>>>>>>>>> + /* Odd table size - 1 left over */ >>>>>>>>>> + value =3D (table->table[count].l3cc_value & 0xffff) | >>>>>>>>>> + ((table->table[0].l3cc_value & 0xffff) << 16); >>>>>>>>>> + } else >>>>>>>>>> + value =3D filler; >>>>>>>>>> + >>>>>>>>>> + /* >>>>>>>>>> + * Now set the rest of the table to uncached - use entry 0 as = this >>>>>>>>>> + * will be uncached. Leave the last pair as initialised as the= y are >>>>>>>>>> + * reserved by the hardware. >>>>>>>>>> + */ >>>>>>>>>> + for (; i < (GEN9_NUM_MOCS_ENTRIES / 2) - 1; i++) { >>>>>>>>>> + intel_logical_ring_emit(ringbuf, GEN9_LNCFCMOCS0 + (i * 4)); >>>>>>>>>> + intel_logical_ring_emit(ringbuf, value); >>>>>>>>>> + >>>>>>>>>> + value =3D filler; >>>>>>>>>> + } >>>>>>>>>> + >>>>>>>>>> + intel_logical_ring_emit(ringbuf, MI_NOOP); >>>>>>>>>> +} >>>>>>>>>> + >>>>>>>>>> +/* >>>>>>>>>> + * gen9_program_mocs() - program the MOCS register. >>>>>>>>>> + * >>>>>>>>>> + * ring: The ring that the programming batch will be run in. >>>>>>>>>> + * ctx: The intel_context to be used. >>>>>>>>>> + * >>>>>>>>>> + * This function will emit a batch buffer with the values requi= red for >>>>>>>>>> + * programming the MOCS register values for all the currently s= upported >>>>>>>>>> + * rings. >>>>>>>>>> + * >>>>>>>>>> + * These registers are partially stored in the RCS context, so = they are >>>>>>>>>> + * emitted at the same time so that when a context is created t= hese >>>>>>>> registers >>>>>>>>>> + * are set up. These registers have to be emitted into the star= t of the >>>>>>>>>> + * context as setting the ELSP will re-init some of these regis= ters back >>>>>>>>>> + * to the hw values. >>>>>>>>>> + * >>>>>>>>>> + * Return: 0 on success, otherwise the error status. >>>>>>>>>> + */ >>>>>>>>>> +int gen9_program_mocs(struct intel_engine_cs *ring, >>>>>>>>>> + struct intel_context *ctx) >>>>>>>>>> +{ >>>>>>>>>> + int ret =3D 0; >>>>>>>>>> + >>>>>>>>>> + struct drm_i915_mocs_table t; >>>>>>>>>> + struct drm_device *dev =3D ring->dev; >>>>>>>>>> + struct intel_ringbuffer *ringbuf =3D ctx->engine[ring->id].rin= gbuf; >>>>>>>>>> + >>>>>>>>>> + if (get_mocs_settings(dev, &t)) { >>>>>>>>>> + u32 table_size; >>>>>>>>>> + >>>>>>>>>> + /* >>>>>>>>>> + * OK. For each supported ring: >>>>>>>>>> + * number of mocs entries * 2 dwords for each control_value >>>>>>>>>> + * plus number of mocs entries /2 dwords for l3cc values. >>>>>>>>>> + * >>>>>>>>>> + * Plus 1 for the load command and 1 for the NOOP per ring >>>>>>>>>> + * and the l3cc programming. >>>>>>>>>> + */ >>>>>>>>>> + table_size =3D GEN9_NUM_MOCS_RINGS * >>>>>>>>>> + ((2 * GEN9_NUM_MOCS_ENTRIES) + 2) + >>>>>>>>>> + GEN9_NUM_MOCS_ENTRIES + 2; >>>>>>>>>> + ret =3D intel_logical_ring_begin(ringbuf, ctx, table_size); >>>>>>>>>> + if (ret) { >>>>>>>>>> + DRM_DEBUG("intel_logical_ring_begin failed %d\n", >>>>>>>> ret); >>>>>>>>>> + return ret; >>>>>>>>>> + } >>>>>>>>>> + >>>>>>>>>> + /* program the control registers */ >>>>>>>>>> + emit_mocs_control_table(ringbuf, &t, GEN9_GFX_MOCS_0); >>>>>>>>>> + emit_mocs_control_table(ringbuf, &t, GEN9_MFX0_MOCS_0); >>>>>>>>>> + emit_mocs_control_table(ringbuf, &t, GEN9_MFX1_MOCS_0); >>>>>>>>>> + emit_mocs_control_table(ringbuf, &t, GEN9_VEBOX_MOCS_0); >>>>>>>>>> + emit_mocs_control_table(ringbuf, &t, GEN9_BLT_MOCS_0); >>>>>>>>>> + >>>>>>>>>> + /* now program the l3cc registers */ >>>>>>>>>> + emit_mocs_l3cc_table(ringbuf, &t); >>>>>>>>>> + >>>>>>>>>> + intel_logical_ring_advance(ringbuf); >>>>>>>>>> + >>>>>>>>>> + DRM_DEBUG("MOCS: Table set in Context\n"); >>>>>>>>>> + } else { >>>>>>>>>> + DRM_DEBUG("MOCS: Table Not supported on platform\n"); >>>>>>>>>> + } >>>>>>>>>> + >>>>>>>>>> + return ret; >>>>>>>>>> +} >>>>>>>>>> + >>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_mocs.h >>>>>>>> b/drivers/gpu/drm/i915/intel_mocs.h >>>>>>>>>> new file mode 100644 >>>>>>>>>> index 0000000..e2780ce >>>>>>>>>> --- /dev/null >>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_mocs.h >>>>>>>>>> @@ -0,0 +1,64 @@ >>>>>>>>>> +/* >>>>>>>>>> + * Copyright (c) 2015 Intel Corporation >>>>>>>>>> + * >>>>>>>>>> + * Permission is hereby granted, free of charge, to any person = obtaining >>>>>>>> a >>>>>>>>>> + * copy of this software and associated documentation files (the >>>>>>>> "Software"), >>>>>>>>>> + * to deal in the Software without restriction, including witho= ut >>>>>>>> limitation >>>>>>>>>> + * the rights to use, copy, modify, merge, publish, distribute, >>>>>>>> sublicense, >>>>>>>>>> + * and/or sell copies of the Software, and to permit persons to= whom the >>>>>>>>>> + * Software is furnished to do so, subject to the following con= ditions: >>>>>>>>>> + * >>>>>>>>>> + * The above copyright notice and this permission notice (inclu= ding the >>>>>>>> next >>>>>>>>>> + * paragraph) shall be included in all copies or substantial po= rtions of >>>>>>>> the >>>>>>>>>> + * Software. >>>>>>>>>> + * >>>>>>>>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KI= ND, >>>>>>>> EXPRESS OR >>>>>>>>>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF >>>>>>>> MERCHANTABILITY, >>>>>>>>>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO= EVENT >>>>>>>> SHALL >>>>>>>>>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DA= MAGES OR >>>>>>>> OTHER >>>>>>>>>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWI= SE, >>>>>>>> ARISING FROM, >>>>>>>>>> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHE= R DEALINGS >>>>>>>> IN THE >>>>>>>>>> + * SOFTWARE. >>>>>>>>>> + * >>>>>>>>>> + * Authors: >>>>>>>>>> + * Peter Antoine >>>>>>>>>> + */ >>>>>>>>>> + >>>>>>>>>> +#ifndef INTEL_MOCS_H >>>>>>>>>> +#define INTEL_MOCS_H >>>>>>>>>> + >>>>>>>>>> +/** >>>>>>>>>> + * DOC: Memory Objects Control State (MOCS) >>>>>>>>>> + * >>>>>>>>>> + * Motivation: >>>>>>>>>> + * In previous Gens the MOCS settings was a value that was set = by user >>>>>>>> land as >>>>>>>>>> + * part of the batch. In Gen9 this has changed to be a single t= able (per >>>>>>>> ring) >>>>>>>>>> + * that all batches now reference by index instead of programmi= ng the >>>>>>>> MOCS >>>>>>>>>> + * directly. >>>>>>>>>> + * >>>>>>>>>> + * The one wrinkle in this is that only PART of the MOCS tables= are >>>>>>>> included >>>>>>>>>> + * in context (The GFX_MOCS_0 - GFX_MOCS_64 and the LNCFCMOCS0 - >>>>>>>> LNCFCMOCS32 >>>>>>>>>> + * registers). The rest are not (the settings for the other rin= gs). >>>>>>>>>> + * >>>>>>>>>> + * This table needs to be set at system start-up because the wa= y the >>>>>>>> table >>>>>>>>>> + * interacts with the contexts and the GmmLib interface. >>>>>>>>>> + * >>>>>>>>>> + * >>>>>>>>>> + * Implementation: >>>>>>>>>> + * >>>>>>>>>> + * The table is programmed on a platform basis from a table tha= t is >>>>>>>> generated >>>>>>>>>> + * from the one that has been agreed by the different responsib= le >>>>>>>> parties. This >>>>>>>>>> + * tables (one per supported platform) is defined in intel_mocs= .c and is >>>>>>>>>> + * programmed in the first batch after the context is loaded (w= ith the >>>>>>>> hardware >>>>>>>>>> + * workarounds). This will then let the usual context handling = keep the >>>>>>>> MOCS in >>>>>>>>>> + * step. >>>>>>>>>> + */ >>>>>>>>>> + >>>>>>>>>> +#include >>>>>>>>>> +#include "i915_drv.h" >>>>>>>>>> + >>>>>>>>>> +int gen9_program_mocs(struct intel_engine_cs *ring, >>>>>>>>>> + struct intel_context *ctx); >>>>>>>>>> + >>>>>>>>>> +#endif >>>>>>>>>> + >>>>>>>>>> -- >>>>>>>>>> 1.9.1 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Intel-gfx mailing list >>>>>>>>>> Intel-gfx@lists.freedesktop.org >>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Peter Antoine (Android Graphics Driver Software Engineer) >>>>>>>> ---------------------------------------------------------------= ------ >>>>>>>> Intel Corporation (UK) Limited >>>>>>>> Registered No. 1134945 (England) >>>>>>>> Registered Office: Pipers Way, Swindon SN3 1RJ >>>>>>>> VAT No: 860 2173 47 >>>>>>>> _______________________________________________ >>>>>>>> Intel-gfx mailing list >>>>>>>> Intel-gfx@lists.freedesktop.org >>>>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Peter Antoine (Android Graphics Driver Software Engineer) >>>>>>> ---------------------------------------------------------------= ------ >>>>>>> Intel Corporation (UK) Limited >>>>>>> Registered No. 1134945 (England) >>>>>>> Registered Office: Pipers Way, Swindon SN3 1RJ >>>>>>> VAT No: 860 2173 47 >>>>>> _______________________________________________ >>>>>> Intel-gfx mailing list >>>>>> Intel-gfx@lists.freedesktop.org >>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >>>>> >>>> >>>> -- >>>> Peter Antoine (Android Graphics Driver Software Engineer) >>>> ------------------------------------------------------------------= --- >>>> Intel Corporation (UK) Limited >>>> Registered No. 1134945 (England) >>>> Registered Office: Pipers Way, Swindon SN3 1RJ >>>> VAT No: 860 2173 47 >>> >> >> -- >> Peter Antoine (Android Graphics Driver Software Engineer) >> --------------------------------------------------------------------- >> Intel Corporation (UK) Limited >> Registered No. 1134945 (England) >> Registered Office: Pipers Way, Swindon SN3 1RJ >> VAT No: 860 2173 47 > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWUBH4ACgkQg5k4nX1Sv1u5EwEAjsAiVFiZ23D5cmGd+iL3nSJP MHDWxcIUl0kR1ZO+1PMA/At3Q6xXyvHc+I3yuaYtpRPZ/H1jcpSM0NQmTfQ2nYBj =77Si -----END PGP SIGNATURE----- --==-=-=-- --===============1474550172== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnRlbC1nZngK --===============1474550172==--