From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 07/22] drm/i915: Refactor execbuffer relocation writing
Date: Wed, 17 Aug 2016 11:47:07 +0300 [thread overview]
Message-ID: <1471423627.3613.19.camel@linux.intel.com> (raw)
In-Reply-To: <1471344168-28136-8-git-send-email-chris@chris-wilson.co.uk>
On ti, 2016-08-16 at 11:42 +0100, Chris Wilson wrote:
> @@ -278,6 +283,9 @@ static void eb_destroy(struct eb_vmas *eb)
>
> static inline int use_cpu_reloc(struct drm_i915_gem_object *obj)
> {
> + if (DBG_USE_CPU_RELOC)
> + return DBG_USE_CPU_RELOC > 0;
If DBG_USE_CPU_RELOC == 0, this path is never taken. So it would have
to be set at -1 to yield false. Unexpected when defining it. 0 and 1 is
the de facto. So drop a comment at defining site.
> +#define KMAP 0x4
At least make a comment that CLFLUSH_AFTER and CLFLUSH_BEFORE are also
in the flag set.
> +
> static void reloc_cache_fini(struct reloc_cache *cache)
> {
> + void *vaddr;
> +
> if (!cache->vaddr)
> return;
>
> - switch (cache->type) {
> - case KMAP:
> - kunmap_atomic(cache->vaddr);
> - break;
> + vaddr = unmask_page(cache->vaddr);
> + if (cache->vaddr & KMAP) {
> + if (cache->vaddr & CLFLUSH_AFTER)
> + mb();
>
> - case IOMAP:
> - io_mapping_unmap_atomic(cache->vaddr);
> - break;
> + kunmap_atomic(vaddr);
> + i915_gem_object_unpin_pages((struct drm_i915_gem_object *)cache->node.mm);
I'd prefer i915_gem_obj_cleanup_shmem_write() for symmetry or a comment
here.
> + } else {
> + io_mapping_unmap_atomic(vaddr);
> + i915_vma_unpin((struct i915_vma *)cache->node.mm);
This does have a clear counterpart.
> - clflush_write32(vaddr + page_offset, lower_32_bits(delta));
> + clflush_write32(vaddr + offset_in_page(offset),
> + lower_32_bits(target_offset),
> + cache->vaddr);
unmap_flags(cache->vaddr) for clarity
This could use another set of eyes, the patch is horribly mangled.
But with my eyes, with couple of comments added;
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-08-17 8:47 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-16 10:42 An almost complete set of reviewed patches for tiled partial Chris Wilson
2016-08-16 10:42 ` [PATCH 01/22] drm/i915: Cache kmap between relocations Chris Wilson
2016-08-16 10:42 ` [PATCH 02/22] drm/i915: Extract i915_gem_obj_prepare_shmem_write() Chris Wilson
2016-08-16 10:42 ` [PATCH 03/22] drm/i915: Before accessing an object via the cpu, flush GTT writes Chris Wilson
2016-08-16 10:42 ` [PATCH 04/22] drm/i915: Wait for writes through the GTT to land before reading back Chris Wilson
2016-08-16 10:42 ` [PATCH 05/22] drm/i915: Pin the pages first in shmem prepare read/write Chris Wilson
2016-08-16 11:57 ` Joonas Lahtinen
2016-08-16 12:02 ` Chris Wilson
2016-08-16 12:46 ` Joonas Lahtinen
2016-08-16 10:42 ` [PATCH 06/22] drm/i915: Tidy up flush cpu/gtt write domains Chris Wilson
2016-08-16 10:42 ` [PATCH 07/22] drm/i915: Refactor execbuffer relocation writing Chris Wilson
2016-08-17 8:47 ` Joonas Lahtinen [this message]
2016-08-17 8:57 ` Chris Wilson
2016-08-17 9:26 ` Joonas Lahtinen
2016-08-16 10:42 ` [PATCH 08/22] drm/i915: Fallback to single page GTT mmappings for relocations Chris Wilson
2016-08-17 7:19 ` Joonas Lahtinen
2016-08-17 7:57 ` Chris Wilson
2016-08-16 10:42 ` [PATCH 09/22] drm/i915: Disallow direct CPU access to stolen pages " Chris Wilson
2016-08-16 11:49 ` Joonas Lahtinen
2016-08-16 10:42 ` [PATCH 10/22] drm/i915: Move map-and-fenceable tracking to the VMA Chris Wilson
2016-08-16 10:42 ` [PATCH 11/22] drm/i915: Allow ringbuffers to be bound anywhere Chris Wilson
2016-08-16 12:52 ` Joonas Lahtinen
2016-08-16 10:42 ` [PATCH 12/22] drm/i915: Allocate rings from stolen Chris Wilson
2016-08-16 11:47 ` Joonas Lahtinen
2016-08-16 10:42 ` [PATCH 13/22] drm/i915/userptr: Make gup errors stickier Chris Wilson
2016-08-16 10:42 ` [PATCH 14/22] drm/i915: Rename fence.lru_list to link Chris Wilson
2016-08-16 11:39 ` Joonas Lahtinen
2016-08-16 10:42 ` [PATCH 15/22] drm/i915: Move fence tracking from object to vma Chris Wilson
2016-08-16 11:38 ` Joonas Lahtinen
2016-08-16 10:42 ` [PATCH 16/22] drm/i915: Choose partial chunksize based on tile row size Chris Wilson
2016-08-16 10:42 ` [PATCH 17/22] drm/i915: Fix partial GGTT faulting Chris Wilson
2016-08-16 10:42 ` [PATCH 18/22] drm/i915: Choose not to evict faultable objects from the GGTT Chris Wilson
2016-08-16 11:31 ` Joonas Lahtinen
2016-08-16 11:46 ` Chris Wilson
2016-08-16 10:42 ` [PATCH 19/22] drm/i915: Fallback to using unmappable memory for scanout Chris Wilson
2016-08-16 10:42 ` [PATCH 20/22] drm/i915: Track display alignment on VMA Chris Wilson
2016-08-16 10:42 ` [PATCH 21/22] drm/i915: Bump the inactive tracking for all VMA accessed Chris Wilson
2016-08-16 11:20 ` Joonas Lahtinen
2016-08-16 10:42 ` [PATCH 22/22] drm/i915: Stop discarding GTT cache-domain on unbind vma Chris Wilson
2016-08-16 11:25 ` ✗ Ro.CI.BAT: failure for series starting with [01/22] drm/i915: Cache kmap between relocations Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1471423627.3613.19.camel@linux.intel.com \
--to=joonas.lahtinen@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox