Peter Antoine <peter.anto...@intel.com> writes:
> On Wed, 1 Jul 2015, Francisco Jerez wrote:
>
>> Peter Antoine <peter.anto...@intel.com> writes:
>>
>>> On Tue, 30 Jun 2015, Francisco Jerez wrote:
>>>
>>>> Francisco Jerez <curroje...@riseup.net> writes:
>>>>
>>>>> Peter Antoine <peter.anto...@intel.com> writes:
>>>>>
>>>>>> On Mon, 29 Jun 2015, Peter Antoine wrote:
>>>>>>
>>>>>>> On Thu, 25 Jun 2015, Francisco Jerez wrote:
>>>>>>>
>>>>>>>> Peter Antoine <peter.anto...@intel.com> writes:
>>>>>>>>
>>>>>>>>> This change adds the programming of the MOCS registers to the gen 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
>>>>>>>>> different
>>>>>>>>> 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 shared
>>>>>>>>> L3 values. By trying to keep the registers consistent across the
>>>>>>>>> different engines it should make the programming for the registers
>>>>>>>>> consistent.
>>>>>>>>>
>>>>>>>>> v2:
>>>>>>>>> -'static const' for private data structures and style changes.(Matt
>>>>>>> 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 <peter.anto...@intel.com>
>>>>>>>>> ---
>>>>>>>>> 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/i915/Makefile
>>>>>>>>> index b7ddf48..c781e19 100644
>>>>>>>>> --- a/drivers/gpu/drm/i915/Makefile
>>>>>>>>> +++ b/drivers/gpu/drm/i915/Makefile
>>>>>>>>> @@ -35,6 +35,7 @@ i915-y += 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 <drm/drmP.h>
>>>>>>>>> #include <drm/i915_drm.h>
>>>>>>>>> #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 written to.
>>>>>>>>> */
>>>>>>>>> -static int intel_logical_ring_begin(struct intel_ringbuffer *ringbuf,
>>>>>>>>> +int intel_logical_ring_begin(struct intel_ringbuffer *ringbuf,
>>>>>>>>> struct intel_context *ctx, int
>>>>>>> num_dwords)
>>>>>>>>> {
>>>>>>>>> struct intel_engine_cs *ring = 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) != 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_device
>>>>>>>>> *dev);
>>>>>>>>>
>>>>>>>>> int logical_ring_flush_all_caches(struct intel_ringbuffer *ringbuf,
>>>>>>>>> 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 without
>>>>>>> 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
>>>>>>>>> conditions: *
>>>>>>>>> + * The above copyright notice and this permission notice (including
>>>>>>>>> the
>>>>>>> next
>>>>>>>>> + * paragraph) shall be included in all copies or substantial
>>>>>>>>> portions of
>>>>>>> the
>>>>>>>>> + * Software.
>>>>>>>>> + *
>>>>>>>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>>>>>> 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, DAMAGES
>>>>>>>>> OR
>>>>>>> OTHER
>>>>>>>>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>>>>>>> ARISING FROM,
>>>>>>>>> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>>>>>>>>> DEALINGS
>>>>>>> IN THE
>>>>>>>>> + * SOFTWARE.
>>>>>>>>> + *
>>>>>>>>> + * Authors:
>>>>>>>>> + * Peter Antoine <peter.anto...@intel.com>
>>>>>>>>> + */
>>>>>>>>> +
>>>>>>>>> +#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 entries 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
>>>>>>>>> program
>>>>>>> */
>>>>>>>>> +#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", but 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 registers
>>>>>>> (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 support 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 length
>>>>>>>>> MUST
>>>>>>> be
>>>>>>>>> + * less than 63 as the last two registers are reserved by the
>>>>>>> hardware.
>>>>>>>>> + */
>>>>>>>>> +static struct drm_i915_mocs_entry skylake_mocs_table[] = {
>>>>>>>>> + /* {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=LLC/eLLC, LeCC=PTE, L3CC=WB,
>>>>>>>> everything else unset, I'll reply with a userspace patch making use of
>>>>>>>> your change if you add such an entry.
>>>>>> Ok. I think what you want is, same as entry two, but use the underlying
>>>>>> pagetable settings and not specify the EDRAM settings. Please confirm 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 which
>>>>>>>> AFAIK doesn't have any effect for LeCC=UC. Is my understanding
>>>>>>>> correct?
>>>>>>>>
>>>>>>> These tables are generated via requests and then boiled down to the
>>>>>>> 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 done 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 that
>>>> our table and the master table don't diverge and end up with conflicting
>>>> 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 this
>>> (so future gens this is baked in) but it is unlikely that the other tables
>>> will stay in step as getting in changes will cause too much grief getting
>>> 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 Android
> and Linux. We need to keep compatibility with userspace and there is no
> guarantee of ordering as these tables are generated at runtime. The tables
> that are in Linux are a snapshot. These changes are supposed to stabilise 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
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 (and
> 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 March and
> teams were directly contacted when this happened and not a lot of response
> 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 tuning 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 current
> 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 question
> 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[] = {
>>>>>>>>> + /* {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 for
>>>>>>>> entries 1 and 2. Is there any reason for this?
>>>>>>> As mentioned above this table is auto-generated and matches another
>>>>>>> tuned
>>>>>>> table, simply keeping them the same allows for the tuning to be
>>>>>>> consistent
>>>>>>> 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 that
>>>>>>>>> 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 = false;
>>>>>>>>> +
>>>>>>>>> + if (IS_SKYLAKE(dev)) {
>>>>>>>>> + table->size = ARRAY_SIZE(skylake_mocs_table);
>>>>>>>>> + table->table = skylake_mocs_table;
>>>>>>>>> + result = true;
>>>>>>>>> + } else if (IS_BROXTON(dev)) {
>>>>>>>>> + table->size = ARRAY_SIZE(broxton_mocs_table);
>>>>>>>>> + table->table = broxton_mocs_table;
>>>>>>>>> + result = true;
>>>>>>>>> + } else {
>>>>>>>>> + /* Platform that should have a MOCS table does not */
>>>>>>>>> + WARN_ON(INTEL_INFO(dev)->gen >= 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
>>>>>>>>> programmed.
>>>>>>>>> + *
>>>>>>>>> + * This function simply emits a MI_LOAD_REGISTER_IMM command for the
>>>>>>>>> + * given table starting at the given address.
>>>>>>>>> + *
>>>>>>>>> + * Return: Nothing.
>>>>>>>>> + */
>>>>>>>>> +static void emit_mocs_control_table(struct intel_ringbuffer *ringbuf,
>>>>>>>>> + 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 = 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 are
>>>>>>>>> + * officially undefined and no contact is given for the
>>>>>>>>> contents and
>>>>>>>>> + * settings is given for these entries.
>>>>>>>>> + *
>>>>>>>>> + * Entry 0 in the table is uncached - so we are just written
>>>>>>>>> that
>>>>>>>>> + * 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 for 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 *ringbuf,
>>>>>>>>> + struct drm_i915_mocs_table *table) {
>>>>>>>>> + unsigned int count;
>>>>>>>>> + unsigned int i;
>>>>>>>>> + u32 value;
>>>>>>>>> + u32 filler = (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 = 0, count = 0; i < table->size / 2; i++, count += 2) {
>>>>>>>>> + value = (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 = (table->table[count].l3cc_value & 0xffff) |
>>>>>>>>> + ((table->table[0].l3cc_value & 0xffff) << 16);
>>>>>>>>> + } else
>>>>>>>>> + value = 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 they
>>>>>>>>> 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 = 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 required
>>>>>>>>> for
>>>>>>>>> + * programming the MOCS register values for all the currently
>>>>>>>>> supported
>>>>>>>>> + * 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 these
>>>>>>> registers
>>>>>>>>> + * are set up. These registers have to be emitted into the start of
>>>>>>>>> the
>>>>>>>>> + * context as setting the ELSP will re-init some of these registers
>>>>>>>>> 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 = 0;
>>>>>>>>> +
>>>>>>>>> + struct drm_i915_mocs_table t;
>>>>>>>>> + struct drm_device *dev = ring->dev;
>>>>>>>>> + struct intel_ringbuffer *ringbuf =
>>>>>>>>> ctx->engine[ring->id].ringbuf;
>>>>>>>>> +
>>>>>>>>> + 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 = GEN9_NUM_MOCS_RINGS *
>>>>>>>>> + ((2 * GEN9_NUM_MOCS_ENTRIES) + 2) +
>>>>>>>>> + GEN9_NUM_MOCS_ENTRIES + 2;
>>>>>>>>> + ret = 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 without
>>>>>>> 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
>>>>>>>>> conditions:
>>>>>>>>> + *
>>>>>>>>> + * The above copyright notice and this permission notice (including
>>>>>>>>> the
>>>>>>> next
>>>>>>>>> + * paragraph) shall be included in all copies or substantial
>>>>>>>>> portions of
>>>>>>> the
>>>>>>>>> + * Software.
>>>>>>>>> + *
>>>>>>>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>>>>>> 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, DAMAGES
>>>>>>>>> OR
>>>>>>> OTHER
>>>>>>>>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>>>>>>> ARISING FROM,
>>>>>>>>> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>>>>>>>>> DEALINGS
>>>>>>> IN THE
>>>>>>>>> + * SOFTWARE.
>>>>>>>>> + *
>>>>>>>>> + * Authors:
>>>>>>>>> + * Peter Antoine <peter.anto...@intel.com>
>>>>>>>>> + */
>>>>>>>>> +
>>>>>>>>> +#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 table
>>>>>>>>> (per
>>>>>>> ring)
>>>>>>>>> + * that all batches now reference by index instead of programming 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 rings).
>>>>>>>>> + *
>>>>>>>>> + * This table needs to be set at system start-up because the way the
>>>>>>> table
>>>>>>>>> + * interacts with the contexts and the GmmLib interface.
>>>>>>>>> + *
>>>>>>>>> + *
>>>>>>>>> + * Implementation:
>>>>>>>>> + *
>>>>>>>>> + * The table is programmed on a platform basis from a table that is
>>>>>>> generated
>>>>>>>>> + * from the one that has been agreed by the different responsible
>>>>>>> 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 (with
>>>>>>>>> the
>>>>>>> hardware
>>>>>>>>> + * workarounds). This will then let the usual context handling keep
>>>>>>>>> the
>>>>>>> MOCS in
>>>>>>>>> + * step.
>>>>>>>>> + */
>>>>>>>>> +
>>>>>>>>> +#include <drm/drmP.h>
>>>>>>>>> +#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
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
