On Mon, Jul 19, 2021 at 4:10 AM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 16:23, Jason Ekstrand wrote:
> >
> > On Fri, Jul 16, 2021 at 9:52 AM Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 15/07/2021 11:15, Matthew Auld wrote:
> >
On Tue, Jul 20, 2021 at 3:25 AM Tvrtko Ursulin
wrote:
>
>
> On 19/07/2021 19:30, Jason Ekstrand wrote:
> > If the driver was not fully loaded, we may still have globals lying
> > around. If we don't tear those down in i915_exit(), we'll leak a bunch
> > of me
On Tue, Jul 20, 2021 at 9:18 AM Daniel Vetter wrote:
>
> On Mon, Jul 19, 2021 at 01:30:44PM -0500, Jason Ekstrand wrote:
> > If the driver was not fully loaded, we may still have globals lying
> > around. If we don't tear those down in i915_exit(), we'll leak a bunc
Sorry... didn't reply to everything the first time
On Tue, Jul 20, 2021 at 3:25 AM Tvrtko Ursulin
wrote:
>
>
> On 19/07/2021 19:30, Jason Ekstrand wrote:
> > If the driver was not fully loaded, we may still have globals lying
> > around. If we don't tear those do
unwinding - if you run selftest with
> nomodeset you get nothing, *shrug*.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_pci.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/g
s but can show up in
other random IGTs depending on test execution order.
Jason Ekstrand (6):
drm/i915: Call i915_globals_exit() after i915_pmu_exit()
drm/i915: Call i915_globals_exit() if pci_register_device() fails
drm/i915: Use a table for i915_init/exit
drm/ttm: Force re-init if ttm_globa
We should tear down in the opposite order we set up.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm
In the unlikely event that pci_register_device() fails, we were tearing
down our PMU setup but not globals. This leaves a bunch of memory slabs
lying around.
Signed-off-by: Jason Ekstrand
Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global")
Reviewed-by: Dan
river always succeeding to load
the driver and then properly tearing down the partially loaded driver.
Signed-off-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pci.c | 104 --
drivers/gpu/drm/i915/i915_perf.c
If we have a failure, decrement the reference count so that the next
call to ttm_global_init() will actually do something instead of assume
everything is all set up.
Signed-off-by: Jason Ekstrand
Fixes: 62b53b37e4b1 ("drm/ttm: use a static ttm_bo_global instance")
Reviewed-by: Chris
again, we'll re-create those debugfs entries
and debugfs will complain in dmesg that we're creating entries that
already exist. This patch fixes this problem by changing the lifetime
of the whole TTM debugfs directory to match that of the TTM global
state.
Signed-off-by: Jason Ekstra
emory situations.
Signed-off-by: Jason Ekstrand
Fixes: 88be9a0a06b7 ("drm/i915/ttm: add ttm_buddy_man")
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_buddy.c | 44 ++---
drivers/gpu/drm/i915/i915_buddy.h | 3 +-
drivers/gpu/drm/i915/i915_globals.c | 2 ++
3 fi
Fixed all the nits below locally. It'll be in the next send.
On Tue, Jul 20, 2021 at 5:53 AM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
> >
> > From: Thomas Hellström
> >
> > Until we support p2p dma or as a complement
On Tue, Jul 20, 2021 at 4:07 AM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
> >
> > From: Thomas Hellström
> >
> > If our exported dma-bufs are imported by another instance of our driver,
> > that instance will typically have
On Tue, Jul 20, 2021 at 4:35 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> >
> > Instead of hand-rolling the same three calls in each function, pull them
> > into an i915_gem_object_create_user helper. Apart from re-ordering of
> &g
On Mon, Jul 19, 2021 at 3:18 AM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
> >
> > Since we don't allow changing the set of regions after creation, we can
> > make ext_set_placements() build up the region set directly in the
> &
On Wed, Jul 21, 2021 at 4:06 AM Tvrtko Ursulin
wrote:
>
>
> On 20/07/2021 19:13, Jason Ekstrand wrote:
> > If the driver was not fully loaded, we may still have globals lying
> > around. If we don't tear those down in i915_exit(), we'll leak a bunch
> > of me
On Wed, Jul 21, 2021 at 6:26 AM Daniel Vetter wrote:
>
> On Tue, Jul 20, 2021 at 09:55:22AM -0500, Jason Ekstrand wrote:
> > On Tue, Jul 20, 2021 at 9:18 AM Daniel Vetter wrote:
> > >
> > > On Mon, Jul 19, 2021 at 01:30:44PM -0500, Jason Ekstrand wrote:
> > &g
s but can show up in
other random IGTs depending on test execution order.
Jason Ekstrand (6):
drm/i915: Call i915_globals_exit() after i915_pmu_exit()
drm/i915: Call i915_globals_exit() if pci_register_device() fails
drm/i915: Use a table for i915_init/exit (v2)
drm/ttm: Force re-init if ttm
In the unlikely event that pci_register_device() fails, we were tearing
down our PMU setup but not globals. This leaves a bunch of memory slabs
lying around.
Signed-off-by: Jason Ekstrand
Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global")
Reviewed-by: Dan
We should tear down in the opposite order we set up.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm
river always succeeding to load
the driver and then properly tearing down the partially loaded driver.
v2 (Tvrtko Ursulin):
- Guard init_funcs[i].exit with GEM_BUG_ON(i >= ARRAY_SIZE(init_funcs))
v2 (Daniel Vetter):
- Update the docstring for i915.mock_selftests
Signed-off-by: Jason Ekstran
emory situations.
Signed-off-by: Jason Ekstrand
Fixes: 88be9a0a06b7 ("drm/i915/ttm: add ttm_buddy_man")
Cc: Matthew Auld
Cc: Christian König
---
drivers/gpu/drm/i915/i915_buddy.c | 44 ++---
drivers/gpu/drm/i915/i915_buddy.h | 3 +-
drivers/gpu/drm/i915/i915_globa
again, we'll re-create those debugfs entries
and debugfs will complain in dmesg that we're creating entries that
already exist. This patch fixes this problem by changing the lifetime
of the whole TTM debugfs directory to match that of the TTM global
state.
Signed-off-by: Jason Ekstra
If we have a failure, decrement the reference count so that the next
call to ttm_global_init() will actually do something instead of assume
everything is all set up.
Signed-off-by: Jason Ekstrand
Fixes: 62b53b37e4b1 ("drm/ttm: use a static ttm_bo_global instance")
Reviewed-by: Chris
On Wed, Jul 21, 2021 at 3:25 AM Matthew Auld
wrote:
>
> On Tue, 20 Jul 2021 at 23:04, Jason Ekstrand wrote:
> >
> > On Tue, Jul 20, 2021 at 4:35 AM Matthew Auld
> > wrote:
> > >
> > > On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> > &g
On Wed, Jul 21, 2021 at 3:32 AM Matthew Auld
wrote:
>
> On Tue, 20 Jul 2021 at 23:07, Jason Ekstrand wrote:
> >
> > On Mon, Jul 19, 2021 at 3:18 AM Matthew Auld
> > wrote:
> > >
> > > On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
> > >
On Mon, Jul 19, 2021 at 8:35 AM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 20:49, Jason Ekstrand wrote:
> >
> > On Fri, Jul 16, 2021 at 1:45 PM Matthew Auld
> > wrote:
> > >
> > > On Fri, 16 Jul 2021 at 18:39, Jason Ekstrand wrote:
> > >
egion"
- Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in
i915_gem_dumb_create()"
- Misc. review feedback from Matthew Auld
v8:
- Misc. review feedback from Matthew Auld
Jason Ekstrand (5):
drm/i915/gem: Check object_can_migrate from object_migrate
drm/i915/gem
ff-by: Jason Ekstrand
Cc: Daniel Vetter
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 13 ++---
.../gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 15 ---
2 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i91
tthew Auld):
- Get rid of MAX_N_PLACEMENTS
- Drop kfree(placements) from set_placements()
v3 (Matthew Auld):
- Properly set ext_data->n_placements
Signed-off-by: Jason Ekstrand
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 82 --
1 fil
This doesn't really fix anything serious since the chances of a client
creating and destroying a mass of dumb BOs is pretty low. However, it
is called by the other two create IOCTLs to garbage collect old objects.
Call it here too for consistency.
Signed-off-by: Jason Ekstrand
Review
i915_gem_dumb_create() in a separate patch
- Move i915_gem_object_alloc() below the simple error checks
v3 (Matthew Auld):
- Add __ to i915_gem_object_create_user and kerneldoc which warns the
caller that it's not validating anything.
Signed-off-by: Jason Ekstrand
Reviewed-by: Matthew
d by, say,
i915_gem_object_migrate().
Signed-off-by: Jason Ekstrand
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm
test error cases
Reported-by: Michael J. Ruhl
Signed-off-by: Thomas Hellström
Signed-off-by: Michael J. Ruhl
Signed-off-by: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 37 --
.../drm/i915/gem/selftests/i915_gem_dmabu
: Thomas Hellström
Signed-off-by: Michael J. Ruhl
Reported-by: kernel test robot
Signed-off-by: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 23 -
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 87 ++-
2 files changed, 106
On Wed, Jul 21, 2021 at 1:56 PM Daniel Vetter wrote:
>
> On Wed, Jul 21, 2021 at 05:25:41PM +0100, Matthew Auld wrote:
> > On 21/07/2021 16:23, Jason Ekstrand wrote:
> > > There's no reason that I can tell why this should be per-i915_buddy_mm
> > > and doing
entire kernel? That also seems to
be pretty good evidence that it's not useful.
Reviewed-by: Jason Ekstrand
Feel free to land at-will and I'll deal with merge conflicts on my end.
> Cc: David Airlie
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/
On Thu, Jul 15, 2021 at 5:16 AM Matthew Auld wrote:
>
> From: Chris Wilson
>
> Jason Ekstrand requested a more efficient method than userptr+set-domain
> to determine if the userptr object was backed by a complete set of pages
> upon creation. To be more efficient than sim
On Thu, Jul 22, 2021 at 3:44 AM Matthew Auld
wrote:
>
> On Wed, 21 Jul 2021 at 21:28, Jason Ekstrand wrote:
> >
> > On Thu, Jul 15, 2021 at 5:16 AM Matthew Auld wrote:
> > >
> > > From: Chris Wilson
> > >
> > > Jason Ekstrand requested a
s the way. Or maybe it isn't. Or maybe they would
> have said meh. I just don't see how the rush was justified given the
> code in question.
>
> Regards,
>
> Tvrtko
>
> > -Daniel
> >
> >>> Noticed while reviewing a patch set fro
egion"
- Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in
i915_gem_dumb_create()"
- Misc. review feedback from Matthew Auld
v8:
- Misc. review feedback from Matthew Auld
v9:
- Replace the i915/ttm patch with two that are hopefully more correct
Jason Ekstrand (6):
tthew Auld):
- Get rid of MAX_N_PLACEMENTS
- Drop kfree(placements) from set_placements()
v3 (Matthew Auld):
- Properly set ext_data->n_placements
Signed-off-by: Jason Ekstrand
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 82 --
1 fil
ff-by: Jason Ekstrand
Cc: Daniel Vetter
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 13 ++---
.../gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 15 ---
2 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i91
This doesn't really fix anything serious since the chances of a client
creating and destroying a mass of dumb BOs is pretty low. However, it
is called by the other two create IOCTLs to garbage collect old objects.
Call it here too for consistency.
Signed-off-by: Jason Ekstrand
Review
i915_gem_dumb_create() in a separate patch
- Move i915_gem_object_alloc() below the simple error checks
v3 (Matthew Auld):
- Add __ to i915_gem_object_create_user and kerneldoc which warns the
caller that it's not validating anything.
Signed-off-by: Jason Ekstrand
Reviewed-by: Matthew
grate also uses __i915_ttm_get_pages to do the
migration so this meant it was unsafe to call on an already populated
object. This patch checks i915_gem_object_has_pages() before trying to
__i915_gem_object_set_pages so i915_ttm_migrate is safe to call, even on
populated objects.
Signed-off-by: Jason Ekstran
: Thomas Hellström
Signed-off-by: Michael J. Ruhl
Reported-by: kernel test robot
Signed-off-by: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 23 -
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 87 ++-
2 files changed, 106
test error cases
Reported-by: Michael J. Ruhl
Signed-off-by: Thomas Hellström
Signed-off-by: Michael J. Ruhl
Signed-off-by: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 37 --
.../drm/i915/gem/selftests/i915_gem_dmabu
contained. Once the migration is
complete, the object will have pages, obj->mm.region will be correct,
and we're done lying.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gp
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044
On Fri, Jul 23, 2021 at 6:35 AM Matthew Auld wrote:
>
> From: Chris Wilson
>
> Jason Ekstrand requested a more efficient method than userptr+set-domain
> to determine if the userptr object was backed by a comple
Are there IGTs for this anywhere?
On Fri, Jul 23, 2021 at 12:47 PM Jason Ekstrand wrote:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044
>
> On Fri, Jul 23, 2021 at 6:35 AM Matthew Auld wrote:
> >
> > From: Chris Wilson
> >
> > Jason
Generally a big fan. 👍
--Jason
On July 23, 2021 19:11:34 Lucas De Marchi wrote:
Patches 1 and 2 are already being reviewed elsewhere. Discussion on 2nd
patch made me revive something I started after comment from Ville
at
https://patchwork.freedesktop.org/patch/428168/?series=88988&rev=1#comm
On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld
wrote:
>
> On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote:
> >
> > This patch series fixes an issue with discrete graphics on Intel where we
> > allowed dma-buf import while leaving the object in local memory. This
> &g
On Mon, Jul 26, 2021 at 3:06 AM Matthew Auld
wrote:
>
> On Fri, 23 Jul 2021 at 18:48, Jason Ekstrand wrote:
> >
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044
>
> Cool, is that ready to go? i.e can we start merging the kernel + IGT side.
Yes, it
On Mon, Jul 26, 2021 at 3:31 AM Maarten Lankhorst
wrote:
>
> Op 23-07-2021 om 13:34 schreef Matthew Auld:
> > From: Chris Wilson
> >
> > Jason Ekstrand requested a more efficient method than userptr+set-domain
> > to determine if the userptr object was backed by a
t; So move that check first, for a bit of orderliness. With Jason's
> module init/exit table this now becomes trivial.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
Reviewed-by: Jason Ekstrand
> ---
> drivers/gpu/drm/i915/i915_pci.c | 2 +-
> 1 file changed,
g the static global.slab_cache to just a slab_cache.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_active.c | 31 ++---
> drivers/gpu/drm/i915/i915_active.h | 3 +++
> drivers/gpu/drm/i915/i915_globals
the static global.slab_blocks to just a
> slab_blocks.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_buddy.c | 25 -
> drivers/gpu/drm/i915/i915_buddy.h | 3 ++-
> drivers/gpu/drm/i915/i915_globals.c |
o each patch because there's quite a bit of
> > noise with removing the static global.slab_ce to just a
> > slab_ce.
> >
> > Cc: Jason Ekstrand
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c | 25
On Mon, Jul 26, 2021 at 10:29 AM Matthew Auld
wrote:
>
> On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand wrote:
> >
> > On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld
> > wrote:
> > >
> > > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote:
> > &
ng the static global.slab_luts to just a
> slab_luts.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 25 +++--
> drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +++
> drivers/gpu/drm/i9
the static global.slab_objects to just a
> slab_objects.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 26 +++---
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +++
> drivers/gpu/drm/
On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand wrote:
>
> On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin
> wrote:
> >
> >
> > On 23/07/2021 20:29, Daniel Vetter wrote:
> > > With the global kmem_cache shrink infrastructure gone there's nothing
&
g the static global.slab_requests|execute_cbs to just a
> slab_requests|execute_cbs.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_globals.c | 2 --
> drivers/gpu/drm/i915/i915_pci.c | 2 ++
> drivers/gpu/drm/i915/i915_reques
t; noise with removing the static global.slab_dependencies|priorities to just a
> slab_dependencies|priorities.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_globals.c | 2 --
> drivers/gpu/drm/i915/i915_globals.h | 2 --
> drivers/gpu/
ng the static global.slab_vmas to just a
> slab_vmas.
>
> We have to keep i915_drv.h include in i915_globals otherwise there's
> nothing anymore that pulls in GEM_BUG_ON.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i9
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> No longer used.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
Reviewed-by: Jason Ekstrand
But, also, tvrtko is right that dumping all that stuff in i915_pci.c
isn't great. Mind typing a quick follow-on
On Mon, Jul 26, 2021 at 11:08 AM Tvrtko Ursulin
wrote:
> On 26/07/2021 16:42, Jason Ekstrand wrote:
> > On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand
> > wrote:
> >>
> >> On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin
> >> wrote:
> >>>
On Mon, Jul 26, 2021 at 11:31 AM Tvrtko Ursulin
wrote:
>
>
> On 26/07/2021 17:20, Jason Ekstrand wrote:
> > On Mon, Jul 26, 2021 at 11:08 AM Tvrtko Ursulin
> > wrote:
> >> On 26/07/2021 16:42, Jason Ekstrand wrote:
> >>> On Mon, Jul 26, 202
dule init table is a lot more obvious.
None of those are deal-breakers but they're kind-of nice. Anyway,
this one is also
Reviewed-by: Jason Ekstrand
--Jason
> There was a bug to fix relating to mock tests, but that is where the
> exercise should have stopped for now. After that it
regions.
Signed-off-by: Matthew Auld
Cc: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
.../drm/i915/gem/selftests/i915_gem_mman.c| 46 ++-
1 file changed, 4 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm
On Tue, Aug 3, 2021 at 10:09 AM Daniel Vetter wrote:
> On Wed, Jul 28, 2021 at 4:22 PM Matthew Auld
> wrote:
> >
> > On Mon, 26 Jul 2021 at 17:10, Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 26/07/2021 16:14, Jason Ekstrand wrote:
> &
Both are
Reviewed-by: Jason Ekstrand
On Tue, Aug 3, 2021 at 7:49 AM Daniel Vetter wrote:
>
> It's already removed, this just garbage collects it all.
>
> v2: Rebase over s/GEN/GRAPHICS_VER/
>
> v3: Also ditch eb.reloc_pool and eb.reloc_context (Maarten)
>
> Signe
+mesa-dev and some Intel mesa people.
On Wed, Apr 14, 2021 at 5:23 AM Daniel Vetter wrote:
>
> On Tue, Apr 13, 2021 at 12:47:06PM +0100, Matthew Auld wrote:
> > Add an entry for the new uAPI needed for DG1.
> >
> > v2(Daniel):
> > - include the overall upstreaming plan
> > - add a note for mm
with the placements extension
> - rather than have a generic setparam which can cover multiple
> use cases, have each extension be responsible for one thing
> only
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc
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-...@lists.freedesktop.org
Reviewed-by: Daniel Vetter
---
include/uapi/drm/i915_drm.h | 54 ++---
1 file
Reviewed-by: Jason Ekstrand
On April 16, 2021 05:37:55 Matthew Auld wrote:
Add a note about the two-step process.
v2(Tvrtko):
- Also document the other method of just passing in a buffer which is
large enough, which avoids two ioctl calls. Can make sense for
smaller query items
On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote:
>
> 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(D
Not going to comment on everything on the first pass...
On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote:
>
> Hi,
>
> This is our initial proposal for explicit fences everywhere and new memory
> management that doesn't use BO fences. It's a redesign of how Linux graphics
> drivers work, and it
It's still early in the morning here and I'm not awake yet so sorry if
this comes out in bits and pieces...
On Tue, Apr 20, 2021 at 7:43 AM Daniel Stone wrote:
>
> Hi Marek,
>
> On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote:
>>
>> 2. Explicit synchronization for window systems and modesetting
the submit and return fences for modesetting and other producer<->consumer
> >> scenarios?
> > Let me work on the full replay for your rfc first, because there's a lot
> > of details here and nuance.
> > -Daniel
> >
> >> Thanks,
> >> Marek
> &
gt; >> the submit and return fences for modesetting and other
> > >> producer<->consumer
> > >> scenarios?
> > > Let me work on the full replay for your rfc first, because there's a lot
> > > of details here and nuance.
> > > -Da
On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
wrote:
>
>
> On 19/04/2021 16:19, Jason Ekstrand wrote:
> > On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote:
> >>
> >> On 16/04/2021 17:38, Jason Ekstrand wrote:
> >>> On Thu, Apr 15
On Tue, Apr 20, 2021 at 1:54 PM Daniel Vetter wrote:
>
> On Tue, Apr 20, 2021 at 7:45 PM Daniel Stone wrote:
>
> > And something more concrete:
> >
> > dma_fence.
> >
> > This already has all of the properties described above. Kernel-wise, it
> > already devolves to CPU-side signaling when it cr
On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin
wrote:
>
> On 20/04/2021 18:00, Jason Ekstrand wrote:
> > On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 19/04/2021 16:19, Jason Ekstrand wrote:
> >>> O
On Wed, Apr 21, 2021 at 9:25 AM Tvrtko Ursulin
wrote:
>
>
> On 21/04/2021 14:54, Jason Ekstrand wrote:
> > On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin
> > wrote:
> >>
> >> On 20/04/2021 18:00, Jason Ekstrand wrote:
> >>> On Tue, A
really care
about solving this problem, they can do it properly.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 85 +--
drivers/gpu/drm/i915/gt/intel_context_param.c | 63 ---
xt.
3. Get rid of the separation between context close and context destroy
4. Get rid of the RCU on i915_gem_context
However, these should probably be done as a separate patch series as this
one is already starting to get longish, especially if you consider the 89
IGT patches that go along w
ml
[2]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067031.html
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 ++--
.../gpu/drm/i915/gem/i915_gem_context_types.h| 1 -
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. This doesn't fix anything but does simplify
the code a bit.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +++
.../gpu/drm/i91
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem
ly()
- Drop the dma_fence reference
- Improved commit message
v3 (Jason Ekstrand):
- Move the dma_fence_put() to before the error exit
Signed-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 49 +--
..
data so it's not useful for discovering what engines
are in the context. It's also not a replacement for the recently
removed I915_CONTEXT_CLONE_ENGINES because it doesn't return any of the
balancing or bonding information.
Signed-off-by: Jason Ekstrand
---
drivers/g
imeline, they can
use a syncobj and set it as an in and out fence on every submit.
Signed-off-by: Jason Ekstrand
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 199 +---
include/uapi/drm/i915_drm.h | 16 +-
2 files changed, 6 insertions
space badly wants it, there's no good reason to support
this case. This makes I915_CONTEXT_ENGINES_EXT_BOND a total no-op. We
leave the validation code in place in case we ever decide we want to do
something interesting with the bonding information.
Signed-off-by: Jason Ekstrand
---
drivers/gp
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 941fbf78267b4..e5efd22c89ba2
This was only ever used for bonded virtual engine execution. Since
that's no longer allowed, this is dead code.
Signed-off-by: Jason Ekstrand
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42 ---
drivers/gpu/drm
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i91
a tiny bit more complicated, so let's get rid of the one hand-
rolled case.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
drivers/gpu/drm/i915/i915_drv.h | 8 +---
2 files changed, 5 insertions(+), 16 deletions(-)
diff
1 - 100 of 832 matches
Mail list logo
