On Wed, Apr 28, 2021 at 01:58:17PM -0500, Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 12:18 PM Jason Ekstrand wrote:
> >
> > On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
> > >
> > > On Tue, Apr 27, 2021 at 08:51:08AM -0500, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 01:22:14PM -0500, Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 5:27 AM Daniel Vetter wrote:
> >
> > On Fri, Apr 23, 2021 at 05:31:21PM -0500, Jason Ekstrand wrote:
> > > As far as I can tell, the only real reason for this is to avoid taking
there we have GuC
scheduler backend.
Not against adding a bit more context to the commit message, but we need
to make sure what we put there is actually correct. Maybe best to ask
Tony/Carl as part of getting an ack from them.
-Daniel
>
> Regards,
>
> Tvrtko
>
> > U
h
> b/drivers/gpu/drm/i915/gt/intel_gtt.h
> index e67e34e179131..4c46068e63c9d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> @@ -217,16 +217,6 @@ struct i915_address_space {
Pls also delete the drm_i915_file_private pre-dcl in this file.
With t
12ef7f3c6 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> @@ -80,11 +80,17 @@ void mock_init_contexts(struct drm_i915_private *i915)
> struct i915_gem_context *
> live_context(struct drm_i915_private *i915, struct file *file
ver_priv;
>
> specific_ctx = i915_gem_context_lookup(file_priv, ctx_handle);
> - if (!specific_ctx) {
> + if (IS_ERR(specific_ctx)) {
> DRM_DEBUG("Failed to look up context with ID %u for
> opening perf stream
ivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> @@ -46,6 +46,26 @@ struct i915_gem_engines_iter {
> const struct i915_gem_engines *engines;
> };
>
> +enum i915_gem_engine_type {
> + I915_GEM_ENGINE_TYPE_INVALID
gt; > We don't care, no.
> >
> > For completeness only - by the end of the series it is what you say. But
> > at _this_ point in the series though it is if modparam changes at any
> > point between context create and rep
On Thu, Apr 29, 2021 at 07:12:05PM +0200, Daniel Vetter wrote:
> On Thu, Apr 29, 2021 at 09:54:15AM -0500, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 3:04 AM Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 28/04/2021 18:24, Jason Ekstrand wrote
On Thu, Apr 29, 2021 at 11:02:27AM -0500, Jason Ekstrand wrote:
> On Thu, Apr 29, 2021 at 7:16 AM Daniel Vetter wrote:
> >
> > On Wed, Apr 28, 2021 at 01:58:17PM -0500, Jason Ekstrand wrote:
> > > On Wed, Apr 28, 2021 at 12:18 PM Jason Ekstrand
> > > wrote:
>
On Thu, Apr 29, 2021 at 10:29:51AM -0500, Jason Ekstrand wrote:
> On Thu, Apr 29, 2021 at 8:27 AM Daniel Vetter wrote:
> >
> > On Fri, Apr 23, 2021 at 05:31:24PM -0500, Jason Ekstrand wrote:
> > > We're about to start doing lazy context creation which means
On Fri, Apr 23, 2021 at 05:31:30PM -0500, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
Maybe spend a few words on explaining why in these two selftest patches
instead of letting me guess :-)
-Daniel
> ---
> drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
ere and which
userspace still uses this post CTX_CREATE_EXT in setparam. That would be
really good to have recorded for all these changes. And if that explainer
is on the proto ctx code you're adding it can even be found in the future
again.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/
l review the details in
these later patches in the series once we've agreed on the big picture
shuffling.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 159 ++
> .../gpu/drm/i915/gem/selftests/mock_context.c | 33 ++--
> 2 files changed, 64 insertion
On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter wrote:
> > > + ret = set_proto_ctx_param(file_priv, pc, args);
> >
> > I think we should have a FIXME here of not allowing this on some future
> &
On Thu, Apr 29, 2021 at 12:04:33PM -0400, Andrey Grodzovsky wrote:
>
>
> On 2021-04-29 7:32 a.m., Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 01:23:19PM +0200, Daniel Vetter wrote:
> > > On Wed, Apr 28, 2021 at 11:12:00AM -0400, Andrey Grodzovsky wrote:
&
On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> > > On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter wrote:
> > > > >
On Thu, Apr 29, 2021 at 02:33:17PM +0200, Hans de Goede wrote:
> Hi,
>
> On 4/29/21 2:04 PM, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 01:54:46PM +0200, Greg Kroah-Hartman wrote:
> >> On Thu, Apr 29, 2021 at 01:40:28PM +0200, Daniel Vetter wrote:
> >>>
On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:
>
> On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
> >
> > On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> > > On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:
> > > > O
On Thu, Apr 29, 2021 at 1:12 PM Daniel Vetter wrote:
>
> On Wed, Apr 28, 2021 at 04:39:24PM -0400, Alex Deucher wrote:
> > On Wed, Apr 28, 2021 at 10:35 AM Daniel Vetter wrote:
> > >
> > > On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote:
> &
On Fri, Apr 30, 2021 at 11:08 AM Christian König
wrote:
>
> Am 30.04.21 um 10:58 schrieb Daniel Vetter:
> > [SNIP]
> >>> When the user allocates usermode queues, the kernel driver sets up a
> >>> queue descriptor in the kernel which defines the location of the
On Thu, Apr 29, 2021 at 09:03:48PM -0700, Matthew Brost wrote:
> On Thu, Apr 29, 2021 at 02:14:19PM +0200, Daniel Vetter wrote:
> > On Wed, Apr 28, 2021 at 01:17:27PM -0500, Jason Ekstrand wrote:
> > > On Wed, Apr 28, 2021 at 1:02 PM Matthew Brost
> > > wrote:
>
Hi,
On Fri, 30 Apr 2021 at 10:35, Daniel Vetter wrote:
> On Fri, Apr 30, 2021 at 11:08 AM Christian König
> wrote:
> > This doesn't work in hardware. We at least need to setup a few registers
> > and memory locations from inside the VM which userspace shouldn't hav
On Thu, Apr 29, 2021 at 04:34:55PM -0400, Andrey Grodzovsky wrote:
>
>
> On 2021-04-29 3:05 p.m., Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 12:04:33PM -0400, Andrey Grodzovsky wrote:
> > >
> > >
> > > On 2021-04-29 7:32 a.m., Daniel Vetter wr
On Fri, Apr 30, 2021 at 1:28 PM Hans de Goede wrote:
>
> Hi,
>
> On 4/29/21 9:09 PM, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 02:33:17PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 4/29/21 2:04 PM, Daniel Vetter wrote:
> >>
t more detail on what exactly was the problem to be fixed
is needed.
-Daniel
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Zhen Han
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 15 +--
> drivers/gpu/drm/i915/gt/intel_context.h
.org/patch/431473/?series=89623&rev=1
>
> I left the splitting up vfunc vs flags for later.
Yeah pls remove this pointer packing asap.
This is yet another case of pointless complications and fragility in the
code base for not reason at all, and it needs to go.
I'll file a
On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
wrote:
>
>
> On 30/04/2021 07:53, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
> > wrote:
> >>
> >> On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
> >>>
&g
On Fri, Apr 30, 2021 at 2:44 PM Tvrtko Ursulin
wrote:
>
>
>
> On 30/04/2021 13:30, Daniel Vetter wrote:
> > On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
> > wrote:
> >> On 30/04/2021 07:53, Daniel Vetter wrote:
> >>> On Thu, Apr 29,
On Fri, Apr 30, 2021 at 3:32 PM Hans de Goede wrote:
>
> Hi,
>
> On 4/30/21 1:38 PM, Daniel Vetter wrote:
> > On Fri, Apr 30, 2021 at 1:28 PM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 4/29/21 9:09 PM, Daniel Vetter wrote:
> >>
On Fri, Apr 30, 2021 at 3:27 PM Tvrtko Ursulin
wrote:
> On 30/04/2021 12:48, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 10:46:40AM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> When a non-persistent context exits we currently mark i
On Fri, Apr 30, 2021 at 6:27 PM Jason Ekstrand wrote:
>
> On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter wrote:
> >
> > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
> > wrote:
> > >
> > > On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
> >
On Fri, Apr 30, 2021 at 6:57 PM Jason Ekstrand wrote:
>
> On Fri, Apr 30, 2021 at 11:33 AM Daniel Vetter wrote:
> >
> > On Fri, Apr 30, 2021 at 6:27 PM Jason Ekstrand wrote:
> > >
> > > On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter wrote:
> > > >
;
> | ^~~
> | might_lock
>cc1: some warnings being treated as errors
I think you're missing an include or something. The other patch you've
done seems good, I queued that up in drm-intel-gt-next for 5.14
he flip completion events.
Once we have solid events I think we should look into statically
tuning guest/host compositor deadlines (like you've suggested in a
bunch of places) to consisently make that deadline and hit 60 fps.
With that we can then look into tuning this automatically and
full-ppgtt platforms. Ditching it all seemed
like a better idea.
References: ccbc1b97948a ("drm/i915/gem: Don't allow changing the VM on running
contexts (v4)")
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: D
s either a full ppgtt stored in gem->ctx, or the ggtt.
We'll make more use of this function later on.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: L
https://lore.kernel.org/dri-devel/20210802154806.3710472-1-daniel.vet...@ffwll.ch/
Cheers, Daniel
Daniel Vetter (9):
drm/i915: Drop code to handle set-vm races from execbuf
drm/i915: Rename i915_gem_context_get_vm_rcu to
i915_gem_context_get_eb_vm
drm/i915: Use i915_gem_context_get_eb_
close to anything
that's a hotpath where removing the single spinlock can be measured).
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel La
xt->vm or gt->vm,
which is always set.
v2: 0day found a testcase that I missed.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc:
e also remove the rcu_barrier in ggtt_cleanup_hw added in
commit 60a4233a4952729089e4df152e730f8f4d0e82ce
Author: Chris Wilson
Date: Mon Jul 29 14:24:12 2019 +0100
drm/i915: Flush the i915_vm_release before ggtt shutdown
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris W
Consolidates the "which is the vm my execbuf runs in" code a bit. We
do some get/put which isn't really required, but all the other users
want the refcounting, and I figured doing a function just for this
getparam to avoid 2 atomis is a bit much.
Signed-off-by: Daniel Vetter
Cc:
ris Wilson
Date: Fri Aug 30 19:03:25 2019 +0100
drm/i915: Use RCU for unlocked vm_idr lookup
except we have the conversion from idr to xarray in between.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
C
r an accident
where we run kernel stuff in userspace vm or the other way round.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc:
Date: Mon Jul 26 17:23:16 2021 -0700
drm/i915/guc: GuC virtual engines
address this all by also splitting the new intel_engine_create_virtual
into a _user variant that doesn't set ce->vm.
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Cc: John Harrison
Signed-off-by
ter since all roads lead to i915_ttm_get_pages()
> >> when we need to actually use the object?
> >>
> >> Also updating the mm.region in ttm_object_init() to reflect the dummy
> >> ttm resource seems a little scary, since any existing is_lmem() check
> >
On Tue, Aug 03, 2021 at 10:49:39AM -0400, Alex Deucher wrote:
> On Tue, Aug 3, 2021 at 4:34 AM Michel Dänzer wrote:
> >
> > On 2021-08-02 4:51 p.m., Alex Deucher wrote:
> > > On Mon, Aug 2, 2021 at 4:31 AM Daniel Vetter wrote:
> > >>
> > >> On
ion it
> > in commit messages. Require the kernel patch to be a one-stop shop for
> > finding the various bits which were used to justify the new uAPI.
> >
> > Signed-off-by: Jason Ekstrand
> > Cc: Daniel Vetter
> > Cc: Dave Airlie
> > ---
> >
nding the various bits which were used to justify the new uAPI.
Acked-by: Daniel Stone
ix this by releasing the RPM reference from the EFI FB's destroy hook,
> called when the FB gets unregistered.
>
> Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI
> D0")
> Cc: Kai-Heng Feng
> Signed-off-by: Imre Deak
Patch looks good:
On Tue, Aug 03, 2021 at 10:47:10AM -0500, Jason Ekstrand wrote:
> Both are
>
> Reviewed-by: Jason Ekstrand
CI is happy, I guess you got all the igt changes indeed. Both pushed
thanks for reviewing.
-Daniel
>
> On Tue, Aug 3, 2021 at 7:49 AM Daniel Vetter wrote:
> >
>
od primitives needs barriers. Those barriers each need a
comment which explains where the counterparty is. If this doesn't feel
like you're writing a small academic paper, you're not doing it right.
Note that with dgpu we can't shrug this all off with "IA i
m_rq_submit_no_id;
>
> + /* GuC number of requests not ready */
> + atomic_t guc_num_rq_not_ready;
atomic_t by default is unordered. This needs some giantic comments and
explainers why this is totally ok and we don't need barriers here.
I think good excuse to convert all the docs he
for all copy engine, when we run out jobs
only on one? Afaiui the arch decision is that the kernel reserves one
copy engine for it's private use on chips with multiple, and that's
it. So this looks like overkill that we should remove.
Adding Jon Bloomfield, that'
Waiman Long
> Acked-by: Peter Zijlstra (Intel)
Both patches pushed to drm-misc-next, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_auth.c | 6 +++---
> include/drm/drm_file.h | 4
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/g
the first two patches
could land asap, but that means testing by some of the other drivers.
Etnaviv especially is pending some testing/reviewed-by.
In general please review and test.
Thanks, Daniel
Daniel Vetter (20):
drm/sched: Split drm_sched_job_init
drm/msm: Fix drm/sched point of
ich the next
patch will address.
Acked-by: Melissa Wen
Cc: Melissa Wen
Acked-by: Emma Anholt
Acked-by: Steven Price (v2)
Reviewed-by: Boris Brezillon (v5)
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: S
Boris Brezillon (v3)
Reviewed-by: Steven Price (v1)
Acked-by: Melissa Wen
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Andrey Grodzovsky
Cc: Lee Jones
Cc: Nirmoy Das
Cc: Boris Brezillon
Cc: Luben Tuikov
Cc: Alex Deuche
-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/msm_gem_submit.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 6
e and load-acquire on ->last_scheduled would be enough,
but we actually requiring ordering between that and the queue state.
v2: Put smp_rmp() in the right place and fix up comment (Andrey)
Acked-by: Melissa Wen
Signed-off-by: Daniel Vetter
Cc: "Christian König"
Cc: Steven Price
g drm/sched
Acked-by: Emma Anholt
Acked-by: Melissa Wen
Reviewed-by: Steven Price (v1)
Reviewed-by: Boris Brezillon (v1)
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzwei
dependencies.
Signed-off-by: Daniel Vetter
Cc: Qiang Yu
Cc: Sumit Semwal
Cc: "Christian König"
Cc: l...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/gpu/drm/lima/lima_gem.c | 6 --
drivers/gpu/drm/lima/lima_sc
en
Reviewed-by: Boris Brezillon (v1)
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: "Christian König"
Cc: Boris Brezillon
Cc: Steven Price
Cc: Emma Anholt
Cc: Lee Jon
set up job, now that job_init()
and job_arm() are apart (Emma).
v3: Rebased over renamed functions for adding depdencies
Acked-by: Emma Anholt
Reviewed-by: Steven Price (v3)
Signed-off-by: Daniel Vetter
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Sumit
under construction correctly (Emma)
v4: Rebase over perfmon patch
Reviewed-by: Melissa Wen (v3)
Acked-by: Emma Anholt
Cc: Melissa Wen
Signed-off-by: Daniel Vetter
Cc: Emma Anholt
---
drivers/gpu/drm/v3d/v3d_drv.h | 1 +
drivers/gpu/drm/v3d/v3d_gem.c | 86
o add dependencies.
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Sumit Semwal
Cc: "Christian König"
Cc: etna...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/gpu/drm/etnaviv/etnaviv_gem.h|
Integrated into the scheduler now and all users converted over.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc:
drm_sched_job_init is already at the right place, so this boils down
to deleting code.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: Sean Paul
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: linux-me...@vger.ker
: Rebase over renamed function names for adding dependencies.
Reviewed-by: Melissa Wen (v1)
Acked-by: Emma Anholt
Cc: Melissa Wen
Signed-off-by: Daniel Vetter
Cc: Emma Anholt
---
drivers/gpu/drm/v3d/v3d_drv.h | 5 -
drivers/gpu/drm/v3d/v3d_gem.c | 26 +-
dri
.
Another option is the fence import ioctl from Jason:
https://lore.kernel.org/dri-devel/20210610210925.642582-7-ja...@jlekstrand.net/
v2: Improve commit message per Lucas' suggestion.
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.
t, so that drivers don't have to hack up their own
solution each on their own.
v2: Improve commit message per Lucas' suggestion.
Cc: Lucas Stach
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
No longer used, the last user disappeared with
commit d07f0e59b2c762584478920cd2d11fba2980a94a
Author: Chris Wilson
Date: Fri Oct 28 13:58:44 2016 +0100
drm/i915: Move GEM activity tracking into a common struct reservation_object
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc
You really need to hold the reservation here or all kinds of funny
things can happen between grabbing the dependencies and inserting the
new fences.
Acked-by: Melissa Wen
Signed-off-by: Daniel Vetter
Cc: "Christian König"
Cc: Daniel Vetter
Cc: Luben Tuikov
Cc: Andrey Grodzovsky
viewers that go across all
drivers wont miss it.
Reviewed-by: Lucas Stach
Acked-by: Melissa Wen
Signed-off-by: Daniel Vetter
Cc: "Christian König"
Cc: Daniel Vetter
Cc: Luben Tuikov
Cc: Andrey Grodzovsky
Cc: Alex Deucher
---
drivers/gpu/drm/scheduler/sched_main.c | 7 +++
1 f
.
Another option is the fence import ioctl from Jason:
https://lore.kernel.org/dri-devel/20210610210925.642582-7-ja...@jlekstrand.net/
v2: Improve commit message per Lucas' suggestion.
Cc: Lucas Stach
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: "Thomas Hellström"
Cc: Jas
use-after-free issues
around dma-buf sharing (Christian)
Reviewed-by: Christian König
Cc: Jason Ekstrand
Cc: Matthew Auld
Reviewed-by: Matthew Auld
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
On Thu, Aug 05, 2021 at 04:15:27AM +, Kasireddy, Vivek wrote:
> Hi Daniel,
>
> > > >>> The solution:
> > > >>> - To ensure full framerate, the Guest compositor has to start it's
> > > >>> repaint cycle
> > (including
>
hart
Reviewed-by: Daniel Vetter
And thanks for not going down the "let's add dummy functions and inflict
lots of error case handling onto a driver that will never be used" route
instead.
-Daniel
> ---
> drivers/gpu/drm/omapdrm/Kconfig | 2 +-
> 1 file changed, 1 insert
On Thu, Aug 5, 2021 at 3:18 PM Christian König wrote:
>
>
>
> Am 05.08.21 um 12:46 schrieb Daniel Vetter:
> > This is essentially part of drm_sched_dependency_optimized(), which
> > only amdgpu seems to make use of. Use it a bit more.
> >
> > This would
On Thu, Aug 5, 2021 at 3:19 PM Christian König wrote:
>
> Am 05.08.21 um 12:47 schrieb Daniel Vetter:
> > You really need to hold the reservation here or all kinds of funny
> > things can happen between grabbing the dependencies and inserting the
> > new fences.
>
On Thu, Aug 5, 2021 at 3:44 PM Christian König wrote:
> Am 05.08.21 um 12:46 schrieb Daniel Vetter:
> > This is a very confusingly named function, because not just does it
> > init an object, it arms it and provides a point of no return for
> > pushing a job into the schedu
On Thu, Aug 5, 2021 at 3:57 PM Christian König wrote:
> Am 05.08.21 um 15:25 schrieb Daniel Vetter:
> > On Thu, Aug 5, 2021 at 3:18 PM Christian König
> > wrote:
> >>
> >>
> >> Am 05.08.21 um 12:46 schrieb Daniel Vetter:
> >>> This is essen
On Thu, Aug 5, 2021 at 4:47 PM Christian König wrote:
>
> Am 05.08.21 um 16:07 schrieb Daniel Vetter:
> > On Thu, Aug 5, 2021 at 3:44 PM Christian König
> > wrote:
> >> Am 05.08.21 um 12:46 schrieb Daniel Vetter:
> >>> This is a very confusingly n
depends on DRM
> > + depends on DRM && OF
> > depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
> > select OMAP2_DSS
> > select DRM_KMS_HELPER
>
> Would it make sense to select OF instead?
select is extremely harmful for any user-visible
On Fri, Aug 6, 2021 at 12:58 AM Rob Clark wrote:
>
> On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote:
> >
> > Originally drm_sched_job_init was the point of no return, after which
> > drivers must submit a job. I've split that up, which allows us to fix
On Fri, Aug 6, 2021 at 7:15 PM Rob Clark wrote:
>
> On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter wrote:
> >
> > On Fri, Aug 6, 2021 at 12:58 AM Rob Clark wrote:
> > >
> > > On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter
> > > wrote:
> > > &g
n;
> >
> > + if (GRAPHICS_VER(i915) >= 12 && !IS_TIGERLAKE(i915) &&
> > + !IS_ROCKETLAKE(i915) && !IS_ALDERLAKE_S(i915)) {
> > + drm_dbg(&i915->drm,
> > + "Bonding on gen12+ aside from TGL, RKL, a
pace, which is worse.
I guess that's another area where the integration between what atomic
modeset expects and the DC backend provides is suboptimal. I think the
data structures we managed to fuse together fairly ok, but the
check/commit flow and semantics are a bit a struggle.
Anyway this
On Fri, Aug 6, 2021 at 8:57 PM Rob Clark wrote:
>
> On Fri, Aug 6, 2021 at 11:41 AM Daniel Vetter wrote:
> >
> > On Fri, Aug 6, 2021 at 7:15 PM Rob Clark wrote:
> > >
> > > On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter
> > > wrote:
> > &g
longer.
> >
> > And if ABI change is okay then commit message needs to talk about it
> > loudly and clearly.
> I don't think we have a choice. The current ABI is not and cannot ever
> be compatible with any scheduler external to i915. It cannot be
> implemented with a ha
t object actually invariant over its _entire_ lifetime.
Signed-off-by: Daniel Vetter
Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)")
Cc: Jason Ekstrand
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Matthew Brost
Cc: Matthew Auld
Cc: Maa
nately our
current code is way too fond of lockless trickery (which really isn't a
great idea in the reset code). We need to apply as much care as possible
here.
Also expect me to ask a lot of annoying questions about all the atomic_t
you touch :-)
-Daniel
>
> Fixes: f4eb1f3fe9
one of the IP markers).
Also I think the above should be replicated in condensed form instead of
the XXX comment.
With those: Acked-by: Daniel Vetter since I
definitely have enough clue here for a detailed review.
-Daniel
>
> Signed-off-by: Matthew Brost
> ---
>
ontext_deregister_done(ce);
>
> + if (I915_SELFTEST_ONLY(ce->drop_deregister)) {
> + I915_SELFTEST_DECLARE(ce->drop_deregister = false;)
This macro wrapping is quite nasty, can't we just #ifdef this? Especially
the _DECLARE name really doesn't expect a statem
hrough? Matt, can you pls figure out and type up the patch to
plug that hole?
Thanks, Daniel
>
> Regards, Joonas
>
> Quoting Stephen Rothwell (2021-07-15 07:18:54)
> > Hi all,
> >
> > Commit
> >
> > db47fe727e1f ("drm/i915/step: s/_revid_tbl/
On Fri, Aug 06, 2021 at 07:27:13AM +, Kasireddy, Vivek wrote:
> Hi Daniel,
>
> > > > > >>> The solution:
> > > > > >>> - To ensure full framerate, the Guest compositor has to start
> > > > > >>> it's repaint c
On Sat, Aug 07, 2021 at 06:21:10PM +0300, Imre Deak wrote:
> On Thu, Aug 05, 2021 at 12:23:21AM +0200, Daniel Vetter wrote:
> > On Mon, Aug 02, 2021 at 04:35:51PM +0300, Imre Deak wrote:
> > > Atm the EFI FB driver gets a runtime PM reference for the associated GFX
> > &g
ck annoations, and call those in the generic code.
Imo the worst kernel abstractions are those where all implementations
look&act the same, except for locking. Unfortunately i915-gem code is full
of this stuff, and we need to stop this by enlisting lockdep to check the
contracts for us.
-Daniel
her aside: How does the perf/OA patching work on GuC?
Anyway, patch looks legit:
Reviewed-by: Daniel Vetter
> + if (intel_engine_uses_guc(engine))
> + return true;
> +
> /* GPU is pointing to the void, as good as in the kernel context. */
> if (intel_gt_is
9a9e502 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -266,6 +266,7 @@ struct intel_engine_cs {
> unsigned int guc_id;
>
> intel_engine_mask_t mask;
> + intel_engine_mask_t logical_mask;
501 - 600 of 26156 matches
Mail list logo
