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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
