On Mon, 2024-01-15 at 15:00 +0200, Jani Nikula wrote:
> On Fri, 12 Jan 2024, Rodrigo Vivi wrote:
> > On Fri, Jan 12, 2024 at 07:31:51AM -0500, Hogander, Jouni wrote:
> > > On Wed, 2024-01-10 at 15:09 -0500, Rodrigo Vivi wrote:
> > > > On Tue, Jan 09, 2024 at 08:40:24PM +, Souza, Jose wrote:
>
On Fri, 2023-01-13 at 09:51 +, Tvrtko Ursulin wrote:
>
> On 12/01/2023 20:40, John Harrison wrote:
> > On 1/12/2023 02:01, Tvrtko Ursulin wrote:
> > > On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
> > > > From: John Harrison
> > > >
> > > > There was a report of error captures
Hi, [back from vacation]
On Tue, 2022-07-26 at 16:39 +0100, Robert Beckett wrote:
> Calling swiotlb functions directly is nowadays considered harmful.
> See
> https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
>
> Replace swiotlb_max_segment() calls with dma_max_mapping_size().
>
On Fri, 2022-07-08 at 07:51 -0700, Niranjana Vishwanathapura wrote:
> > Since we don't loop over the vm_bound_list, there is a need to
> > check
> > whether the rebind_list is empty here under the notifier_lock in
> > read
> > mode, and in that case, restart from eb_lookup_vmas(). That might
> >
On Fri, 2022-07-08 at 15:43 +0200, Thomas Hellström wrote:
> > The vm_bind/bound_list and the non_priv_vm_bind_list are there for
> > very different reasons.
> >
> > The reason for having separate vm_bind_list and vm_bound_list is
> > that
> > during the execbuf path, we can rebind the unbound
Hi,
On Fri, 2022-07-08 at 06:47 -0700, Niranjana Vishwanathapura wrote:
> On Thu, Jul 07, 2022 at 07:41:54AM -0700, Hellstrom, Thomas wrote:
> > On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> > > Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) whic
On Fri, 2022-07-08 at 06:14 -0700, Niranjana Vishwanathapura wrote:
> On Thu, Jul 07, 2022 at 03:31:42AM -0700, Hellstrom, Thomas wrote:
> > On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> > > Add uapi allowing user to specify a BO as private to a
On Fri, 2022-07-08 at 05:44 -0700, Niranjana Vishwanathapura wrote:
> On Thu, Jul 07, 2022 at 07:54:16AM -0700, Hellstrom, Thomas wrote:
> > On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> > > Handle persistent (VM_BIND) mappings during the reques
On Thu, 2022-07-07 at 21:38 +0200, Andi Shyti wrote:
> Hi,
>
> > It seems we are duplicating a lot of code from i915_execbuffer.c.
> > Did
> > you consider
>
> yeah... while reading the code I was thinking the same then I see
> that you made the same comment. Perhaps we need to group
>
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> For persistent (vm_bind) vmas of userptr BOs, handle the user
> page pinning by using the i915_gem_object_userptr_submit_init()
> /done() functions
>
> Signed-off-by: Niranjana Vishwanathapura
>
> ---
>
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> Handle persistent (VM_BIND) mappings during the request submission
> in the execbuf3 path.
>
> Signed-off-by: Niranjana Vishwanathapura
>
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 176
> +-
> 1
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
> works in vm_bind mode. The vm_bind mode only works with
> this new execbuf3 ioctl.
>
> The new execbuf3 ioctl will not have any execlist
I understand this that you
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> For persistent (vm_bind) vmas of userptr BOs, handle the user
> page pinning by using the i915_gem_object_userptr_submit_init()
> /done() functions
>
> Signed-off-by: Niranjana Vishwanathapura
>
> ---
>
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> Treat VM_BIND vmas as persistent and handle them during the
> request submission in the execbuff path.
>
> Support eviction by maintaining a list of evicted persistent vmas
> for rebinding during next submission.
>
>
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> Add uapi allowing user to specify a BO as private to a specified VM
> during the BO creation.
> VM private BOs can only be mapped on the specified VM and can't be
> dma_buf exported. VM private BOs share a single common dma_resv
On Wed, 2022-07-06 at 22:01 -0700, Niranjana Vishwanathapura wrote:
> > > + /**
> > > + * true: allow only vm_bind method of binding.
> > > + * false: allow only legacy execbuff method of binding.
> > > + */
> >
> > Use proper kerneldoc. (Same holds for structure
Hi,
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> Add VM_BIND and VM_UNBIND ioctls to bind/unbind a section of an
> object at the specified GPU virtual addresses.
>
> Add I915_PARAM_VM_BIND_VERSION to indicate version of VM_BIND feature
> supported and
Hi!
On Thu, 2022-06-30 at 15:20 +0100, Robert Beckett wrote:
>
>
> On 29/06/2022 13:51, Robert Beckett wrote:
> >
> >
> > On 28/06/2022 17:22, Robert Beckett wrote:
> > >
> > >
> > > On 28/06/2022 09:46, Tvrtko Ursulin wrote:
> > > >
> > > > On 27/06/2022 18:08, Robert Beckett wrote:
> > >
Hi Nirmoy.
On Fri, 2022-05-13 at 13:37 +0200, Nirmoy Das wrote:
> _i915_vma_move_to_active() can receive > 1 fence for
> multiple batch buffer submission so make sure to
> individualize fences before adding to dma_resv obj
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5614
>
On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> Object created with list of memory classes as placement preferences,
> can
> be backed with any memory class of the list as per kernel's migration
> policy for the memory contrain situation. Userspace won't be notified
> of
> the memory
On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> Capture the eviction details for Flat-CCS capable lmem only objects
> and
> lmem objects with smem residency. This also captures the impact of
> eviction on object's memory residency and Flat-CCS compression
> state.
>
> Signed-off-by:
On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> While locating the start of ccs scatterlist in smem scatterlist, that
> has
> to be the size of lmem obj size + corresponding ccs data size. Report
> bug
> if scatterlist terminate before that length.
>
> Signed-off-by: Ramalingam C
> ---
On Tue, 2022-03-29 at 00:37 +0530, Ramalingam C wrote:
> To make it uniform across copy and clear, use the engine offset
> directly
> to calculate the offset in the cmd forming for emit_clear.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/gt/intel_migrate.c | 11 ---
> 1
On Sun, 2022-03-20 at 02:12 +0530, Ramalingam C wrote:
> While clearing the Flat-CCS capable lmem object, we need to clear the
> CCS
> meta data corresponding to the memory.
>
> As part of live_migrate_clear add check for the ccs meta data clear
> for
> the Flat-CCS capable lmem object.
>
>
On Sun, 2022-03-20 at 02:12 +0530, Ramalingam C wrote:
> XY_FAST_COLOR_BLT cmd is faster than the older XY_COLOR_BLT. Hence
> for
> clearing (Zero out) the pages of the newly allocated object, faster
> cmd
> is used.
NIT: Imperative wording
>
> Signed-off-by: Ramalingam C
> Signed-off-by:
On Mon, 2022-03-07 at 19:10 +0530, Ramalingam C wrote:
> Xe-HP and latest devices support Flat CCS which reserved a portion of
> the device memory to store compression metadata, during the clearing
> of
> device memory buffer object we also need to clear the associated
> CCS buffer.
>
>
Hi, Ram.
Typo in patch title FASR/FAST
On Mon, 2022-03-07 at 19:10 +0530, Ramalingam C wrote:
> XY_FAST_COLOR_BLT cmd is faster than the older XY_COLOR_BLT. Hence
> for
> clearing (Zero out) the pages of the newly allocated object, faster
> cmd
> is used.
>
> Signed-off-by: Ramalingam C
>
On Wed, 2022-03-02 at 10:37 +, Tvrtko Ursulin wrote:
>
> + Thomas, Matt
>
> On 02/03/2022 06:19, Jiasheng Jiang wrote:
> > As the potential failure of the i915_gem_object_trylock(),
> > it should be better to check it and return error if fails.
> >
> > Fixes: 94ce0d65076c ("drm/i915/gt:
On Wed, 2022-03-02 at 03:23 +0530, Ramalingam C wrote:
> When we are swapping out the local memory obj on flat-ccs capable
> platform,
> we need to capture the ccs data too along with main meory and we need
> to
> restore it when we are swapping in the content.
>
> When lmem object is swapped
On Wed, 2022-03-02 at 03:23 +0530, Ramalingam C wrote:
> From: Ayaz A Siddiqui
>
> Xe-HP and latest devices support Flat CCS which reserved a portion of
> the device memory to store compression metadata, during the clearing
> of
> device memory buffer object we also need to clear the associated
On Mon, 2022-02-07 at 20:44 +0530, Ramalingam C wrote:
> On 2022-02-07 at 20:25:42 +0530, Hellstrom, Thomas wrote:
> > Hi, Ram,
> >
> > A couple of quick questions before starting a more detailed review:
> >
> > 1) Does this also support migrating of compresse
Hi, Ram,
A couple of quick questions before starting a more detailed review:
1) Does this also support migrating of compressed data LMEM->LMEM?
What-about inter-tile?
2) Do we need to block faulting of compressed data in the fault handler
as a follow-up patch?
/Thomas
On Mon, 2022-02-07 at
Hi, Christian,
On Mon, 2022-02-07 at 12:41 +0100, Christian König wrote:
> Am 07.02.22 um 10:37 schrieb Ramalingam C:
> > On flat-ccs capable platform we need to evict and resore the ccs data
> > along with the corresponding main memory.
> >
> > This ccs data can only be access through BLT
On Wed, 2021-12-08 at 16:05 -0800, Jasmine Newsome wrote:
> Using local pointer ttm as argument in __i915_ttm_move
> instead of bo->ttm, as local pointer was previously assigned
> to bo->ttm in function. This will make code a bit more readable.
>
> Signed-off-by: Jasmine Newsome
Reviewed-by:
34 matches
Mail list logo
