Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-07-08 Thread Chris Wilson
On Wed, Jul 08, 2015 at 03:24:08PM +0100, Tvrtko Ursulin wrote: > > On 07/08/2015 02:53 PM, Chris Wilson wrote: > >On Wed, Jul 08, 2015 at 02:36:08PM +0100, Tvrtko Ursulin wrote: > >> > >>On 07/08/2015 02:28 PM, Chris Wilson wrote: > >>>On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrot

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-07-08 Thread Tvrtko Ursulin
On 07/08/2015 02:53 PM, Chris Wilson wrote: On Wed, Jul 08, 2015 at 02:36:08PM +0100, Tvrtko Ursulin wrote: On 07/08/2015 02:28 PM, Chris Wilson wrote: On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote: Hi, On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: From: R

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-07-08 Thread Chris Wilson
On Wed, Jul 08, 2015 at 02:36:08PM +0100, Tvrtko Ursulin wrote: > > On 07/08/2015 02:28 PM, Chris Wilson wrote: > >On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote: > >> > >>Hi, > >> > >>On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: > >>>From: Rodrigo Vivi > >>> > >>

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-07-08 Thread Chris Wilson
On Wed, Jul 08, 2015 at 02:28:33PM +0100, Chris Wilson wrote: > On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote: > > > > Hi, > > > > On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: > > >From: Rodrigo Vivi > > > > > >When constructing a batchbuffer, it is sometimes cr

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-07-08 Thread Tvrtko Ursulin
On 07/08/2015 02:28 PM, Chris Wilson wrote: On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote: Hi, On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: From: Rodrigo Vivi When constructing a batchbuffer, it is sometimes crucial to know the largest hole into which we c

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-07-08 Thread Tvrtko Ursulin
On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: From: Rodrigo Vivi When constructing a batchbuffer, it is sometimes crucial to know the largest hole into which we can fit a fenceable buffer (for example when handling very large objects on gen2 and gen3). This depends on the fragm

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-07-08 Thread Chris Wilson
On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote: > > Hi, > > On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: > >From: Rodrigo Vivi > > > >When constructing a batchbuffer, it is sometimes crucial to know the > >largest hole into which we can fit a fenceable buffer (fo

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-07-08 Thread Tvrtko Ursulin
Hi, On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: From: Rodrigo Vivi When constructing a batchbuffer, it is sometimes crucial to know the largest hole into which we can fit a fenceable buffer (for example when handling very large objects on gen2 and gen3). This depends on the

[Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-07-08 Thread ankitprasad . r . sharma
From: Rodrigo Vivi When constructing a batchbuffer, it is sometimes crucial to know the largest hole into which we can fit a fenceable buffer (for example when handling very large objects on gen2 and gen3). This depends on the fragmentation of pinned buffers inside the aperture, a question only t

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-07-01 Thread Ankitprasad Sharma
On Wed, 2015-07-01 at 15:39 +0200, Daniel Vetter wrote: > On Wed, Jul 01, 2015 at 02:55:12PM +0530, ankitprasad.r.sha...@intel.com > wrote: > > From: Rodrigo Vivi > > > > When constructing a batchbuffer, it is sometimes crucial to know the > > largest hole into which we can fit a fenceable buffe

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-07-01 Thread Daniel Vetter
On Wed, Jul 01, 2015 at 02:55:12PM +0530, ankitprasad.r.sha...@intel.com wrote: > From: Rodrigo Vivi > > When constructing a batchbuffer, it is sometimes crucial to know the > largest hole into which we can fit a fenceable buffer (for example when > handling very large objects on gen2 and gen3).

[Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-07-01 Thread ankitprasad . r . sharma
From: Rodrigo Vivi When constructing a batchbuffer, it is sometimes crucial to know the largest hole into which we can fit a fenceable buffer (for example when handling very large objects on gen2 and gen3). This depends on the fragmentation of pinned buffers inside the aperture, a question only t

[Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

2015-05-13 Thread ankitprasad . r . sharma
From: Rodrigo Vivi When constructing a batchbuffer, it is sometimes crucial to know the largest hole into which we can fit a fenceable buffer (for example when handling very large objects on gen2 and gen3). This depends on the fragmentation of pinned buffers inside the aperture, a question only t