On Fri, Apr 16, 2021 at 11:37:19AM +0200, Peter Enderborg wrote:
> diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
> index 6fa761c9cc78..3c1a82b51a6f 100644
> --- a/fs/proc/meminfo.c
> +++ b/fs/proc/meminfo.c
> @@ -16,6 +16,7 @@
> #ifdef CONFIG_CMA
> #include
> #endif
> +#include
> #includ
On 14/04/2021 16:09, Tvrtko Ursulin wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Stolen memory is always allocated as physically contiguous pages, mark
the object flags as such.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem
On 14/04/2021 16:33, Tvrtko Ursulin wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: Anusha Srivatsa
In the scenario where local memory is available, we have
rely on CPU access via lmem directly instead of aperture.
v2:
gmch is only relevant for much older hw, therefore we can drop the
On 14/04/2021 16:01, Tvrtko Ursulin wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2:
- s/drm_info/drm_dbg; userspace like
Fix the cases where it is almost already valid kernel doc, for the
others just nerf the warnings for now.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa
Add section for drm/i915 uAPI and pull in i915_drm.h.
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa
Add some example usage for the extension chaining also, which is quite
nifty.
v2: (Daniel)
- clarify that the name is just some integer, also document that the
name space is not global
v3: prefer kernel-doc references for structs
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc
Vetter
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
Reviewed-by: Daniel Vetter
Reviewed-by: Jason Ekstrand
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matthew Auld wrote:
On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: Venkata
On 16/04/2021 17:38, Jason Ekstrand wrote:
On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote:
Add an entry for the new uAPI needed for DG1.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other
On 19/04/2021 15:07, Tvrtko Ursulin wrote:
On 19/04/2021 12:30, Matthew Auld wrote:
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matthew Auld wrote:
On Wed, 14 Apr 2021 at 16
region_query and
region_info, just keep the bare minimum needed for padding
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
7;t be needed
anymore.
v3:
- split stolen lmem vs smem ops(Tvrtko)
- add shortcut for stolen region in i915(Tvrtko)
- sanity check dsm base vs bar size(Xinyun)
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
Cc: Xinyun Liu
---
drivers/gpu/drm/i
From: CQ Tang
Since stolen can now be device local-memory underneath, we should try to
enforce any min_page_size restrictions when allocating pages.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 7 ---
1
Underneath it's the same stuff, so things like the PTE_LM bits for the
GTT should just keep working as-is.
Signed-off-by: Matthew Auld
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/driver
From: CQ Tang
Stolen memory is always allocated as physically contiguous pages, mark
the object flags as such.
v2: move setting I915_BO_ALLOC_CONTIGUOUS into create_stolen
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c
(all GT registers will read back as 0, forcewake requests will timeout,
etc.) so we should abort driver initialization if this happens. We can
confirm that LMEM was initialized successfully via sgunit register
GU_CNTL.
Bspec: 53111
Signed-off-by: Matt Roper
Cc: Caz Yokoyama
Reviewed-by: Matthew
On 20/04/2021 17:06, Tvrtko Ursulin wrote:
On 20/04/2021 14:18, Matthew Auld wrote:
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2:
- s/drm_info/drm_dbg; userspace like
On 20/04/2021 17:14, Tvrtko Ursulin wrote:
On 20/04/2021 14:18, Matthew Auld wrote:
From: CQ Tang
Stolen memory is always allocated as physically contiguous pages, mark
the object flags as such.
v2: move setting I915_BO_ALLOC_CONTIGUOUS into create_stolen
Signed-off-by: CQ Tang
Signed-off
7;t be needed
anymore.
v3:
- split stolen lmem vs smem ops(Tvrtko)
- add shortcut for stolen region in i915(Tvrtko)
- sanity check dsm base vs bar size(Xinyun)
v4(Tvrtko):
- more cleanup
- add some TODOs
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
Cc: X
Underneath it's the same stuff, so things like the PTE_LM bits for the
GTT should just keep working as-is.
Signed-off-by: Matthew Auld
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/driver
we don't have a use for that.
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_sto
From: CQ Tang
Since stolen can now be device local-memory underneath, we should try to
enforce any min_page_size restrictions when allocating pages.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 7 ---
1
On 19/04/2021 16:01, Tvrtko Ursulin wrote:
On 19/04/2021 15:37, Matthew Auld wrote:
On 19/04/2021 15:07, Tvrtko Ursulin wrote:
On 19/04/2021 12:30, Matthew Auld wrote:
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko
On Wed, 21 Apr 2021 at 16:41, Tvrtko Ursulin
wrote:
>
>
> On 21/04/2021 12:42, Matthew Auld wrote:
> > On 19/04/2021 16:01, Tvrtko Ursulin wrote:
> >>
> >> On 19/04/2021 15:37, Matthew Auld wrote:
> >>> On 19/04/2021 15:07, Tvrtko Ursulin wrote:
&g
}
>
> - drm_modeset_unlock_all(drm_dev);
> -
I might remove the {} around ret = -EBUSY, but this is good.
Reviewed-by: Matthew Wilcox (Oracle)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, 21 Apr 2021 at 20:13, Matthew Auld
wrote:
>
> On Wed, 21 Apr 2021 at 16:41, Tvrtko Ursulin
> wrote:
> >
> >
> > On 21/04/2021 12:42, Matthew Auld wrote:
> > > On 19/04/2021 16:01, Tvrtko Ursulin wrote:
> > >>
> > >> On 19/04
region_query and
region_info, just keep the bare minimum needed for padding
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
apply our extensions
to.
v3:(Daniel & Jason)
- drop I915_GEM_CREATE_EXT_SETPARAM. Instead just have each extension
do one thing only, instead of generic setparam which can cover
various use cases.
- add some kernel-doc.
Signed-off-by: Matthew Auld
Signed-off-by: CQ Ta
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freed
In the next patch we want to expose the supported regions to userspace,
which can then be fed into the gem_create_ext placement extensions. For
now treat stolen memory as private from userspace pov.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
ason):
- Add a bunch of kernel-doc
- Simplify design for placements extension
Testcase: igt/gem_create/create-ext-placement-sanity-check
Testcase: igt/gem_create/create-ext-placement-each
Testcase: igt/gem_create/create-ext-placement-all
Signed-off-by: Matthew Auld
Signed-off-by: CQ Tang
From: Abdiel Janulgue
Returns the available memory region areas supported by the HW.
v2(Daniel & Jason):
- Add some kernel-doc, including example usage.
- Drop all the extra rsvd
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
For some internal device local-memory objects it would be useful to have
an option to CPU clear the pages upon gathering the backing store. Note
that this might be before the blitter is useable, which is the case for
some internal GuC objects.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc
: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
Treat it the same as the fake local-memory stuff, where it is disabled
for normal kernels, in case some random UMD is tempted to use this. Once
we have all the other bits and pieces in place, like the TTM conversion,
we can turn this on for real.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
From: Venkata Sandeep Dhanalakota
Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always coherent
mapping.
Cc: Matthew Auld
Cc: CQ Tang
Suggested-by: Michal Wajdeczko
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by
From: Venkata Ramana Nayana
Use I915_MAP_WC when default state object is allocated in LMEM.
Signed-off-by: Venkata Ramana Nayana
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
v2: use i915_coherent_map_type()
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 -
drivers/gpu/drm/i915/gt/intel_gtt.c
simple single page shmemfs object will return a
plain kmap, that is then kept for the lifetime of the page directory.
v2: (Thomas) Rebase on dma_resv and obj->mm.lock removal.
Signed-off-by: Matthew Auld
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
.../drm/i915/gem/selfte
From: Mohammed Khajapasha
Use local memory io BAR address for fbdev's fb_mmap() operation on
discrete, fbdev uses the physical address of our framebuffer for its
fb_mmap() fn.
Signed-off-by: Mohammed Khajapasha
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm
: Ville Syrjälä
Cc: Dhinakaran Pandiyan
Cc: Maarten Lankhorst
Cc: Chris P Wilson
Cc: Daniel Vetter
Cc: Joonas Lahtinen
Cc: Daniele Ceraolo Spurio
Cc: CQ Tang
Signed-off-by: Anusha Srivatsa
Signed-off-by: Matthew Auld
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/display/intel_fbdev.c
From: Mohammed Khajapasha
Return EREMOTE value when frame buffer object is not backed by LMEM
for discrete. If Local memory is supported by hardware the framebuffer
backing gem objects should be from local memory.
Signed-off-by: Mohammed Khajapasha
Signed-off-by: Matthew Auld
Reviewed-by
On 26/04/2021 16:11, Jason Ekstrand wrote:
On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
Add an entry for the new uAPI needed for DG1. Also add the overall
upstream plan, including some notes for the TTM conversion.
v2(Daniel):
- include the overall upstreaming plan
- add a note
On 26/04/2021 16:20, Tvrtko Ursulin wrote:
On 26/04/2021 11:18, Matthew Auld wrote:
We need to general our accessor for the page directories and tables from
Generalise?
using the simple kmap_atomic to support local memory, and this setup
must be done on acquisition of the backing storage
On 26/04/2021 16:22, Tvrtko Ursulin wrote:
On 26/04/2021 11:18, Matthew Auld wrote:
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
v2: use i915_coherent_map_type()
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i9
From: Venkata Ramana Nayana
Use I915_MAP_WC when default state object is allocated in LMEM.
Signed-off-by: Venkata Ramana Nayana
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
ff-by: Matthew Auld
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
.../drm/i915/gem/selftests/i915_gem_context.c | 11 +
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 11 ++---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 26 --
drivers/gpu/drm/i915/gt/intel_ggtt.c
From: Mohammed Khajapasha
Return EREMOTE value when frame buffer object is not backed by LMEM
for discrete. If Local memory is supported by hardware the framebuffer
backing gem objects should be from local memory.
Signed-off-by: Mohammed Khajapasha
Signed-off-by: Matthew Auld
Reviewed-by
: Ville Syrjälä
Cc: Dhinakaran Pandiyan
Cc: Maarten Lankhorst
Cc: Chris P Wilson
Cc: Daniel Vetter
Cc: Joonas Lahtinen
Cc: Daniele Ceraolo Spurio
Cc: CQ Tang
Signed-off-by: Anusha Srivatsa
Signed-off-by: Matthew Auld
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/display/intel_fbdev.c
From: Venkata Sandeep Dhanalakota
Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always coherent
mapping.
Cc: Matthew Auld
Cc: CQ Tang
Suggested-by: Michal Wajdeczko
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by
From: Mohammed Khajapasha
Use local memory io BAR address for fbdev's fb_mmap() operation on
discrete, fbdev uses the physical address of our framebuffer for its
fb_mmap() fn.
Signed-off-by: Mohammed Khajapasha
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
v2: use i915_coherent_map_type()
v3: improve the shared dma-resv object comment
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 -
drivers/gpu/drm
it is better to remove the first put?
>
> Fixes: 82adf901138cc ("drm/i915/gt: Shrink i915_page_directory's slab bucket")
> Signed-off-by: Lv Yunlong
Yes, it looks like this fixes a potential use-after-free. Thanks for the patch,
Reviewed-by: Matthew Auld
Pushed to drm-intel-gt
On 27/04/2021 14:34, Tang, CQ wrote:
-Original Message-
From: Intel-gfx On Behalf Of
Matthew Auld
Sent: Tuesday, April 27, 2021 1:54 AM
To: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v2 4/7] drm/i915/gtt/dgfx: place the PD in LMEM
On 28/04/2021 16:16, Kenneth Graunke wrote:
On Monday, April 26, 2021 2:38:53 AM PDT Matthew Auld wrote:
+Existing uAPI issues
+
+Some potential issues we still need to resolve.
+
+I915 MMAP
+-
+In i915 there are multiple ways to MMAP GEM object, including mapping
On 28/04/2021 16:51, Jason Ekstrand wrote:
On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
Add an entry for the new uAPI needed for DG1. Also add the overall
upstream plan, including some notes for the TTM conversion.
v2(Daniel):
- include the overall upstreaming plan
- add a note
On Wed, Apr 28, 2021 at 12:18:29PM -0500, Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
> >
> > On Tue, Apr 27, 2021 at 08:51:08AM -0500, Jason Ekstrand wrote:
> > > On Fri, Apr 23, 2021 at 5:31 PM Jason Ekstrand
> > > wrote:
> > > >
> > > > This adds a bunch of co
On Wed, Apr 28, 2021 at 12:46:07PM -0500, Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 12:26 PM Matthew Brost
> wrote:
> >
> > On Wed, Apr 28, 2021 at 12:18:29PM -0500, Jason Ekstrand wrote:
> > > On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
> > >
(Kenneth)
- improve the comment for the smem+lmem mmap mode and caching
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave
In the next patch we want to expose the supported regions to userspace,
which can then be fed into the gem_create_ext placement extensions. For
now treat stolen memory as private from userspace pov.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
From: Abdiel Janulgue
Returns the available memory region areas supported by the HW.
v2(Daniel & Jason):
- Add some kernel-doc, including example usage.
- Drop all the extra rsvd
v3(Jason & Tvrtko)
- add back rsvd
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freed
apply our extensions
to.
v3:(Daniel & Jason)
- drop I915_GEM_CREATE_EXT_SETPARAM. Instead just have each extension
do one thing only, instead of generic setparam which can cover
various use cases.
- add some kernel-doc.
Signed-off-by: Matthew Auld
Signed-off-by: CQ Ta
ason):
- Add a bunch of kernel-doc
- Simplify design for placements extension
Testcase: igt/gem_create/create-ext-placement-sanity-check
Testcase: igt/gem_create/create-ext-placement-each
Testcase: igt/gem_create/create-ext-placement-all
Signed-off-by: Matthew Auld
Signed-off-by: CQ Tang
For some internal device local-memory objects it would be useful to have
an option to CPU clear the pages upon gathering the backing store. Note
that this might be before the blitter is useable, which is the case for
some internal GuC objects.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc
: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
Reviewed
Treat it the same as the fake local-memory stuff, where it is disabled
for normal kernels, in case some random UMD is tempted to use this. Once
we have all the other bits and pieces in place, like the TTM conversion,
we can turn this on for real.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
On Thu, Apr 29, 2021 at 02:14:19PM +0200, Daniel Vetter wrote:
> On Wed, Apr 28, 2021 at 01:17:27PM -0500, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 1:02 PM Matthew Brost
> > wrote:
> > >
> > > On Wed, Apr 28, 2021 at 12:46:07PM -0500, Jason Ekstrand wr
m_sys_man_alloc,
> + .free = ttm_sys_man_free,
> +};
> +
> +int ttm_sys_man_init(struct ttm_device *bdev)
> +{
> + struct ttm_resource_manager *man = &bdev->sysman;
> +
> + /*
> +* Initialize the system memory buffer type.
> +* Other types need to be driver / IOCTL initialized.
> +*/
> + man->use_tt = true;
> + man->func = &ttm_sys_manager_func;
> +
> + ttm_resource_manager_init(man, 0);
> + ttm_set_driver_manager(bdev, TTM_PL_SYSTEM, man);
> + ttm_resource_manager_set_used(man, true);
> + return 0;
> +}
Can this return non-zero value later in the series? If not, we can
maybe just make this void.
Either way,
Reviewed-by: Matthew Auld
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Drop the special handling here.
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Auld
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> To improve the handling we want the establish the resource object as base
> class for the backend allocations.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +-
> drivers/gpu/drm/amd/amdgpu/amdg
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Init all fields in ttm_resource_alloc() when we create a new resource.
>
> Signed-off-by: Christian König
> Reviewed-by: Matthew Auld
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 --
> drivers/gpu/drm/ttm/
de/drm/ttm/ttm_range_manager.h
> b/include/drm/ttm/ttm_range_manager.h
> new file mode 100644
> index ..e02b6c8d355e
> --- /dev/null
> +++ b/include/drm/ttm/ttm_range_manager.h
> @@ -0,0 +1,43 @@
> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> +
> +#ifndef _TTM_RANGE_MANAGER_H_
> +#define _TTM_RANGE_MANAGER_H_
> +
> +#include
> +#include
> +
> +/**
> + * struct ttm_range_mgr_node
> + *
> + * @base: base clase we extend
> + * @mm_nodes: MM nodes, usually 1
> + *
> + * Extending the ttm_resource object to manage an address space allocation
> with
> + * one or more drm_mm_nodes.
> + */
> +struct ttm_range_mgr_node {
> + struct ttm_resource base;
> + struct drm_mm_node mm_nodes[];
> +};
> +
> +/**
> + * to_ttm_range_mgr_node
> + *
> + * @res: the resource to upcast
> + *
> + * Upcast the ttm_resource object into a ttm_range_mgr_node object.
> + */
> +static inline struct ttm_range_mgr_node *
> +to_ttm_range_mgr_node(struct ttm_resource *res)
> +{
> + return container_of(res->mm_node, struct ttm_range_mgr_node,
> + mm_nodes[1]);
Should be mm_nodes[0]?
Otherwise I think looks good,
Reviewed-by: Matthew Auld
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Make sure to allocate a resource object here.
>
> Signed-off-by: Christian König
Ok, I guess I have to keep reading,
Reviewed-by: Matthew Auld
> ---
> drivers/gpu/drm/ttm/ttm_sys_manager.c | 7 +++
> 1 file
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Similar to the TTM range manager.
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Auld
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop
;
> struct amdgpu_device *adev = to_amdgpu_device(mgr);
> - struct drm_mm_node *nodes = mem->mm_node;
> + struct ttm_range_mgr_node *node;
> uint64_t usage = 0, vis_usage = 0;
> unsigned pages = mem->num_pages;
> + struct drm_mm_node *nodes;
>
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Similar to the TTM range manager.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/nouveau/nouveau_mem.h | 1 +
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 4
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Make sure to allocate a resource object here.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_sys_manager.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_sys_manager.c
> b/drive
On Fri, Apr 30, 2021 at 12:11:07PM +0200, Daniel Vetter wrote:
> On Thu, Apr 29, 2021 at 09:03:48PM -0700, Matthew Brost wrote:
> > On Thu, Apr 29, 2021 at 02:14:19PM +0200, Daniel Vetter wrote:
> > > On Wed, Apr 28, 2021 at 01:17:27PM -0500, Jason Ekstrand wrote:
> > >
Number of available GuC contexts ids might be limited.
Stop referring in code to macro and use variable instead.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c| 16
Since child contexts do not own the guc_ids or GuC context registration,
child contexts can simply be freed on destroy. Add
guc_child_context_destroy context operation to do this.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 +++
1 file changed, 7
a context is configured by set parallel extension.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submissio
Introduce 'set parallel submit' extension to connect UAPI to GuC
multi-lrc interface. Kernel doc in new uAPI should explain it all.
Cc: Tvrtko Ursulin
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 157 +-
.../gpu/dr
Add very basic (single submission) multi-lrc selftest.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 168 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
3 files changed, 170
will enable multiple do_execbuf calls with a single exec object
array in a later patch.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 31 +--
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu
Update parallel submit doc to point to i915_drm.h
Signed-off-by: Matthew Brost
---
Documentation/gpu/rfc/i915_parallel_execbuf.h | 122 --
Documentation/gpu/rfc/i915_scheduler.rst | 4 +-
2 files changed, 2 insertions(+), 124 deletions(-)
delete mode 100644 Documentation
meantime.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 +-
drivers/gpu/drm/i915/gt/intel_context.c | 1 -
.../drm/i915/gt/intel_execlists_submission.c | 201 +-
3 files changed, 205 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu
. If all the requests are not present this handshake
doesn't work. To work around this, if multi-lrc request has an error we
skip the handshake but still emit the breadcrumbs seqno.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 61 ++-
1
Enable multi-bb execbuf by enabling the set_parallel extension.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index
Goal is to remove all input sanity checks from the core submission.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 35 +++
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem
This will help with upcoming extensions where more than 1 batch can be
submitted in a single execbuf IOCTL.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 19 +--
1 file changed, 9 insertions(+), 10 deletions
Move the job of creating a new file descriptor and passing it back to
userspace to i915_gem_execbuffer2.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 45 ++-
1 file changed, 25 insertions(+), 20 deletions
d put into the dma reseveration excl
fence slot.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 262 +++---
drivers/gpu/drm/i915/gt/intel_context.c | 5 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 9 +
driver
Only track object dependencies on the first request generated from the
execbuf, this help with the upcoming multi-bb execbuf extension.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a
Certain VMA functions in the execbuf IOCTL only need to be called on
first or last BB of a multi-BB submission. eb_relocate() on the first
and eb_release_vmas() on the last. Doing so will save CPU / GPU cycles.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 127
Hold all parallel requests, via a submit fence, until the last request
is generated. If an error occurs in the middle of generating the
requests, skip the requests signal the backend of the error via a
request flag.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c
likely cause many selftests to fail. Follow up
patches will fix all the selftests and enable the delay period.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
.../i915/gem/selftests/i915_gem_coherency.c | 2 +-
.../drm/i915/gem/selftests
On Mon, Aug 02, 2021 at 10:11:18PM -0700, Matthew Brost wrote:
> From: Venkata Sandeep Dhanalakota
>
> Defining vma on stack can cause stack overflow, if
> vma gets populated with new fields.
>
> Cc: Daniele Ceraolo Spurio
> Cc: Tvrtko Ursulin
> Signed-off-by: Ven
On Thu, Aug 05, 2021 at 01:05:09PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> When a non-persistent context exits we currently mark it as banned in
> order to trigger fast termination of any outstanding GPU jobs it may have
> left running.
>
> In doing so we apply a very strict 1ms
301 - 400 of 4754 matches
Mail list logo
