Francisco Jerez <currojerez@xxxxxxxxxx> writes:
> Peter Antoine <peter.antoine@xxxxxxxxx> writes:
>
>> On Wed, 1 Jul 2015, Francisco Jerez wrote:
>>
>>> Peter Antoine <peter.antoine@xxxxxxxxx> writes:
>>>
>>>> On Tue, 30 Jun 2015, Francisco Jerez wrote:
>>>>
>>>>> Francisco Jerez <currojerez@xxxxxxxxxx> writes:
>>>>>
>>>>>> Peter Antoine <peter.antoine@xxxxxxxxx> writes:
>>>>>>
>>>>>>> On Mon, 29 Jun 2015, Peter Antoine wrote:
>>>>>>>
>>>>>>>> On Thu, 25 Jun 2015, Francisco Jerez wrote:
>>>>>>>>
>>>>>>>>> Peter Antoine <peter.antoine@xxxxxxxxx> 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.antoine@xxxxxxxxx>
>>>>>>>>>> ---
>>>>>>>>>> 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.antoine@xxxxxxxxx>
>>>>>>>>>> + */
>>>>>>>>>> +
>>>>>>>>>> +#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
Oh, the 0-th entry may as well have LRUM=0 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 (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.antoine@xxxxxxxxx>
>>>>>>>>>> + */
>>>>>>>>>> +
>>>>>>>>>> +#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@xxxxxxxxxxxxxxxxxxxxx
>>>>>>>>>> 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@xxxxxxxxxxxxxxxxxxxxx
>>>>>>>> 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@xxxxxxxxxxxxxxxxxxxxx
>>>>>> 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@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
