. Now that everything is synchronous, we
don't need it.
v2 (Daniel Vetter):
- Add stabel Cc and Fixes tag
Signed-off-by: Jason Ekstrand
Cc: # v5.6+
Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled
fences")
Cc: Maarten Lankhorst
Reviewed-by:
ned-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 20
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/d
Asynchronous command parsing was the only thing which ever returned a
non-zero error. With that gone, we can drop the error handling from
dma_fence_work.
Signed-off-by: Jason Ekstrand
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4
that's not a case we should optimize for in the kernel. We should
optimize for code clarity instead.
Signed-off-by: Jason Ekstrand
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 67 +-
1 file changed, 34 insertions(+
ri-devel/20210602164149.391653-2-ja...@jlekstrand.net/
for otherwise backporting just this patch opens up a security bug.
v2: Augment commit message. Also restore Jason's sob that I
accidentally lost.
v3: Add a note for backporters
Signed-off-by: Jason Ekstrand
Reported-by: Marcin Slusarz
Cc: # v5.6
CI is being dumb. This trybot should be identical:
https://patchwork.freedesktop.org/series/90705/
On July 10, 2021 23:20:01 Patchwork wrote:
Patch DetailsSeries:drm/i915: Get rid of fence error propagation (rev3)
URL:https://patchwork.freedesktop.org/series/90891/
State:failure
Couldn't find
No worries. Thanks for pushing!
On Mon, Jul 12, 2021 at 6:37 AM Christian König
wrote:
>
> Sorry for the vacation and sick leave induced delay.
>
> I've just pushed this to drm-misc-fixes.
>
> Thanks,
> Christian.
>
> Am 24.06.21 um 21:43 schrieb Jason Ekstrand:
On Fri, Jul 9, 2021 at 6:41 AM Maarten Lankhorst
wrote:
>
> This is only used for ttm, and tells userspace that the mapping type is
> ignored. This disables the other type of mmap offsets when discrete
> memory is used, so fix the selftests as well.
>
> Document the struct as well, so it shows up
On Mon, Jul 12, 2021 at 9:12 AM Daniel Vetter wrote:
>
> On Mon, Jul 12, 2021 at 08:47:24AM -0500, Jason Ekstrand wrote:
> > On Fri, Jul 9, 2021 at 6:41 AM Maarten Lankhorst
> > wrote:
> > >
> > > This is only used for ttm, and tells userspace that the
On Mon, Jul 12, 2021 at 9:38 AM Daniel Vetter wrote:
>
> On Mon, Jul 12, 2021 at 09:31:13AM -0500, Jason Ekstrand wrote:
> > On Mon, Jul 12, 2021 at 9:12 AM Daniel Vetter wrote:
> > >
> > > On Mon, Jul 12, 2021 at 08:47:24AM -0500, Jason Ekstrand wrote:
> >
: 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| 43 +--
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 118 +-
2 files changed, 147 insertions(+), 14 deletions
() callback.
v4:
- Migrate in attach
v5: (jason)
- Lock around the migration
Signed-off-by: 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| 25
On Tue, Jul 13, 2021 at 9:40 AM Daniel Vetter wrote:
>
> On Mon, Jul 12, 2021 at 06:12:33PM -0500, Jason Ekstrand wrote:
> > From: Thomas Hellström
> >
> > If our exported dma-bufs are imported by another instance of our driver,
> > that instance will typically hav
ment the struct as well, so it shows up in docbook.
>
> Cc: Jason Ekstrand
> Reviewed-by: Daniel Vetter
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 17 ++-
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
> .../drm/
On Wed, Jul 14, 2021 at 12:05 PM Maarten Lankhorst
wrote:
>
> Op 14-07-2021 om 18:17 schreef Jason Ekstrand:
> > On Wed, Jul 14, 2021 at 5:03 AM Maarten Lankhorst
> > wrote:
> >> The FIXED mapping is only used for ttm, and tells userspace that the
> >> mappin
#x27;m not 100% sure where the Linux release cuts land. In any
case, I'm happy to make a version of this series per-release if needed for
Greg to back-port.
v2 (Daniel Vetter):
- Re-order to put the reverts first
- Add ACKs from Daniel
- Add better CC and Fixes tags
v3 (Jason Ekstran
. Now that everything is synchronous, we
don't need it.
v2 (Daniel Vetter):
- Add stabel Cc and Fixes tag
Signed-off-by: Jason Ekstrand
Cc: # v5.6+
Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled
fences")
Cc: Maarten Lankhorst
Reviewed-by:
ri-devel/20210602164149.391653-2-ja...@jlekstrand.net/
for otherwise backporting just this patch opens up a security bug.
v2: Augment commit message. Also restore Jason's sob that I
accidentally lost.
v3: Add a note for backporters
Signed-off-by: Jason Ekstrand
Reported-by: Marcin Slusarz
Cc: # v5.6
that's not a case we should optimize for in the kernel. We should
optimize for code clarity instead.
Signed-off-by: Jason Ekstrand
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 67 +-
1 file changed, 34 insertions(+
ned-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 20
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/d
Asynchronous command parsing was the only thing which ever returned a
non-zero error. With that gone, we can drop the error handling from
dma_fence_work.
Signed-off-by: Jason Ekstrand
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4
ff-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 8 +++-
drivers/gpu/drm/i915/gem/i915_gem_object.c| 13 ++---
.../gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 15 ---
3 files changed, 5 inser
On Tue, Jul 13, 2021 at 10:23 AM Daniel Vetter wrote:
>
> On Tue, Jul 13, 2021 at 04:06:13PM +0100, Matthew Auld wrote:
> > On Tue, 13 Jul 2021 at 15:44, Daniel Vetter wrote:
> > >
> > > On Mon, Jul 12, 2021 at 06:12:34PM -0500, Jason Ekstrand wrote:
t; >> On 15/07/2021 11:15, 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 com
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
breaks down pretty badly if the import happened on a different physical
device.
Jason Ekstrand (5):
drm/i915/gem: Check object_can_migrate from
ned-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 75 +-
1 file changed, 45 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 51f92e4b1a69d..391c8c4a12172 100644
---
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
probably should have been calling all along.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 106 +
1 file changed, 43 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem
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
: Michael J. Ruhl
Reported-by: kernel test robot
Signed-off-by: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_create.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 23 -
drivers/gpu/drm/i915/gem/i915_gem_object.h| 4 +
.../drm/i915/gem
dma_buf_attach_dynamic in the selftests
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| 43 ++--
.../drm/i915/gem/selftests
__i915_gem_ttm_object_init() was ignoring the placement requests coming
from the client and always placing all BOs in SMEM upon creation.
Instead, compute the requested placement set from the object and pass
that into ttm_bo_init_reserved().
Signed-off-by: Jason Ekstrand
Cc: Thomas Hellström
Cc
On Fri, Jul 16, 2021 at 8:18 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> >
> > __i915_gem_ttm_object_init() was ignoring the placement requests coming
> > from the client and always placing all BOs in SMEM upon creation.
> >
On Fri, Jul 16, 2021 at 6:12 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, 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 Fri, Jul 16, 2021 at 6:21 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 Fri, Jul 16, 2021 at 8:54 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> >
> > Whenever we had a user object (n_placements > 0), we were ignoring
> > obj->mm.region and always putting obj->placements[0] as the requested
&
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
egion"
- Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in
i915_gem_dumb_create()"
- Misc. review feedback from Matthew Auld
Jason Ekstrand (5):
drm/i915/gem: Check object_can_migrate from object_migrate
drm/i915/gem: Refactor placement setup for i915_gem_object_cr
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
Cc: Matthew
i915_gem_dumb_create() in a separate patch
- Move i915_gem_object_alloc() below the simple error checks
Signed-off-by: Jason Ekstrand
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 108 -
1 file changed, 43 insertions(+), 65 deletions(-)
diff --git a/drivers
tthew Auld):
- Get rid of MAX_N_PLACEMENTS
- Drop kfree(placements) from set_placements()
Signed-off-by: Jason Ekstrand
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 81 --
1 file changed, 45 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/dr
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
: Michael J. Ruhl
Reported-by: kernel test robot
Signed-off-by: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_create.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 23 -
drivers/gpu/drm/i915/gem/i915_gem_object.h| 4 +
.../drm/i915/gem
dma_buf_attach_dynamic in the selftests
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| 43 ++--
.../drm/i915/gem/selftests
; Cc: Thomas Hellström
> > Cc: Maarten Lankhorst
> > Cc: Tvrtko Ursulin
> > Cc: Jordan Justen
> > Cc: Kenneth Graunke
> > Cc: Jason Ekstrand
> > Cc: Daniel Vetter
> > Cc: Ramalingam C
> > Reviewed-by: Ramalingam C
> > ---
> >
On Fri, Jul 16, 2021 at 11:00 AM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 16:52, Matthew Auld
> wrote:
> >
> > On Fri, 16 Jul 2021 at 15:10, Jason Ekstrand wrote:
> > >
> > > On Fri, Jul 16, 2021 at 8:54 AM Matthew Auld
> > > wrote:
>
On Fri, Jul 16, 2021 at 1:45 PM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 18:39, Jason Ekstrand wrote:
> >
> > On Fri, Jul 16, 2021 at 11:00 AM Matthew Auld
> > wrote:
> > >
> > > On Fri, 16 Jul 2021 at 16:52, Matthew Auld
> > > wrote:
We should tear down in the opposite order we set up.
Signed-off-by: Jason Ekstrand
Fixes: 537f9c84a427 ("drm/i915/pmu: Fix CPU hotplug with multiple GPUs")
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
ugfs entries, and debugfs warns that we're trying
to create directories and files that already exist. Since this all
happens as part of the next driver load, it shows up in the dmesg-warn
of whatever IGT test ran after the mock selftests.
Signed-off-by: Jason Ekstrand
Fixes: 32eb6bcfdda9 (&quo
in the selftests
but can show up in other random IGTs depending on test execution order.
Cc: Daniel Vetter
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: Always call i915_globals_e
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")
Cc: Daniel Vetter
---
d
rtantly, this
means that everything from our selftests has the ability to properly
flush out between i915_init() and i915_exit() because there are a couple
syscall boundaries in between.
Signed-off-by: Jason Ekstrand
Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation c
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
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")
Cc: 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 Ekstrand
-
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, Mar 23, 2021 at 4:35 AM Tvrtko Ursulin
wrote:
>
>
> On 22/03/2021 16:10, Jason Ekstrand wrote:
> > On Mon, Mar 22, 2021 at 7:28 AM Tvrtko Ursulin
>
> [snip]
>
> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>>
>>>>>>
> >>>>>> On 22/03/2021 14:09, Daniel Vetter wrote:
> >>>>>>> On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote:
> >>>>>>>>
> >>>>>>>> On 19/03/2021 22:
ly()
- Drop the dma_fence reference
- Improved commit message
Signed-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 47 ---
.../gpu/drm/i915/gem/i915_gem_context_types.h | 14 +-
.../gpu/drm/i915/gem/i915_g
On Tue, Mar 23, 2021 at 12:01 PM Simon Ser wrote:
>
> Side note: I feel like we could have better lines of communication
> between kernel devs and user-space devs. The new uAPI requirements seem
> to be a high barrier to entry for kernel devs. However sometimes
> user-space devs might be intereste
t at all ...
I'm a fan of this. GitLab issues provide a good place to organize the
chatter on any particular ToDo item. I'd also rather see people
chattering about this stuff on public GitLab than JIRA, when possible.
The last patch in the series closing out a ToDo can be a patch to this
fil
Never used by Mesa AFAIK
Acked-by: Jason Ekstrand
On Tue, Mar 23, 2021 at 10:51 AM Maarten Lankhorst
wrote:
>
> Userptr should not need the kernel for a userspace memcpy, userspace
> needs to call memcpy directly.
>
> Specifically, disable i915_gem_pwrite_ioctl() and i915_
On Wed, Mar 24, 2021 at 6:36 AM Tvrtko Ursulin
wrote:
>
>
> On 24/03/2021 09:52, Daniel Vetter wrote:
> > On Wed, Mar 24, 2021 at 09:28:58AM +, Tvrtko Ursulin wrote:
> >>
> >> On 23/03/2021 17:51, Jason Ekstrand wrote:
> >>> This API is entirely u
Acked-by: Jason Ekstrand
On March 24, 2021 16:10:48 Daniel Vetter wrote:
Motivated by the pre-review process for i915 gem/gt features, but
probably useful in general for complex stuff.
v2: Add reminder to not forget userspace projects in the discussion
(Simon, Jason)
Cc: Simon Ser
Cc
On Thu, Mar 25, 2021 at 4:21 PM Matthew Brost wrote:
>
> On Tue, Mar 23, 2021 at 12:51:49PM -0500, Jason Ekstrand wrote:
> > This API is entirely unnecessary and I'd love to get rid of it. If
> > userspace wants a single timeline across multiple contexts, they can
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 | 47 ---
..
cy’
2995 | static void intel_print_wm_latency(struct drm_i915_private
*dev_priv,
| ^~
As far as I can tell, we don't actually need 8 elements except on SKL
and that uses dev_priv->wm.skl_latency which has enough.
Signed-off-by: Jason Ekstrand
+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-de...@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
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 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
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
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
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 ---
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
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
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
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
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
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
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
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 143 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 21 +++
.../gpu/drm/i915/gem/selftests/mock_context.c | 16 +-
3 files changed, 150 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu
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
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
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 657 --
drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 26 +
.../gpu/drm/i915/gem/selftests/mock_context.c | 5 +-
drivers/gpu/drm/i915
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
drivers/gpu/drm/i91
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 267 --
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 119
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
4 files changed
Signed-off-by: Jason Ekstrand
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
.../gpu/drm/i915/gem/selftests/mock_context.c | 8 +++-
.../gpu/drm/i915/gem/selftests/mock_context.h | 4 +++-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 20 +--
drivers/gpu/drm
There's a big comment saying how useful it is but no one is using this
for anything.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 -
drivers/gpu/drm/i915/gt/intel_gtt.h | 10 --
drivers/gpu/drm/i915/selftests/mock_gtt.c | 1
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 301
1 file changed, 301 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 3238260cffa31..ef23ab4260c24 100644
--- a
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 76029d7143f6c
Now that we have the whole engine set and VM at context creation time,
we can just assign those fields instead of creating first and handling
the VM and engines later. This lets us avoid creating useless VMs and
engine sets and lets us git rid of the complex VM setting code.
Signed-off-by: Jason
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-de...@lists.free
On Wed, Apr 21, 2021 at 2:23 PM Daniel Vetter wrote:
>
> On Wed, Apr 21, 2021 at 8:28 PM Tvrtko Ursulin
> wrote:
> > On 21/04/2021 18:17, Jason Ekstrand wrote:
> > > On Wed, Apr 21, 2021 at 9:25 AM Tvrtko Ursulin
> > > wrote:
> > >> On 21/04/2021 14:
301 - 400 of 653 matches
Mail list logo
