[Intel-gfx] [PATCH] drm/i915/oa: Reconfigure contexts on the fly

Lionel Landwerlin lionel.g.landwerlin at intel.com
Fri Jul 5 13:06:25 UTC 2019


On 05/07/2019 15:54, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2019-07-05 13:42:51)
>> Wow nice. I didn't have the courage to actually write it, knowing how
>> easy it could be to screw an offset and write at random in GGTT...
>>
>> I only have one concern below.
>>
>> Thanks a lot,
>>
>> -Lionel
>>
>> On 05/07/2019 15:30, Chris Wilson wrote:
>>>        CTX_REG(reg_state,
>>> @@ -1692,6 +1693,150 @@ gen8_update_reg_state_unlocked(struct intel_context *ce,
>>>                intel_sseu_make_rpcs(i915, &ce->sseu));
>>>    }
>>>    
>>> +struct flex {
>>> +     i915_reg_t reg;
>>> +     u32 offset;
>>> +     u32 value;
>>> +};
>>> +
>>> +static int
>>> +gen8_store_flex(struct i915_request *rq,
>>> +             struct intel_context *ce,
>>> +             const struct flex *flex, unsigned int count)
>>> +{
>>> +     u32 offset;
>>> +     u32 *cs;
>>> +
>>> +     cs = intel_ring_begin(rq, 4 * count);
>>> +     if (IS_ERR(cs))
>>> +             return PTR_ERR(cs);
>>
>> Is the right of the kernel context large enough to hold the MI_SDIs for
>> all the contexts?
> At the moment we are using 9 registers, add in say 128 bytes tops for
> the request overhead, that's <300 bytes. The kernel context uses 4k
> rings, so enough for a few updates before we have to flush. We may have
> to wait for external rings to idle and be interrupt -- but that's the
> same as before, including the chance that we may be interrupted in the
> middle of conversion.
>
> The worst case is that we overrun the ring and we should get a juicy
> warning (GEM_BUG_ON or -ENOSPC) in that case. We can increase the
> kernel_context ring if that's an issue or just fallback to suballocating
> a batchbuffer for the updates.


Ah, thanks. I didn't notice it was one request per context to reconfigure.

Still I wouldn't want to have this fail somewhat randomly because 
something else stayed on the HW just a bit too long.


Maybe checking the available space in the ring in 
gen8_configure_all_contexts() and wait on last_request if there isn't 
enough?


-Lionel


>
>>> +static int
>>> +gen8_emit_oa_config(struct i915_request *rq,
>>> +                 struct intel_context *ce,
>>> +                 const struct i915_oa_config *oa_config,
>>> +                 bool self)
>>> +{
>>> +     struct drm_i915_private *i915 = rq->i915;
>>> +     /* The MMIO offsets for Flex EU registers aren't contiguous */
>>> +     const u32 ctx_flexeu0 = i915->perf.oa.ctx_flexeu0_offset;
>>> +#define ctx_flexeuN(N) (ctx_flexeu0 + 2 * (N))
>>> +     struct flex regs[] = {
>>> +             {
>>> +                     GEN8_R_PWR_CLK_STATE,
>>> +                     CTX_R_PWR_CLK_STATE,
>>> +                     intel_sseu_make_rpcs(i915, &ce->sseu)
>>> +             },
>>> +             {
>>> +                     GEN8_OACTXCONTROL,
>>> +                     i915->perf.oa.ctx_oactxctrl_offset,
>>> +                     ((i915->perf.oa.period_exponent << GEN8_OA_TIMER_PERIOD_SHIFT) |
>>> +                      (i915->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
>>> +                      GEN8_OA_COUNTER_RESUME)
>>> +             },
>>> +             { EU_PERF_CNTL0, ctx_flexeuN(0) },
>>> +             { EU_PERF_CNTL1, ctx_flexeuN(1) },
>>> +             { EU_PERF_CNTL2, ctx_flexeuN(2) },
>>> +             { EU_PERF_CNTL3, ctx_flexeuN(3) },
>>> +             { EU_PERF_CNTL4, ctx_flexeuN(4) },
>>> +             { EU_PERF_CNTL5, ctx_flexeuN(5) },
>>> +             { EU_PERF_CNTL6, ctx_flexeuN(6) },
>>> +     };
>>> +#undef ctx_flexeuN
>>> +     int i;
>>> +
>>> +     for (i = 2; i < ARRAY_SIZE(regs); i++)
>>> +             regs[i].value = oa_config_flex_reg(oa_config, regs[i].reg);
>>
>> I guess this mapping could be done only once in
>> gen8_configure_all_contexts().
> Ah, it's just ce->sseu giving the appearance of it being context
> specific :)
> -Chris
>



More information about the Intel-gfx mailing list