Re: [PATCH] drm/i915: Perform execbuffer object locking as a separate step

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Subject: Re: [PATCH] drm/i915: Perform execbuffer object locking as a separate step
From: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>
Date: Thu, 17 Jun 2021 12:07:31 +0200
Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx, matthew.auld@xxxxxxxxx, dri-devel@xxxxxxxxxxxxxxxxxxxxx
In-reply-to: <20210617095620.GA15664@intel.com>
References: <20210615113600.30660-1-thomas.hellstrom@linux.intel.com> <20210617095620.GA15664@intel.com>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1


On 6/17/21 11:56 AM, Ramalingam C wrote:

On 2021-06-15 at 13:36:00 +0200, Thomas Hellström wrote:

To help avoid evicting already resident buffers from the batch we're
processing, perform locking as a separate step.

Looks reasonable to me.

Reviewed-by: Ramalingam C <ramalingam.c@xxxxxxxxx>

Thanks for reviewing!

/Thomas

References:
- [PATCH] drm/i915: Perform execbuffer object locking as a separate step
  - From: Thomas Hellström
- Re: [PATCH] drm/i915: Perform execbuffer object locking as a separate step
  - From: Ramalingam C

Prev by Date: Re: [PATCH] drm/i915: Perform execbuffer object locking as a separate step
Next by Date: Re: [PATCH] drm/i915: Perform execbuffer object locking as a separate step
Previous by thread: Re: [PATCH] drm/i915: Perform execbuffer object locking as a separate step
Next by thread: Re: [PATCH] drm/i915: Perform execbuffer object locking as a separate step
Index(es):
- Date
- Thread

[Index of Archives] [Linux DRI Users] [Linux Intel Graphics] [Linux USB Devel] [Video for Linux] [Linux Audio Users] [Yosemite News] [Linux Kernel] [Linux SCSI] [XFree86] [Linux USB Devel] [Video for Linux] [Linux Audio Users] [Linux Kernel] [Linux SCSI] [XFree86]

Powered by Linux