On Thu, Jan 12, 2023 at 11:17 AM Matthew Brost
wrote:
> On Thu, Jan 12, 2023 at 10:54:25AM +0100, Lucas De Marchi wrote:
> > On Thu, Jan 05, 2023 at 09:27:57PM +, Matthew Brost wrote:
> > > On Tue, Jan 03, 2023 at 12:21:08PM +, Tvrtko Ursulin wrote:
> > > >
> > > > On 22/12/2022 22:21, Ma
On Thu, Dec 22, 2022 at 4:29 PM Matthew Brost
wrote:
> Hello,
>
> This is a submission for Xe, a new driver for Intel GPUs that supports both
> integrated and discrete platforms starting with Tiger Lake (first platform
> with
> Intel Xe Architecture). The intention of this new driver is to have a
On Wed, Jan 11, 2023 at 4:32 PM Matthew Brost
wrote:
> On Wed, Jan 11, 2023 at 04:18:01PM -0600, Jason Ekstrand wrote:
> > On Wed, Jan 11, 2023 at 2:50 AM Tvrtko Ursulin <
> > tvrtko.ursu...@linux.intel.com> wrote:
> >
> > >
> > > On 10/01/2023 14:08,
On Wed, Jan 11, 2023 at 2:50 AM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:
>
> On 10/01/2023 14:08, Jason Ekstrand wrote:
> > On Tue, Jan 10, 2023 at 5:28 AM Tvrtko Ursulin
> > mailto:tvrtko.ursu...@linux.intel.com>>
>
> > wrote:
> &g
On Tue, Jan 10, 2023 at 5:28 AM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:
>
>
> On 09/01/2023 17:27, Jason Ekstrand wrote:
>
> [snip]
>
> > >>> AFAICT it proposes to have 1:1 between *userspace* created
> > contexts (per
> &
On Mon, Jan 9, 2023 at 7:46 AM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:
>
> On 06/01/2023 23:52, Matthew Brost wrote:
> > On Thu, Jan 05, 2023 at 09:43:41PM +, Matthew Brost wrote:
> >> On Tue, Jan 03, 2023 at 01:02:15PM +, Tvrtko Ursulin wrote:
> >>>
> >>> On 02/01/2023 07:
On Thu, Jan 5, 2023 at 1:40 PM Matthew Brost
wrote:
> On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris Brezillon wrote:
> > On Fri, 30 Dec 2022 12:55:08 +0100
> > Boris Brezillon wrote:
> >
> > > On Fri, 30 Dec 2022 11:20:42 +0100
> > > Boris Brezillon wrote:
> > >
> > > > Hello Matthew,
> > > >
Acked-by: Jason Ekstrand
On Thu, Dec 1, 2022 at 4:22 AM Daniel Vetter wrote:
> On Thu, 1 Dec 2022 at 11:07, Daniel Vetter wrote:
> >
> > On Wed, Nov 23, 2022 at 08:24:37PM +0100, Daniel Vetter wrote:
> > > It's a bit a FAQ, and we really can't claim to be
On Mon, Aug 22, 2022 at 8:27 AM Christian König
wrote:
> Am 22.08.22 um 10:34 schrieb Bas Nieuwenhuizen:
> > On Mon, Aug 22, 2022 at 9:28 AM Dave Airlie wrote:
> >> On Mon, 22 Aug 2022 at 17:05, Dave Airlie wrote:
> >>> Hey,
> >>>
> >>> I've just been looking at the vm bind type interfaces and
+mesa-dev and my jlekstrand.net e-mail
On Sun, 2022-08-21 at 20:44 +0200, Karol Herbst wrote:
> On Sun, Aug 21, 2022 at 8:34 PM Rob Clark
> wrote:
> >
> > On Sun, Aug 21, 2022 at 10:45 AM Karol Herbst
> > wrote:
> > >
> > > On Sun, Aug 21, 2022 at 7:43 PM Karol Herbst
> > > wrote:
> > > >
>
se others
> are using the dma_resv object in the same way.
>
Especially in the new world of dma_resv being a "bag of fences", I think
this makes a lot of sense.
Reviewed-by: Jason Ekstrand
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 3 ++
On Mon, Aug 8, 2022 at 11:39 AM Jason Ekstrand
wrote:
> On Sun, 2022-08-07 at 18:35 +0200, Christian König wrote:
> > Am 02.08.22 um 23:01 schrieb Jason Ekstrand:
> > > Ever since 68129f431faa ("dma-buf: warn about containers in
> > > dma_resv object"),
>
On Fri, 2022-07-15 at 11:20 +0100, Dennis Tsiang wrote:
> On 30/06/2022 08:47, Pekka Paalanen wrote:
> > On Wed, 29 Jun 2022 14:53:49 +
> > Simon Ser wrote:
> >
> > > On Wednesday, June 29th, 2022 at 16:46, Dennis Tsiang
> > > wrote:
> > >
> > > > Thanks for your comments. This is not inten
On Sun, 2022-08-07 at 18:35 +0200, Christian König wrote:
> Am 02.08.22 um 23:01 schrieb Jason Ekstrand:
> > Ever since 68129f431faa ("dma-buf: warn about containers in
> > dma_resv object"),
> > dma_resv_add_shared_fence will warn if you attempt to add a
>
FILE. Use dma_fence_unwrap_for_each
to add each fence one at a time.
Fixes: 594740497e99 ("dma-buf: Add an API for importing sync files (v10)")
Signed-off-by: Jason Ekstrand
Reported-by: Sarah Walker
Cc: Christian König
---
drivers/dma-buf/dma-buf.c | 23 +--
1 file changed,
On Sat, Jun 25, 2022 at 8:49 PM Niranjana Vishwanathapura <
niranjana.vishwanathap...@intel.com> wrote:
> VM_BIND and related uapi definitions
>
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand VM_UNBIND documentation and add
> I915_GEM_VM_BIND/UNBIND_FENCE_VALID
> and I915_GEM
On Thu, Jun 30, 2022 at 10:14 AM Matthew Auld
wrote:
> On 30/06/2022 06:11, Jason Ekstrand wrote:
> > On Sat, Jun 25, 2022 at 8:49 PM Niranjana Vishwanathapura
> > > <mailto:niranjana.vishwanathap...@intel.com>> wrote:
> >
> > VM_BIND and related uapi
On Sat, Jun 25, 2022 at 8:49 PM Niranjana Vishwanathapura <
niranjana.vishwanathap...@intel.com> wrote:
> VM_BIND and related uapi definitions
>
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand VM_UNBIND documentation and add
> I915_GEM_VM_BIND/UNBIND_FENCE_VALID
> and I915_GEM
2022 at 11:18:11AM -0700, Niranjana Vishwanathapura
> wrote:
> >>>On Tue, Jun 07, 2022 at 12:12:03PM -0500, Jason Ekstrand wrote:
> >>>> On Fri, Jun 3, 2022 at 6:52 PM Niranjana Vishwanathapura
> >>>> wrote:
> >>>>
> >>>> On F
owever, this is a
case of userspace 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):
- L
tionality to be used in an entirely driver-agnostic way without
having access to a DRM fd. This makes it ideal for use in driver-generic
code in Mesa or in a client such as a compositor where the DRM fd may be
hard to reach.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences includi
y for now.
Mesa MR: https://gitlab.freedesktop.org/mesa/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 (Dani
On Tue, 2022-06-07 at 12:55 +0200, Greg KH wrote:
> On Thu, Jun 02, 2022 at 08:47:56AM +0200, Daniel Vetter wrote:
> > On Thu, 2 Jun 2022 at 08:34, Simon Ser wrote:
> > >
> > > On Thursday, June 2nd, 2022 at 08:25, Greg KH
> > > wrote:
> > >
> > > > On Thu, Jun 02, 2022 at 06:17:31AM +, Sim
On Fri, Jun 3, 2022 at 6:52 PM Niranjana Vishwanathapura <
niranjana.vishwanathap...@intel.com> wrote:
> On Fri, Jun 03, 2022 at 10:20:25AM +0300, Lionel Landwerlin wrote:
> > On 02/06/2022 23:35, Jason Ekstrand wrote:
> >
> > On Thu, Jun 2, 2022 at 3:11 P
On Thu, Jun 2, 2022 at 3:11 PM Niranjana Vishwanathapura <
niranjana.vishwanathap...@intel.com> wrote:
> On Wed, Jun 01, 2022 at 01:28:36PM -0700, Matthew Brost wrote:
> >On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel Landwerlin wrote:
> >> On 17/05/2022 21:32, Niranjana Vishwanathapura wrote:
>
> - Fix SPDX comment style
>
> v4: improve sysfs code (Greg)
>
> Signed-off-by: Simon Ser
> Reviewed-by: Jason Ekstrand
> Cc: Daniel Vetter
> Cc: Bas Nieuwenhuizen
> Cc: Christian König
> Cc: Greg KH
> ---
> .../ABI/testing/sysfs-kernel-dmabuf-caps
On Mon, 2022-05-30 at 10:26 +0200, Greg KH wrote:
> On Mon, May 30, 2022 at 08:15:04AM +, Simon Ser wrote:
> > On Monday, May 30th, 2022 at 09:20, Greg KH
> > wrote:
> >
> > > > > +static struct attribute *dma_buf_caps_attrs[] = {
> > > > > + &dma_buf_sync_file_import_export_attr.attr,
from/to DMA-BUFs is supported.
>
> Signed-off-by: Simon Ser
> Cc: Jason Ekstrand
> Cc: Daniel Vetter
> Cc: Bas Nieuwenhuizen
> Cc: Christian König
> ---
>
> Oops, I forgot to check in new files after spliting a commit.
> Fixed.
>
> This depends on:
> https:
On Wed, May 25, 2022 at 5:02 AM Daniel Stone wrote:
> On Sat, 7 May 2022 at 14:18, Jason Ekstrand wrote:
> > This patch series actually contains two new ioctls. There is the export
> one
> > mentioned above as well as an RFC for an import ioctl which provides the
>
--Jason
> >
> > Christian.
> >
> > Am 06.05.22 um 20:02 schrieb Jason Ekstrand:
> > > Modern userspace APIs like Vulkan are built on an explicit
> > > synchronization model. This doesn't always play nicely with the
> > > implicit synchron
On Wed, May 25, 2022 at 10:43 AM Daniel Vetter wrote:
> On Wed, May 25, 2022 at 10:35:47AM -0500, Jason Ekstrand wrote:
> > On Wed, May 25, 2022 at 8:20 AM Daniel Vetter wrote:
> >
> > > On Mon, May 09, 2022 at 07:54:19AM +0200, Christian König wrote:
> > > &g
tionality to be used in an entirely driver-agnostic way without
having access to a DRM fd. This makes it ideal for use in driver-generic
code in Mesa or in a client such as a compositor where the DRM fd may be
hard to reach.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences includi
y for now.
Mesa MR: https://gitlab.freedesktop.org/mesa/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 (Dani
owever, this is a
case of userspace 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):
- L
On Thu, May 5, 2022 at 3:23 AM Daniel Vetter wrote:
> On Thu, May 05, 2022 at 03:05:44AM -0500, Jason Ekstrand wrote:
> > On Wed, May 4, 2022 at 5:49 PM Daniel Vetter wrote:
> >
> > > On Wed, May 04, 2022 at 03:34:03PM -0500, Jason Ekstrand wrote:
> > > > M
On Wed, May 4, 2022 at 5:53 PM Daniel Vetter wrote:
> On Wed, May 04, 2022 at 03:34:04PM -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
> >
On Thu, May 5, 2022 at 1:25 AM Christian König
wrote:
> Am 04.05.22 um 22:34 schrieb Jason Ekstrand:
> > Modern userspace APIs like Vulkan are built on an explicit
> > synchronization model. This doesn't always play nicely with the
> > implicit synchronization used in
On Wed, May 4, 2022 at 5:49 PM Daniel Vetter wrote:
> On Wed, May 04, 2022 at 03:34:03PM -0500, Jason Ekstrand wrote:
> > Modern userspace APIs like Vulkan are built on an explicit
> > synchronization model. This doesn't always play nicely with the
> > implicit s
y for now.
Mesa MR: https://gitlab.freedesktop.org/mesa/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 (Dani
owever, this is a
case of userspace 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):
- L
y for now.
Mesa MR: https://gitlab.freedesktop.org/mesa/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 (Dani
owever, this is a
case of userspace 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):
- L
tionality to be used in an entirely driver-agnostic way without
having access to a DRM fd. This makes it ideal for use in driver-generic
code in Mesa or in a client such as a compositor where the DRM fd may be
hard to reach.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences includi
tionality to be used in an entirely driver-agnostic way without
having access to a DRM fd. This makes it ideal for use in driver-generic
code in Mesa or in a client such as a compositor where the DRM fd may be
hard to reach.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences includi
On Wed, Dec 22, 2021 at 4:00 PM Daniel Vetter wrote:
> On Tue, Dec 07, 2021 at 01:34:05PM +0100, Christian König wrote:
> > This change adds the dma_resv_usage enum and allows us to specify why a
> > dma_resv object is queried for its containing fences.
> >
> > Additional to that a dma_resv_usage
On Mon, Jan 17, 2022 at 5:26 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 14.01.22 um 17:31 schrieb Daniel Vetter:
> > On Mon, Jan 03, 2022 at 12:13:41PM +0100, Christian König wrote:
> >> Am 22.12.21 um 22:21 schrieb Daniel Vetter:
> >>> On Tue, Dec 07, 2021 at 01:33:51PM +0
On Wed, Dec 22, 2021 at 4:05 PM Daniel Vetter wrote:
> On Tue, Dec 07, 2021 at 01:34:07PM +0100, Christian König wrote:
> > Add an usage for kernel submissions. Waiting for those
> > are mandatory for dynamic DMA-bufs.
> >
> > Signed-off-by: Christian König
>
> Again just skipping to the doc bik
On Thu, Aug 19, 2021 at 1:22 AM Matthew Brost wrote:
>
> Propagating errors to dependent fences is wrong, don't do it. A selftest
> in the following exposed the propagating of an error to a dependent
> fence after an engine reset.
I feel like we could still have a bit of a better message. Maybe
I'd really like this for Mesa so we can pull drm_fourcc.h into common
WSI code. Why has it stalled?
--Jason
On Tue, Dec 8, 2020 at 2:33 AM James Park wrote:
>
> I updated the patch earlier today incorporating the suggestions. I also had
> to bring back "#include " to drm.h because there's some
Makes sense
Reviewed-by: Jason Ekstrand
On Mon, Aug 16, 2021 at 2:40 AM Christian König
wrote:
>
> Am 10.08.21 um 21:59 schrieb Dan Moulding:
> > In 69de4421bb4c ("drm/ttm: Initialize debugfs from
> > ttm_global_init()"), ttm_global_init was changed so that if
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
It's needed for pgprot_t which is used in the header.
Signed-off-by: Jason Ekstrand
Cc: Christian König
---
drivers/gpu/drm/ttm/ttm_tt.c | 1 -
include/drm/ttm/ttm_tt.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/dr
These names were changed in
commit 8af8a109b34fa88b8b91f25d11485b37d37549c3
Author: Christian König
Date: Thu Oct 1 14:51:40 2020 +0200
drm/ttm: device naming cleanup
But he missed a couple of them.
Signed-off-by: Jason Ekstrand
Cc: Christian König
Fixes: 8af8a109b34f ("dr
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&#
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
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,
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
aniel Vetter):
- Minor wording tweaks
Signed-off-by: Jason Ekstrand
Acked-by: Daniel Vetter
Cc: Dave Airlie
---
Documentation/gpu/drm-uapi.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 199afb503ab1..7b398c6fadc6 1
On Wed, Aug 4, 2021 at 1:48 PM Jason Ekstrand wrote:
>
> While tracking down various bits of i915 uAPI, it's been difficult to
> find the userspace much of the time because no one bothers to mention it
> in commit messages. Require the kernel patch to be a one-stop shop for
>
ff-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Dave Airlie
---
Documentation/gpu/drm-uapi.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 199afb503ab1..82f780bc3fce 100644
--- a/Documentation/gpu/drm-uapi.rst
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
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:
> &
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
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
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
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 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
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
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/
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
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
&
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/
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
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:
> > &
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
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 |
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
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,
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
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: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
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
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
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
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
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
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
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
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):
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
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
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
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 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
: Thomas Hellström
Signed-off-by: Michael J. Ruhl
Reported-by: kernel test robot
Signed-off-by: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 23 -
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 87 ++-
2 files changed, 106
test error cases
Reported-by: Michael J. Ruhl
Signed-off-by: Thomas Hellström
Signed-off-by: Michael J. Ruhl
Signed-off-by: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 37 --
.../drm/i915/gem/selftests/i915_gem_dmabu
1 - 100 of 832 matches
Mail list logo
