Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
From: Rodrigo Vivi rodrigo.vivi at intel.com
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 the
kernel can easily answer.
This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to
include a couple of new fields in its reply to userspace - the total
amount of space available in the mappable region of the aperture and
also the single largest block available.
This is not quite what userspace wants to answer the question of whether
this batch will fit as fences are also required to meet severe alignment
constraints within the batch. For this purpose, a third conservative
estimate of largest fence available is also provided. For when userspace
needs more than one batch, we also provide the culmulative space
available for fences such that it has some additional guidance to how
much space it could allocate to fences. Conservatism still wins.
The patch also adds a debugfs file for convenient testing and reporting.
v2: The first object cannot end at offset 0, so we can use last==0 to
detect the empty list.
v3: Expand all values to 64bit, just in case.
Report total mappable aperture size for userspace that cannot easily
determine it by inspecting the PCI device.
v4: (Rodrigo) Fixed rebase conflicts.
Signed-off-by: Chris Wilson chris at chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.vivi at intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 +
drivers/gpu/drm/i915/i915_gem.c | 116 ++--
include/uapi/drm/i915_drm.h | 25
3 files changed, 164 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 31d8768..49ec438 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -512,6 +512,32 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
return 0;
}
+static int i915_gem_aperture_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m-private;
+ struct drm_i915_gem_get_aperture arg;
+ int ret;
+
+ ret = i915_gem_get_aperture_ioctl(node-minor-dev, arg, NULL);
+ if (ret)
+ return ret;
+
+ seq_printf(m, Total size of the GTT: %llu bytes\n,
+ arg.aper_size);
+ seq_printf(m, Available space in the GTT: %llu bytes\n,
+ arg.aper_available_size);
+ seq_printf(m, Available space in the mappable aperture: %llu bytes\n,
+ arg.map_available_size);
+ seq_printf(m, Single largest space in the mappable aperture: %llu
bytes\n,
+ arg.map_largest_size);
+ seq_printf(m, Available space for fences: %llu bytes\n,
+ arg.fence_available_size);
+ seq_printf(m, Single largest fence available: %llu bytes\n,
+ arg.fence_largest_size);
+
+ return 0;
+}
+
static int i915_gem_gtt_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m-private;
@@ -5030,6 +5056,7 @@ static int i915_debugfs_create(struct dentry *root,
static const struct drm_info_list i915_debugfs_list[] = {
{i915_capabilities, i915_capabilities, 0},
{i915_gem_objects, i915_gem_object_info, 0},
+ {i915_gem_aperture, i915_gem_aperture_info, 0},
{i915_gem_gtt, i915_gem_gtt_info, 0},
{i915_gem_pinned, i915_gem_gtt_info, 0, (void *) PINNED_LIST},
{i915_gem_active, i915_gem_object_list_info, 0, (void *) ACTIVE_LIST},
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a2a4a27..ccfc8d3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -32,6 +32,7 @@
#include i915_vgpu.h
#include i915_trace.h
#include intel_drv.h
+#include linux/list_sort.h
#include linux/shmem_fs.h
#include linux/slab.h
#include linux/swap.h
@@ -143,6 +144,55 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
return 0;
}
+static inline bool
+i915_gem_object_is_inactive(struct drm_i915_gem_object *obj)
+{
+ return i915_gem_obj_bound_any(obj) !obj-active;
+}
Oh and this function is not used.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
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 rodrigo.vivi at intel.com 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 the kernel can easily answer. This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to include a couple of new fields in its reply to userspace - the total amount of space available in the mappable region of the aperture and also the single largest block available. Since whatever this returns is a transient number is this really that useful? There are no guarantees that by the time caller tries to act on it it will still be valid. Yes. My use case is actually after a failure to capture debug information. I don't anticipate frequent calls to get_aperture (usually just a single call during early init). Though that predates full-ppgtt (and even the recent aliasing-ppgtt split). Time to start thinking about doing something similar for contexts. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
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 rodrigo.vivi at intel.com 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 the kernel can easily answer. This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to include a couple of new fields in its reply to userspace - the total amount of space available in the mappable region of the aperture and also the single largest block available. Since whatever this returns is a transient number is this really that useful? There are no guarantees that by the time caller tries to act on it it will still be valid. Yes. My use case is actually after a failure to capture debug information. I don't anticipate frequent calls to get_aperture (usually just a single call during early init). -Chrs -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
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 rodrigo.vivi at intel.com 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 the kernel can easily answer. This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to include a couple of new fields in its reply to userspace - the total amount of space available in the mappable region of the aperture and also the single largest block available. Since whatever this returns is a transient number is this really that useful? There are no guarantees that by the time caller tries to act on it it will still be valid. Yes. My use case is actually after a failure to capture debug information. I don't anticipate frequent calls to get_aperture (usually just a single call during early init). Should it better go to debugfs then? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
Hi,
On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
From: Rodrigo Vivi rodrigo.vivi at intel.com
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 the
kernel can easily answer.
This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to
include a couple of new fields in its reply to userspace - the total
amount of space available in the mappable region of the aperture and
also the single largest block available.
Since whatever this returns is a transient number is this really that
useful? There are no guarantees that by the time caller tries to act on
it it will still be valid.
This is not quite what userspace wants to answer the question of whether
this batch will fit as fences are also required to meet severe alignment
constraints within the batch. For this purpose, a third conservative
estimate of largest fence available is also provided. For when userspace
needs more than one batch, we also provide the culmulative space
available for fences such that it has some additional guidance to how
much space it could allocate to fences. Conservatism still wins.
The patch also adds a debugfs file for convenient testing and reporting.
v2: The first object cannot end at offset 0, so we can use last==0 to
detect the empty list.
v3: Expand all values to 64bit, just in case.
Report total mappable aperture size for userspace that cannot easily
determine it by inspecting the PCI device.
v4: (Rodrigo) Fixed rebase conflicts.
Signed-off-by: Chris Wilson chris at chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.vivi at intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 +
drivers/gpu/drm/i915/i915_gem.c | 116 ++--
include/uapi/drm/i915_drm.h | 25
3 files changed, 164 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 31d8768..49ec438 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -512,6 +512,32 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
return 0;
}
+static int i915_gem_aperture_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m-private;
+ struct drm_i915_gem_get_aperture arg;
+ int ret;
+
+ ret = i915_gem_get_aperture_ioctl(node-minor-dev, arg, NULL);
+ if (ret)
+ return ret;
+
+ seq_printf(m, Total size of the GTT: %llu bytes\n,
+ arg.aper_size);
+ seq_printf(m, Available space in the GTT: %llu bytes\n,
+ arg.aper_available_size);
+ seq_printf(m, Available space in the mappable aperture: %llu bytes\n,
+ arg.map_available_size);
+ seq_printf(m, Single largest space in the mappable aperture: %llu
bytes\n,
+ arg.map_largest_size);
+ seq_printf(m, Available space for fences: %llu bytes\n,
+ arg.fence_available_size);
+ seq_printf(m, Single largest fence available: %llu bytes\n,
+ arg.fence_largest_size);
+
+ return 0;
+}
+
static int i915_gem_gtt_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m-private;
@@ -5030,6 +5056,7 @@ static int i915_debugfs_create(struct dentry *root,
static const struct drm_info_list i915_debugfs_list[] = {
{i915_capabilities, i915_capabilities, 0},
{i915_gem_objects, i915_gem_object_info, 0},
+ {i915_gem_aperture, i915_gem_aperture_info, 0},
{i915_gem_gtt, i915_gem_gtt_info, 0},
{i915_gem_pinned, i915_gem_gtt_info, 0, (void *) PINNED_LIST},
{i915_gem_active, i915_gem_object_list_info, 0, (void *) ACTIVE_LIST},
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a2a4a27..ccfc8d3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -32,6 +32,7 @@
#include i915_vgpu.h
#include i915_trace.h
#include intel_drv.h
+#include linux/list_sort.h
#include linux/shmem_fs.h
#include linux/slab.h
#include linux/swap.h
@@ -143,6 +144,55 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
return 0;
}
+static inline bool
+i915_gem_object_is_inactive(struct drm_i915_gem_object *obj)
+{
+ return i915_gem_obj_bound_any(obj) !obj-active;
+}
+
+static int obj_rank_by_ggtt(void *priv,
+ struct list_head *A,
+ struct list_head *B)
+{
+ struct drm_i915_gem_object *a = list_entry(A,typeof(*a), obj_exec_link);
+ struct drm_i915_gem_object *b = list_entry(B,typeof(*b), obj_exec_link);
Nitpick - space after comma.
+
+ return i915_gem_obj_ggtt_offset(a) -
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
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 rodrigo.vivi at intel.com 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 the kernel can easily answer. This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to include a couple of new fields in its reply to userspace - the total amount of space available in the mappable region of the aperture and also the single largest block available. Since whatever this returns is a transient number is this really that useful? There are no guarantees that by the time caller tries to act on it it will still be valid. Yes. My use case is actually after a failure to capture debug information. I don't anticipate frequent calls to get_aperture (usually just a single call during early init). Should it better go to debugfs then? Hmm, I could accept that. In such a scenario, I would suggest we ignore the avail_aperture_space field all together, just report it as max (or whatever) and simply add fields for max stolen, max mappable, max ggtt (already present) and max ppgtt. (Rather than continue trying to kill multiple birds with one stone, where 99.9% of users don't want the overhead.) Move the current patch series into debugfs.c and just add the limits to get_aperture? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
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: Rodrigo Vivi rodrigo.vivi at intel.com 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 the kernel can easily answer. This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to include a couple of new fields in its reply to userspace - the total amount of space available in the mappable region of the aperture and also the single largest block available. Since whatever this returns is a transient number is this really that useful? There are no guarantees that by the time caller tries to act on it it will still be valid. Yes. My use case is actually after a failure to capture debug information. I don't anticipate frequent calls to get_aperture (usually just a single call during early init). Should it better go to debugfs then? Hmm, I could accept that. In such a scenario, I would suggest we ignore the avail_aperture_space field all together, just report it as max (or whatever) and simply add fields for max stolen, max mappable, max ggtt (already present) and max ppgtt. (Rather than continue trying to kill multiple birds with one stone, where 99.9% of users don't want the overhead.) Move the current patch series into debugfs.c and just add the limits to get_aperture? It would make a more sensible ioctl if you think we could get away with it. Hopefully no userspace tries to do anything smart with aper_available_size today? I see one IGT user, gem_ctx_exec, which probably isn't a blocker. In that case for stolen we would add: stolen_size = dev_priv-gtt.stolen_size stolen_available = stolen_size - bios_reserved (Bios_reserved would have to be stored in i915_gtt since it is currently local to i915_gem_init_stolen.) Plus the ones you listed, mappable_size and ppgtt_size. And the used/largest/fence/... ones go to debugfs. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
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 wrote: Hi, On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: From: Rodrigo Vivi rodrigo.vivi at intel.com 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 the kernel can easily answer. This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to include a couple of new fields in its reply to userspace - the total amount of space available in the mappable region of the aperture and also the single largest block available. Since whatever this returns is a transient number is this really that useful? There are no guarantees that by the time caller tries to act on it it will still be valid. Yes. My use case is actually after a failure to capture debug information. I don't anticipate frequent calls to get_aperture (usually just a single call during early init). Should it better go to debugfs then? Hmm, I could accept that. In such a scenario, I would suggest we ignore the avail_aperture_space field all together, just report it as max (or whatever) and simply add fields for max stolen, max mappable, max ggtt (already present) and max ppgtt. (Rather than continue trying to kill multiple birds with one stone, where 99.9% of users don't want the overhead.) Move the current patch series into debugfs.c and just add the limits to get_aperture? It would make a more sensible ioctl if you think we could get away with it. Hopefully no userspace tries to do anything smart with aper_available_size today? I see one IGT user, gem_ctx_exec, which probably isn't a blocker. Now that you mention it, we lie anyway there. The idea behind gem_ctx_exec is try and guage how much remaining global gtt space we need to fill with context objects - but important reservations of global gtt aren't even subtracted from the avail aperture space. There's also a use in sna when we run very close to the limit, we double check if the available space is enough. That's semi-sensible, certainly for the gen2-3 system that hit it most. Ok, so we get to keep aper_available_size. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
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 rodrigo.v...@intel.com
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 the
kernel can easily answer.
This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to
include a couple of new fields in its reply to userspace - the total
amount of space available in the mappable region of the aperture and
also the single largest block available.
This is not quite what userspace wants to answer the question of whether
this batch will fit as fences are also required to meet severe alignment
constraints within the batch. For this purpose, a third conservative
estimate of largest fence available is also provided. For when userspace
needs more than one batch, we also provide the culmulative space
available for fences such that it has some additional guidance to how
much space it could allocate to fences. Conservatism still wins.
The patch also adds a debugfs file for convenient testing and reporting.
v2: The first object cannot end at offset 0, so we can use last==0 to
detect the empty list.
v3: Expand all values to 64bit, just in case.
Report total mappable aperture size for userspace that cannot easily
determine it by inspecting the PCI device.
v4: (Rodrigo) Fixed rebase conflicts.
v5: Rebased to the latest drm-intel-nightly (Ankit)
Signed-off-by: Chris Wilson chris at chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.vivi at intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 +
drivers/gpu/drm/i915/i915_gem.c | 116
++--
2 files changed, 139 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 31d8768..49ec438 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -512,6 +512,32 @@ static int i915_gem_object_info(struct seq_file *m,
void* data)
return 0;
}
+static int i915_gem_aperture_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m-private;
+ struct drm_i915_gem_get_aperture arg;
+ int ret;
+
+ ret = i915_gem_get_aperture_ioctl(node-minor-dev, arg, NULL);
+ if (ret)
+ return ret;
+
+ seq_printf(m, Total size of the GTT: %llu bytes\n,
+ arg.aper_size);
+ seq_printf(m, Available space in the GTT: %llu bytes\n,
+ arg.aper_available_size);
+ seq_printf(m, Available space in the mappable aperture: %llu bytes\n,
+ arg.map_available_size);
+ seq_printf(m, Single largest space in the mappable aperture: %llu
bytes\n,
+ arg.map_largest_size);
+ seq_printf(m, Available space for fences: %llu bytes\n,
+ arg.fence_available_size);
+ seq_printf(m, Single largest fence available: %llu bytes\n,
+ arg.fence_largest_size);
+
+ return 0;
+}
+
static int i915_gem_gtt_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m-private;
@@ -5030,6 +5056,7 @@ static int i915_debugfs_create(struct dentry *root,
static const struct drm_info_list i915_debugfs_list[] = {
{i915_capabilities, i915_capabilities, 0},
{i915_gem_objects, i915_gem_object_info, 0},
+ {i915_gem_aperture, i915_gem_aperture_info, 0},
{i915_gem_gtt, i915_gem_gtt_info, 0},
{i915_gem_pinned, i915_gem_gtt_info, 0, (void *) PINNED_LIST},
{i915_gem_active, i915_gem_object_list_info, 0, (void *) ACTIVE_LIST},
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index a2a4a27..ccfc8d3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -32,6 +32,7 @@
#include i915_vgpu.h
#include i915_trace.h
#include intel_drv.h
+#include linux/list_sort.h
#include linux/shmem_fs.h
#include linux/slab.h
#include linux/swap.h
@@ -143,6 +144,55 @@ int i915_mutex_lock_interruptible(struct drm_device
*dev)
return 0;
}
+static inline bool
+i915_gem_object_is_inactive(struct drm_i915_gem_object *obj)
+{
+ return i915_gem_obj_bound_any(obj) !obj-active;
+}
+
+static int obj_rank_by_ggtt(void *priv,
+ struct list_head *A,
+ struct list_head *B)
+{
+ struct drm_i915_gem_object *a = list_entry(A,typeof(*a), obj_exec_link);
+ struct drm_i915_gem_object *b = list_entry(B,typeof(*b), obj_exec_link);
+
+ return i915_gem_obj_ggtt_offset(a) - i915_gem_obj_ggtt_offset(b);
+}
+
+static u32
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
On Wed, Jul 01, 2015 at 02:55:12PM +0530, ankitprasad.r.sha...@intel.com wrote:
From: Rodrigo Vivi rodrigo.v...@intel.com
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 the
kernel can easily answer.
This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to
include a couple of new fields in its reply to userspace - the total
amount of space available in the mappable region of the aperture and
also the single largest block available.
This is not quite what userspace wants to answer the question of whether
this batch will fit as fences are also required to meet severe alignment
constraints within the batch. For this purpose, a third conservative
estimate of largest fence available is also provided. For when userspace
needs more than one batch, we also provide the culmulative space
available for fences such that it has some additional guidance to how
much space it could allocate to fences. Conservatism still wins.
The patch also adds a debugfs file for convenient testing and reporting.
v2: The first object cannot end at offset 0, so we can use last==0 to
detect the empty list.
v3: Expand all values to 64bit, just in case.
Report total mappable aperture size for userspace that cannot easily
determine it by inspecting the PCI device.
v4: (Rodrigo) Fixed rebase conflicts.
v5: Rebased to the latest drm-intel-nightly (Ankit)
Signed-off-by: Chris Wilson chris at chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.vivi at intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 +
drivers/gpu/drm/i915/i915_gem.c | 116
++--
2 files changed, 139 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 31d8768..49ec438 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -512,6 +512,32 @@ static int i915_gem_object_info(struct seq_file *m,
void* data)
return 0;
}
+static int i915_gem_aperture_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m-private;
+ struct drm_i915_gem_get_aperture arg;
+ int ret;
+
+ ret = i915_gem_get_aperture_ioctl(node-minor-dev, arg, NULL);
+ if (ret)
+ return ret;
+
+ seq_printf(m, Total size of the GTT: %llu bytes\n,
+arg.aper_size);
+ seq_printf(m, Available space in the GTT: %llu bytes\n,
+arg.aper_available_size);
+ seq_printf(m, Available space in the mappable aperture: %llu bytes\n,
+arg.map_available_size);
+ seq_printf(m, Single largest space in the mappable aperture: %llu
bytes\n,
+arg.map_largest_size);
+ seq_printf(m, Available space for fences: %llu bytes\n,
+arg.fence_available_size);
+ seq_printf(m, Single largest fence available: %llu bytes\n,
+arg.fence_largest_size);
+
+ return 0;
+}
+
static int i915_gem_gtt_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m-private;
@@ -5030,6 +5056,7 @@ static int i915_debugfs_create(struct dentry *root,
static const struct drm_info_list i915_debugfs_list[] = {
{i915_capabilities, i915_capabilities, 0},
{i915_gem_objects, i915_gem_object_info, 0},
+ {i915_gem_aperture, i915_gem_aperture_info, 0},
{i915_gem_gtt, i915_gem_gtt_info, 0},
{i915_gem_pinned, i915_gem_gtt_info, 0, (void *) PINNED_LIST},
{i915_gem_active, i915_gem_object_list_info, 0, (void *) ACTIVE_LIST},
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a2a4a27..ccfc8d3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -32,6 +32,7 @@
#include i915_vgpu.h
#include i915_trace.h
#include intel_drv.h
+#include linux/list_sort.h
#include linux/shmem_fs.h
#include linux/slab.h
#include linux/swap.h
@@ -143,6 +144,55 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
return 0;
}
+static inline bool
+i915_gem_object_is_inactive(struct drm_i915_gem_object *obj)
+{
+ return i915_gem_obj_bound_any(obj) !obj-active;
+}
+
+static int obj_rank_by_ggtt(void *priv,
+ struct list_head *A,
+ struct list_head *B)
+{
+ struct drm_i915_gem_object *a = list_entry(A,typeof(*a), obj_exec_link);
+ struct drm_i915_gem_object *b = list_entry(B,typeof(*b), obj_exec_link);
+
+ return i915_gem_obj_ggtt_offset(a) - i915_gem_obj_ggtt_offset(b);
+}
+
+static u32 __fence_size(struct drm_i915_private *dev_priv, u32 start, u32
end)
+{
+ u32 size = end - start;
+ u32
