[Intel-gfx] [PATCH v4] drm/i915 : Added Programming of the MOCS

Francisco Jerez currojerez at riseup.net
Wed Jul 1 06:05:23 PDT 2015


Peter Antoine <peter.antoine at intel.com> writes:

> On Tue, 30 Jun 2015, Francisco Jerez wrote:
>
>> Francisco Jerez <currojerez at riseup.net> writes:
>>
>>> Peter Antoine <peter.antoine at intel.com> writes:
>>>
>>>> On Mon, 29 Jun 2015, Peter Antoine wrote:
>>>>
>>>>> On Thu, 25 Jun 2015, Francisco Jerez wrote:
>>>>>
>>>>>> Peter Antoine <peter.antoine at 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.antoine at 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.antoine at 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 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 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).

 - 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).

 - 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.

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 at 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 at 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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20150701/1ab19e36/attachment-0001.sig>


More information about the Intel-gfx mailing list