Instead of attempting to recycle a request in to the cache when it
retires, stuff a new one in the cache every time we allocate a request
for some other reason.
Signed-off-by: Jason Ekstrand
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Matthew Auld
Cc: Maarten Lankhorst
---
drivers/gpu/drm/i915
The only real-world user of SLAB_TYPESAFE_BY_RCU was i915 and it doesn't
use that anymore so there's no need to be testing it in selftests.
Signed-off-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Christian König
Cc: Matthew Auld
Cc: Maarten Lankhorst
---
drivers/dma-buf/st-dma-fen
using SLAB_TYPESAFE_BY_RCU for i915_request
and, instead, does an RCU-safe slab free via rcu_call(). This should
let us keep most of the perf benefits of slab allocation while avoiding
the bear traps inherent in SLAB_TYPESAFE_BY_RCU.
Signed-off-by: Jason Ekstrand
Cc: Jon Bloomfield
Cc: Daniel Vetter
dma_fence_get_rcu_safe did an rcu_dereference as well as a
SLAB_TYPESAFE_BY_RCU-safe dma_fence_get_rcu. This means each call site
ends up being 3 lines instead of 1.
Signed-off-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Christian König
Cc: Matthew Auld
Cc: Maarten Lankhorst
---
drivers/dma-buf/dma-fence
On Thu, Jun 10, 2021 at 6:30 AM Daniel Vetter wrote:
>
> On Thu, Jun 10, 2021 at 11:39 AM Christian König
> wrote:
> > Am 10.06.21 um 11:29 schrieb Tvrtko Ursulin:
> > > On 09/06/2021 22:29, Jason Ekstrand wrote:
> > >> Ever since 0eafec6d3244 ("dr
On Thu, Jun 10, 2021 at 5:08 AM Tvrtko Ursulin
wrote:
>
>
> On 09/06/2021 22:29, Jason Ekstrand wrote:
> > Instead of attempting to recycle a request in to the cache when it
> > retires, stuff a new one in the cache every time we allocate a request
> > for some other
On Thu, Jun 10, 2021 at 5:04 AM Tvrtko Ursulin
wrote:
>
> On 09/06/2021 22:29, Jason Ekstrand wrote:
> > This appears to break encapsulation by moving an intel_engine_cs
> > function to a i915_request file. However, this function is
> > intrinsically tied to the lifet
On Thu, Jun 10, 2021 at 1:51 AM Christian König
wrote:
>
> Am 09.06.21 um 23:29 schrieb Jason Ekstrand:
> > This helper existed to handle the weird corner-cases caused by using
> > SLAB_TYPESAFE_BY_RCU for backing dma_fence. Now that no one is using
> > that anymore (i91
On Thu, Jun 10, 2021 at 10:13 AM Daniel Vetter wrote:
>
> On Thu, Jun 10, 2021 at 3:59 PM Jason Ekstrand wrote:
> >
> > On Thu, Jun 10, 2021 at 1:51 AM Christian König
> > wrote:
> > >
> > > Am 09.06.21 um 23:29 schrieb Jason Ekstrand:
> > &g
On Thu, Jun 10, 2021 at 10:07 AM Tvrtko Ursulin
wrote:
>
> On 10/06/2021 14:57, Jason Ekstrand wrote:
> > On Thu, Jun 10, 2021 at 5:04 AM Tvrtko Ursulin
> > wrote:
> >>
> >> On 09/06/2021 22:29, Jason Ekstrand wrote:
> >>> This appears to
On Thu, Jun 10, 2021 at 11:38 AM Daniel Vetter wrote:
>
> On Thu, Jun 10, 2021 at 6:24 PM Jason Ekstrand wrote:
> >
> > On Thu, Jun 10, 2021 at 10:13 AM Daniel Vetter
> > wrote:
> > >
> > > On Thu, Jun 10, 2021 at 3:59 PM Jason Ekstrand
> > &g
On Thu, Jun 10, 2021 at 11:44 AM Daniel Vetter wrote:
>
> On Wed, Jun 09, 2021 at 11:00:26AM -0500, Jason Ekstrand wrote:
> > On Wed, Jun 9, 2021 at 6:28 AM Daniel Vetter wrote:
> > >
> > > On Tue, Jun 08, 2021 at 11:35:58PM -0500, Jason Ekstrand wrote:
> >
On Thu, Jun 10, 2021 at 8:35 AM Jason Ekstrand wrote:
> On Thu, Jun 10, 2021 at 6:30 AM Daniel Vetter wrote:
> > On Thu, Jun 10, 2021 at 11:39 AM Christian König
> > wrote:
> > > Am 10.06.21 um 11:29 schrieb Tvrtko Ursulin:
> > > > On 09
On Thu, Jun 10, 2021 at 3:11 PM Chia-I Wu wrote:
>
> On Tue, May 25, 2021 at 2:18 PM Jason Ekstrand wrote:
> > Modern userspace APIs like Vulkan are built on an explicit
> > synchronization model. This doesn't always play nicely with the
> > implicit synchroni
On Thu, May 27, 2021 at 5:38 AM Daniel Vetter wrote:
>
> On Tue, May 25, 2021 at 04:17:50PM -0500, Jason Ekstrand wrote:
> > This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds
> > documentation for DMA_BUF_IOCTL_SYNC.
> >
> > Signe
This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds
documentation for DMA_BUF_IOCTL_SYNC.
v2 (Daniel Vetter):
- Fix a couple typos
- Add commentary about synchronization with other devices
- Use item list format for describing flags
Signed-off-by: Jason Ekstrand
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
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
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
In c9d9fdbc108a ("drm/i915: Revert "drm/i915/gem: Asynchronous
cmdparser""), the parameters to intel_engine_cmd_parser() were altered
without updating the docs, causing Fi.CI.DOCS to start failing.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 4
On Tue, Jul 20, 2021 at 3:26 PM Rodrigo Vivi wrote:
>
> On Tue, Jul 20, 2021 at 04:25:21PM -0400, Rodrigo Vivi wrote:
> > On Tue, Jul 20, 2021 at 01:21:08PM -0500, Jason Ekstrand wrote:
> > > In c9d9fdbc108a ("drm/i915: Revert "drm/i915/gem: Asynchronous
> &
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
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
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
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
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
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
Would you mind pushing? I still don't have those magic powers. :-)
--Jason
On Wed, Jul 21, 2021 at 5:05 AM Rodrigo Vivi wrote:
>
> On Tue, Jul 20, 2021 at 04:04:59PM -0500, Jason Ekstrand wrote:
> > On Tue, Jul 20, 2021 at 3:26 PM Rodrigo Vivi wrote:
> > >
> >
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 Wed, Jul 21, 2021 at 4:08 AM Daniel Vetter wrote:
>
> On Wed, Jul 21, 2021 at 8:21 AM Zhenyu Wang wrote:
> > We've seen recent regression with host and windows VM running
> > simultaneously that cause gpu hang or even crash. Finally bisect to
> > 58586680ffad ("drm/i915: Disable atomics in L3
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
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
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
: 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):
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
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
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
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
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
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
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
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
o allow them.
My gut says we actually want to back-port
https://lore.kernel.org/dri-devel/YPk3OCMrhg7UlU6T@phenom.ffwll.local/
instead. Daniel, thoughts?
--Jason
>
> Fixes: 1354d830cb8f ("drm/i915: Call i915_globals_exit() if
> pci_register_device() fails")
> Signed-off-b
reference.
This tripped up Jason when reimplementing the single timeline feature
in
commit 00dae4d3d35d4f526929633b76e00b0ab4d3970d
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:12 2021 -0500
drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)
We could fix the bug by holding ctx->mutex,
Acked-by: Jason Ekstrand
On Tue, Aug 10, 2021 at 7:34 AM Daniel Vetter wrote:
>
> We still have quite a bit more work to do with overall reworking of
> the ttm-based dg1 code, but the uapi stuff is now finalized with the
> latest pull. So remove that.
>
> This also fix
at does) faster with
> a proper design fix.
>
> Also since there's only one caller of context_apply_all left and it's
> really just a loop, inline it and then inline the lopp body too. This
> is how all other callers that take the engine lock loop over engines,
> it&#
definitely just enable the uapi parts by default.
> >
> > Signed-off-by: Maarten Lankhorst
> > References: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11584
> > Cc: Jordan Justen jordan.l.jus...@intel.com
> > Cc: Jason Ekstrand ja...@jlekstrand.ne
On May 9, 2021 12:12:36 Martin Peres wrote:
Hi,
On 06/05/2021 22:13, Matthew Brost wrote:
Basic GuC submission support. This is the first bullet point in the
upstreaming plan covered in the following RFC [1].
At a very high level the GuC is a piece of firmware which sits between
the i915 and
pt-in should be universally useful.
Signed-off-by: Tvrtko Ursulin
Reported-by: Marcin Slusarz
Reported-by: Miroslav Bendik
References: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already
signaled fences")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
Cc: J
101 - 200 of 653 matches
Mail list logo
