Re: [PATCH v3 5/7] drm/i915: add a new perf configuration execbuf parameter

[Lionel Landwerlin <lionel.g.landwerlin@intel.com>]

On 04/06/2019 16:40, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2019-06-04 14:11:38)
>>          list_add_tail(&rq->client_link, &rq->file_priv->mm.request_list);
>>   }
>>   
>> +static int eb_oa_config(struct i915_execbuffer *eb)
>> +{
>> +       struct i915_vma *oa_vma;
>> +       int err;
>> +
>> +       if (!eb->oa_config)
>> +               return 0;
>> +
>> +       /*
>> +        * If the config hasn't changed, skip reconfiguring the HW (this is
>> +        * subject to a delay we want to avoid has much as possible).
>> +        */
>> +       if (eb->oa_config == eb->i915->perf.oa.exclusive_stream->oa_config)
>> +               return 0;
> But you don't order the execution so it may not be the right oa_config.
> Just add the barrier. It is virtually no cost for the exclusive oa
> userspace.


Ah right sorry :(


>
> How does this interact with the global oa_config being changed via the
> ioctl?


eb_oa_config() should be called under the global lock right?
Or are you referring to something else?


>   What significance is there for this per-execbuf oa_config being
> applied to other users?


The expectation is that a single application is using this and data 
other users get from MI_REPORT_PERF_COUNT is undefined (much like when 
OA is turned off).

Now I see there is a problem with an application with multiple contexts 
because we have the Flex EU counter configurations per context.

I can break the config in 2 parts and execute the flex counter 
programming everything regardless.


We really want to minimize the NOA reprogramming because it takes an 
undefined amount of time to apply (been told below 1ms).


Thanks for spotting those issue.


-Lionel


> -Chris
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx