[Intel-gfx] [PATCH v6] drm/i915: Add IOCTL Param to control data port coherency.
Lis, Tomasz
tomasz.lis at intel.com
Wed Jul 18 15:28:32 UTC 2018
On 2018-07-18 16:42, Tvrtko Ursulin wrote:
>
> On 18/07/2018 14:24, Joonas Lahtinen wrote:
>> Quoting Tomasz Lis (2018-07-16 16:07:16)
>>> +static int emit_set_data_port_coherency(struct i915_request *rq,
>>> bool enable)
>>> +{
>>> + u32 *cs;
>>> + i915_reg_t reg;
>>> +
>>> + GEM_BUG_ON(rq->engine->class != RENDER_CLASS);
>>> + GEM_BUG_ON(INTEL_GEN(rq->i915) < 9);
>>> +
>>> + cs = intel_ring_begin(rq, 4);
>>> + if (IS_ERR(cs))
>>> + return PTR_ERR(cs);
>>> +
>>> + if (INTEL_GEN(rq->i915) >= 11)
>>> + reg = ICL_HDC_MODE;
>>> + else if (INTEL_GEN(rq->i915) >= 10)
>>> + reg = CNL_HDC_CHICKEN0;
>>> + else
>>> + reg = HDC_CHICKEN0;
>>> +
>>> + *cs++ = MI_LOAD_REGISTER_IMM(1);
>>> + *cs++ = i915_mmio_reg_offset(reg);
>>> + /* Enabling coherency means disabling the bit which forces
>>> it off */
>>
>> This comment is still spurious, please get rid of the habit of writing
>> comments about "what" the code is doing, useful comments should be
>> limited to "why", which is quite self explanatory here, that's the way
>> the register is.
Ok, I will read the related doc:
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting
>>
>>> +static int
>>> +intel_lr_context_update_data_port_coherency(struct i915_request *rq)
>>> +{
>>> + struct i915_gem_context *ctx = rq->gem_context;
>>> + bool enable = test_bit(CONTEXT_DATA_PORT_COHERENT_REQUESTED,
>>> &ctx->flags);
>>> + int ret;
>>> +
>>> + lockdep_assert_held(&rq->i915->drm.struct_mutex);
>>> +
>>> + if (test_bit(CONTEXT_DATA_PORT_COHERENT_ACTIVE, &ctx->flags)
>>> == enable)
>>> + return 0;
>>> +
>>> + ret = emit_set_data_port_coherency(rq, enable);
>>> +
>>> + if (!ret) {
>>> + if (enable)
>>> + __set_bit(CONTEXT_DATA_PORT_COHERENT_ACTIVE, &ctx->flags);
>>> + else
>>> + __clear_bit(CONTEXT_DATA_PORT_COHERENT_ACTIVE, &ctx->flags);
>>> + }
>>
>> Do we have indication that the hardware feature will be unreliable in
>> responding to the requests? I don't think you need the differentiation
>> of requested vs. active. If there is an error, we can just report
>> back to
>> the user as a failed IOCTL. Now it adds unnecessary complication for
>> no benefit.
>
> Requested vs active is for implementing the lazy emit.
>
> AFAIR it does propagate the error out of execbuf (although we never
> ever expect it to happen), and this is just to keep the internal
> house-keeping in sync.
>
> Regards,
>
> Tvrtko
>
>>> @@ -2164,6 +2221,13 @@ static int gen8_emit_flush_render(struct
>>> i915_request *request,
>>> /* WaForGAMHang:kbl */
>>> if (IS_KBL_REVID(request->i915, 0, KBL_REVID_B0))
>>> dc_flush_wa = true;
>>> +
>>> + /* Emit the switch of data port coherency state if
>>> needed */
>>
>> Ditto for spurious comment, just about what the code does.
>>
>>> +++ b/include/uapi/drm/i915_drm.h
>>> @@ -1456,6 +1456,13 @@ struct drm_i915_gem_context_param {
>>> #define I915_CONTEXT_MAX_USER_PRIORITY 1023 /* inclusive */
>>> #define I915_CONTEXT_DEFAULT_PRIORITY 0
>>> #define I915_CONTEXT_MIN_USER_PRIORITY -1023 /* inclusive */
>>> +/*
>>> + * When data port level coherency is enabled, the GPU will update
>>> memory
>>> + * buffers shared with CPU, by forcing internal cache units to send
>>> memory
>>> + * writes to higher level caches faster. Enabling data port
>>> coherency has
>>> + * a performance cost.
>>> + */
>>
>> I was under impression this is enabled by default and it can be disabled
>> for a performance optimization?
This is true, coherency is kept by default. We disable it as a
workaround: performance-related for gen11, and due to minor hardware
issue on previous platforms. See WaForceEnableNonCoherent.
-Tomasz
>>
>> Regards, Joonas
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
More information about the Intel-gfx
mailing list