Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: fix context/engine cleanup order

On 11/02/16 15:02, Mika Kuoppala wrote: Chris Wilson writes: On Sat, Jan 30, 2016 at 11:17:07AM +, Chris Wilson wrote: On Fri, Jan 29, 2016 at 07:19:31PM +, Dave Gordon wrote: From: Nick Hoath Swap the order of context & engine cleanup, so that contexts are cleaned up first,

Re: [Intel-gfx] [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd

On 12/02/16 16:31, Martin Peres wrote: This is not a big issue to return -1 since the only codepath that uses it is for display purposes. Caught by Klockwork. Signed-off-by: Martin Peres --- src/intel_device.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/intel

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: fix context/engine cleanup order

On 11/02/16 13:36, Chris Wilson wrote: On Sat, Jan 30, 2016 at 11:17:07AM +, Chris Wilson wrote: On Fri, Jan 29, 2016 at 07:19:31PM +, Dave Gordon wrote: From: Nick Hoath Swap the order of context & engine cleanup, so that contexts are cleaned up first, and *then* engines. This

Re: [Intel-gfx] [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd

On 15/02/16 13:40, Martin Peres wrote: On 15/02/16 14:24, Dave Gordon wrote: On 12/02/16 16:31, Martin Peres wrote: This is not a big issue to return -1 since the only codepath that uses it is for display purposes. Caught by Klockwork. Signed-off-by: Martin Peres --- src/intel_device.c

Re: [Intel-gfx] [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd

On 15/02/16 13:43, David Weinehall wrote: On Mon, Feb 15, 2016 at 12:24:04PM +, Dave Gordon wrote: On 12/02/16 16:31, Martin Peres wrote: This is not a big issue to return -1 since the only codepath that uses it is for display purposes. Caught by Klockwork. Signed-off-by: Martin Peres

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object

On 12/02/16 13:03, Tvrtko Ursulin wrote: On 11/02/16 23:09, yu@intel.com wrote: From: Alex Dai GuC client object is always pinned during its life cycle. We cache the kmap of its first page, which includes guc_process_desc and doorbell. By doing so, we can simplify the code where we read f

Re: [Intel-gfx] [PATCH] drm/i915/guc: Set init value for cached work queue head

On 10/02/16 20:31, Yu Dai wrote: On 02/10/2016 09:30 AM, Tvrtko Ursulin wrote: Hi, On 10/02/16 00:05, yu@intel.com wrote: > From: Alex Dai > > The cached work queue header pointer is set to last byte of work > queue buffer. It will make sure the whole work queue buffer is > available aft

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object

On 12/02/16 13:03, Tvrtko Ursulin wrote: On 11/02/16 23:09, yu@intel.com wrote: From: Alex Dai GuC client object is always pinned during its life cycle. We cache the kmap of its first page, which includes guc_process_desc and doorbell. By doing so, we can simplify the code where we read f

Re: [Intel-gfx] [PATCH] [v2] drm/i915: Check for get_pages instead of shmem (filp)

rptr calls drm_gem_private_object_init() which explicitly sets the filp to none. NOTE: I manually retyped this from a test machine. So I haven't even compiled this exact patch. v2: Use same logic as from a2a4f916c2f (Kristian, Dave Gordon) Cc: Chris Wilson Cc: Kristian Høgsberg Cc: Dave Gordon Sig

Re: [Intel-gfx] [PATCH i-g-t v3] lib/igt_core.c: Expand --run-subtest functionality.

/html/rfc3977#section-4 for a description of allowed wildcard expressions. v2: Use comma as list separator (Ville Syrjala) support both ^ and ! as not operators (Dave Gordon) v3: Updated to use uwildmat() (Dave Gordon) Signed-off-by: Derek Morton --- COPYING | 21 +++ lib

Re: [Intel-gfx] [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd

On 15/02/16 15:56, Martin Peres wrote: On 15/02/16 15:47, Dave Gordon wrote: On 15/02/16 13:40, Martin Peres wrote: On 15/02/16 14:24, Dave Gordon wrote: On 12/02/16 16:31, Martin Peres wrote: This is not a big issue to return -1 since the only codepath that uses it is for display purposes

Re: [Intel-gfx] [PATCH 03/11] drm/i915: return ctx->global_id from intel_execlists_ctx_id()

On 16/02/16 05:27, sourab.gu...@intel.com wrote: From: Robert Bragg The newly added intel_context::global_id is suitable (a globally unique 20 bit ID) for giving to the hardware as a unique context identifier. Compared to using the pinned address of a logical ring context these IDs are constan

[Intel-gfx] [PATCH v4 1/3] drm/i915: add i915_gem_object_vmap_range() to map GEM object to virtual space

obj->pages->nents for iteration within i915_gem_object_vmap; break when it finishes all desired pages. The caller must pass the actual page count required. (Tvrtko Ursulin) v4: renamed to i915_gem_object_vmap_range() to make its function clearer. (Dave Gordon) Signed-off-by: Al

[Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

dmabuf unmapper This patch [v4] reimplements the same functionality, but now as wrappers round the recently-introduced i915_gem_object_vmap_range() from Alex's patch mentioned above. With this change, we have only one vmap() in the whole driver :) Signed-off-by: Dave Gordon Cc: Chris

[Intel-gfx] [PATCH v4 3/3] drm/i915: optimise i915_gem_object_vmap_range() for small objects

pages) or a context image (currently up to 22 pages). Signed-off-by: Dave Gordon Cc: Tvrtko Ursulin Cc: Alex Dai Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/

[Intel-gfx] [PATCH v4 0/3] Reorganise calls to vmap() GEM objects

t; objects e.g. ringbuffers and contexts, which are expected to be the objects most commonly handled by this code. Signed-off-by: Dave Gordon Cc: Alex Dai Cc: Chris Wilson Cc: Tvrtko Ursulin Cc: Daniel Vetter Alex Dai (1): drm/i915: add i915_gem_object_vmap_range() to map GEM object to vi

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

On 23/02/16 14:39, Tvrtko Ursulin wrote: On 23/02/16 14:03, Chris Wilson wrote: On Tue, Feb 23, 2016 at 01:31:17PM +, Tvrtko Ursulin wrote: On 23/02/16 13:06, Gabriel Feceoru wrote: On 23.02.2016 13:05, Tvrtko Ursulin wrote: Hi, On 23/02/16 10:52, Gabriel Feceoru wrote: Return erro

[Intel-gfx] [PATCH v5] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

so we could accommodate GPUs that required different amounts of padding, generalised NOOP fill [Rodrigo Vivi], added W/A space to reserved amount and updated code comments [Dave Gordon], v4: Made #define for WA_RAIL_DWORDS a function-type macro in case we want different values

Re: [Intel-gfx] [PATCH v5] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

On 25/02/16 10:05, Chris Wilson wrote: On Wed, Feb 24, 2016 at 10:02:58AM +, Dave Gordon wrote: @@ -907,7 +942,8 @@ int intel_logical_ring_reserve_space(struct drm_i915_gem_request *request) * adding any commands to it then there might not actually be * sufficient room

Re: [Intel-gfx] [PATCH] drm/i915/guc: Support GuC SKL v6.1

full. Signed-off-by: Alex Dai Hi Alex, I heard a rumour that GuC 6.1 required a change to the driver interface? If you can confirm that this is not so, then I'm happy with this, so: Reviewed-by: Dave Gordon Also: GuC 6.1 has no known outstanding bugs to be fixed, so this would be a r

[Intel-gfx] [PATCH] drm/i915: add enable_guc_loading parameter

are), and to fall back to execlist mode if any required firmware cannot be found or fails to load. Signed-off-by: Dave Gordon Reviewed-by: Alex Dai --- drivers/gpu/drm/i915/i915_gem.c | 1 - drivers/gpu/drm/i915/i915_params.c | 14 - drivers/gpu/drm/i915/i915_params.h | 3

[Intel-gfx] [PATCH v5 3/7] drm/i915: introduce and use i915_gem_object_vmap_range()

l page count required. [Tvrtko Ursulin] v4: renamed to i915_gem_object_vmap_range() to make its function clearer. [Dave Gordon] v5: use Chris Wilson's new drm_malloc_gfp() rather than kmalloc() or drm_malloc_ab(). [Dave Gordon] Signed-off-by: Alex Dai Signed-off-by: Dave Gordon

[Intel-gfx] [PATCH v5 0/7] Reorganise calls to vmap() GEM objects

[Tvrtko Ursulin]. Potentially, the vunmap() could be moved back to the put_pages() stage (thus extending the cache lifetime) if a suitable notifier were written, but that's not included here. Signed-off-by: Dave Gordon Cc: Alex Dai Cc: Chris Wilson Cc: Tvrtko Ursulin Cc:

[Intel-gfx] [PATCH v5 4/7] drm/i915: optimise i915_gem_object_vmap_range() for small objects

er (4 pages) or a context image (currently up to 22 pages). v5: change name of local array [Chris Wilson] Signed-off-by: Dave Gordon Cc: Tvrtko Ursulin Cc: Alex Dai Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-)

[Intel-gfx] [PATCH v5 5/7] drm/i915: move locking in i915_gem_unmap_dma_buf()

uplicate object vmap functions in preparation for the reimplementation of the same. Signed-off-by: Dave Gordon Cc: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c

[Intel-gfx] [PATCH v5 2/7] drm: add parameter-order checking to drm memory allocators

ome compile-time checks and complain if the second (size) parameter isn't a sizeof() expression, or at least a compile-time constant. This patch also fixes those callers where the order was wrong. Signed-off-by: Dave Gordon Cc: Chris Wilson Cc: Ville Syrjälä Cc: dri- Cc: dri-d

[Intel-gfx] [PATCH v5 7/7] drm/i915: refactor duplicate object vmap functions (reworked some more)

could be deferred until the put_pages() stage if a suitable notifier were written, but we're not doing that here. Nonetheless, the simplification of both dmabuf and ringbuffer code makes it worthwhile in its own right. With this change, we have only one vmap() in the whole driver :)

[Intel-gfx] [PATCH v5 1/7] drm,i915: introduce drm_malloc_gfp()

: dri-de...@lists.freedesktop.org Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Acked-by: Dave Airlie Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +++- drivers/gpu/drm/i915/i915_gem_gtt.c| 5 +++-- drivers/gpu/drm/i915/i915_gem_userptr.c| 15

[Intel-gfx] [PATCH v5 6/7] drm/i915: deduplicate intel_pin_and_map_ringbuffer_obj() error handling

Signed-off-by: Dave Gordon Cc: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 4

Re: [Intel-gfx] [PATCH v5 7/7] drm/i915: refactor duplicate object vmap functions (reworked some more)

On 29/02/16 12:36, Tvrtko Ursulin wrote: On 29/02/16 11:13, Dave Gordon wrote: This is essentially Chris Wilson's patch of a similar name, reworked on top of Alex Dai's recent patch: drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space Chris' original commen

[Intel-gfx] [PATCH v6 5/7] drm/i915: move locking in i915_gem_unmap_dma_buf()

uplicate object vmap functions in preparation for the reimplementation of the same. Signed-off-by: Dave Gordon Reviewed-by: Tvrtko Ursulin Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_

[Intel-gfx] [PATCH v6 4/7] drm/i915: optimise i915_gem_object_vmap_range() for small objects

er (4 pages) or a context image (currently up to 22 pages). v5: change name of local array [Chris Wilson] Signed-off-by: Dave Gordon Reviewed-by: Tvrtko Ursulin Cc: Chris Wilson Cc: Alex Dai --- drivers/gpu/drm/i915/i915_gem.c | 17 +++-- 1 file changed, 11 insertions(+), 6 d

[Intel-gfx] [PATCH v6 2/7] drm: add parameter-order checking to drm memory allocators

em with #defines and then calling the function (non-recursively!) from inside the #define [Chris Wilson] Signed-off-by: Dave Gordon Cc: Chris Wilson Cc: Ville Syrjälä Cc: dri- Cc: dri-de...@lists.freedesktop.org --- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +- drivers/gpu/drm/i915/i915_gem_e

[Intel-gfx] [PATCH v6 6/7] drm/i915: deduplicate intel_pin_and_map_ringbuffer_obj() error handling

Signed-off-by: Dave Gordon Reviewed-by: Tvrtko Ursulin Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_ringbuffer.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.

[Intel-gfx] [PATCH v6 3/7] drm/i915: introduce and use i915_gem_object_vmap_range()

l page count required. [Tvrtko Ursulin] v4: renamed to i915_gem_object_vmap_range() to make its function clearer. [Dave Gordon] v5: use Chris Wilson's new drm_malloc_gfp() rather than kmalloc() or drm_malloc_ab(). [Dave Gordon] v6: changed range checking to not use pages->nents. [

[Intel-gfx] [PATCH v6 1/7] drm,i915: introduce drm_malloc_gfp()

: dri-de...@lists.freedesktop.org Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Acked-by: Dave Airlie Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +++- drivers/gpu/drm/i915/i915_gem_gtt.c| 5 +++-- drivers/gpu/drm/i915/i915_gem_userptr.c| 15

[Intel-gfx] [PATCH v6 0/7] Reorganise calls to vmap() GEM objects

i915_gem_object_vmap_range() now takes a range in bytes rather than pages, so we use sg_nents_for_len() to validate it against the actual scatterlist. Signed-off-by: Dave Gordon Cc: Alex Dai Cc: Chris Wilson Cc: Tvrtko Ursulin Cc: Daniel Vetter Alex Dai (1): drm/i915: introduce an

[Intel-gfx] [PATCH v6 7/7] drm/i915: refactor duplicate object vmap functions (reworked again)

the put_pages() stage if a suitable notifier were written, but we're not doing that here. Nonetheless, the simplification of both dmabuf and ringbuffer code makes it worthwhile in its own right. v6: change BUG_ON() to WARN_ON(). [Tvrtko Ursulin] Signed-off-by: Dave Gordon Reviewed-

Re: [Intel-gfx] [PATCH v6 3/7] drm/i915: introduce and use i915_gem_object_vmap_range()

On 01/03/16 10:12, Tvrtko Ursulin wrote: On 29/02/16 21:16, Dave Gordon wrote: From: Alex Dai There are several places inside driver where a GEM object is mapped to kernel virtual space. The mapping may be done either for the whole object or only a subset of it. This patch introduces a

[Intel-gfx] [PATCH v7 7/7] drm: add parameter-order checking to drm memory allocators

em with #defines and then calling the function (non-recursively!) from inside the #define [Chris Wilson] Signed-off-by: Dave Gordon Cc: Chris Wilson Cc: Ville Syrjälä Cc: dri- Cc: dri-de...@lists.freedesktop.org --- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +- drivers/gpu/drm/i915/i915_gem_e

[Intel-gfx] [PATCH v7 5/7] drm/i915: optimise i915_gem_object_vmap_range() for small objects

er (4 pages) or a context image (currently up to 22 pages). v5: change name of local array [Chris Wilson] Signed-off-by: Dave Gordon Reviewed-by: Tvrtko Ursulin Cc: Chris Wilson Cc: Alex Dai --- drivers/gpu/drm/i915/i915_gem.c | 17 +++-- 1 file changed, 11 insertions(+), 6 d

[Intel-gfx] [PATCH v7 3/7] drm,i915: introduce drm_malloc_gfp()

: dri-de...@lists.freedesktop.org Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Acked-by: Dave Airlie Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +++- drivers/gpu/drm/i915/i915_gem_gtt.c| 5 +++-- drivers/gpu/drm/i915/i915_gem_userptr.c| 15

[Intel-gfx] [PATCH v7 0/7] Reorganise calls to vmap() GEM objects

;. Reordered patch sequence, with the most local changes first and the optional ones at the end. Signed-off-by: Dave Gordon Cc: Alex Dai Cc: Chris Wilson Cc: Tvrtko Ursulin Cc: Daniel Vetter Alex Dai (1): drm/i915: introduce and use i915_gem_object_vmap_range() Chris Wilson (3): d

[Intel-gfx] [PATCH v7 4/7] drm/i915: introduce and use i915_gem_object_vmap_range()

l page count required. [Tvrtko Ursulin] v4: renamed to i915_gem_object_vmap_range() to make its function clearer. [Dave Gordon] v5: use Chris Wilson's new drm_malloc_gfp() rather than kmalloc() or drm_malloc_ab(). [Dave Gordon] v6: changed range checking to not use pages->nents. [

[Intel-gfx] [PATCH v7 2/7] drm/i915: move locking in i915_gem_unmap_dma_buf()

uplicate object vmap functions in preparation for the reimplementation of the same. Signed-off-by: Dave Gordon Reviewed-by: Tvrtko Ursulin Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_

[Intel-gfx] [PATCH v7 6/7] drm/i915: refactor duplicate object vmap functions (the final rework?)

the put_pages() stage if a suitable notifier were written, but we're not doing that here. Nonetheless, the simplification of both dmabuf and ringbuffer code makes it worthwhile in its own right. v6: change BUG_ON() to WARN_ON(). [Tvrtko Ursulin] Signed-off-by: Dave Gordon Reviewed-

[Intel-gfx] [PATCH v7 1/7] drm/i915: deduplicate intel_pin_and_map_ringbuffer_obj() error handling

Signed-off-by: Dave Gordon Reviewed-by: Tvrtko Ursulin Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_ringbuffer.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Reorganise calls to vmap() GEM objects (rev5)

On 02/03/16 06:54, Patchwork wrote: == Series Details == Series: Reorganise calls to vmap() GEM objects (rev5) URL : https://patchwork.freedesktop.org/series/3688/ State : warning All of the issues below are known and unrelated to the patchset == Summary == Series 3688v5 Reorganise calls

Re: [Intel-gfx] [PATCH v7 6/7] drm/i915: refactor duplicate object vmap functions (the final rework?)

On 02/03/16 12:08, Chris Wilson wrote: On Tue, Mar 01, 2016 at 04:33:58PM +, Dave Gordon wrote: This is essentially Chris Wilson's patch of a similar name, reworked on top of Alex Dai's recent patch: | drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space Chris

Re: [Intel-gfx] [PATCH i-g-t 1/4] lib/igt_bb_factory: Add igt_bb_factory library

On 02/03/16 18:08, Morton, Derek J wrote: The CMD parser blacklists the TIMESTAMP register on gen 7.5 so I will leave this as requiring gen8+ //Derek You might still be able to store its value (to memory or the PPHWSP?) using a PIPE_CONTROL or MI_FLUSH_DW instruction rather than accessing

Re: [Intel-gfx] [PATCH i-g-t v2 2/7] lib/ioctl_wrappers: Separate ring BSD1 from BSD2 checks

On 02/03/16 18:10, Derek Morton wrote: Some platforms have ring BSD available but no BSD2. Because of the current verification, tests involving ring BSD1 will be skipped if no BSD2 is available. Decoupling the checks will allow running the BSD1 specific tests on these platforms. Based on a patc

Re: [Intel-gfx] [PATCH i-g-t v2 2/7] lib/ioctl_wrappers: Separate ring BSD1 from BSD2 checks

On 07/03/16 11:56, Dave Gordon wrote: On 02/03/16 18:10, Derek Morton wrote: Some platforms have ring BSD available but no BSD2. Because of the current verification, tests involving ring BSD1 will be skipped if no BSD2 is available. Decoupling the checks will allow running the BSD1 specific

Re: [Intel-gfx] [PATCH i-g-t v2 4/7] tests/gem_scheduler: Add gem_scheduler test

On 02/03/16 20:15, Chris Wilson wrote: +static struct ring { + const char *name; + int id; + bool exists; +} rings[] = { + { "render", I915_EXEC_RENDER, false }, + { "bsd1",I915_EXEC_BSD | 1<<13, false }, + { "bsd2",I915_EXEC_BSD | 2<<13, false }, Thi

Re: [Intel-gfx] [maintainer-tools PATCH] drm-intel: Add note about patches that move code between files

On 09/03/16 11:46, Ander Conselvan de Oliveira wrote: Patches that move big chunks of code between files can cause some complicated conflicts. Add a note to coordinate with maintainers before merging such patches. Signed-off-by: Ander Conselvan de Oliveira --- drm-intel.rst | 4 1 file

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Mark obj->mapping as dirtying the backing storage

On 12/04/16 16:18, Chris Wilson wrote: On Tue, Apr 12, 2016 at 02:32:31PM +0100, Chris Wilson wrote: When reviewing some of Tvrtko's usage for i915_gem_object_pin_map(), he suggested replacing some use of kmap(i915_gem_object_get_dirty_page()) with a plain i915_gem_object_pin_map(). This raised

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Mark obj->mapping as dirtying the backing storage

On 12/04/16 16:18, Chris Wilson wrote: On Tue, Apr 12, 2016 at 02:32:31PM +0100, Chris Wilson wrote: When reviewing some of Tvrtko's usage for i915_gem_object_pin_map(), he suggested replacing some use of kmap(i915_gem_object_get_dirty_page()) with a plain i915_gem_object_pin_map(). This raised

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Simplify i915_gem_obj_ggtt_bound_view

t;vma_list, obj_link) - if (vma->vm == &ggtt->base && + if (vma->is_ggtt && i915_ggtt_view_equal(&vma->ggtt_view, view) && drm_mm_node_allocated(&vma->node))

Re: [Intel-gfx] [PATCH] lib: Always NUL terminate ucs2_as_utf8

On 21/04/16 16:13, Peter Jones wrote: On Thu, Apr 21, 2016 at 01:18:27PM +0100, Matt Fleming wrote: ( Good Lord, I hate doing string manipulation in C ) (yep) On Wed, 20 Apr, at 03:25:32PM, Laszlo Ersek wrote: So, "len" does not include the room for the terminating NUL-byte here. When "le

Re: [Intel-gfx] [PATCH] drm/i915: Propagate error from drm_gem_object_init()

On 22/04/16 11:57, Matthew Auld wrote: From: Chris Wilson Propagate the real error from drm_gem_object_init(). Note this also fixes some confusion in the error return from i915_gem_alloc_object... v2: (Matthew Auld) - updated new users of gem_alloc_object from latest drm-nightly - replac

[Intel-gfx] [PATCH] drm/i915: rename i915_gem_alloc_object() to i915_gem_object_create()

-allocated object.) Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/i915_gem.c | 6 +++--- drivers/gpu/drm/i915/i915_gem_batch_pool.c | 2 +- drivers/gpu/drm/i915/i915_gem_context.c | 2 +- drivers/gpu/drm/i915

[Intel-gfx] [PATCH 2/2] drm/i915/guc: default to using GuC submission where possible

y of these conditions are not met, the driver will fall back to using execlist mode. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c ind

[Intel-gfx] [PATCH 1/2] drm/i915/guc: add enable_guc_loading parameter

2 REQUIRE must load/use the GuC, else leave the GPU wedged The new platform default (as coded here) will be to attempt to load the GuC iff the device has a GuC that requires firmware, but not yet to use it for submission. A later patch will change to enable it if appropriate. Signed-off-by:

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: default to using GuC submission where possible

On 22/04/16 19:51, Chris Wilson wrote: On Fri, Apr 22, 2016 at 07:45:15PM +0100, Chris Wilson wrote: On Fri, Apr 22, 2016 at 07:22:55PM +0100, Dave Gordon wrote: This patch simply changes the default value of "enable_guc_submission" from 0 (never) to -1 (auto). This means that GuC

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: rename i915_gem_alloc_object() to i915_gem_object_create()

On 24/04/16 10:23, Patchwork wrote: == Series Details == Series: drm/i915: rename i915_gem_alloc_object() to i915_gem_object_create() URL : https://patchwork.freedesktop.org/series/6183/ State : warning == Summary == Series 6183v1 drm/i915: rename i915_gem_alloc_object() to i915_gem_object_

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/4] drm/i915: Remove i915_gem_obj_size

On 23/04/16 16:58, Patchwork wrote: == Series Details == Series: series starting with [1/4] drm/i915: Remove i915_gem_obj_size URL : https://patchwork.freedesktop.org/series/6060/ State : warning == Summary == Series 6060v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: default to using GuC submission where possible

On 22/04/16 19:45, Chris Wilson wrote: On Fri, Apr 22, 2016 at 07:22:55PM +0100, Dave Gordon wrote: This patch simply changes the default value of "enable_guc_submission" from 0 (never) to -1 (auto). This means that GuC submission will be used if the platform has a GuC, the GuC su

[Intel-gfx] [PATCH 2/4] CI_ONLY: change default to using GuC submission if possible

y of these conditions are not met, the driver will fall back to using execlist mode. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c ind

[Intel-gfx] [PATCH 4/4] CI_ONLY: DO NOT MERGE: WARN on GuC WQ full

Let's try not waiting for the GuC WQ to be not-full, but instead * count how many times this happens * print a WARNING, at least sometimes * return -EAGAIN and see whether the GuC is ever a bottleneck for submission. .Dave. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_debu

[Intel-gfx] [PATCH 3/4] CI_ONLY: pass request (not client) to i915_guc_wq_check_space()

The knowledge of how to derive the relevant client from the request should be localised within i915_guc_submission.c; the LRC code shouldn't have to know about the internal details of the GuC submission process. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.

[Intel-gfx] [PATCH 1/4] CI_ONLY: add enable_guc_loading parameter

EQUIRE must load/use the GuC, else leave the GPU wedged The new platform default (as coded here) will be to attempt to load the GuC iff the device has a GuC that requires firmware, but not yet to use it for submission. A later patch will change to enable it if appropriate. Signed-off-by: Dave

Re: [Intel-gfx] [PATCH v3 13/21] drm/i915: Replace the pinned context address with its unique ID

On 24/04/16 19:10, Chris Wilson wrote: Rather than reuse the current location of the context in the global GTT for its hardware identifier, use the context's unique ID assigned to it for its whole lifetime. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin Hmmm I wonder whether this wi

Re: [Intel-gfx] [PATCH v3 13/21] drm/i915: Replace the pinned context address with its unique ID

On 25/04/16 16:48, Chris Wilson wrote: On Mon, Apr 25, 2016 at 04:21:58PM +0100, Dave Gordon wrote: On 24/04/16 19:10, Chris Wilson wrote: Rather than reuse the current location of the context in the global GTT for its hardware identifier, use the context's unique ID assigned to it fo

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: default to using GuC submission where possible

On 25/04/16 11:39, Chris Wilson wrote: On Mon, Apr 25, 2016 at 11:07:13AM +0100, Dave Gordon wrote: On 22/04/16 19:45, Chris Wilson wrote: On Fri, Apr 22, 2016 at 07:22:55PM +0100, Dave Gordon wrote: This patch simply changes the default value of "enable_guc_submission" >from 0

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: default to using GuC submission where possible

On 26/04/16 09:49, Dave Gordon wrote: On 25/04/16 11:39, Chris Wilson wrote: On Mon, Apr 25, 2016 at 11:07:13AM +0100, Dave Gordon wrote: On 22/04/16 19:45, Chris Wilson wrote: [snip] And what exactly is that atomic64_cmpxchg() serialising with? There are no other CPUs contending with the

Re: [Intel-gfx] [PATCH] drm/i915: In render_state_init reset obj in teardown path

ume that; it should leave everything in a consistent state so there aren't any dangling pointers to objects that have been freed lying around - someday the argument may turn into a per-engine static or some other long-lived thing. So, Reviewed-by: Dave Gordon _

Re: [Intel-gfx] [RFC 3/3] drm/i915: Micro-optimize i915_gem_obj_to_vma

On 21/04/16 13:05, Tvrtko Ursulin wrote: From: Tvrtko Ursulin i915_gem_obj_to_vma is one of the most expensive functions in our profiles. Could avoiding some branching by replacing it with arithmetic be beneficial? Some benchmarks suggest it slightly might. Signed-off-by: Tvrtko Ursulin ---

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: default to using GuC submission where possible

On 26/04/16 11:35, Chris Wilson wrote: On Tue, Apr 26, 2016 at 10:52:41AM +0100, Dave Gordon wrote: On 26/04/16 09:49, Dave Gordon wrote: On 25/04/16 11:39, Chris Wilson wrote: On Mon, Apr 25, 2016 at 11:07:13AM +0100, Dave Gordon wrote: On 22/04/16 19:45, Chris Wilson wrote: [snip] And

Re: [Intel-gfx] [PATCH 1/4] CI_ONLY: add enable_guc_loading parameter

On 26/04/16 15:18, Daniel Vetter wrote: On Mon, Apr 25, 2016 at 03:37:11PM +0100, Dave Gordon wrote: Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware ima

Re: [Intel-gfx] Kernel Oops on 3.14.66

drm_i915_gem_request->list.prev or ->list.next. Thank you Andreas Try this patch. .Dave. >From 6dde6b8b07239c68f32315faffa9d80b6e2d0aec Mon Sep 17 00:00:00 2001 From: Dave Gordon Date: Fri, 22 Apr 2016 19:33:53 +0100 Subject: [PATCH] Request constructor should initialise list head Org

Re: [Intel-gfx] [PATCH] drm/i915: tidy up gen8_init_scratch

On 26/04/16 10:27, Matthew Auld wrote: Use goto teardown path and also ensure we reset any struct members which would otherwise contain an error encoded pointer, and could be mistaken for a valid address. Cc: Joonas Lahtinen Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: default to using GuC submission where possible

On 26/04/16 15:00, Daniel Vetter wrote: On Mon, Apr 25, 2016 at 09:29:42AM +0100, Chris Wilson wrote: On Mon, Apr 25, 2016 at 08:31:07AM +0100, Dave Gordon wrote: On 22/04/16 19:51, Chris Wilson wrote: On Fri, Apr 22, 2016 at 07:45:15PM +0100, Chris Wilson wrote: On Fri, Apr 22, 2016 at 07

[Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter

le 2 REQUIRE must load/use the GuC, else leave the GPU wedged The new platform default (as coded here) will be to attempt to load the GuC iff the device has a GuC that requires firmware, but not yet to use it for submission. A later patch will change to enable it if appropriate. S

[Intel-gfx] [PATCH v2 2/5] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

hable from) the request. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 11 ++- drivers/gpu/drm/i915/intel_guc.h | 5 ++--- drivers/gpu/drm/i915/intel_lrc.c | 9 +++-- 3 files changed, 11 insertions(+), 14 deletions(-) diff --git a/dr

[Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

o see how often we find the WQ full. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_debugfs.c| 1 + drivers/gpu/drm/i915/i915_guc_submission.c | 16 +--- drivers/gpu/drm/i915/intel_guc.h | 8 3 files changed, 10 insertions(+), 15 deletions(-)

[Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

y Chris Wilson, and update the calling code appropriately. Signed-off-by: Dave Gordon Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_guc_submission.c | 69 +++--- drivers/gpu/drm/i915/intel_guc.h | 2 +- drivers/gpu/drm/i915/intel_guc_fwif.h | 3 +- 3 files

[Intel-gfx] [PATCH v2 5/5] DO NOT MERGE: change default to using GuC submission if possible

y of these conditions are not met, the driver will fall back to using execlist mode. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c ind

Re: [Intel-gfx] Kernel Oops on 3.14.66

2016-04-27 12:03 GMT+02:00 Dave Gordon : On 27/04/16 10:19, Andreas Lampersperger wrote: Hello, has anyone here a hint for me, what can cause this error. The error occures highly sporadic on different machines with intel hd graphics (ivb_gt1). I did also some kernel coredumps and found out

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

On 27/04/16 15:53, Chris Wilson wrote: On Wed, Apr 27, 2016 at 04:25:09PM +0300, Eero Tamminen wrote: Hi, On 26.04.2016 20:25, Frederick, Michael T wrote: Sorry I'm not tracking all the MOCs discussions. I just want to indicate what the coherency means in SoC for BXT. GTI sets the non-inclu

Re: [Intel-gfx] [CI-ping 15/15] drm/i915: Late request cancellations are harmful

On 22/04/16 23:57, John Harrison wrote: On 21/04/2016 14:04, John Harrison wrote: On 19/04/2016 13:35, Dave Gordon wrote: On 13/04/16 15:21, John Harrison wrote: On 13/04/2016 10:57, Daniel Vetter wrote: On Tue, Apr 12, 2016 at 09:03:09PM +0100, Chris Wilson wrote: Conceptually, each

Re: [Intel-gfx] [PATCH] drm/i915: Validate execbuffer start/length arguments against the target bo

On 28/04/16 10:02, Chris Wilson wrote: On Thu, Apr 28, 2016 at 11:54:04AM +0300, Jani Nikula wrote: On Thu, 28 Apr 2016, Jani Nikula wrote: On Fri, 20 Nov 2015, Ville Syrjälä wrote: On Fri, Nov 20, 2015 at 03:11:04PM +, Chris Wilson wrote: The offset within and the length of the command

Re: [Intel-gfx] Kernel Oops on 3.14.66

On 28/04/16 09:58, Andreas Lampersperger wrote: Hi Dave, thank you again. I searched, where the memory for the request came from, it is set in line 2158 of i915_gem.c

Re: [Intel-gfx] [CI 13/25] drm/i915: Remove the identical implementations of request space reservation

On 28/04/16 09:56, Chris Wilson wrote: Now that we share intel_ring_begin(), reserving space for the tail of the request is identical between legacy/execlists and so the tautology can be removed. In the process, we move the reserved space tracking from the ringbuffer on to the request. This is to

Re: [Intel-gfx] [CI 14/25] drm/i915: Manually unwind after a failed request allocation

On 28/04/16 09:56, Chris Wilson wrote: In the next patches, we want to move the work out of freeing the request and into its retirement (so that we can free the request without requiring the struct_mutex). This means that we cannot rely on unreferencing the request to completely teardown the requ

Re: [Intel-gfx] [CI 17/25] drm/i915: Assign every HW context a unique ID

On 28/04/16 09:56, Chris Wilson wrote: The hardware tracks contexts and expects all live contexts (those active on the hardware) to have a unique identifier. This is used by the hardware to assign pagefaults and the like to a particular context. v2: Reorder to make sure ctx->link is not left dan

Re: [Intel-gfx] [CI 18/25] drm/i915: Replace the pinned context address with its unique ID

On 28/04/16 09:56, Chris Wilson wrote: Rather than reuse the current location of the context in the global GTT for its hardware identifier, use the context's unique ID assigned to it for its whole lifetime. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Refactor common engine setup

On 28/04/16 14:47, Chris Wilson wrote: Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible for later use during initialisation. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- I'm not too happy

[Intel-gfx] [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty()

intel_pin_and_map_ringbuffer_obj() should have been setting the dirty flag, but wasn't; and the LRC code in intel_lr_context_do_pin() is also updated to use the new function. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/intel_lrc.c| 10 +- drivers/gpu/drm

[Intel-gfx] [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()

Wilson Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_drv.h| 11 +++ drivers/gpu/drm/i915/i915_gem.c| 6 +++--- drivers/gpu/drm/i915/i915_gem_context.c| 2 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +- drivers/gpu/drm/i915/intel_lrc.c

Re: [Intel-gfx] [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty()

On 28/04/16 17:36, Chris Wilson wrote: On Thu, Apr 28, 2016 at 05:26:21PM +0100, Dave Gordon wrote: intel_pin_and_map_ringbuffer_obj() should have been setting the dirty flag, but wasn't; and the LRC code in intel_lr_context_do_pin() is also updated to use the new function. Technical

Re: [Intel-gfx] [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()

On 28/04/16 17:34, Chris Wilson wrote: On Thu, Apr 28, 2016 at 05:26:20PM +0100, Dave Gordon wrote: This just hides the existing obj->dirty flag inside a trivial inline setter, to discourage non-GEM code from looking too closely. Existing code that sets obj->dirty is then changed to u

<    1   2   3   4   5   6   7   8   9   10   >