* [PATCH v4 1/2] drm/i915: lookup for mem_region of a mem_type @ 2019-12-02 6:54 ` Ramalingam C 0 siblings, 0 replies; 20+ messages in thread From: Ramalingam C @ 2019-12-02 6:54 UTC (permalink / raw) To: intel-gfx, Chris Wilson, Matthew Auld Lookup function to retrieve the pointer to a memory region of a mem_type. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> cc: Matthew Auld <matthew.auld@intel.com> --- drivers/gpu/drm/i915/intel_memory_region.c | 12 ++++++++++++ drivers/gpu/drm/i915/intel_memory_region.h | 3 +++ 2 files changed, 15 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_memory_region.c b/drivers/gpu/drm/i915/intel_memory_region.c index baaeaecc64af..ae899df7a1c2 100644 --- a/drivers/gpu/drm/i915/intel_memory_region.c +++ b/drivers/gpu/drm/i915/intel_memory_region.c @@ -16,6 +16,18 @@ const u32 intel_region_map[] = { [INTEL_REGION_STOLEN] = REGION_MAP(INTEL_MEMORY_STOLEN, 0), }; +struct intel_memory_region * +intel_memory_region_lookup(struct drm_i915_private *i915, + enum intel_memory_type mem_type) +{ + enum intel_region_id id; + + for (id = INTEL_REGION_SMEM; id < INTEL_REGION_UNKNOWN; id++) + if (i915->mm.regions[id]->type == mem_type) + return i915->mm.regions[id]; + return NULL; +} + static u64 intel_memory_region_free_pages(struct intel_memory_region *mem, struct list_head *blocks) diff --git a/drivers/gpu/drm/i915/intel_memory_region.h b/drivers/gpu/drm/i915/intel_memory_region.h index 238722009677..d210936c4d72 100644 --- a/drivers/gpu/drm/i915/intel_memory_region.h +++ b/drivers/gpu/drm/i915/intel_memory_region.h @@ -125,5 +125,8 @@ void intel_memory_region_put(struct intel_memory_region *mem); int intel_memory_regions_hw_probe(struct drm_i915_private *i915); void intel_memory_regions_driver_release(struct drm_i915_private *i915); +struct intel_memory_region * +intel_memory_region_lookup(struct drm_i915_private *i915, + enum intel_memory_type mem_type); #endif -- 2.20.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [Intel-gfx] [PATCH v4 1/2] drm/i915: lookup for mem_region of a mem_type @ 2019-12-02 6:54 ` Ramalingam C 0 siblings, 0 replies; 20+ messages in thread From: Ramalingam C @ 2019-12-02 6:54 UTC (permalink / raw) To: intel-gfx, Chris Wilson, Matthew Auld Lookup function to retrieve the pointer to a memory region of a mem_type. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> cc: Matthew Auld <matthew.auld@intel.com> --- drivers/gpu/drm/i915/intel_memory_region.c | 12 ++++++++++++ drivers/gpu/drm/i915/intel_memory_region.h | 3 +++ 2 files changed, 15 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_memory_region.c b/drivers/gpu/drm/i915/intel_memory_region.c index baaeaecc64af..ae899df7a1c2 100644 --- a/drivers/gpu/drm/i915/intel_memory_region.c +++ b/drivers/gpu/drm/i915/intel_memory_region.c @@ -16,6 +16,18 @@ const u32 intel_region_map[] = { [INTEL_REGION_STOLEN] = REGION_MAP(INTEL_MEMORY_STOLEN, 0), }; +struct intel_memory_region * +intel_memory_region_lookup(struct drm_i915_private *i915, + enum intel_memory_type mem_type) +{ + enum intel_region_id id; + + for (id = INTEL_REGION_SMEM; id < INTEL_REGION_UNKNOWN; id++) + if (i915->mm.regions[id]->type == mem_type) + return i915->mm.regions[id]; + return NULL; +} + static u64 intel_memory_region_free_pages(struct intel_memory_region *mem, struct list_head *blocks) diff --git a/drivers/gpu/drm/i915/intel_memory_region.h b/drivers/gpu/drm/i915/intel_memory_region.h index 238722009677..d210936c4d72 100644 --- a/drivers/gpu/drm/i915/intel_memory_region.h +++ b/drivers/gpu/drm/i915/intel_memory_region.h @@ -125,5 +125,8 @@ void intel_memory_region_put(struct intel_memory_region *mem); int intel_memory_regions_hw_probe(struct drm_i915_private *i915); void intel_memory_regions_driver_release(struct drm_i915_private *i915); +struct intel_memory_region * +intel_memory_region_lookup(struct drm_i915_private *i915, + enum intel_memory_type mem_type); #endif -- 2.20.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH v4 2/2] drm/i915: Create dumb buffer from LMEM @ 2019-12-02 6:54 ` Ramalingam C 0 siblings, 0 replies; 20+ messages in thread From: Ramalingam C @ 2019-12-02 6:54 UTC (permalink / raw) To: intel-gfx, Chris Wilson, Matthew Auld When LMEM is supported, dumb buffer preferred to be created from LMEM. v2: Parameters are reshuffled. [Chris] v3: s/region_id/mem_type v4: use the i915_gem_object_create_region [chris] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> cc: Matthew Auld <matthew.auld@intel.com> --- drivers/gpu/drm/i915/i915_gem.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 61395b03443e..34e480c8293e 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -44,6 +44,7 @@ #include "gem/i915_gem_clflush.h" #include "gem/i915_gem_context.h" #include "gem/i915_gem_ioctls.h" +#include "gem/i915_gem_region.h" #include "gem/i915_gem_pm.h" #include "gt/intel_context.h" #include "gt/intel_engine_user.h" @@ -176,6 +177,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj, static int i915_gem_create(struct drm_file *file, struct drm_i915_private *dev_priv, + enum intel_memory_type mem_type, u64 *size_p, u32 *handle_p) { @@ -189,7 +191,8 @@ i915_gem_create(struct drm_file *file, return -EINVAL; /* Allocate the new object */ - obj = i915_gem_object_create_shmem(dev_priv, size); + obj = i915_gem_object_create_region(intel_memory_region_lookup(dev_priv, + mem_type), size, 0); if (IS_ERR(obj)) return PTR_ERR(obj); @@ -209,6 +212,7 @@ i915_gem_dumb_create(struct drm_file *file, struct drm_device *dev, struct drm_mode_create_dumb *args) { + enum intel_memory_type mem_type = INTEL_MEMORY_SYSTEM; int cpp = DIV_ROUND_UP(args->bpp, 8); u32 format; @@ -235,7 +239,11 @@ i915_gem_dumb_create(struct drm_file *file, args->pitch = ALIGN(args->pitch, 4096); args->size = args->pitch * args->height; - return i915_gem_create(file, to_i915(dev), + + if (HAS_LMEM(to_i915(dev))) + mem_type = INTEL_MEMORY_LOCAL; + + return i915_gem_create(file, to_i915(dev), mem_type, &args->size, &args->handle); } @@ -254,7 +262,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data, i915_gem_flush_free_objects(dev_priv); - return i915_gem_create(file, dev_priv, + return i915_gem_create(file, dev_priv, INTEL_MEMORY_SYSTEM, &args->size, &args->handle); } -- 2.20.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [Intel-gfx] [PATCH v4 2/2] drm/i915: Create dumb buffer from LMEM @ 2019-12-02 6:54 ` Ramalingam C 0 siblings, 0 replies; 20+ messages in thread From: Ramalingam C @ 2019-12-02 6:54 UTC (permalink / raw) To: intel-gfx, Chris Wilson, Matthew Auld When LMEM is supported, dumb buffer preferred to be created from LMEM. v2: Parameters are reshuffled. [Chris] v3: s/region_id/mem_type v4: use the i915_gem_object_create_region [chris] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> cc: Matthew Auld <matthew.auld@intel.com> --- drivers/gpu/drm/i915/i915_gem.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 61395b03443e..34e480c8293e 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -44,6 +44,7 @@ #include "gem/i915_gem_clflush.h" #include "gem/i915_gem_context.h" #include "gem/i915_gem_ioctls.h" +#include "gem/i915_gem_region.h" #include "gem/i915_gem_pm.h" #include "gt/intel_context.h" #include "gt/intel_engine_user.h" @@ -176,6 +177,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj, static int i915_gem_create(struct drm_file *file, struct drm_i915_private *dev_priv, + enum intel_memory_type mem_type, u64 *size_p, u32 *handle_p) { @@ -189,7 +191,8 @@ i915_gem_create(struct drm_file *file, return -EINVAL; /* Allocate the new object */ - obj = i915_gem_object_create_shmem(dev_priv, size); + obj = i915_gem_object_create_region(intel_memory_region_lookup(dev_priv, + mem_type), size, 0); if (IS_ERR(obj)) return PTR_ERR(obj); @@ -209,6 +212,7 @@ i915_gem_dumb_create(struct drm_file *file, struct drm_device *dev, struct drm_mode_create_dumb *args) { + enum intel_memory_type mem_type = INTEL_MEMORY_SYSTEM; int cpp = DIV_ROUND_UP(args->bpp, 8); u32 format; @@ -235,7 +239,11 @@ i915_gem_dumb_create(struct drm_file *file, args->pitch = ALIGN(args->pitch, 4096); args->size = args->pitch * args->height; - return i915_gem_create(file, to_i915(dev), + + if (HAS_LMEM(to_i915(dev))) + mem_type = INTEL_MEMORY_LOCAL; + + return i915_gem_create(file, to_i915(dev), mem_type, &args->size, &args->handle); } @@ -254,7 +262,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data, i915_gem_flush_free_objects(dev_priv); - return i915_gem_create(file, dev_priv, + return i915_gem_create(file, dev_priv, INTEL_MEMORY_SYSTEM, &args->size, &args->handle); } -- 2.20.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Create dumb buffer from LMEM 2019-12-02 6:54 ` [Intel-gfx] " Ramalingam C (?) @ 2019-12-05 12:12 ` Matthew Auld 2019-12-05 12:20 ` Chris Wilson 2019-12-05 12:59 ` Ramalingam C -1 siblings, 2 replies; 20+ messages in thread From: Matthew Auld @ 2019-12-05 12:12 UTC (permalink / raw) To: Ramalingam C; +Cc: intel-gfx, Matthew Auld On Mon, 2 Dec 2019 at 06:55, Ramalingam C <ramalingam.c@intel.com> wrote: > > When LMEM is supported, dumb buffer preferred to be created from LMEM. > > v2: > Parameters are reshuffled. [Chris] > v3: > s/region_id/mem_type > v4: > use the i915_gem_object_create_region [chris] > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com> > cc: Matthew Auld <matthew.auld@intel.com> > --- > drivers/gpu/drm/i915/i915_gem.c | 14 +++++++++++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 61395b03443e..34e480c8293e 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -44,6 +44,7 @@ > #include "gem/i915_gem_clflush.h" > #include "gem/i915_gem_context.h" > #include "gem/i915_gem_ioctls.h" > +#include "gem/i915_gem_region.h" > #include "gem/i915_gem_pm.h" > #include "gt/intel_context.h" > #include "gt/intel_engine_user.h" > @@ -176,6 +177,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj, > static int > i915_gem_create(struct drm_file *file, > struct drm_i915_private *dev_priv, > + enum intel_memory_type mem_type, > u64 *size_p, > u32 *handle_p) > { > @@ -189,7 +191,8 @@ i915_gem_create(struct drm_file *file, > return -EINVAL; > > /* Allocate the new object */ > - obj = i915_gem_object_create_shmem(dev_priv, size); > + obj = i915_gem_object_create_region(intel_memory_region_lookup(dev_priv, > + mem_type), size, 0); Reviewed-by: Matthew Auld <matthew.auld@intel.com> But how should we go about testing this? We would still need to clear the object(maybe I915_BO_ALLOC_CLEARED?) in order to pass the IGTs. We also need to adjust dumb_buffer.c, since that uses get_avail_ram_mb() for always_clear, but maybe we need the query region uapi for that? > if (IS_ERR(obj)) > return PTR_ERR(obj); > > @@ -209,6 +212,7 @@ i915_gem_dumb_create(struct drm_file *file, > struct drm_device *dev, > struct drm_mode_create_dumb *args) > { > + enum intel_memory_type mem_type = INTEL_MEMORY_SYSTEM; > int cpp = DIV_ROUND_UP(args->bpp, 8); > u32 format; > > @@ -235,7 +239,11 @@ i915_gem_dumb_create(struct drm_file *file, > args->pitch = ALIGN(args->pitch, 4096); > > args->size = args->pitch * args->height; > - return i915_gem_create(file, to_i915(dev), > + > + if (HAS_LMEM(to_i915(dev))) > + mem_type = INTEL_MEMORY_LOCAL; > + > + return i915_gem_create(file, to_i915(dev), mem_type, > &args->size, &args->handle); > } > > @@ -254,7 +262,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data, > > i915_gem_flush_free_objects(dev_priv); > > - return i915_gem_create(file, dev_priv, > + return i915_gem_create(file, dev_priv, INTEL_MEMORY_SYSTEM, > &args->size, &args->handle); > } > > -- > 2.20.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Create dumb buffer from LMEM 2019-12-05 12:12 ` Matthew Auld @ 2019-12-05 12:20 ` Chris Wilson 2019-12-05 13:02 ` Ramalingam C 2019-12-05 12:59 ` Ramalingam C 1 sibling, 1 reply; 20+ messages in thread From: Chris Wilson @ 2019-12-05 12:20 UTC (permalink / raw) To: Matthew Auld, Ramalingam C; +Cc: intel-gfx, Matthew Auld Quoting Matthew Auld (2019-12-05 12:12:19) > On Mon, 2 Dec 2019 at 06:55, Ramalingam C <ramalingam.c@intel.com> wrote: > > > > When LMEM is supported, dumb buffer preferred to be created from LMEM. > > > > v2: > > Parameters are reshuffled. [Chris] > > v3: > > s/region_id/mem_type > > v4: > > use the i915_gem_object_create_region [chris] > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com> > > cc: Matthew Auld <matthew.auld@intel.com> > > --- > > drivers/gpu/drm/i915/i915_gem.c | 14 +++++++++++--- > > 1 file changed, 11 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > > index 61395b03443e..34e480c8293e 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -44,6 +44,7 @@ > > #include "gem/i915_gem_clflush.h" > > #include "gem/i915_gem_context.h" > > #include "gem/i915_gem_ioctls.h" > > +#include "gem/i915_gem_region.h" > > #include "gem/i915_gem_pm.h" > > #include "gt/intel_context.h" > > #include "gt/intel_engine_user.h" > > @@ -176,6 +177,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj, > > static int > > i915_gem_create(struct drm_file *file, > > struct drm_i915_private *dev_priv, > > + enum intel_memory_type mem_type, > > u64 *size_p, > > u32 *handle_p) > > { > > @@ -189,7 +191,8 @@ i915_gem_create(struct drm_file *file, > > return -EINVAL; > > > > /* Allocate the new object */ > > - obj = i915_gem_object_create_shmem(dev_priv, size); > > + obj = i915_gem_object_create_region(intel_memory_region_lookup(dev_priv, > > + mem_type), size, 0); > > Reviewed-by: Matthew Auld <matthew.auld@intel.com> > > But how should we go about testing this? > > We would still need to clear the object(maybe I915_BO_ALLOC_CLEARED?) > in order to pass the IGTs. We also need to adjust dumb_buffer.c, since > that uses get_avail_ram_mb() for always_clear, but maybe we need the > query region uapi for that? Hmm. Questions over the maximum size for dumb buffer, maximum number of dumb buffers, etc, should be addressed to the dumb API. So some form of drmGetCap() ? Note for merging, we need the lmem vm_fault implementation first. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Create dumb buffer from LMEM 2019-12-05 12:20 ` Chris Wilson @ 2019-12-05 13:02 ` Ramalingam C 2019-12-05 13:11 ` Chris Wilson 0 siblings, 1 reply; 20+ messages in thread From: Ramalingam C @ 2019-12-05 13:02 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Matthew Auld On 2019-12-05 at 12:20:12 +0000, Chris Wilson wrote: > Quoting Matthew Auld (2019-12-05 12:12:19) > > On Mon, 2 Dec 2019 at 06:55, Ramalingam C <ramalingam.c@intel.com> wrote: > > > > > > When LMEM is supported, dumb buffer preferred to be created from LMEM. > > > > > > v2: > > > Parameters are reshuffled. [Chris] > > > v3: > > > s/region_id/mem_type > > > v4: > > > use the i915_gem_object_create_region [chris] > > > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com> > > > cc: Matthew Auld <matthew.auld@intel.com> > > > --- > > > drivers/gpu/drm/i915/i915_gem.c | 14 +++++++++++--- > > > 1 file changed, 11 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > > > index 61395b03443e..34e480c8293e 100644 > > > --- a/drivers/gpu/drm/i915/i915_gem.c > > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > > @@ -44,6 +44,7 @@ > > > #include "gem/i915_gem_clflush.h" > > > #include "gem/i915_gem_context.h" > > > #include "gem/i915_gem_ioctls.h" > > > +#include "gem/i915_gem_region.h" > > > #include "gem/i915_gem_pm.h" > > > #include "gt/intel_context.h" > > > #include "gt/intel_engine_user.h" > > > @@ -176,6 +177,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj, > > > static int > > > i915_gem_create(struct drm_file *file, > > > struct drm_i915_private *dev_priv, > > > + enum intel_memory_type mem_type, > > > u64 *size_p, > > > u32 *handle_p) > > > { > > > @@ -189,7 +191,8 @@ i915_gem_create(struct drm_file *file, > > > return -EINVAL; > > > > > > /* Allocate the new object */ > > > - obj = i915_gem_object_create_shmem(dev_priv, size); > > > + obj = i915_gem_object_create_region(intel_memory_region_lookup(dev_priv, > > > + mem_type), size, 0); > > > > Reviewed-by: Matthew Auld <matthew.auld@intel.com> > > > > But how should we go about testing this? > > > > We would still need to clear the object(maybe I915_BO_ALLOC_CLEARED?) > > in order to pass the IGTs. We also need to adjust dumb_buffer.c, since > > that uses get_avail_ram_mb() for always_clear, but maybe we need the > > query region uapi for that? > > Hmm. Questions over the maximum size for dumb buffer, maximum number of > dumb buffers, etc, should be addressed to the dumb API. So some form of > drmGetCap() ? Chris, Is this suggestion to add this capability probing through a new IOCTL for dumb APIs? Please clarify. -Ram > > Note for merging, we need the lmem vm_fault implementation first. > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Create dumb buffer from LMEM 2019-12-05 13:02 ` Ramalingam C @ 2019-12-05 13:11 ` Chris Wilson 2019-12-09 11:57 ` Ramalingam C 0 siblings, 1 reply; 20+ messages in thread From: Chris Wilson @ 2019-12-05 13:11 UTC (permalink / raw) To: Ramalingam C; +Cc: intel-gfx, Matthew Auld Quoting Ramalingam C (2019-12-05 13:02:40) > On 2019-12-05 at 12:20:12 +0000, Chris Wilson wrote: > > Quoting Matthew Auld (2019-12-05 12:12:19) > > > We would still need to clear the object(maybe I915_BO_ALLOC_CLEARED?) > > > in order to pass the IGTs. We also need to adjust dumb_buffer.c, since > > > that uses get_avail_ram_mb() for always_clear, but maybe we need the > > > query region uapi for that? > > > > Hmm. Questions over the maximum size for dumb buffer, maximum number of > > dumb buffers, etc, should be addressed to the dumb API. So some form of > > drmGetCap() ? > Chris, Is this suggestion to add this capability probing through a new IOCTL for > dumb APIs? Please clarify. I don't think we need a new ioctl, as drm_getcap already covers the dumb buffer API. We just need to expose the limits of the dumb buffer API through it. The 2 that spring to mind are maximum size of individual buffer and maximum size of total dumb buffers. (The latter may be infinite for drivers that allow swapping of inactive buffers.) There was a request on irc for something like this as well, but I'm not aware of the context. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Create dumb buffer from LMEM 2019-12-05 13:11 ` Chris Wilson @ 2019-12-09 11:57 ` Ramalingam C 2019-12-09 12:03 ` Chris Wilson 0 siblings, 1 reply; 20+ messages in thread From: Ramalingam C @ 2019-12-09 11:57 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Matthew Auld On 2019-12-05 at 13:11:29 +0000, Chris Wilson wrote: > Quoting Ramalingam C (2019-12-05 13:02:40) > > On 2019-12-05 at 12:20:12 +0000, Chris Wilson wrote: > > > Quoting Matthew Auld (2019-12-05 12:12:19) > > > > We would still need to clear the object(maybe I915_BO_ALLOC_CLEARED?) > > > > in order to pass the IGTs. We also need to adjust dumb_buffer.c, since > > > > that uses get_avail_ram_mb() for always_clear, but maybe we need the > > > > query region uapi for that? > > > > > > Hmm. Questions over the maximum size for dumb buffer, maximum number of > > > dumb buffers, etc, should be addressed to the dumb API. So some form of > > > drmGetCap() ? > > Chris, Is this suggestion to add this capability probing through a new IOCTL for > > dumb APIs? Please clarify. > > I don't think we need a new ioctl, as drm_getcap already covers the dumb > buffer API. We just need to expose the limits of the dumb buffer API > through it. > > The 2 that spring to mind are maximum size of individual buffer and > maximum size of total dumb buffers. Will there be question for userspace for this extension or no? AFAIK There is no consumer except IGT. -Ram > (The latter may be infinite for > drivers that allow swapping of inactive buffers.) There was a request on > irc for something like this as well, but I'm not aware of the context. > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Create dumb buffer from LMEM 2019-12-09 11:57 ` Ramalingam C @ 2019-12-09 12:03 ` Chris Wilson 2019-12-09 12:05 ` Ramalingam C 0 siblings, 1 reply; 20+ messages in thread From: Chris Wilson @ 2019-12-09 12:03 UTC (permalink / raw) To: Ramalingam C; +Cc: intel-gfx, Matthew Auld Quoting Ramalingam C (2019-12-09 11:57:01) > On 2019-12-05 at 13:11:29 +0000, Chris Wilson wrote: > > Quoting Ramalingam C (2019-12-05 13:02:40) > > > On 2019-12-05 at 12:20:12 +0000, Chris Wilson wrote: > > > > Quoting Matthew Auld (2019-12-05 12:12:19) > > > > > We would still need to clear the object(maybe I915_BO_ALLOC_CLEARED?) > > > > > in order to pass the IGTs. We also need to adjust dumb_buffer.c, since > > > > > that uses get_avail_ram_mb() for always_clear, but maybe we need the > > > > > query region uapi for that? > > > > > > > > Hmm. Questions over the maximum size for dumb buffer, maximum number of > > > > dumb buffers, etc, should be addressed to the dumb API. So some form of > > > > drmGetCap() ? > > > Chris, Is this suggestion to add this capability probing through a new IOCTL for > > > dumb APIs? Please clarify. > > > > I don't think we need a new ioctl, as drm_getcap already covers the dumb > > buffer API. We just need to expose the limits of the dumb buffer API > > through it. > > > > The 2 that spring to mind are maximum size of individual buffer and > > maximum size of total dumb buffers. > > Will there be question for userspace for this extension or no? > AFAIK There is no consumer except IGT. There was someone else asking for maximum dumb buffer size on irc from an application perspective. But I strongly believe that discoverability and testability of an API should be a central tenet of API design. :) -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Create dumb buffer from LMEM 2019-12-09 12:03 ` Chris Wilson @ 2019-12-09 12:05 ` Ramalingam C 0 siblings, 0 replies; 20+ messages in thread From: Ramalingam C @ 2019-12-09 12:05 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Matthew Auld On 2019-12-09 at 12:03:22 +0000, Chris Wilson wrote: > Quoting Ramalingam C (2019-12-09 11:57:01) > > On 2019-12-05 at 13:11:29 +0000, Chris Wilson wrote: > > > Quoting Ramalingam C (2019-12-05 13:02:40) > > > > On 2019-12-05 at 12:20:12 +0000, Chris Wilson wrote: > > > > > Quoting Matthew Auld (2019-12-05 12:12:19) > > > > > > We would still need to clear the object(maybe I915_BO_ALLOC_CLEARED?) > > > > > > in order to pass the IGTs. We also need to adjust dumb_buffer.c, since > > > > > > that uses get_avail_ram_mb() for always_clear, but maybe we need the > > > > > > query region uapi for that? > > > > > > > > > > Hmm. Questions over the maximum size for dumb buffer, maximum number of > > > > > dumb buffers, etc, should be addressed to the dumb API. So some form of > > > > > drmGetCap() ? > > > > Chris, Is this suggestion to add this capability probing through a new IOCTL for > > > > dumb APIs? Please clarify. > > > > > > I don't think we need a new ioctl, as drm_getcap already covers the dumb > > > buffer API. We just need to expose the limits of the dumb buffer API > > > through it. > > > > > > The 2 that spring to mind are maximum size of individual buffer and > > > maximum size of total dumb buffers. > > > > Will there be question for userspace for this extension or no? > > AFAIK There is no consumer except IGT. > > There was someone else asking for maximum dumb buffer size on irc from > an application perspective. > > But I strongly believe that discoverability and testability of an API > should be a central tenet of API design. :) So can i take it for "No userspace is required for this uAPI extension as this helps the testing" ? -Ram > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Create dumb buffer from LMEM 2019-12-05 12:12 ` Matthew Auld 2019-12-05 12:20 ` Chris Wilson @ 2019-12-05 12:59 ` Ramalingam C 1 sibling, 0 replies; 20+ messages in thread From: Ramalingam C @ 2019-12-05 12:59 UTC (permalink / raw) To: Matthew Auld; +Cc: intel-gfx, Matthew Auld On 2019-12-05 at 12:12:19 +0000, Matthew Auld wrote: > On Mon, 2 Dec 2019 at 06:55, Ramalingam C <ramalingam.c@intel.com> wrote: > > > > When LMEM is supported, dumb buffer preferred to be created from LMEM. > > > > v2: > > Parameters are reshuffled. [Chris] > > v3: > > s/region_id/mem_type > > v4: > > use the i915_gem_object_create_region [chris] > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com> > > cc: Matthew Auld <matthew.auld@intel.com> > > --- > > drivers/gpu/drm/i915/i915_gem.c | 14 +++++++++++--- > > 1 file changed, 11 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > > index 61395b03443e..34e480c8293e 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -44,6 +44,7 @@ > > #include "gem/i915_gem_clflush.h" > > #include "gem/i915_gem_context.h" > > #include "gem/i915_gem_ioctls.h" > > +#include "gem/i915_gem_region.h" > > #include "gem/i915_gem_pm.h" > > #include "gt/intel_context.h" > > #include "gt/intel_engine_user.h" > > @@ -176,6 +177,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj, > > static int > > i915_gem_create(struct drm_file *file, > > struct drm_i915_private *dev_priv, > > + enum intel_memory_type mem_type, > > u64 *size_p, > > u32 *handle_p) > > { > > @@ -189,7 +191,8 @@ i915_gem_create(struct drm_file *file, > > return -EINVAL; > > > > /* Allocate the new object */ > > - obj = i915_gem_object_create_shmem(dev_priv, size); > > + obj = i915_gem_object_create_region(intel_memory_region_lookup(dev_priv, > > + mem_type), size, 0); > > Reviewed-by: Matthew Auld <matthew.auld@intel.com> > > But how should we go about testing this? > > We would still need to clear the object(maybe I915_BO_ALLOC_CLEARED?) > in order to pass the IGTs. Is this not cleared now? Tested this always clear on system memory not yet on LMEM. Yes. we need to adjust the dumb buffer IGT to check whether LMEM is supported? if so what is the max size that we could allocate as dumb buffer etc. -Ram. > We also need to adjust dumb_buffer.c, since > that uses get_avail_ram_mb() for always_clear, but maybe we need the > query region uapi for that? > > > if (IS_ERR(obj)) > > return PTR_ERR(obj); > > > > @@ -209,6 +212,7 @@ i915_gem_dumb_create(struct drm_file *file, > > struct drm_device *dev, > > struct drm_mode_create_dumb *args) > > { > > + enum intel_memory_type mem_type = INTEL_MEMORY_SYSTEM; > > int cpp = DIV_ROUND_UP(args->bpp, 8); > > u32 format; > > > > @@ -235,7 +239,11 @@ i915_gem_dumb_create(struct drm_file *file, > > args->pitch = ALIGN(args->pitch, 4096); > > > > args->size = args->pitch * args->height; > > - return i915_gem_create(file, to_i915(dev), > > + > > + if (HAS_LMEM(to_i915(dev))) > > + mem_type = INTEL_MEMORY_LOCAL; > > + > > + return i915_gem_create(file, to_i915(dev), mem_type, > > &args->size, &args->handle); > > } > > > > @@ -254,7 +262,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data, > > > > i915_gem_flush_free_objects(dev_priv); > > > > - return i915_gem_create(file, dev_priv, > > + return i915_gem_create(file, dev_priv, INTEL_MEMORY_SYSTEM, > > &args->size, &args->handle); > > } > > > > -- > > 2.20.1 > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* ✗ Fi.CI.CHECKPATCH: warning for series starting with [v4,1/2] drm/i915: lookup for mem_region of a mem_type @ 2019-12-02 7:01 ` Patchwork 0 siblings, 0 replies; 20+ messages in thread From: Patchwork @ 2019-12-02 7:01 UTC (permalink / raw) To: Ramalingam C; +Cc: intel-gfx == Series Details == Series: series starting with [v4,1/2] drm/i915: lookup for mem_region of a mem_type URL : https://patchwork.freedesktop.org/series/70271/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2ee9f8e9b658 drm/i915: lookup for mem_region of a mem_type 1172ee9d724f drm/i915: Create dumb buffer from LMEM -:44: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #44: FILE: drivers/gpu/drm/i915/i915_gem.c:195: + obj = i915_gem_object_create_region(intel_memory_region_lookup(dev_priv, + mem_type), size, 0); total: 0 errors, 0 warnings, 1 checks, 50 lines checked _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v4,1/2] drm/i915: lookup for mem_region of a mem_type @ 2019-12-02 7:01 ` Patchwork 0 siblings, 0 replies; 20+ messages in thread From: Patchwork @ 2019-12-02 7:01 UTC (permalink / raw) To: Ramalingam C; +Cc: intel-gfx == Series Details == Series: series starting with [v4,1/2] drm/i915: lookup for mem_region of a mem_type URL : https://patchwork.freedesktop.org/series/70271/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2ee9f8e9b658 drm/i915: lookup for mem_region of a mem_type 1172ee9d724f drm/i915: Create dumb buffer from LMEM -:44: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #44: FILE: drivers/gpu/drm/i915/i915_gem.c:195: + obj = i915_gem_object_create_region(intel_memory_region_lookup(dev_priv, + mem_type), size, 0); total: 0 errors, 0 warnings, 1 checks, 50 lines checked _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* ✗ Fi.CI.BAT: failure for series starting with [v4,1/2] drm/i915: lookup for mem_region of a mem_type @ 2019-12-02 7:31 ` Patchwork 0 siblings, 0 replies; 20+ messages in thread From: Patchwork @ 2019-12-02 7:31 UTC (permalink / raw) To: Ramalingam C; +Cc: intel-gfx == Series Details == Series: series starting with [v4,1/2] drm/i915: lookup for mem_region of a mem_type URL : https://patchwork.freedesktop.org/series/70271/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7458 -> Patchwork_15532 ==================================================== Summary ------- **FAILURE** Serious unknown changes coming with Patchwork_15532 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_15532, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/index.html Possible new issues ------------------- Here are the unknown changes that may have been introduced in Patchwork_15532: ### IGT changes ### #### Possible regressions #### * igt@i915_module_load@reload: - fi-bwr-2160: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-bwr-2160/igt@i915_module_load@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-bwr-2160/igt@i915_module_load@reload.html Known issues ------------ Here are the changes found in Patchwork_15532 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@i915_selftest@live_gem_contexts: - fi-skl-lmem: [PASS][3] -> [INCOMPLETE][4] ([i915#424]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html #### Possible fixes #### * igt@gem_exec_suspend@basic-s0: - fi-icl-u3: [DMESG-WARN][5] ([i915#592]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-icl-u3/igt@gem_exec_suspend@basic-s0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-icl-u3/igt@gem_exec_suspend@basic-s0.html * igt@i915_selftest@live_gem_contexts: - fi-hsw-peppy: [INCOMPLETE][7] -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html #### Warnings #### * igt@i915_module_load@reload: - fi-icl-u2: [DMESG-WARN][9] ([i915#289]) -> [DMESG-WARN][10] ([i915#109] / [i915#289]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-icl-u2/igt@i915_module_load@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-icl-u2/igt@i915_module_load@reload.html * igt@kms_busy@basic-flip-pipe-a: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][12] ([i915#62] / [i915#92]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-kbl-x1275/igt@kms_busy@basic-flip-pipe-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-kbl-x1275/igt@kms_busy@basic-flip-pipe-a.html * igt@kms_busy@basic-flip-pipe-b: - fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) -> [DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-kbl-x1275/igt@kms_busy@basic-flip-pipe-b.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-kbl-x1275/igt@kms_busy@basic-flip-pipe-b.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109 [i915#243]: https://gitlab.freedesktop.org/drm/intel/issues/243 [i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289 [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424 [i915#592]: https://gitlab.freedesktop.org/drm/intel/issues/592 [i915#609]: https://gitlab.freedesktop.org/drm/intel/issues/609 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (50 -> 44) ------------------------------ Missing (6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes ------------- * CI: CI-20190529 -> None * Linux: CI_DRM_7458 -> Patchwork_15532 CI-20190529: 20190529 CI_DRM_7458: 25263c754b3969b8554842bbe362c0a2fb214c42 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5320: 06833ffeaf7621c3fef097166539bbe999a33e9c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_15532: 1172ee9d724f374af75ba72961ad2bf462cd654a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1172ee9d724f drm/i915: Create dumb buffer from LMEM 2ee9f8e9b658 drm/i915: lookup for mem_region of a mem_type == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/index.html _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/2] drm/i915: lookup for mem_region of a mem_type @ 2019-12-02 7:31 ` Patchwork 0 siblings, 0 replies; 20+ messages in thread From: Patchwork @ 2019-12-02 7:31 UTC (permalink / raw) To: Ramalingam C; +Cc: intel-gfx == Series Details == Series: series starting with [v4,1/2] drm/i915: lookup for mem_region of a mem_type URL : https://patchwork.freedesktop.org/series/70271/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7458 -> Patchwork_15532 ==================================================== Summary ------- **FAILURE** Serious unknown changes coming with Patchwork_15532 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_15532, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/index.html Possible new issues ------------------- Here are the unknown changes that may have been introduced in Patchwork_15532: ### IGT changes ### #### Possible regressions #### * igt@i915_module_load@reload: - fi-bwr-2160: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-bwr-2160/igt@i915_module_load@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-bwr-2160/igt@i915_module_load@reload.html Known issues ------------ Here are the changes found in Patchwork_15532 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@i915_selftest@live_gem_contexts: - fi-skl-lmem: [PASS][3] -> [INCOMPLETE][4] ([i915#424]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html #### Possible fixes #### * igt@gem_exec_suspend@basic-s0: - fi-icl-u3: [DMESG-WARN][5] ([i915#592]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-icl-u3/igt@gem_exec_suspend@basic-s0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-icl-u3/igt@gem_exec_suspend@basic-s0.html * igt@i915_selftest@live_gem_contexts: - fi-hsw-peppy: [INCOMPLETE][7] -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html #### Warnings #### * igt@i915_module_load@reload: - fi-icl-u2: [DMESG-WARN][9] ([i915#289]) -> [DMESG-WARN][10] ([i915#109] / [i915#289]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-icl-u2/igt@i915_module_load@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-icl-u2/igt@i915_module_load@reload.html * igt@kms_busy@basic-flip-pipe-a: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][12] ([i915#62] / [i915#92]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-kbl-x1275/igt@kms_busy@basic-flip-pipe-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-kbl-x1275/igt@kms_busy@basic-flip-pipe-a.html * igt@kms_busy@basic-flip-pipe-b: - fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) -> [DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7458/fi-kbl-x1275/igt@kms_busy@basic-flip-pipe-b.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/fi-kbl-x1275/igt@kms_busy@basic-flip-pipe-b.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109 [i915#243]: https://gitlab.freedesktop.org/drm/intel/issues/243 [i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289 [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424 [i915#592]: https://gitlab.freedesktop.org/drm/intel/issues/592 [i915#609]: https://gitlab.freedesktop.org/drm/intel/issues/609 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (50 -> 44) ------------------------------ Missing (6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes ------------- * CI: CI-20190529 -> None * Linux: CI_DRM_7458 -> Patchwork_15532 CI-20190529: 20190529 CI_DRM_7458: 25263c754b3969b8554842bbe362c0a2fb214c42 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5320: 06833ffeaf7621c3fef097166539bbe999a33e9c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_15532: 1172ee9d724f374af75ba72961ad2bf462cd654a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1172ee9d724f drm/i915: Create dumb buffer from LMEM 2ee9f8e9b658 drm/i915: lookup for mem_region of a mem_type == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15532/index.html _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: lookup for mem_region of a mem_type 2019-12-02 6:54 ` [Intel-gfx] " Ramalingam C ` (3 preceding siblings ...) (?) @ 2019-12-05 11:40 ` Matthew Auld -1 siblings, 0 replies; 20+ messages in thread From: Matthew Auld @ 2019-12-05 11:40 UTC (permalink / raw) To: Ramalingam C; +Cc: intel-gfx, Matthew Auld On Mon, 2 Dec 2019 at 06:55, Ramalingam C <ramalingam.c@intel.com> wrote: > > Lookup function to retrieve the pointer to a memory region of > a mem_type. > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com> > cc: Matthew Auld <matthew.auld@intel.com> > --- > drivers/gpu/drm/i915/intel_memory_region.c | 12 ++++++++++++ > drivers/gpu/drm/i915/intel_memory_region.h | 3 +++ > 2 files changed, 15 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_memory_region.c b/drivers/gpu/drm/i915/intel_memory_region.c > index baaeaecc64af..ae899df7a1c2 100644 > --- a/drivers/gpu/drm/i915/intel_memory_region.c > +++ b/drivers/gpu/drm/i915/intel_memory_region.c > @@ -16,6 +16,18 @@ const u32 intel_region_map[] = { > [INTEL_REGION_STOLEN] = REGION_MAP(INTEL_MEMORY_STOLEN, 0), > }; > > +struct intel_memory_region * > +intel_memory_region_lookup(struct drm_i915_private *i915, > + enum intel_memory_type mem_type) > +{ > + enum intel_region_id id; > + > + for (id = INTEL_REGION_SMEM; id < INTEL_REGION_UNKNOWN; id++) > + if (i915->mm.regions[id]->type == mem_type) Is it not worth doing: if (region && region->type == mem_type) ? I guess we can always extend and improve upon this later. Reviewed-by: Matthew Auld <matthew.auld@intel.com> _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v4 1/2] drm/i915: lookup for mem_region of a mem_type @ 2019-11-06 16:08 Ramalingam C 2019-11-06 16:15 ` Tang, CQ 0 siblings, 1 reply; 20+ messages in thread From: Ramalingam C @ 2019-11-06 16:08 UTC (permalink / raw) To: intel-gfx, Chris Wilson; +Cc: Matthew Auld Lookup function to retrieve the pointer to a memory region of a mem_type. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> cc: Matthew Auld <matthew.auld@intel.com> --- drivers/gpu/drm/i915/intel_memory_region.c | 12 ++++++++++++ drivers/gpu/drm/i915/intel_memory_region.h | 3 +++ 2 files changed, 15 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_memory_region.c b/drivers/gpu/drm/i915/intel_memory_region.c index baaeaecc64af..ae899df7a1c2 100644 --- a/drivers/gpu/drm/i915/intel_memory_region.c +++ b/drivers/gpu/drm/i915/intel_memory_region.c @@ -16,6 +16,18 @@ const u32 intel_region_map[] = { [INTEL_REGION_STOLEN] = REGION_MAP(INTEL_MEMORY_STOLEN, 0), }; +struct intel_memory_region * +intel_memory_region_lookup(struct drm_i915_private *i915, + enum intel_memory_type mem_type) +{ + enum intel_region_id id; + + for (id = INTEL_REGION_SMEM; id < INTEL_REGION_UNKNOWN; id++) + if (i915->mm.regions[id]->type == mem_type) + return i915->mm.regions[id]; + return NULL; +} + static u64 intel_memory_region_free_pages(struct intel_memory_region *mem, struct list_head *blocks) diff --git a/drivers/gpu/drm/i915/intel_memory_region.h b/drivers/gpu/drm/i915/intel_memory_region.h index 238722009677..d210936c4d72 100644 --- a/drivers/gpu/drm/i915/intel_memory_region.h +++ b/drivers/gpu/drm/i915/intel_memory_region.h @@ -125,5 +125,8 @@ void intel_memory_region_put(struct intel_memory_region *mem); int intel_memory_regions_hw_probe(struct drm_i915_private *i915); void intel_memory_regions_driver_release(struct drm_i915_private *i915); +struct intel_memory_region * +intel_memory_region_lookup(struct drm_i915_private *i915, + enum intel_memory_type mem_type); #endif -- 2.20.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH v4 1/2] drm/i915: lookup for mem_region of a mem_type 2019-11-06 16:08 Ramalingam C @ 2019-11-06 16:15 ` Tang, CQ 2019-11-06 16:25 ` Ramalingam C 0 siblings, 1 reply; 20+ messages in thread From: Tang, CQ @ 2019-11-06 16:15 UTC (permalink / raw) To: C, Ramalingam, intel-gfx, Chris Wilson; +Cc: Auld, Matthew > -----Original Message----- > From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of > Ramalingam C > Sent: Wednesday, November 6, 2019 8:08 AM > To: intel-gfx <intel-gfx@lists.freedesktop.org>; Chris Wilson <chris@chris- > wilson.co.uk> > Cc: Auld, Matthew <matthew.auld@intel.com> > Subject: [Intel-gfx] [PATCH v4 1/2] drm/i915: lookup for mem_region of a > mem_type > > Lookup function to retrieve the pointer to a memory region of a mem_type. We could have multi-regions with the same memory type. Your code just returns the first one. Is this desired? --CQ > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com> > cc: Matthew Auld <matthew.auld@intel.com> > --- > drivers/gpu/drm/i915/intel_memory_region.c | 12 ++++++++++++ > drivers/gpu/drm/i915/intel_memory_region.h | 3 +++ > 2 files changed, 15 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_memory_region.c > b/drivers/gpu/drm/i915/intel_memory_region.c > index baaeaecc64af..ae899df7a1c2 100644 > --- a/drivers/gpu/drm/i915/intel_memory_region.c > +++ b/drivers/gpu/drm/i915/intel_memory_region.c > @@ -16,6 +16,18 @@ const u32 intel_region_map[] = { > [INTEL_REGION_STOLEN] = REGION_MAP(INTEL_MEMORY_STOLEN, > 0), }; > > +struct intel_memory_region * > +intel_memory_region_lookup(struct drm_i915_private *i915, > + enum intel_memory_type mem_type) > +{ > + enum intel_region_id id; > + > + for (id = INTEL_REGION_SMEM; id < INTEL_REGION_UNKNOWN; > id++) > + if (i915->mm.regions[id]->type == mem_type) > + return i915->mm.regions[id]; > + return NULL; > +} > + > static u64 > intel_memory_region_free_pages(struct intel_memory_region *mem, > struct list_head *blocks) > diff --git a/drivers/gpu/drm/i915/intel_memory_region.h > b/drivers/gpu/drm/i915/intel_memory_region.h > index 238722009677..d210936c4d72 100644 > --- a/drivers/gpu/drm/i915/intel_memory_region.h > +++ b/drivers/gpu/drm/i915/intel_memory_region.h > @@ -125,5 +125,8 @@ void intel_memory_region_put(struct > intel_memory_region *mem); > > int intel_memory_regions_hw_probe(struct drm_i915_private *i915); void > intel_memory_regions_driver_release(struct drm_i915_private *i915); > +struct intel_memory_region * > +intel_memory_region_lookup(struct drm_i915_private *i915, > + enum intel_memory_type mem_type); > > #endif > -- > 2.20.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 1/2] drm/i915: lookup for mem_region of a mem_type 2019-11-06 16:15 ` Tang, CQ @ 2019-11-06 16:25 ` Ramalingam C 0 siblings, 0 replies; 20+ messages in thread From: Ramalingam C @ 2019-11-06 16:25 UTC (permalink / raw) To: Tang, CQ; +Cc: intel-gfx, Auld, Matthew On 2019-11-06 at 21:45:44 +0530, Tang, CQ wrote: > > > > -----Original Message----- > > From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of > > Ramalingam C > > Sent: Wednesday, November 6, 2019 8:08 AM > > To: intel-gfx <intel-gfx@lists.freedesktop.org>; Chris Wilson <chris@chris- > > wilson.co.uk> > > Cc: Auld, Matthew <matthew.auld@intel.com> > > Subject: [Intel-gfx] [PATCH v4 1/2] drm/i915: lookup for mem_region of a > > mem_type > > > > Lookup function to retrieve the pointer to a memory region of a mem_type. > > We could have multi-regions with the same memory type. Your code just returns the first one. Is this desired? At present even i915_gem_object_create_lmem i915_gem_object_create_shmem retrieve the mem_region in this manner only. may be when we have more region_ids per type we could extend based on a need. This is just my thoughts. -Ram > > --CQ > > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com> > > cc: Matthew Auld <matthew.auld@intel.com> > > --- > > drivers/gpu/drm/i915/intel_memory_region.c | 12 ++++++++++++ > > drivers/gpu/drm/i915/intel_memory_region.h | 3 +++ > > 2 files changed, 15 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_memory_region.c > > b/drivers/gpu/drm/i915/intel_memory_region.c > > index baaeaecc64af..ae899df7a1c2 100644 > > --- a/drivers/gpu/drm/i915/intel_memory_region.c > > +++ b/drivers/gpu/drm/i915/intel_memory_region.c > > @@ -16,6 +16,18 @@ const u32 intel_region_map[] = { > > [INTEL_REGION_STOLEN] = REGION_MAP(INTEL_MEMORY_STOLEN, > > 0), }; > > > > +struct intel_memory_region * > > +intel_memory_region_lookup(struct drm_i915_private *i915, > > + enum intel_memory_type mem_type) > > +{ > > + enum intel_region_id id; > > + > > + for (id = INTEL_REGION_SMEM; id < INTEL_REGION_UNKNOWN; > > id++) > > + if (i915->mm.regions[id]->type == mem_type) > > + return i915->mm.regions[id]; > > + return NULL; > > +} > > + > > static u64 > > intel_memory_region_free_pages(struct intel_memory_region *mem, > > struct list_head *blocks) > > diff --git a/drivers/gpu/drm/i915/intel_memory_region.h > > b/drivers/gpu/drm/i915/intel_memory_region.h > > index 238722009677..d210936c4d72 100644 > > --- a/drivers/gpu/drm/i915/intel_memory_region.h > > +++ b/drivers/gpu/drm/i915/intel_memory_region.h > > @@ -125,5 +125,8 @@ void intel_memory_region_put(struct > > intel_memory_region *mem); > > > > int intel_memory_regions_hw_probe(struct drm_i915_private *i915); void > > intel_memory_regions_driver_release(struct drm_i915_private *i915); > > +struct intel_memory_region * > > +intel_memory_region_lookup(struct drm_i915_private *i915, > > + enum intel_memory_type mem_type); > > > > #endif > > -- > > 2.20.1 > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2019-12-09 12:06 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-02 6:54 [PATCH v4 1/2] drm/i915: lookup for mem_region of a mem_type Ramalingam C 2019-12-02 6:54 ` [Intel-gfx] " Ramalingam C 2019-12-02 6:54 ` [PATCH v4 2/2] drm/i915: Create dumb buffer from LMEM Ramalingam C 2019-12-02 6:54 ` [Intel-gfx] " Ramalingam C 2019-12-05 12:12 ` Matthew Auld 2019-12-05 12:20 ` Chris Wilson 2019-12-05 13:02 ` Ramalingam C 2019-12-05 13:11 ` Chris Wilson 2019-12-09 11:57 ` Ramalingam C 2019-12-09 12:03 ` Chris Wilson 2019-12-09 12:05 ` Ramalingam C 2019-12-05 12:59 ` Ramalingam C 2019-12-02 7:01 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [v4,1/2] drm/i915: lookup for mem_region of a mem_type Patchwork 2019-12-02 7:01 ` [Intel-gfx] " Patchwork 2019-12-02 7:31 ` ✗ Fi.CI.BAT: failure " Patchwork 2019-12-02 7:31 ` [Intel-gfx] " Patchwork 2019-12-05 11:40 ` [Intel-gfx] [PATCH v4 1/2] " Matthew Auld -- strict thread matches above, loose matches on Subject: below -- 2019-11-06 16:08 Ramalingam C 2019-11-06 16:15 ` Tang, CQ 2019-11-06 16:25 ` Ramalingam C
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.