From: Tvrtko Ursulin
To enable accounting of indirect client memory usage (such as page tables)
in the following patch, lets start recording the creator of each PPGTT.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11
Hi Dave, Daniel,
Only two small fixes for the 6.5 RC this week - one display for display
(DPT) corruption under memory pressure, and one for selftests theoretical
edge case.
Regards,
Tvrtko
drm-intel-fixes-2023-07-27:
- Use shmem for dpt objects [dpt] (Radhakrishna Sripada)
- Fix an error
On 21/07/2023 23:21, Tejun Heo wrote:
On Wed, Jul 12, 2023 at 12:46:04PM +0100, Tvrtko Ursulin wrote:
$ cat drm.memory.stat
card0 region=system total=12898304 shared=0 active=0 resident=12111872
purgeable=167936
card0 region=stolen-system total=0 shared=0 active=0 resident=0
On 26/07/2023 11:14, Maarten Lankhorst wrote:
Hey,
On 2023-07-22 00:21, Tejun Heo wrote:
On Wed, Jul 12, 2023 at 12:46:04PM +0100, Tvrtko Ursulin wrote:
$ cat drm.memory.stat
card0 region=system total=12898304 shared=0 active=0
resident=12111872 purgeable=167936
card0 region
On 21/07/2023 23:20, Tejun Heo wrote:
On Fri, Jul 21, 2023 at 12:19:32PM -1000, Tejun Heo wrote:
On Wed, Jul 12, 2023 at 12:46:03PM +0100, Tvrtko Ursulin wrote:
+ drm.active_us
+ GPU time used by the group recursively including all child groups.
Maybe instead add drm.stat and have
On 21/07/2023 23:17, Tejun Heo wrote:
On Wed, Jul 12, 2023 at 12:46:00PM +0100, Tvrtko Ursulin wrote:
+DRM scheduling soft limits
+~~
Please don't say soft limits for this. It means something different for
memcg, so it gets really confusing. Call it "weight base
From: Tvrtko Ursulin
Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available")
added a code path which does not map via GGTT, but was still setting the
ggtt write bit, and so triggering the GGTT flushing.
Fix it by not setting that bit unless the GGTT mapping pat
On 24/07/2023 21:16, Andi Shyti wrote:
Hi Tvrtko,
On Mon, Jul 24, 2023 at 01:56:33PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available")
added a code path which does not map via GGTT, but was still settin
flush appropriate for the mapping that was used. But
it is work and double flush does not really harm. I don't think it does
at least.
Regards,
Tvrtko
--Radhakrishna(RK) Sripada
-Original Message-
From: Tvrtko Ursulin
Sent: Monday, July 24, 2023 5:57 AM
To: intel-...@lists.freedesktop.or
From: Tvrtko Ursulin
Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available")
added a code path which does not map via GGTT, but was still setting the
ggtt write bit, and so triggering the GGTT flushing.
Fix it by not setting that bit unless the GGTT mapping pat
From: Tvrtko Ursulin
For_each_set_bit wants the max number of bits to walk and not the byte
storage size of the source field.
In this case there is no bug since abox_mask can mostly contain bits 0-2.
Another funny thing is that both sizeof(abox_mask), where abox_mask is
unsigned long
From: Tvrtko Ursulin
We can use the existing helper in flush_write_domain() and save some lines
of code.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem
On 21/07/2023 05:28, Yang, Fei wrote:
[snip]
@@ -27,15 +28,8 @@ static bool gpu_write_needs_clflush(struct
drm_i915_gem_object *obj)
The code change here looks accurate, but while we're here, I have a
side question about this function in general...it was originally
introduced in commit
[Here let me just focus on the points which did not get further discussion in
follow ups yet.]
On 19/07/2023 23:31, Matt Roper wrote:
On Wed, Jul 19, 2023 at 01:37:30PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_
On 20/07/2023 01:22, Matt Roper wrote:
On Wed, Jul 19, 2023 at 05:07:15PM -0700, Yang, Fei wrote:
[snip]
@@ -27,15 +28,8 @@ static bool gpu_write_needs_clflush(struct
drm_i915_gem_object *obj)
The code change here looks accurate, but while we're here, I have a side
question about this
Hi,
On 19/07/2023 21:31, T.J. Mercier wrote:
On Wed, Jul 12, 2023 at 4:47 AM Tvrtko Ursulin
wrote:
drm.memory.stat
A nested file containing cumulative memory statistics for the whole
sub-hierarchy, broken down into separate GPUs and separate memory
regions
t in
via drm-misc-next:
Acked-by: Tvrtko Ursulin
Let me know which route works best.
Regards,
Tvrtko
Link: https://reviews.llvm.org/D142609
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Hi Dave, Daniel,
Only two fixes for the 6.5 rc window this week - one perf/OA use after
free on Xe_HP platforms and one defconfig build fix for GCC versions older
than 8.
Regards,
Tvrtko
drm-intel-fixes-2023-07-20:
- Add sentinel to xehp_oa_b_counters [perf] (Andrzej Hajda)
- Revert "drm/i915:
From: Tvrtko Ursulin
Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has
introduced PAT indices to i915 internal APIs, partially replacing the
usage of driver internal cache_level, but has also added a few
questionable design decisions which this patch tries
From: Tvrtko Ursulin
Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has
introduced PAT indices to i915 internal APIs, partially replacing the
usage of driver internal cache_level, but has also added a few
questionable design decisions which this patch tries
From: Tvrtko Ursulin
User feedback indicates significant performance gains are possible in
specific games with non default RPS up/down thresholds.
Expose these tunables via sysfs which will allow users to achieve best
performance when running games and best power efficiency elsewhere.
Note
From: Tvrtko Ursulin
In preparation for exposing via sysfs add helpers for managing rps
thresholds.
v2:
* Force sw and hw re-programming on threshold change.
Signed-off-by: Tvrtko Ursulin
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt
From: Tvrtko Ursulin
Since 36d516be867c ("drm/i915/gt: Switch to manual evaluation of RPS")
thresholds are invariant so lets move their setting to init time.
Signed-off-by: Tvrtko Ursulin
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
Reviewed-by: Andi Shyti
---
drivers/gpu/d
From: Tvrtko Ursulin
Record the default values as preparation for exposing the sysfs controls.
Signed-off-by: Tvrtko Ursulin
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +++
drivers/gpu/drm/i915/gt/intel_rps.c | 2
On 15/07/2023 01:20, Matt Roper wrote:
On Fri, Jul 14, 2023 at 11:11:30AM +0100, Tvrtko Ursulin wrote:
On 14/07/2023 06:43, Yang, Fei wrote:
From: Tvrtko Ursulin
According to the comment in i915_gem_object_can_bypass_llc the
purpose of the function is to return false if the platform
On 14/07/2023 06:43, Yang, Fei wrote:
From: Tvrtko Ursulin
According to the comment in i915_gem_object_can_bypass_llc the
purpose of the function is to return false if the platform/object
has a caching mode where GPU can bypass the LLC.
So far the only platforms which allegedly can do
On 14/07/2023 06:36, Yang, Fei wrote:
[snip]
@@ -326,10 +330,10 @@ int i915_gem_get_caching_ioctl(struct drm_device *dev,
void *data,
goto out;
}
- if (i915_gem_object_has_cache_level(obj, I915_CACHE_LLC) ||
- i915_gem_object_has_cache_level(obj,
On 13/07/2023 16:09, Thomas Zimmermann wrote:
Hi
Am 13.07.23 um 16:41 schrieb Sean Paul:
On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
wrote:
hello Sean,
On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
I'd really prefer this patch (series or single) is not accepted. This
From: Tvrtko Ursulin
Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has
introduced PAT indices to i915 internal APIs, partially replacing the
usage of driver internal cache_level, but has also added a few
questionable design decisions which this patch tries
From: Tvrtko Ursulin
According to the comment in i915_gem_object_can_bypass_llc the purpose of
the function is to return false if the platform/object has a caching mode
where GPU can bypass the LLC.
So far the only platforms which allegedly can do this are Jasperlake and
Elkhartlake
On 12/07/2023 18:49, Teres Alexis, Alan Previn wrote:
On Wed, 2023-07-12 at 10:19 +0100, Tvrtko Ursulin wrote:
On 11/07/2023 23:02, Alan Previn wrote:
On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
buffer boundary when zeroing out reports [perf] (Umesh Nerlige
Ramappa)
- Remove dead code from gen8_pte_encode (Tvrtko Ursulin)
- Fix one wrong caching mode enum usage (Tvrtko Ursulin)
The following changes since commit 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5:
Linux 6.5-rc1 (2023-07-09 13:53:13
From: Tvrtko Ursulin
Simply refactor the existing helpers which collate the data for fdinfo
and share them with thin drm cgroup controller callbacks.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_driver.c | 4 +
drivers/gpu/drm/i915/i915_drm_client.c | 183
From: Tvrtko Ursulin
With a few DRM drivers exposing per client memory stats via the fdinfo
interface already, we can add support for exposing the same data (albeit
aggregated for cgroup hierarchies) via the drm cgroup controller.
Add some driver callbacks and controller code to use them
From: Tvrtko Ursulin
To support container use cases where external orchestrators want to make
deployment and migration decisions based on GPU load and capacity, we can
expose the GPU load as seen by the controller in a new drm.active_us
field. This field contains a monotonic cumulative time
From: Tvrtko Ursulin
When notified by the drm core we are over our allotted time budget, i915
instance will check if any of the GPU engines it is reponsible for is
fully saturated. If it is, and the client in question is using that
engine, it will throttle it.
For now throttling is done
From: Tvrtko Ursulin
Similar to CPU scheduling, implement a concept of weight in the drm cgroup
controller.
Uses the same range and default as the CPU controller - CGROUP_WEIGHT_MIN,
CGROUP_WEIGHT_DFL and CGROUP_WEIGHT_MAX.
Later each cgroup is assigned a time budget proportionaly based
From: Tvrtko Ursulin
Add a new callback via which the drm cgroup controller is notifying the
drm core that a certain process is above its allotted GPU time.
Signed-off-by: Tvrtko Ursulin
---
include/drm/drm_drv.h | 8
kernel/cgroup/drm.c | 16
2 files changed, 24
From: Tvrtko Ursulin
Implement the drm_cgroup_ops->active_time_us callback.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_driver.c | 8 ++
drivers/gpu/drm/i915/i915_drm_client.c | 116 ++---
drivers/gpu/drm/i915/i915_drm_client.h | 2 +
3 fi
From: Tvrtko Ursulin
To reduce the number of tracking going on, especially with drivers which
will not support any sort of control from the drm cgroup controller side,
lets express the funcionality as opt-in and use the presence of
drm_cgroup_ops as activation criteria.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
Add a driver callback and core helper which allow querying the time spent
on GPUs for processes belonging to a group.
Signed-off-by: Tvrtko Ursulin
---
include/drm/drm_drv.h | 28
kernel/cgroup/drm.c | 20
2 files
From: Tvrtko Ursulin
To enable propagation of settings from the cgroup DRM controller to DRM
and vice-versa, we need to start tracking to which cgroups DRM clients
belong.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_file.c | 6
include/drm/drm_file.h | 6
include
From: Tvrtko Ursulin
Skeleton controller without any functionality.
Signed-off-by: Tvrtko Ursulin
---
include/linux/cgroup_drm.h| 9 ++
include/linux/cgroup_subsys.h | 4 +++
init/Kconfig | 7
kernel/cgroup/Makefile| 1 +
kernel/cgroup/drm.c
From: Tvrtko Ursulin
To enable accounting of indirect client memory usage (such as page tables)
in the following patch, lets start recording the creator of each PPGTT.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11
From: Tvrtko Ursulin
With the typical model where the display server opens the file descriptor
and then hands it over to the client(*), we were showing stale data in
debugfs.
Fix it by updating the drm_file->pid on ioctl access from a different
process.
The field is also made RCU protec
From: Tvrtko Ursulin
Use the newly added drm_print_memory_stats helper to show memory
utilisation of our objects in drm/driver specific fdinfo output.
To collect the stats we walk the per memory regions object lists
and accumulate object size into the respective drm_memory_stats
categories
From: Tvrtko Ursulin
Account page table backing store against the owning client memory usage
stats.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt
From: Tvrtko Ursulin
Account ring buffers and logical context space against the owning client
memory usage stats.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_context.c | 14 ++
drivers/gpu/drm/i915/i915_drm_client.c | 10
From: Tvrtko Ursulin
In order to show per client memory usage lets add some infrastructure
which enables tracking buffer objects owned by clients.
We add a per client list protected by a new per client lock and to support
delayed destruction (post client exit) we make tracked objects hold
From: Tvrtko Ursulin
This series contains a proposal for a DRM cgroup controller which implements a
weight based hierarchical GPU usage budget based controller similar in concept
to some of the existing controllers and also exposes GPU memory usage as a read-
only field.
Motivation mostly comes
On 11/07/2023 23:02, Alan Previn wrote:
On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915
On 11/07/2023 10:29, Iddamsetty, Aravind wrote:
On 07-07-2023 18:32, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Account ring buffers and logical context space against the owning client
memory usage stats.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 13
On 11/07/2023 08:48, Iddamsetty, Aravind wrote:
On 10-07-2023 18:50, Tvrtko Ursulin wrote:
On 10/07/2023 11:44, Iddamsetty, Aravind wrote:
On 07-07-2023 18:32, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In order to show per client memory usage lets add some infrastructure
which enables
On 10/07/2023 11:44, Iddamsetty, Aravind wrote:
On 07-07-2023 18:32, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In order to show per client memory usage lets add some infrastructure
which enables tracking buffer objects owned by clients.
We add a per client list protected by a new per
On 07/07/2023 15:17, Rodrigo Vivi wrote:
On Fri, Jul 07, 2023 at 01:46:44PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
added a dedicated gen12_pte_encode but forgot to remove the Gen12 specifi
On 07/07/2023 14:23, Upadhyay, Tejas wrote:
-Original Message-
From: Intel-gfx On Behalf Of
Tvrtko Ursulin
Sent: Friday, July 7, 2023 6:25 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915: Fix one wrong caching mode enum
From: Tvrtko Ursulin
Account page table backing store against the owning client memory usage
stats.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt
From: Tvrtko Ursulin
Account ring buffers and logical context space against the owning client
memory usage stats.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 13 +
drivers/gpu/drm/i915/i915_drm_client.c | 10 ++
drivers/gpu/drm/i915
From: Tvrtko Ursulin
I added tracking of most classes of objects which contribute to client's memory
footprint and accouting along the similar lines as in Rob's msm code. Then
printing it out to fdinfo using the drm helper Rob added.
Accounting by keeping per client lists may not be the most
From: Tvrtko Ursulin
Use the newly added drm_print_memory_stats helper to show memory
utilisation of our objects in drm/driver specific fdinfo output.
To collect the stats we walk the per memory regions object lists
and accumulate object size into the respective drm_memory_stats
categories
From: Tvrtko Ursulin
In order to show per client memory usage lets add some infrastructure
which enables tracking buffer objects owned by clients.
We add a per client list protected by a new per client lock and to support
delayed destruction (post client exit) we make tracked objects hold
From: Tvrtko Ursulin
To enable accounting of indirect client memory usage (such as page tables)
in the following patch, lets start recording the creator of each PPGTT.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 ---
drivers/gpu/drm/i915
From: Tvrtko Ursulin
Commit a4d86249c773 ("drm/i915/gt: Provide a utility to create a scratch
buffer") mistakenly passed in uapi I915_CACHING_CACHED as argument to
i915_gem_object_set_cache_coherency(), which actually takes internal
enum i915_cache_level.
No functional issue since
From: Tvrtko Ursulin
Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
added a dedicated gen12_pte_encode but forgot to remove the Gen12 specific
bit from gen8_pte_encode.
Signed-off-by: Tvrtko Ursulin
Fixes: 9275277d5324 ("drm/i915: use pat_index instead
On 05/07/2023 01:09, Yang, Fei wrote:
>>> From: Tvrtko Ursulin
>>>
>>> Informal commit message for now.
>>>
>>> I got a bit impatient and curious to see if the idea we discussed would
>>> work so sketched something out. I think it is
On 05/07/2023 13:08, Jani Nikula wrote:
On Wed, 05 Jul 2023, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Commit 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence
registers across reset") removed the temporary implementation of a reset
under stop machine but forgot
Hi Dave, Daniel,
A weekly collection of fixes for the drm-next/6.5 merge window.
Mostly small display fixups, one for GuC/SLPC and one header file tidy.
I see last week did not get pulled so this week contains those ones plus
two more fixups - one code tidy actually and one fixup.
Regards,
From: Tvrtko Ursulin
Commit 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence
registers across reset") removed the temporary implementation of a reset
under stop machine but forgot to remove this one commented out define.
Signed-off-by: Tvrtko Ursulin
---
drivers/gp
From: Tvrtko Ursulin
Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
preempt disable section over the hardware reset callback to prepare the
driver for being able to reset from atomic contexts.
In retrospect I can see that the work item at a time was abou
On 30/06/2023 07:55, Yang, Fei wrote:
> From: Tvrtko Ursulin
>
> Informal commit message for now.
>
> I got a bit impatient and curious to see if the idea we discussed would
> work so sketched something out. I think it is what I was describing back
> then..
&g
On 29/06/2023 21:42, Alan Previn wrote:
On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915
From: Tvrtko Ursulin
Informal commit message for now.
I got a bit impatient and curious to see if the idea we discussed would
work so sketched something out. I think it is what I was describing back
then..
So high level idea is to teach the driver what caching modes are hidden
behind PAT
On 29/06/2023 06:39, Yang, Fei wrote:
> From: Tvrtko Ursulin
>
> Informal commit message for now.
>
> I got a bit impatient and curious to see if the idea we discussed would
> work so sketched something out. I think it is what I was describing back
> then
Hi Dave, Daniel,
A weekly collection of fixes for the drm-next/6.5 merge window.
Mostly small display fixups, one for GuC/SLPC and one header file tidy.
Regards,
Tvrtko
drm-intel-next-fixes-2023-06-29:
- Allow DC states along with PW2 only for PWB functionality [adlp+] (Imre Deak)
- Fix SSC
From: Tvrtko Ursulin
Informal commit message for now.
I got a bit impatient and curious to see if the idea we discussed would
work so sketched something out. I think it is what I was describing back
then..
So high level idea is to teach the driver what caching modes are hidden
behind PAT
On 27/06/2023 14:28, Jani Nikula wrote:
On Tue, 09 May 2023, fei.y...@intel.com wrote:
From: Fei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not
On 20/06/2023 14:23, Ira Weiny wrote:
Sumitra Sharma wrote:
On Sun, Jun 18, 2023 at 11:11:08AM -0700, Ira Weiny wrote:
Sumitra Sharma wrote:
kmap() has been deprecated in favor of the kmap_local_page()
due to high cost, restricted mapping space, the overhead of a
global lock for
On 21/06/2023 19:51, Thomas Hellström (Intel) wrote:
On 6/21/23 18:35, Ira Weiny wrote:
Thomas Hellström (Intel) wrote:
I think one thing worth mentioning in the context of this patch is that
IIRC kmap_local_page() will block offlining of the mapping CPU until
kunmap_local(), so while I
Hi Dave, Daniel,
A weekly collection of fixes for the drm-next/6.5 merge window:
One fix for incorrect error handling in the frame buffer mmap callback,
HuC init error handling fix, missing wakeref during GSC init and a build
fix when !CONFIG_PROC_FS.
Regards,
Tvrtko
From: Tvrtko Ursulin
With the typical model where the display server opens the file descriptor
and then hands it over to the client(*), we were showing stale data in
debugfs.
Fix it by updating the drm_file->pid on ioctl access from a different
process.
The field is also made RCU protec
On 16/06/2023 12:17, Tvrtko Ursulin wrote:
On 16/06/2023 11:16, Andi Shyti wrote:
Hi Arnd,
On Fri, Jun 16, 2023 at 11:31:47AM +0200, Arnd Bergmann wrote:
From: Arnd Bergmann
The function is only defined if CONFIG_PROC_FS is enabled:
ld.lld: error: undefined symbol
On 19/06/2023 08:59, Thomas Hellström (Intel) wrote:
On 6/18/23 20:11, Ira Weiny wrote:
Sumitra Sharma wrote:
kmap() has been deprecated in favor of the kmap_local_page()
due to high cost, restricted mapping space, the overhead of a
global lock for synchronization, and making the process
On 16/06/2023 11:16, Andi Shyti wrote:
Hi Arnd,
On Fri, Jun 16, 2023 at 11:31:47AM +0200, Arnd Bergmann wrote:
From: Arnd Bergmann
The function is only defined if CONFIG_PROC_FS is enabled:
ld.lld: error: undefined symbol: i915_drm_client_fdinfo
referenced by i915_driver.c
On 14/06/2023 13:35, Sumitra Sharma wrote:
Pages allocated with GFP_KERNEL cannot come from Highmem.
That is why there is no need to call kmap() on them.
Are you sure it is GFP_KERNEL backed and not tmpfs? I am not sure myself
so let me copy Matt and Thomas if they happen to know off hand.
From: Tvrtko Ursulin
Use the newly added drm_print_memory_stats helper to show memory
utilisation of our objects in drm/driver specific fdinfo output.
To collect the stats we walk the per memory regions object lists
and accumulate object size into the respective drm_memory_stats
categories
From: Tvrtko Ursulin
Account ring buffers and logical context space against the owning client
memory usage stats.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 8
drivers/gpu/drm/i915/i915_drm_client.c | 10 ++
drivers/gpu/drm/i915
From: Tvrtko Ursulin
Account page table backing store against the owning client memory usage
stats.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt
From: Tvrtko Ursulin
To enable accounting of indirect client memory usage (such as page tables)
in the following patch, lets start recording the creator of each PPGTT.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 ---
drivers/gpu/drm/i915
From: Tvrtko Ursulin
In order to show per client memory usage lets add some infrastructure
which enables tracking buffer objects owned by clients.
We add a per client list protected by a new per client lock and to support
delayed destruction (post client exit) we make tracked objects hold
From: Tvrtko Ursulin
I added tracking of most classes of objects which contribute to client's memory
footprint and accouting along the similar lines as in Rob's msm code. Then
printing it out to fdinfo using the drm helper Rob added.
Accounting by keeping per client lists may not be the most
On 09/06/2023 18:09, Rob Clark wrote:
On Fri, Jun 9, 2023 at 7:12 AM Tvrtko Ursulin
wrote:
On 09/06/2023 13:44, Iddamsetty, Aravind wrote:
On 09-06-2023 17:41, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
I need a new flavour of the drm_gem_prime_fd_to_handle helper, one which
On 09/06/2023 13:44, Iddamsetty, Aravind wrote:
On 09-06-2023 17:41, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
I need a new flavour of the drm_gem_prime_fd_to_handle helper, one which
will return a reference to a newly created GEM objects (if created), in
order to enable tracking
On 09/06/2023 13:52, Christian König wrote:
Am 09.06.23 um 14:09 schrieb Tvrtko Ursulin:
On 09/06/2023 07:32, Christian König wrote:
Am 08.06.23 um 16:30 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
For dma_fence_is_signaled signaling critical path annotations are an
annoying cause
From: Tvrtko Ursulin
Use the newly added drm_print_memory_stats helper to show memory
utilisation of our objects in drm/driver specific fdinfo output.
To collect the stats we walk the per memory regions object lists
and accumulate object size into the respective drm_memory_stats
categories
From: Tvrtko Ursulin
I need a new flavour of the drm_gem_prime_fd_to_handle helper, one which
will return a reference to a newly created GEM objects (if created), in
order to enable tracking of imported i915 GEM objects in the following
patch.
Minor code reshuffule and only trivial additions
From: Tvrtko Ursulin
We want to be able to show memory usage of imported dma-buf opjects in the
fdinfo stats.
To achieve this we wrap drm_gem_prime_fd_to_handle(_obj) in
i915_gem_prime_fd_to_handle and append some client management at the end.
Signed-off-by: Tvrtko Ursulin
Cc: Aravind
From: Tvrtko Ursulin
Account page table backing store against the owning client memory usage
stats.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt
From: Tvrtko Ursulin
Account ring buffers and logical context space against the owning client
memory usage stats.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 ++
drivers/gpu/drm/i915/i915_drm_client.c | 10 ++
drivers/gpu/drm/i915
From: Tvrtko Ursulin
In order to show per client memory usage lets start tracking which
objects belong to which clients.
We start with objects explicitly created by object creation UAPI and
track it on a new per client lists, protected by a new per client lock.
In order for delayed destruction
From: Tvrtko Ursulin
To enable accounting of indirect client memory usage (such as page tables)
in the following patch, lets start recording the creator of each PPGTT.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 ---
drivers/gpu/drm/i915
301 - 400 of 2126 matches
Mail list logo
