From: Tvrtko Ursulin
If i915 does not want to use huge pages there is a) no point in setting up
the private mount and b) should former fail, it is misleading to log THP
support is disabled in the caller, which does not even know if callee
tried to enable it.
Fix both by restructuring the flow
From: Tvrtko Ursulin
We have a statement from HW designers that the GPU read regression when
using 2M pages was fixed from Icelake onwards, which was also confirmed
by bencharking Eero did last year:
"""
When IOMMU is disabled, enabling THP causes following perf changes on
TGL-H
Hi,
On 28/04/2022 00:07, Matt Roper wrote:
Rather than storing subslice masks internally as u8[] (inside the sseu
structure) and u32 (everywhere else), let's move over to using an
intel_sseu_ss_mask_t typedef compatible with the operations in
linux/bitmap.h. We're soon going to start adding
On 28/04/2022 11:25, Matthew Auld wrote:
On 28/04/2022 09:55, Tvrtko Ursulin wrote:
On 27/04/2022 18:36, Matthew Auld wrote:
On 27/04/2022 09:36, Tvrtko Ursulin wrote:
On 20/04/2022 18:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some
On 27/04/2022 18:36, Matthew Auld wrote:
On 27/04/2022 09:36, Tvrtko Ursulin wrote:
On 20/04/2022 18:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error cap
ontext" is used
on bspec 46167).
Bspec: 43930
Cc: Prathap Kumar Valsan
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
Happy even a blind chicken (me) managed to pick on this piece of
correctness. :)
Acked-by: Tvrtko Ursulin
Prathap please r-b since you were the authoritative source in
On 28/04/2022 05:19, Matt Roper wrote:
We're now ready to start exposing compute engines to userspace.
v2:
- Move kerneldoc for other engine classes to a separate patch. (Andi)
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Vinay Belgaumkar
Cc: Jordan Justen
Cc: Szymon Morek
UMD
Harrison, Rodrigo Vivi, Tvrtko Ursulin)
- Sysfs support for multi-tile devices (Andi Shyti, Sujaritha Sundaresan)
- Per client GPU utilisation via fdinfo (Tvrtko Ursulin, Ashutosh Dixit)
- Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (Matt Atwood)
Cross-subsystem Changes:
- Add GSC as a MEI auxiliary
On 20/04/2022 18:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture.
On 25/04/2022 19:40, Yang, Fei wrote:
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -1175,6 +1175,7 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
[VIDEO_DECODE_CLASS]= GEN12_VD_TLB_INV_CR,
On 08/04/2022 16:10, Daniel Vetter wrote:
On Fri, 8 Apr 2022 at 12:29, Tvrtko Ursulin
wrote:
On 08/04/2022 10:50, Dave Airlie wrote:
On Fri, 8 Apr 2022 at 18:25, Tvrtko Ursulin
wrote:
On 08/04/2022 08:58, Daniel Vetter wrote:
On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin
On 22/04/2022 20:50, Matt Roper wrote:
We're now ready to start exposing compute engines to userspace.
While we're at it, let's extend the kerneldoc description for the other
engine types as well.
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Vinay Belgaumkar
Cc: Jordan Justen
Cc
On 08/04/2022 10:50, Dave Airlie wrote:
On Fri, 8 Apr 2022 at 18:25, Tvrtko Ursulin
wrote:
On 08/04/2022 08:58, Daniel Vetter wrote:
On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Inherit submitter nice at point of request submission to account
On 07/04/2022 21:49, John Harrison wrote:
On 4/7/2022 08:49, Tvrtko Ursulin wrote:
On 03/06/2021 17:48, Matthew Brost wrote:
From: John Harrison
The meaning of 'default' for the enable_guc module parameter has been
updated to accurately reflect what is supported on current platforms.
So
On 08/04/2022 10:12, Christian König wrote:
Am 08.04.22 um 11:08 schrieb Tvrtko Ursulin:
On 07/04/2022 17:45, Matthew Auld wrote:
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess
On 07/04/2022 17:45, Matthew Auld wrote:
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess is that this comes from the pin_map() for the scratch page,
which does an
On 08/04/2022 08:58, Daniel Vetter wrote:
On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Inherit submitter nice at point of request submission to account for long
running processes getting either externally or self re-niced.
This accounts
On 03/06/2021 17:48, Matthew Brost wrote:
From: John Harrison
The meaning of 'default' for the enable_guc module parameter has been
updated to accurately reflect what is supported on current platforms.
So start using the defaults instead of forcing everything off.
Although, note that right
From: Tvrtko Ursulin
Inherit submitter nice at point of request submission to account for long
running processes getting either externally or self re-niced.
This accounts for the current processing landscape where computational
pipelines are composed of CPU and GPU parts working in tandem
From: Tvrtko Ursulin
Current processing landscape seems to be more and more composed of pipelines
where computations are done on multiple hardware devices. Furthermore some of
the non-CPU devices, like in this case many GPUs supported by the i915 driver,
actually support priority based
From: Tvrtko Ursulin
Inherit submitter nice at point of request submission to account for long
running processes getting either externally or self re-niced.
This accounts for the current processing landscape where computational
pipelines are composed of CPU and GPU parts working in tandem
From: Tvrtko Ursulin
Current processing landscape seems to be more and more composed of pipelines
where computations are done on multiple hardware devices. Furthermore some of
the non-CPU devices, like in this case many GPUs supported by the i915 driver,
actually support priority based
On 04/04/2022 22:42, Matt Roper wrote:
On Fri, Apr 01, 2022 at 09:34:04AM +0100, Tvrtko Ursulin wrote:
On 31/03/2022 00:28, Matt Roper wrote:
Historically we've selected and programmed a single MCR group/instance
ID at driver startup that will steer register accesses for GSLICE/DSS
ranges
On 04/04/2022 22:35, Matt Roper wrote:
On Thu, Mar 31, 2022 at 06:35:52PM +0100, Tvrtko Ursulin wrote:
On 31/03/2022 00:28, Matt Roper wrote:
Historically we've selected and programmed a single MCR group/instance
ID at driver startup that will steer register accesses for GSLICE/DSS
ranges
On 05/04/2022 17:05, Daniel Vetter wrote:
On Tue, Apr 05, 2022 at 04:53:45PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Mixup in rebasing and patchwork re-runs made me push the wrong version of
the patch. Or I even forgot to send out the fixed version. Fix it up.
Signed-off
From: Tvrtko Ursulin
Mixup in rebasing and patchwork re-runs made me push the wrong version of
the patch. Or I even forgot to send out the fixed version. Fix it up.
Signed-off-by: Tvrtko Ursulin
Fixes: 748716041dfa ("drm/i915: Track all user contexts per client")
Cc: Umesh Nerli
From: Tvrtko Ursulin
Inherit submitter nice at point of request submission to account for
long running processes getting either externally or self re-niced.
Nice value will only apply to requests which originate from user
contexts and have default context priority.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
Code added in 71ed60112d5d ("drm/i915: Add kick_backend function to
i915_sched_engine") and ee242ca704d3 ("drm/i915/guc: Implement GuC
priority management") introduced some scheduling related vfuncs which
take integer request priority as argument.
Ma
From: Tvrtko Ursulin
Introduce the concept of context nice value which matches the process
nice.
We do this by extending the struct i915_sched_attr and add a helper
(i915_sched_attr_priority) to be used to convert to effective priority
when used by backend code and for priority sorting
From: Tvrtko Ursulin
Current processing landscape seems to be more and more composed of pipelines
where computations are done on multiple hardware devices. Furthermore some of
the non-CPU devices, like in this case many GPUs supported by the i915 driver,
actually support priority based
On 04/04/2022 16:36, Daniel Vetter wrote:
On Mon, Apr 04, 2022 at 10:23:53AM +0100, Tvrtko Ursulin wrote:
+ Dave and Daniel
Guys, are you okay with merging this via drm-intel-gt-next? It is one new
file at Documentation/gpu/drm-usage-stats.rst only which is outside i915. It
has acks from
On 23/03/2022 13:19, Tvrtko Ursulin wrote:
Hi,
On 21/03/2022 16:45, Alan Previn wrote:
This series:
1. Enables support of GuC to report error-state-capture
using a list of MMIO registers the driver registers
and GuC will dump, log and notify right before a GuC
triggered
potentially re-visit the AMD side by re-sending the
patch which tweaks the fdinfo format there and adds support for relative
engine utilisation as provided by amdgpu.
Regards,
Tvrtko
On 04/04/2022 10:12, Tvrtko Ursulin wrote:
On 01/04/2022 15:22, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On 01/04/2022 15:22, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the outpu
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
From: Tvrtko Ursulin
This will be useful to have at hand in a following patch.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 11 ++-
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 7 insertions
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace tools to be written while at the same time avoiding a more heavy
handed approach of adding a mid-layer to DRM
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between
From: Tvrtko Ursulin
Test-with: 20220401141155.3122817-1-tvrtko.ursu...@linux.intel.com
Tvrtko Ursulin (8):
drm/i915: Explicitly track DRM clients
drm/i915: Make GEM contexts track DRM clients
drm/i915: Track runtime spent in closed and unreachable GEM contexts
drm/i915: Track all user
of the comments below.
On Tue, Feb 22, 2022 at 01:55:57PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Use the i915 exported data in /proc//fdinfo to show GPU utilization
per DRM client.
Example of the output:
intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card0 - 220/ 221 MHz
70% RC6
From: Tvrtko Ursulin
Use the i915 exported data in /proc//fdinfo to show GPU utilization
per DRM client.
Example of the output:
intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card0 - 220/ 221 MHz
70% RC6; 0.62/ 7.08 W; 760 irqs/s
ENGINES BUSY
From: Tvrtko Ursulin
Mostly inherited from the perf_pmu, some basic tests, and some tests to
verify exported GPU busyness is as expected.
v2:
* Skip when kernel does not export drm keys in fdinfo.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Umesh Nerlige Ramappa
---
tests/i915/drm_fdinfo.c
From: Tvrtko Ursulin
Tests and intel_gpu_top will share common code for parsing this file.
v2:
* Fix key-value parsing if valid key line ends with ':'.
* Return number of drm keys found.
* Add DRM_CLIENT_FDINFO_MAX_ENGINES. (Umesh)
* Always zero terminate read buffer. (Umesh)
Signed-off
From: Tvrtko Ursulin
Only first three patches for review purposes (first stage) - adding the test and
intel_gpu_top support.
Tvrtko Ursulin (3):
lib: Helper library for parsing i915 fdinfo output
tests/i915/drm_fdinfo: Basic and functional tests for GPU busyness
exported via fdinfo
On 31/03/2022 00:28, Matt Roper wrote:
Historically we've selected and programmed a single MCR group/instance
ID at driver startup that will steer register accesses for GSLICE/DSS
ranges to a non-terminated instance. Any reads of these register ranges
that don't need a specific unicast access
On 31/03/2022 00:28, Matt Roper wrote:
Rather than treating multicast registers as 'i915_reg_t' let's define
them as a completely new type. This will allow the compiler to help us
make sure we're using multicast-aware functions to operate on multicast
registers.
This plan does break down a
On 31/03/2022 00:28, Matt Roper wrote:
Historically we've selected and programmed a single MCR group/instance
ID at driver startup that will steer register accesses for GSLICE/DSS
ranges to a non-terminated instance. Any reads of these register ranges
that don't need a specific unicast access
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace tools to be written while at the same time avoiding a more heavy
handed approach of adding a mid-layer to DRM
From: Tvrtko Ursulin
This will be useful to have at hand in a following patch.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 11 ++-
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 7 insertions
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between
From: Tvrtko Ursulin
Just a rebase - fully reviewed now.
Example of the intel_gpu_top output:
intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card0 - 220/ 221 MHz
70% RC6; 0.62/ 7.08 W; 760 irqs/s
From: Tvrtko Ursulin
Some libdrmclient operations require that inactive clients are last in the
list. Rather than relying on callers of the library sort routine to
implement their comparison callbacks correctly, enforce this order
directly in the library and let callers comparison callbacks
From: Tvrtko Ursulin
It is currently unused so no need to export it as API for now.
Also change the signature to take struct drm_client_fdinfo in order to
avoid needing to pass in a sized array.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 16
lib
From: Tvrtko Ursulin
Require DRM minor match during client lookup.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 14 --
lib/igt_drm_clients.h | 2 +-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index
From: Tvrtko Ursulin
Prepare for supporting clients belonging to multiple DRM cards by storing
the DRM minor in the client record.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 33 -
lib/igt_drm_clients.h | 6 --
2 files changed, 24 insertions
From: Tvrtko Ursulin
Code movement with some improvements to prepare for further work in
making a vendor agnostic gputop tool possible.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 386 +++
lib/igt_drm_clients.h | 102 +
lib/meson.build
From: Tvrtko Ursulin
Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used
to display a sorted by card and usage list of processes using GPUs.
Signed-off-by: Tvrtko Ursulin
Cc: Rob Clark
---
tools/gputop.c| 276 ++
tools
From: Tvrtko Ursulin
Use the i915 exported data in /proc//fdinfo to show GPU utilization
per DRM client.
Example of the output:
intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card0 - 220/ 221 MHz
70% RC6; 0.62/ 7.08 W; 760 irqs/s
ENGINES BUSY
From: Tvrtko Ursulin
Instead of hard coding the engine names, allow a map of names to indices
to either be passed in or it gets auto-detected (less efficient) while
parsing.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 7 +++---
lib/igt_drm_clients.h | 3 ++-
lib
From: Tvrtko Ursulin
Prep code for incoming work.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_fdinfo.c | 2 ++
lib/igt_drm_fdinfo.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/lib/igt_drm_fdinfo.c b/lib/igt_drm_fdinfo.c
index d5c66881ed43..3926cbd25ecf 100644
--- a/lib
From: Tvrtko Ursulin
Intel_gpu_top gets it's main engine configuration data via PMU probe and
uses that for per client view as well. Furthemore code so far assumed only
clients belonging from a single DRM card would be tracked in a single
clients list.
Break this inter-dependency by moving
From: Tvrtko Ursulin
Mostly inherited from the perf_pmu, some basic tests, and some tests to
verify exported GPU busyness is as expected.
Signed-off-by: Tvrtko Ursulin
---
tests/i915/drm_fdinfo.c | 555
tests/meson.build | 8 +
2 files changed
From: Tvrtko Ursulin
This series contains four main components:
1. Per client support for intel_gpu_top.
2. IGT test for per client data exposed via fdinfo from i915.
3. Extracting intel_gpu_top code into shared IGT libraries - which makes
possible to write:
4. Vendor agnostic
From: Tvrtko Ursulin
Tests and intel_gpu_top will share common code for parsing this file.
v2:
* Fix key-value parsing if valid key line ends with ':'.
* Add DRM_CLIENT_FDINFO_MAX_ENGINES. (Umesh)
* Always zero terminate read buffer. (Umesh)
Signed-off-by: Tvrtko Ursulin
---
lib
Umesh
On Tue, Feb 22, 2022 at 01:55:56PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Mostly inherited from the perf_pmu, some basic tests, and some tests to
verify exported GPU busyness is as expected.
Signed-off-by: Tvrtko Ursulin
---
tests/i915/drm_fdinfo.c | 555
On 30/03/2022 20:52, Umesh Nerlige Ramappa wrote:
On Tue, Feb 22, 2022 at 01:55:55PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Tests and intel_gpu_top will share common code for parsing this file.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_fdinfo.c | 183
From: Tvrtko Ursulin
Continuation of the effort to declutter i915_drv.h.
Also, component specific helpers which consult the iommu/virtualization
helpers moved to respective component source/header files as appropriate.
v2:
* s/dev_priv/i915/ in intel_scanout_needs_vtd_wa. (Lucas)
Signed-off
uction and let the hardware to figure out the local aux_inv
register at runtime to avoid invalidating auxiliary table for all
engines.
Bspec: 45728
v2: Invalidate AUX table for indirect context as well.
Cc: Stuart Summers
Cc: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Signed-off-by: Fe
From: Tvrtko Ursulin
Continuation of the effort to declutter i915_drv.h.
Also, component specific helpers which consult the iommu/virtualization
helpers moved to respective component source/header files as appropriate.
Signed-off-by: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Lucas De Marchi
Acked
+ Joonas
On 25/03/2022 23:03, Francisco Jerez wrote:
Matt Atwood writes:
Newer platforms have DSS that aren't necessarily available for both
geometry and compute, two queries will need to exist. This introduces
the first, when passing a valid engine class and engine instance in the
flags
uction and let the hardware to figure out the local aux_inv
register at runtime to avoid invalidating auxiliary table for all
engines.
Bspec: 45728
v2: Invalidate AUX table for indirect context as well.
Cc: Stuart Summers
Cc: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Signed-off-by: Fe
On 25/03/2022 09:53, Daniel Vetter wrote:
On Fri, Mar 25, 2022 at 09:49:16AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
UAPI with absolutely no documentation should not have been added -
clarify blob format and content will be described externally.
Fixes: 78e1fb3112c0 ("drm
From: Tvrtko Ursulin
UAPI with absolutely no documentation should not have been added -
clarify blob format and content will be described externally.
Fixes: 78e1fb3112c0 ("drm/i915/uapi: Add query for hwconfig blob")
Signed-off-by: Tvrtko Ursulin
Co-developed-by: Jordan Juste
On 24/03/2022 18:57, Jani Nikula wrote:
On Thu, 24 Mar 2022, Tvrtko Ursulin wrote:
On 24/03/2022 11:57, Jani Nikula wrote:
On Thu, 24 Mar 2022, Tvrtko Ursulin wrote:
On 24/03/2022 09:31, Jani Nikula wrote:
On Tue, 22 Mar 2022, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
...
Signed
On 24/03/2022 11:57, Jani Nikula wrote:
On Thu, 24 Mar 2022, Tvrtko Ursulin wrote:
On 24/03/2022 09:31, Jani Nikula wrote:
On Tue, 22 Mar 2022, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Lucas De Marchi
---
Typed up how I see
On 24/03/2022 09:31, Jani Nikula wrote:
On Tue, 22 Mar 2022, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Lucas De Marchi
---
Typed up how I see it - bash away.
So is intel_vtd_active() so performance critical that it needs
Hi Dave, Daniel,
A few fixes for the merge window.
Apart from a uninteresting rename of a field in an unused macro, the rest
are display fixes - two for SAGV and one for TDMS rate calculation on
Icelake and above.
Regards,
Tvrtko
drm-intel-next-fixes-2022-03-24:
- Reject unsupported TMDS
Hi,
On 21/03/2022 16:45, Alan Previn wrote:
This series:
1. Enables support of GuC to report error-state-capture
using a list of MMIO registers the driver registers
and GuC will dump, log and notify right before a GuC
triggered engine-reset event.
2. Updates the ADS
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Lucas De Marchi
---
Typed up how I see it - bash away.
---
drivers/gpu/drm/i915/display/intel_bw.c | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 9 -
drivers/gpu/drm/i915/display/intel_display.h
On 22/03/2022 11:37, Thomas Hellström wrote:
On Tue, 2022-03-22 at 11:20 +, Tvrtko Ursulin wrote:
On 22/03/2022 10:26, Thomas Hellström wrote:
On Tue, 2022-03-22 at 10:13 +, Tvrtko Ursulin wrote:
On 21/03/2022 15:15, Thomas Hellström wrote:
On Mon, 2022-03-21 at 14:43 +
On 22/03/2022 10:26, Thomas Hellström wrote:
On Tue, 2022-03-22 at 10:13 +, Tvrtko Ursulin wrote:
On 21/03/2022 15:15, Thomas Hellström wrote:
On Mon, 2022-03-21 at 14:43 +, Tvrtko Ursulin wrote:
On 21/03/2022 13:40, Thomas Hellström wrote:
Hi,
On Mon, 2022-03-21 at 13:12 +
On 21/03/2022 15:15, Thomas Hellström wrote:
On Mon, 2022-03-21 at 14:43 +, Tvrtko Ursulin wrote:
On 21/03/2022 13:40, Thomas Hellström wrote:
Hi,
On Mon, 2022-03-21 at 13:12 +, Tvrtko Ursulin wrote:
On 21/03/2022 12:33, Thomas Hellström wrote:
On Mon, 2022-03-21 at 12:22 +
On 21/03/2022 16:31, Michael Cheng wrote:
On 2022-03-21 3:30 a.m., Tvrtko Ursulin wrote:
On 19/03/2022 19:42, Michael Cheng wrote:
Previous concern with using drm_clflush_sg was that we don't know
what the
sg_table is pointing to, thus the usage of wbinvd_on_all_cpus to flush
everything
From: Jordan Justen
Also, document DRM_I915_QUERY_HWCONFIG_BLOB with this struct.
v3:
* Add various changes suggested by Tvrtko
v5:
* Fix documenation formatting and verified with `make htmldocs` as
suggested by Daniel
Cc: Daniel Vetter
Signed-off-by: Jordan Justen
Acked-by: Jon
On 21/03/2022 13:40, Thomas Hellström wrote:
Hi,
On Mon, 2022-03-21 at 13:12 +, Tvrtko Ursulin wrote:
On 21/03/2022 12:33, Thomas Hellström wrote:
On Mon, 2022-03-21 at 12:22 +, Tvrtko Ursulin wrote:
On 21/03/2022 11:03, Thomas Hellström wrote:
Hi, Tvrtko.
On 3/21/22 11:27
uction and let the hardware to figure out the local aux_inv
register at runtime to avoid invalidating auxiliary table for all
engines.
Bspec: 45728
Cc: Stuart Summers
Cc: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Signed-off-by: Fei Yang
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c
On 21/03/2022 12:33, Thomas Hellström wrote:
On Mon, 2022-03-21 at 12:22 +, Tvrtko Ursulin wrote:
On 21/03/2022 11:03, Thomas Hellström wrote:
Hi, Tvrtko.
On 3/21/22 11:27, Tvrtko Ursulin wrote:
On 19/03/2022 19:42, Michael Cheng wrote:
To align with the discussion in [1][2
On 21/03/2022 11:03, Thomas Hellström wrote:
Hi, Tvrtko.
On 3/21/22 11:27, Tvrtko Ursulin wrote:
On 19/03/2022 19:42, Michael Cheng wrote:
To align with the discussion in [1][2], this patch series drops all
usage of
wbvind_on_all_cpus within i915 by either replacing the call with certain
On 19/03/2022 19:42, Michael Cheng wrote:
Previous concern with using drm_clflush_sg was that we don't know what the
sg_table is pointing to, thus the usage of wbinvd_on_all_cpus to flush
everything at once to avoid paranoia.
And now we know, or we know it is not a concern?
To make i915
On 19/03/2022 19:42, Michael Cheng wrote:
To align with the discussion in [1][2], this patch series drops all usage of
wbvind_on_all_cpus within i915 by either replacing the call with certain
drm clflush helpers, or reverting to a previous logic.
AFAIU, complaint from [1] was that it is
uction and let the hardware to figure out the local aux_inv
register at runtime to avoid invalidating auxiliary table for all
engines.
Bspec: 45728
Cc: Stuart Summers
Cc: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Signed-off-by: Fei Yang
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c
1201 - 1300 of 2202 matches
Mail list logo
