On Tue, May 4, 2021 at 11:13 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:37AM -0500, Jason Ekstrand wrote:
> > The current context uAPI allows for two methods of setting context
> > parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
>
On Mon, May 31, 2021 at 3:47 AM Daniel Vetter wrote:
>
> On Thu, May 27, 2021 at 11:26:37AM -0500, Jason Ekstrand wrote:
> > The current context uAPI allows for two methods of setting context
> > parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
>
but 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
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 67 +-
1 file changed, 34 insertions(+), 33 deletions(-)
diff --git
Ekstrand
Reported-by: Marcin Slusarz
Cc: # v5.6+
Cc: Jason Ekstrand
Cc: Marcin Slusarz
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled
fences")
Signed-off-by: Daniel Vetter
Reviewed-by: Jon
Signed-off-by: Jason Ekstrand
Reviewed-by: Jon Bloomfield
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4 +---
drivers/gpu/drm/i915/i915_sw_fence_work.c | 5 +
drivers/gpu/drm/i915/i915_sw_fence_work.h | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 3 +--
4 files changed, 4
Signed-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Reviewed-by: Jon Bloomfield
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 -
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
3 files changed, 10 insertions(+), 23
Now that everything is synchronous, we
don't need it.
Signed-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Reviewed-by: Jon Bloomfield
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 227 +-
.../i915/gem/selftests/i915_gem_execbuffer.c | 4 +
drivers/gpu/drm/i915/i915_cmd_p
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.
Cc: Daniel Vetter
Cc: Jon Bloomfield
Jason Ekstrand (5):
drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"
drm/i915: Remove allow_
Since free_engines works for partially constructed engine sets, we can
use the usual goto pattern.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers
With the proto-context stuff added later in this series, we end up
having to duplicate set_priority. This lets us avoid duplicating the
validation logic.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file
This better models where we want to go with contexts in general where
things like the VM and engine set are create parameters instead of being
set after the fact.
Signed-off-by: Jason Ekstrand
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
.../gpu/drm/i915/gem/selftests
itself or try to get
around kernel context banning.
v2 (Jason Ekstrand):
- Expand the commit mesage
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 303
1 file changed, 303 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem
We want to delete __assign_ppgtt and, generally, stop setting the VM
after context creation. This is the one place I could find in the
selftests where we set a VM after the fact.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
1 file changed
This is the VM equivalent of i915_gem_context_lookup. It's only used
once in this patch but future patches will need to duplicate this lookup
code so it's better to have it in a helper.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +-
drivers/gpu/drm
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 get rid of the complex VM setting code.
Signed-off-by: Jason
Vetter):
- Mention the exact IGT test this breaks
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h| 7 ---
.../drm/i915/gt/intel_execlists_submission.c| 17
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers
Ekstrand):
- Expand the commit message
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 262 --
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 119
.../drm/i915/selftests
ever touches
a proto-context is guarded by drm_i915_file_private::proto_context_lock,
including context creation. Yes, this means context creation now takes
a giant global lock but it can't really be helped and that should never
be on any driver's fast-path anyway.
Signed-off-by: Jason Ekstrand
CONTEXT_PARAM_RECOVERABLE to false and look for -EIO
coming from execbuf to check for hangs instead.
v2 (Daniel Vetter):
- Add a comment in the commit message about recoverable contexts
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13
client
stats from debugfs/i915_gem_objects")
v2 (Daniel Vetter):
- Delete a struct drm_i915_file_private pre-declaration
- Add a comment to the commit message about history
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9
on SSEU in the commit message
- Use proto_context_set_persistence in set_proto_ctx_param
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 552 +-
.../gpu/drm/i915/gem/i915_gem_context_types.h | 58 ++
2 files changed, 588 insertions(+), 22 deletions
be trying to implicitly check is
that offsetof(user->engines) == sizeof(*user) and we don't have any
weird padding throwing us off. However, that's not the check it's doing
and it's not even a reliable way to do that check.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3
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
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
drivers
For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
.../gpu/drm/i915/gem/selftests
this wart, this
commit adds a proto-context struct which contains all the context create
parameters.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 145 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 22 +++
.../gpu/drm/i915/gem/selftests
In order to prevent kernel doc warnings, also fill out docs for any
missing fields and fix those that forgot the "@".
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
Documentation/gpu/i915.rst| 2 +
.../gpu/drm/i915/gem/i915_gem_context_ty
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42
information.
v2 (Jason Ekstrand):
- Don't delete quite as much code.
v3 (Tvrtko Ursulin):
- Add some history to the commit message
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 18 +-
.../drm/i915/gt/intel_execlists_submission.c | 69
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
Reviewed-by: Daniel Vetter
---
drivers/gpu
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff
and set it as an in and out fence on every submit.
v2 (Jason Ekstrand):
- More detailed commit message
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 199 +-
.../drm/i915/gt/intel_execlists_submission.c | 28
an emulation and the possible race if userspace calls execbuffer2
twice on the same context concurrently.
v2 (Jason Ekstrand):
- Wrap the checks for eb.gem_context->syncobj in unlikely()
- Drop the dma_fence reference
- Improved commit message
v3 (Jason Ekstrand):
- Move the dma_fence_
]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067031.html
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
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
request_timeout_ms and context creation, they
can theoretically end up with different timeouts. However, since both
of these are fairly harmless and require changing kernel params, we
don't care.
v2 (Tvrtko Ursulin):
- Add a comment about races with request_timeout_ms
Signed-off-by: Jason
, this patch adds a new ring_size field and makes everything use
that.
v2 (Daniel Vetter):
- Replace 512 * SZ_4K with SZ_2M
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +--
drivers/gpu/drm/i915/gt/intel_context.c | 3
hey can do it properly.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
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 --
drivers/gpu/d
t 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 with it.
Test-with: 20210423033253.792669-1-ja...@jlekstrand.net
Jaso
On Thu, May 27, 2021 at 4:49 AM Christian König
wrote:
>
> Am 26.05.21 um 19:42 schrieb Jason Ekstrand:
> > On Wed, May 26, 2021 at 6:02 AM Christian König
> > wrote:
> >> Regarding that, why do we actually use a syncfile and not a drm_syncobj
> >> here?
&
roduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over- synchronization.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exc
racing with itself. As long as we ensure userspace
can't back the kernel into a corner, it should be fine.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well
This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds
documentation for DMA_BUF_IOCTL_SYNC.
Signed-off-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Christian König
Cc: Sumit Semwal
---
Documentation/driver-api/dma-buf.rst | 8 +++
include/uapi/linux/dma-buf.h
For dma-buf sync_file import, we want to get all the fences on a
dma_resv plus one more. We could wrap the fence we get back in an array
fence or we could make dma_resv_get_singleton_unlocked take "one more"
to make this case easier.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel
Add a helper function to get a single fence representing
all fences in a dma_resv object.
This fence is either the only one in the object or all not
signaled fences of the object in a flatted out dma_fence_array.
v2 (Jason Ekstrand):
- Take reference of fences both for creating
None of these helpers actually leak any RCU details to the caller. They
all assume you have a genuine reference, take the RCU read lock, and
retry if needed. Naming them with an _rcu is likely to cause callers
more panic than needed.
v2 (Jason Ekstrand):
- Fix function argument indentation
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL
a/mesa/-/merge_requests/4037
IGT tests: https://patchwork.freedesktop.org/series/90490/
v10 (Jason Ekstrand, Daniel Vetter):
- Add reviews/acks
- Add a patch to rename _rcu to _unlocked
- Split things better so import is clearly RFC status
v11 (Daniel Vetter):
- Add more CCs to try and get maint
On Tue, May 25, 2021 at 10:37 AM Daniel Vetter wrote:
>
> On Mon, May 24, 2021 at 03:59:54PM -0500, Jason Ekstrand wrote:
> > This patch is analogous to the previous sync file export patch in that
> > it allows you to import a sync_file into a dma-buf. Unlike the previous
racing with itself. As long as we ensure userspace
can't back the kernel into a corner, it should be fine.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well
None of these helpers actually leak any RCU details to the caller. They
all assume you have a genuine reference, take the RCU read lock, and
retry if needed. Naming them with an _rcu is likely to cause callers
more panic than needed.
Signed-off-by: Jason Ekstrand
Suggested-by: Daniel Vetter
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL
Add a helper function to get a single fence representing
all fences in a dma_resv object.
This fence is either the only one in the object or all not
signaled fences of the object in a flatted out dma_fence_array.
v2 (Jason Ekstrand):
- Take reference of fences both for creating
roduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over- synchronization.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exc
For dma-buf sync_file import, we want to get all the fences on a
dma_resv plus one more. We could wrap the fence we get back in an array
fence or we could make dma_resv_get_singleton_unlocked take "one more"
to make this case easier.
Signed-off-by: Jason Ekstrand
---
drivers/dma-buf
a/mesa/-/merge_requests/4037
IGT tests: https://patchwork.freedesktop.org/series/90490/
v10 (Jason Ekstrand, Daniel Vetter):
- Add reviews/acks
- Add a patch to rename _rcu to _unlocked
- Split things better so import is clearly RFC status
Cc: Christian König
Cc: Michel Dänzer
Cc: Dave Airlie
C
t; > Am 19.05.21 um 01:58 schrieb Matthew Brost:
> > > > > Add entry fpr i915 new parallel submission uAPI plan.
> > > > >
> > > > > v2:
> > > > >(Daniel Vetter):
> > > > > - Expand logical order expl
On May 19, 2021 12:16:15 Daniel Vetter wrote:
On Wed, May 19, 2021 at 5:06 PM Jason Ekstrand wrote:
Once we no longer rely on error propagation, I think there's a lot we
can rip out.
I honestly did not find that much ... what did you uncover?
When I was digging through this earlier
Once we no longer rely on error propagation, I think there's a lot we
can rip out.
--Jason
On Wed, May 19, 2021 at 5:15 AM Daniel Vetter wrote:
>
> From: Jason Ekstrand
>
> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> since that commit, we've been havi
nsense.
>
> Kudos to Jason for figuring this out.
>
> Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled
> fences")
> Cc: # v5.6+
> Cc: Jason Ekstrand
> Cc: Marcin Slusarz
> Cc: Jon Bloomfield
> Relates: https://gitlab.fre
On Mon, May 17, 2021 at 8:40 AM Daniel Vetter wrote:
>
> On Fri, May 14, 2021 at 02:13:57PM -0500, Jason Ekstrand wrote:
> > On Tue, May 4, 2021 at 3:33 PM Daniel Vetter wrote:
> > >
> > > On Mon, May 03, 2021 at 10:57:40AM -0500, Jason Ekstrand wrote:
> > &
On Tue, May 4, 2021 at 3:33 PM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:40AM -0500, Jason Ekstrand wrote:
> > This means that the proto-context needs to grow support for engine
> > configuration information as well as setparam logic. Fortunately, we'll
>
On Tue, May 4, 2021 at 11:17 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:38AM -0500, Jason Ekstrand wrote:
> > Since free_engines works for partially constructed engine sets, we can
> > use the usual goto pattern.
> >
> > Signed-off-by: Jason Ekstrand
On Tue, May 4, 2021 at 3:56 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:31AM -0500, Jason Ekstrand wrote:
> > Even though FENCE_SUBMIT is only documented to wait until the request in
> > the in-fence starts instead of waiting until it completes, it has a bit
&
On Tue, May 4, 2021 at 3:50 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:27AM -0500, Jason Ekstrand wrote:
> > This API allows one context to grab bits out of another context upon
> > creation. It can be used as a short-cut for setparam(getparam()) f
On Tue, May 4, 2021 at 3:47 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:23AM -0500, Jason Ekstrand wrote:
> > Previously, we were storing the ring size in the ring pointer before it
> > was actually allocated. We would then guard setting the ring si
On Fri, May 14, 2021 at 6:12 AM Tvrtko Ursulin
wrote:
>
> On 06/05/2021 20: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
Pulling a few threads together...
On Mon, May 10, 2021 at 1:39 PM Francisco Jerez wrote:
>
> I agree with Martin on this. Given that using GuC currently involves
> making your open-source graphics stack rely on a closed-source
> cryptographically-protected blob in order to submit commands to
On May 10, 2021 08:55:55 Martin Peres wrote:
On 10/05/2021 02:11, Jason Ekstrand wrote:
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
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: Jason Ekstrand
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
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 get rid of the complex VM setting code.
Signed-off-by: Jason
This better models where we want to go with contexts in general where
things like the VM and engine set are create parameters instead of being
set after the fact.
Signed-off-by: Jason Ekstrand
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
.../gpu/drm/i915/gem/selftests
We want to delete __assign_ppgtt and, generally, stop setting the VM
after context creation. This is the one place I could find in the
selftests where we set a VM after the fact.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
1 file changed
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 304
1 file changed, 304 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ad6e98d8a4fbd..6e5828fe1a792 100644
ever touches
a proto-context is guarded by drm_i915_file_private::proto_context_lock,
including context creation. Yes, this means context creation now takes
a giant global lock but it can't really be helped and that should never
be on any driver's fast-path anyway.
Signed-off-by: Jason Ekstrand
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
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
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
drivers
client
stats from debugfs/i915_gem_objects")
v2 (Daniel Vetter):
- Delete a struct drm_i915_file_private pre-declaration
- Add a comment to the commit message about history
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9
This means that the proto-context needs to grow support for engine
configuration information as well as setparam logic. Fortunately, we'll
be deleting a lot of setparam logic on the primary context shortly so it
will hopefully balance out.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915
For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
.../gpu/drm/i915/gem/selftests
Since free_engines works for partially constructed engine sets, we can
use the usual goto pattern.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem
this wart, this
commit adds a proto-context struct which contains all the context create
parameters.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 145 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 22 +++
.../gpu/drm/i915/gem/selftests
In order to prevent kernel doc warnings, also fill out docs for any
missing fields and fix those that forgot the "@".
Signed-off-by: Jason Ekstrand
---
Documentation/gpu/i915.rst| 2 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 43 ---
2 fil
With the proto-context stuff added later in this series, we end up
having to duplicate set_priority. This lets us avoid duplicating the
validation logic.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file
CONTEXT_PARAM_RECOVERABLE to false and look for -EIO
coming from execbuf to check for hangs instead.
v2 (Daniel Vetter):
- Add a comment in the commit message about recoverable contexts
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.
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/i915
it on such that they can run in parallel.
However, this functionality has never been used in the real world. The
media driver (the only user of FENCE_SUBMIT) always picks exactly two
physical engines to bond and never asks us to pick which to use.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915
information.
v2 (Jason Ekstrand):
- Don't delete quite as much code.
v3 (Tvrtko Ursulin):
- Add some history to the commit message
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 18 +-
.../drm/i915/gt/intel_execlists_submission.c | 69 --
.../drm/i915/gt
an emulation and the possible race if userspace calls execbuffer2
twice on the same context concurrently.
v2 (Jason Ekstrand):
- Wrap the checks for eb.gem_context->syncobj in unlikely()
- Drop the dma_fence reference
- Improved commit message
v3 (Jason Ekstrand):
- Move the dma_fence_
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
Reviewed-by: Daniel Vetter
---
drivers/gpu
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 +-
.../drm/i915/gt/intel_execlists_submission.c | 28 ---
.../drm/i915/gt/intel_execlists_submission.h | 3 -
include/uapi
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff
request_timeout_ms and context creation, they
can theoretically end up with different timeouts. However, since both
of these are fairly harmless and require changing kernel params, we
don't care.
v2 (Tvrtko Ursulin):
- Add a comment about races with request_timeout_ms
Signed-off-by: Jason
]: 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 | 8
, this patch adds a new ring_size field and makes everything use
that.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +--
drivers/gpu/drm/i915/gt/intel_context.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_context.h | 5 -
drivers/gpu/drm/i915/gt
hey can do it properly.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
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 --
drivers/gpu/d
t 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 with it.
Test-with: 20210423214853.876911-1-ja...@jlekstrand.net
Jaso
On April 30, 2021 23:01:44 "Dixit, Ashutosh" wrote:
On Fri, 30 Apr 2021 19:19:59 -0700, Umesh Nerlige Ramappa wrote:
On Fri, Apr 30, 2021 at 07:35:41PM -0500, Jason Ekstrand wrote:
On April 30, 2021 18:00:58 "Dixit, Ashutosh"
wrote:
On Fri, 30 Apr 2021 15:26:09 -0700, U
On April 30, 2021 18:00:58 "Dixit, Ashutosh" wrote:
On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
Looks like the engine can be dropped since all timestamps are in sync. I
just have one more question here. The timestamp itself is 36 bits. Should
the uapi also report the
301 - 400 of 653 matches
Mail list logo
