| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
| |
Iris and i965 both need to enumerate the available metrics, so these
routines must be located in perf.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
| |
The perf subsystem needs several macro definitions that were
duplicated in Iris and i965 headers. Place these macros within perf,
if the perf implementation contains the only references to the values.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
| |
In preparation for calling both Iris and i965 implementions from perf.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
| |
In preparation for calling both Iris and i965 implementions from perf.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
| |
In preparation for calling both Iris and i965 implementions from perf.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
| |
In preparation for calling both Iris and i965 implementions from perf.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Performance metrics collections requires several actions (eg bo_map())
that have different implementations for Iris and i965. The perf
subsystem needs a vtable for each of these actions, so it can invoke
the corresponding implementation for each driver.
The first call to be added to the table is bo_alloc.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
| |
There were multiple ioctl-wrapper functions, so a common
implementation was put in gen_gem.h. With a common implementation,
perf no longer needs the caller to configure one for it.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This structure contains the configurations of the metrics for the
current platform, and the settings needed for the perf subsystem to
query that configuration from the device. This data is available
without a rendering context, and needed to support MDAPI metrics for
Vulkan.
A gen_perf_context struct will be added later, which holds additional
state from the rendering context necessary for metric data
collection. The gen_perf struct needs a more precise name to reduce
confusion.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
| |
MAYBE_UNUSED is going away, so let's replace legitimate uses of it with
UNUSED, which the former aliased to so far anyway.
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're currently trying to detect dynamic loading config support by
trying to remove to test config (hard coded in the i915 driver) and
checking we get ENOENT.
This can fail if the test config was updated in Mesa but not yet in
i915.
A better way to do this is to pick an invalid ID and check for ENOENT.
Signed-off-by: Lionel Landwerlin <[email protected]>
Cc: <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
EuThreadsCount is supposed to be the number of threads per EU, not the
total number of threads in the whole device.
Signed-off-by: Lionel Landwerlin <[email protected]>
Fixes: 1fc7b951278428 ("i965: Add Gen8+ INTEL_performance_query support")
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
This was a rebase issue which lost of change to a file moved from i965
to src/intel/perf.
Signed-off-by: Lionel Landwerlin <[email protected]>
Fixes: 134e750e16bfc5 ("i965: extract performance query metrics")
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Mark Janes <[email protected]>
|
| |
|
|
|
|
|
| |
We can deduct the size from another field, let's just save some space.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Mark Janes <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
The Gen10+ expected format adds an additional counter which we can't
disclose yet. We can still make the size of the expected query result
match.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Mark Janes <[email protected]>
|
| |
|
|
| |
Reviewed-by: Mark Janes <[email protected]>
|
| |
|
|
|
|
|
| |
One more thing we want to share between the different APIs.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Mark Janes <[email protected]>
|
| |
|
|
|
|
|
| |
We want to reuse this in Anv.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Mark Janes <[email protected]>
|
| |
|
|
|
|
|
| |
We'll want to reuse this in our Vulkan extension.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Mark Janes <[email protected]>
|
| |
|
|
|
|
|
| |
We'll want to reuse those structures later on.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Mark Janes <[email protected]>
|
|
|
We would like to reuse performance query metrics in other APIs. Let's
make the query code dealing with the processing of raw counters into
human readable values API agnostic.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Mark Janes <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
